βοΈ Cloud Rightsizing: Scaling Down to Scale Smart
Hey Cloud Architects! π
Welcome to Day 7 of the #100DaysOfCloud Challenge: Change EC2 Instance Type! As the Nautilus DevOps team continues their migration, theyβve hit a common scenario: over-provisioning. After monitoring their resources via KodeKloud Engineer, they realized one server wasn't doing much work.
Today, we are performing Rightsizing changing our nautilus-ec2 instance from a t2.micro to a smaller, more cost-effective t2.nano.
1. Introduction: What is Rightsizing? π‘
In the cloud, you pay for what you provision. If you have a large server running a tiny task, you are wasting money.
- Rightsizing: The process of matching instance types and sizes to your workload performance and capacity requirements at the lowest possible cost.
- Vertical Scaling: Changing an instance type is a form of vertical scaling. We are essentially changing the "hardware" specs (CPU/RAM) of our virtual server.
- Important Requirement: You cannot change an instance type while the server is running. It must be Stopped first.
2. Step-by-Step Guide: Scaling Down nautilus-ec2
Before we start, ensure the instance has finished its "Initializing" phase and shows 2/2 status checks passed.
Step 2.1: Stop the Instance
You cannot change the engine of a car while it's driving! We must shut down the instance first.
- Log in to the AWS Console and navigate to the EC2 Dashboard.
- Click on "Instances".
- Select the nautilus-ec2 instance.
- Click "Instance state" and select "Stop instance".
- Confirm by clicking "Stop". Wait until the instance state shows π΄ Stopped.
Step 2.2: Change the Instance Type
Once the instance is stopped, the "Change instance type" option becomes available.
- With the instance still selected, click the "Actions" button.
- Navigate to "Instance settings" -> "Change instance type".
- In the dropdown, search for and select
t2.nano.
- Click "Apply".
Step 2.3: Restart the Instance
Now that we've swapped the "hardware," let's turn the server back on.
- With nautilus-ec2 selected, click "Instance state".
- Select "Start instance".
Step 2.4: Verify the Change
- Wait for the instance state to return to π’ Running.
- Check the "Instance type" column in your dashboard. It should now proudly display
t2.nano. - Ensure Status checks pass again.
3. Key Takeaways π
- Downtime is Required: Changing an instance type requires stopping the instance, which means a brief period of downtime.
- Vertical Scaling: This is the easiest way to handle a server that is either struggling (scale up) or underutilized (scale down).
- Compatibility: Ensure your AMI (Amazon Machine Image) and virtualization type are compatible with the new instance family you are moving to.
4. Common Mistakes to Avoid π«
- Forgetting to Stop: Youβll find the "Change instance type" option greyed out if the instance is still running.
- Public IP Change: Warning! If you are NOT using an Elastic IP, stopping and starting your instance will change its Public IP address. This is why our previous task of allocating an EIP was so important!
- Ignoring Status Checks: Never perform maintenance on an instance that is still "Initializing" or failing health checks.
5. Conclusion + Call to Action! π
Rightsizing is a superpower for DevOps engineers. By moving to a t2.nano, the Nautilus team is optimizing their cloud spend without sacrificing the performance needed for that specific task.
Are you keeping up with the 100 Days of Cloud Challenge?
- π¬ Letβs connect on LinkedIn: Let's discuss cloud cost optimization! π Hritik Raj
- β Support my journey on GitHub: Check out the logs for this task and more. π GitHub β 100 Days of Cloud














Top comments (0)