Ravindra BagaleCourses & study guides

Chapter 14: EC2 Operations — Elastic IP, AMI, Snapshots and Vertical Scaling

14.4 Vertical scaling: changing the instance type

By Last updated:

Scale up vs scale out

Vertical scaling (scale up/down) Horizontal scaling (scale out/in)
What Make one server bigger/smaller (more vCPU/RAM) Add/remove more servers of the same size
AWS way Change instance type (e.g. t3.micro → t3.medium) Auto Scaling group (ASG) behind an Elastic Load Balancer (ELB)
Downtime Yes — stop/start needed No — instances added/removed while running
Limit Largest instance size available Practically unlimited
Best for Single servers, databases, quick fixes, labs Stateless web/app tiers, high availability, variable traffic

Think of a busy dosa stall: vertical scaling is buying a bigger tawa for the same cook; horizontal scaling is opening two more counters with more cooks. Technically, vertical scaling moves your EBS-backed instance to different hardware with more resources; horizontal scaling distributes requests across multiple instances via a load balancer.

Steps to change the instance type

Step 1 — Check the current size (on the instance):

nproc          # number of vCPUs
free -h        # RAM
lscpu | grep -E "Model name|Architecture|^CPU\(s\)"

Step 2 — Stop the instance: EC2 → Instances → select → Instance state → Stop instance → wait for Stopped. (Take a snapshot/AMI first if this is important.)

Step 3 — Change type: Actions → Instance settings → Change instance type (the UI may vary slightly) → choose, e.g., t3.small → Apply (or Change). Incompatible types are usually greyed out or rejected with a message.

Step 4 — Start: Instance state → Start instance → note the new public IP (unless you use an Elastic IP) → SSH in again.

Step 5 — Verify:

nproc
free -h
lscpu | grep -E "Model name|Architecture|^CPU\(s\)"
sudo service nginx status        # make sure your apps came back (enabled at boot)

CLI alternative (instance must be stopped):

aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --instance-type "{\"Value\": \"t3.small\"}"
aws ec2 start-instances --instance-ids i-0123456789abcdef0

What changes and what stays

Changes Stays the same
vCPU, RAM, network/EBS bandwidth All EBS volumes and their data (root and data)
Auto-assigned public IP (new one after start) — unless an Elastic IP is attached Private IP address(es) and ENIs
Instance store data is lost (it's temporary host disk) Instance ID, security groups, IAM role, tags, key pair
Hourly price AMI/OS and installed software

Compatibility cautions

  • Architecture must match: an x86_64 instance (t3, m7i) cannot simply become an Arm/Graviton type (t4g, m7g). The AMI/OS is compiled for one architecture — for Graviton, launch a new instance from an arm64 AMI and migrate.
  • Drivers for Nitro types: modern types (t3, m5 and newer) need ENA networking and NVMe storage drivers. Current Amazon Linux, Ubuntu and CentOS Stream AMIs have them; very old AMIs moving from t2 to t3 may fail to boot or lose networking. Also remember disk names change to /dev/nvme... — another reason fstab uses UUIDs (Chapter 13).
  • Availability: not every instance type is offered in every AZ/region; the console tells you if a type is unsupported.
  • Other features: hibernation, instance store volumes, or placement groups can restrict which types you can switch to.
  • Downtime: the stop/start takes a few minutes — plan it in a maintenance window and inform users.

Free tier caution

Only specific instance types (for example t2.micro/t3.micro, depending on your account and region) are covered by the free tier/free plan. Scaling up to t3.small or larger is billed normally from the moment it starts. Scale back down after your test.

Ravindra Bagale's Tip

Before scaling up, find out what is actually short — CPU, RAM or disk I/O. Check top, free -h and CloudWatch metrics. If RAM is the problem, a bigger CPU won't help; if a T-instance keeps running out of CPU credits, a larger T-type or an M-type fixes it. And when you find yourself scaling up again and again for a web app, it is time to think horizontal: an Auto Scaling group behind a load balancer. Clear?