Amazon EC2 right-sizing means choosing an instance family and size that meet an application’s performance and availability needs without paying for capacity it does not use. A quiet CPU graph alone is not enough evidence: memory, network, storage, workload peaks, and application behavior can all limit a server.

Choose a candidate family before comparing sizes

Match the family to the bottleneck

EC2 offers general-purpose, compute-optimized, memory-optimized, storage-optimized, and accelerated-computing families. Start with the resource that constrains the workload, then compare instance sizes within compatible families. The EC2 fundamentals guide explains AMIs, architecture, and the broader family categories.

Include architecture and software compatibility

Compare vCPUs, memory, network bandwidth, EBS bandwidth, local storage, processor architecture, and price for the exact instance types under consideration. A move from x86 to Arm can change software compatibility: confirm that the AMI, application binaries, libraries, agents, and vendor licenses support the target architecture before testing it.

Size from representative workload evidence

Measure normal and peak periods

Collect enough history to include ordinary traffic, scheduled jobs, deployments, busy periods, and known seasonal or monthly cycles. Pair infrastructure metrics with application indicators such as request latency, error rate, queue depth, throughput, and saturation. Include a reasonable capacity margin for workload variation and recovery; derive that margin from the service’s objectives and observed behavior rather than applying a universal CPU threshold.

Check every likely bottleneck

EC2 publishes metrics such as CPU utilization and network traffic, but standard instance metrics do not report guest operating-system memory usage. To use memory in a sizing decision, publish it with the CloudWatch agent or a supported external observability integration. Metrics sent by the CloudWatch agent are billed as custom metrics, so review the current CloudWatch pricing before enabling collection across a fleet. See AWS’s guidance for metrics collected by the CloudWatch agent.

Distinguish storage metrics before diagnosing a bottleneck: EC2 DiskRead* and DiskWrite* metrics measure instance-store activity. For EBS, inspect the volume’s AWS/EBS metrics and, on supported Nitro instances, the EBS* metrics in AWS/EC2. Compare the volume’s IOPS and throughput with its configured limits and the instance’s EBS bandwidth. A workload waiting on storage or network may not benefit from a larger CPU allocation. Review application and operating-system signs of memory pressure as well as averages: brief peaks, swapping, out-of-memory events, and latency can matter more than a quiet mean. See AWS’s EC2 CloudWatch metric definitions for the distinction.

Compare candidate types on the workload

Use observed CPU, memory, EBS, and network demand to shortlist alternatives. For each one, compare the instance’s documented limits with workload peaks and the headroom you chose. If you use a burstable T instance, inspect CPU credit balance and surplus-credit metrics: its baseline and credit mode affect sustained CPU behavior and possible charges. AWS describes how burstable instance CPU credits work.

Treat Compute Optimizer as a starting point

AWS Compute Optimizer compares supported instances with their utilization data and presents candidate types, projected utilization, and performance-risk ratings. Its default EC2 lookback is 14 days; rightsizing preferences also offer 32 days at no additional charge and 93 days with the paid enhanced infrastructure metrics feature. To include memory, install the CloudWatch agent or configure a supported external metrics integration; Compute Optimizer does not infer guest memory from its default EC2 metrics. Review the metrics analyzed for EC2, recommendation preferences, and EC2 recommendations and performance risk for the current options and eligibility rules.

Recommendations reflect the data, lookback period, utilization settings, and pricing assumptions available to the service. Check the projected resource limits against your workload, and treat any monthly savings estimate as an estimate rather than a promised reduction.

Compare pricing after choosing capacity

First determine a suitable instance configuration using workload evidence. Then compare On-Demand with eligible Savings Plans or Reserved Instances if usage is steady enough to support a term commitment. Savings Plans commit to a consistent hourly compute spend for one or three years; EC2 Reserved Instances discount matching usage, and only zonal Reserved Instances reserve capacity. Model expected usage and changing requirements before buying. See the current Savings Plans terms and EC2 Reserved Instance behavior. Spot Instances suit interruption-tolerant work and are a separate capacity and pricing choice.

Keep measurements useful over time

Review service outcomes after a change

Continue to watch the metrics that expose the bottleneck: CPU and credit behavior, memory pressure, EBS I/O and throughput, network traffic, and application latency or errors. Use the same representative periods and workload indicators before and after the change so you can see whether cost fell while service objectives still held.

Revisit automated recommendations

Compute Optimizer can help surface options, but recommendation quality depends on coverage and representative metrics. Confirm the relevant instances are supported, the selected lookback includes workload cycles, memory is present when needed, and the performance-risk rating is acceptable for the workload. Investigate any recommendation that conflicts with application-level evidence.

Group resources by purpose and owner

Tags for service, environment, and owner make it easier to compare like workloads, trace costs, and find the team that can validate a proposed change. Keep the baseline and the reason for a sizing decision with the service’s normal operational records.

Use horizontal scaling for variable demand

When an application can serve work from interchangeable instances, an Auto Scaling group can add or remove instances as demand changes. Auto Scaling does not change the size of an existing instance: changing type requires updating launch settings and replacing or refreshing instances. See the EC2 Auto Scaling setup guide for group configuration and rollout considerations.

Plan and validate the change

Account for interruption and rollback

Changing the type of an EBS-backed instance in place requires stopping it, so plan for downtime. A stop and start can also assign a new public IPv4 address unless an Elastic IP or another supported arrangement is used. For a service that must remain available, evaluate a replacement instance or a controlled Auto Scaling rollout instead. Back up stateful data and verify the recovery path before you change production capacity.

Test software and storage compatibility

Confirm the target type supports the AMI architecture, required networking and storage features, and any application or licensing constraints. Check EBS volume settings, instance-store dependence, device names, initialization time, and service discovery. If the target type or architecture changes, test a replacement in a non-production environment or a limited rollout before shifting all traffic.

Compare the result with the baseline

Record the expected cost change and the application metrics that must stay within their objectives. After rollout, compare equivalent workload periods for errors, latency, throughput, CPU, memory, EBS, and network behavior. If the service loses headroom or misses its objectives, restore the previous configuration or test another candidate. Lower hourly price is not a saving if it causes slower or unreliable service.

Make right-sizing a measured operating practice

A practical sequence

  1. Collect representative application and infrastructure data.
  2. Identify the constrained resource and suitable instance families.
  3. Compare candidate sizes, compatibility, headroom, and price.
  4. Test a recommendation and plan a reversible rollout.
  5. Validate service outcomes and actual costs before committing to longer-term pricing.

Repeat when the workload changes

Revisit sizing after meaningful changes in traffic, software, architecture, or service objectives. A previous fit can become too small or unnecessarily large as the workload evolves; ongoing measurement keeps the decision grounded in current behavior.