EC2 Right-Sizing and Compute Optimizer

You inherit an account with 40 web servers on m5.2xlarge. Every instance is healthy. No alarm has fired in eight months. CloudWatch shows CPUUtilization averaging 8% with peaks around 22%. The monthly compute bill is roughly $11,000, and about $8,000 of that is buying capacity nobody uses.

Nothing here is broken, which is exactly why nobody looks at it. Right-sizing is the part of the CloudOps job with no incident attached to it, and the exam tests it because the skills involved are the same ones you use when something is broken: reading utilization metrics correctly, knowing which metric is missing, and knowing which tool answers which question.

CPU utilization is one dimension of four

CPUUtilization is the metric everyone reaches for, and on its own it is close to useless for sizing decisions.

An instance has at least four capacity dimensions that can independently run out: CPU, memory, network, and storage I/O. CloudWatch publishes instance metrics for three of them out of the box. It does not publish memory, because the hypervisor cannot see inside the guest. To AWS, your operating system's memory is opaque; only an agent running inside the instance can report how much of it is in use.

This produces a specific and very common failure shape: an application that is slow while CPUUtilization sits at 12%. The instance is starved for memory, the operating system is swapping, and every graph in the console looks calm. If a scenario describes low CPU and poor performance, memory is the first thing to suspect, and the fix that unblocks the diagnosis is installing the unified CloudWatch agent so that memory becomes a metric you can see.

The same blind spot affects the tooling built on top of these metrics. Compute Optimizer analyzes memory utilization only for resources with the CloudWatch agent installed. Without it, you get findings based on CPU, network, and I/O, and the service will happily recommend a smaller instance for a workload that is actually memory-bound.

What Compute Optimizer does

AWS Compute Optimizer reads the configuration and CloudWatch utilization metrics of your resources and returns a recommended configuration, with the projected utilization if you adopted it.

Four facts about how it works shape most exam questions:

You must opt in. It does nothing until you activate it for a standalone account, a member account, or the management account of an organization. A scenario where "Compute Optimizer shows no recommendations" often ends at this.

The default lookback is 14 days. It analyzes the last 14 days of metrics and refreshes recommendations daily. Activating enhanced infrastructure metrics, a paid recommendation preference, extends the window to 93 days. That is the answer whenever a workload has a monthly close, a quarterly batch, or any peak that a 2-week window would miss entirely.

It needs enough data. Recommendations can take up to 24 hours to appear after opt-in, and a resource with too little metric history gets no finding at all.

It covers far more than EC2. EC2 instances and Auto Scaling groups, EBS volumes, Lambda functions, ECS services on Fargate, RDS and Aurora databases, DynamoDB, ElastiCache, MemoryDB, DocumentDB, NAT gateways, WorkSpaces, SageMaker, and commercial software licenses. If a question asks which single service gives right-sizing recommendations across compute and storage and databases, this is it.

Reading a finding

Every analyzed instance lands in one of three classifications:

The classification tells you that something is wrong. The finding reason tells you what, and it is specific: CPU over-provisioned, Memory under-provisioned, EBS throughput under-provisioned, EBS IOPS over-provisioned, Network bandwidth under-provisioned, Network PPS under-provisioned, Disk IOPS, Disk throughput, and their GPU equivalents. Each names the metric it was derived from, so you can go verify it yourself: EBS IOPS reasons come from VolumeReadOps and VolumeWriteOps, network bandwidth from NetworkIn and NetworkOut, network PPS from NetworkPacketsIn and NetworkPacketsOut.

Note the split that catches people: Disk reasons refer to instance store volumes (DiskReadOps, DiskWriteBytes), while EBS reasons refer to attached EBS volumes. Different hardware, different fix. A disk finding is solved by changing the instance type; an EBS finding is often solved by modifying the volume, which the next lesson but one covers in detail.

Each recommendation also carries a performance risk from very low to very high (0 to 4 in the API). It is the maximum risk score across all the analyzed specifications, and it answers "how likely is this smaller type to disappoint me?" Very low means the type is predicted to always have enough capability. Anything higher is a prompt to test under real load first.

Burstable instances follow different rules

Everything above assumes an instance can use 100% of its CPU whenever it wants. T instances cannot, and this is the single most-tested piece of EC2 sizing knowledge.

A burstable instance is sold with a baseline level of CPU it can sustain forever, plus a bucket of CPU credits that let it run above the baseline for a while. One CPU credit equals one vCPU running at 100% for one minute. Below baseline, the instance earns more than it spends and the bucket fills. Above baseline, it spends more than it earns and the bucket drains.

Here is a t3.large, which has 2 vCPUs, earns 36 credits per hour, has a 30% baseline, and can accrue up to 864 credits (one full day of earning):

