Articles

Right-Size EC2 Instances to Cut Costs Without Hurting Performance (2026)

April 16, 2026 5 min read

You can run your AWS workloads on instances that are too large, wasting money, and that’s the core problem this guide tackles.

Let’s look at a real-world scenario. Imagine a web application running on m5.xlarge instances. You’ve got three of them behind an Application Load Balancer. The application is mostly idle during off-peak hours but spikes during peak times. You notice your AWS bill is higher than expected, and you suspect the instances might be over-provisioned.

Here’s how you can start right-sizing:

  1. Gather Metrics: The most crucial data comes from Amazon CloudWatch. You need to look at CPU utilization, memory utilization, network traffic, and disk I/O for your instances over a representative period (e.g., 2-4 weeks) to capture both peak and off-peak behavior.

    • CPU: aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization --start-time 2023-10-01T00:00:00Z --end-time 2023-10-31T23:59:59Z --period 3600 --statistics Average --dimensions Name=InstanceId,Value=i-0123456789abcdef0

      • Diagnosis: Look for consistently low average CPU utilization (e.g., below 20%) over extended periods. Spikes are normal, but if the average is low, you’re likely over-provisioned.
      • Fix: If average CPU is consistently low, consider downsizing to an m5.large or m5.medium instance.
      • Why it works: A smaller instance has fewer vCPUs and less allocated CPU power, directly reducing the cost while still being able to handle typical loads.

    • Memory: CloudWatch doesn’t directly expose memory utilization for EC2 instances by default; you need the CloudWatch agent installed on the instance.

      • Diagnosis: Once the agent is configured, look for metrics like mem_used_percent or mem_available_percent in CloudWatch Logs Insights or via custom metrics. Consistently high memory usage (e.g., above 90%) indicates a potential memory bottleneck. Conversely, if memory is always mostly free, you might be able to downsize.
      • Fix: If memory is consistently underutilized, downsize the instance type. If it’s consistently high and causing performance issues (which you’d see in application logs or other performance counters), you might need to upsize or switch to an instance family with more memory (e.g., r5 instances).
      • Why it works: Memory is a fixed cost per instance type. Matching instance memory to application needs prevents paying for unused RAM or suffering performance degradation from insufficient RAM.

    • Network I/O:

      • Diagnosis: Monitor NetworkIn and NetworkOut metrics in CloudWatch. Check if your instance’s network bandwidth is consistently hitting the limits of its current type. For example, an m5.xlarge has up to 10 Gbps of network performance. If you’re frequently maxing this out, you might need a larger instance or a different family optimized for networking (e.g., c5n or m5n).
      • Fix: If your network traffic is consistently low, downsizing might save costs. If it’s high and a bottleneck, consider an instance type with higher network throughput.
      • Why it works: Different instance types offer varying levels of network bandwidth. Paying for high bandwidth when you don’t use it is wasteful, while insufficient bandwidth cripples performance.

    • Disk I/O (EBS-backed instances):

      • Diagnosis: Monitor EBSReadOps, EBSWriteOps, EBSReadBytes, and EBSWriteBytes in CloudWatch. Compare these to the IOPS and throughput limits of your attached EBS volumes and the instance’s network-attached storage (if applicable, though less common for general-purpose). For example, a general-purpose SSD (gp2) volume offers 3 IOPS per GB, with a maximum of 16,000 IOPS. An m5.xlarge instance can support up to 4.5 Gbps of EBS bandwidth. If you’re consistently hitting EBS volume limits or instance EBS bandwidth limits, you might need a larger instance or a different EBS volume type (e.g., io1/io2).
      • Fix: If EBS I/O is consistently low, you might be able to reduce the provisioned IOPS/throughput on your EBS volumes or, if the instance itself is underutilized across the board, downsize the instance.
      • Why it works: Over-provisioned EBS volumes or instance EBS bandwidth capabilities contribute to cost. Matching these to actual workload demands is key.

  2. Utilize AWS Tools:

    • AWS Compute Optimizer: This service analyzes your historical utilization data and provides recommendations for right-sizing EC2 instances. It can suggest downsizing, upsizing, or changing instance families.

      • Diagnosis: Enable Compute Optimizer for your AWS account. It will start generating recommendations after a period of data collection.
      • Fix: Apply the recommendations provided by Compute Optimizer, carefully reviewing them for accuracy based on your understanding of the application’s behavior.
      • Why it works: It automates the analysis of CloudWatch metrics and applies AWS’s understanding of instance capabilities to suggest optimal configurations.

    • AWS Cost Explorer: While not directly for performance metrics, Cost Explorer can highlight your spending on EC2 instances. You can filter by instance type and usage to identify the largest cost contributors, which can then be investigated further with CloudWatch metrics.

      • Diagnosis: Navigate to AWS Cost Explorer, select "Cost & Usage Reports," and filter by "Service: EC2-Instances." Group by "Instance Type" or "Tag" to see where the money is going.
      • Fix: Once you identify expensive, potentially over-provisioned instances, use the other tools (CloudWatch, Compute Optimizer) to determine the correct size.
      • Why it works: It provides a high-level financial view, pointing you towards areas where cost optimization efforts will have the biggest impact.

  3. Consider Instance Families: Not all xlarge instances are equal. An m5.xlarge is a general-purpose instance, while a c5.xlarge is compute-optimized, and an r5.xlarge is memory-optimized. If your application is consistently CPU-bound, a c5.xlarge might offer better performance for the same price or even less than an m5.xlarge that’s struggling. Conversely, if you have a memory-intensive workload, an r5.xlarge might be more appropriate.

    • Diagnosis: Analyze your CloudWatch metrics to understand what resource is the bottleneck (CPU, memory, network).
    • Fix: If CPU is the bottleneck, switch from a general-purpose instance (like m5) to a compute-optimized one (c5, c6g). If memory is the bottleneck, switch to a memory-optimized instance (r5, r6g).
    • Why it works: Different instance families are engineered with specific hardware configurations (CPU, RAM, network) optimized for particular workload types, offering better price-performance ratios when matched correctly.

The next error you’ll encounter after successfully right-sizing is likely a "Resource Exhaustion" error if you downsize too aggressively, or perhaps an "Application Latency Spike" if the new instance type, while cheaper, doesn’t quite meet the demands of your peak traffic.

Want structured learning?

Take the full Ec2 course →