• Demand rises to a steady 55% CPU.
• Credits spent per minute = vCPUs x utilization = 2 x 0.55 = 1.1, so 66 per hour.
• Credits earned per hour = 36.
• Net drain = 30 credits per hour. Starting from a full 864, the balance hits zero in about 29 hours.

What happens at zero depends on the credit configuration mode:

• Standard mode: the instance is brought down to its baseline. CPU is clamped at 30% and the application slows, with no error, no alarm, and no obvious cause. This is the default for T2 and for T3 on a Dedicated Host.
• Unlimited mode: the instance keeps running above baseline by spending surplus credits. If its average CPU over a rolling 24 hours stays at or below baseline, the surplus is covered by the normal hourly price. If not, you pay a flat additional rate per vCPU-hour. This is the default for T3, T3a, and T4g.

The misconception to name out loud: people read "burstable" as a bonus and assume the instance can hold high CPU indefinitely. It cannot, in either mode, without a consequence. In standard mode the consequence is a performance cliff roughly a day after the load increased. In unlimited mode the consequence is a bill line that nobody was expecting. The metric that predicts both is CPUCreditBalance, not CPUUtilization, so a T-instance fleet needs an alarm on the credit balance trending toward zero. CPUSurplusCreditsCharged is the one to watch for the billing side.

A few more credit facts worth holding:

• The accrual limit is always 24 hours' worth of earning. A t3.micro earns 12 per hour and accrues 288; a t3.2xlarge earns 192 per hour and accrues 4,608.
• Baseline percentages are per vCPU and match what CloudWatch shows. A t3.large at baseline reads as 30% in the console.
• For T3, T3a, and T4g, accrued credits survive a stop for 7 days. For T2 they are lost the moment you stop the instance.
• Launch credits exist only for T2 in standard mode. T3 and later launch in unlimited mode, so they can burst immediately without needing them.

If a T instance is consistently living above its baseline, it is the wrong instance for the workload. That is a right-sizing finding, not a tuning problem, and Compute Optimizer draws a burstable baseline line on its CPU graph so you can see it.

Right-sizing a live instance

Once you have the finding, the change itself is mechanical, and the exam cares about the ordering and the side effects.

For an EBS-backed instance, changing the type requires the instance to be stopped:

aws ec2 stop-instances --instance-ids i-0abc123def4567890
aws ec2 wait instance-stopped --instance-ids i-0abc123def4567890

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123def4567890 \
  --instance-type "{\"Value\": \"m5.xlarge\"}"

aws ec2 start-instances --instance-ids i-0abc123def4567890

The instance keeps its ID, its EBS volumes, its security groups, and its IAM role. Three things do not survive the stop and start:

• Data on instance store volumes, because the instance moves to different host hardware.
• The public IPv4 address, unless an Elastic IP is associated.
• The CPU credit balance on a T2 instance.

Tags do the organizational half of this work. Right-sizing at fleet scale means being able to answer "who owns this instance and what environment is it in" before you resize it, which is why Skill 1.3.1 of the exam guide names resource tags alongside performance metrics. A consistent Environment, Owner, and Application tag set is what turns a list of 400 findings into 12 conversations.

For instances in an Auto Scaling group, do not resize instances individually. Update the launch template with the new instance type and start an instance refresh, so the change is durable and the group replaces instances in a controlled way.

Which tool answers which question

Three services produce overlapping-sounding advice, and questions are written to separate them.

The cue: "recommend an instance type based on measured utilization" is Compute Optimizer. "Show me savings opportunities alongside my bill" is Cost Explorer. "Check my account against a list of best practices" is Trusted Advisor.

Exam tips

• Low CPU plus a slow application means memory. The unblocking action is installing the CloudWatch agent, because memory is not a default CloudWatch metric and Compute Optimizer cannot analyze it without the agent.
• "Monthly batch job", "quarterly peak", or "seasonal load" plus Compute Optimizer points at enhanced infrastructure metrics and its 93-day lookback. The default 14 days would never see the peak.
• A T instance that gets slow after about a day of elevated load is a credit exhaustion question. The metric is CPUCreditBalance; the fix is either unlimited mode (accepting the surplus charge) or a non-burstable instance family.
• Watch which default the question implies. T2 defaults to standard mode and throttles; T3, T3a, and T4g default to unlimited and bill instead.
• Do not confuse Disk finding reasons (instance store) with EBS finding reasons (attached volumes). They lead to different remediations.
• Changing an instance type needs the instance stopped, and stopping it destroys instance store data and releases a non-Elastic public IP.

The habit to carry forward: before you change any instance's size, know which of its four capacity dimensions is actually constrained. CPU is the one you can see by default, memory is the one you have to go get, and for T instances the constraint is not a dimension at all but a credit balance. The next lesson takes the third dimension, network, and shows why an instance can be nowhere near its stated bandwidth and still be throttled.