Right-Sizing and Compute Optimizer

One of the most common and costly mistakes in cloud architecture is over-provisioning — allocating more resources than the workload actually needs. IT teams often over-provision due to on-premises habits (buying capacity for peak load), fear of performance degradation, or simply never reviewing initial sizing decisions. In AWS, over-provisioned EC2 instances, EBS volumes, and Lambda functions waste money every minute they run. Right-sizing is the systematic process of identifying and eliminating this waste.

AWS Compute Optimizer analyses historical utilisation metrics from CloudWatch and uses machine learning to recommend optimal AWS compute resources. It covers EC2 instances, EC2 Auto Scaling Groups, EBS volumes, Lambda functions, and Amazon ECS on Fargate. Compute Optimizer requires at least 30 days of metric history to generate confident recommendations. It is free to enable and provides recommendations with estimated monthly savings and a risk rating for changing.

Compute Optimizer analyses EC2 CPU utilisation, memory utilisation (via CloudWatch agent), network throughput, and EBS IOPS over the past 3, 14, or 30+ days. It then recommends one of four findings: Optimized (current size is appropriate), Over-provisioned (can downsize), Under-provisioned (should upsize), or Not optimized (insufficient data). Always review performance risk — Compute Optimizer assigns VeryLow, Low, Medium, High risk to each recommendation.

Lambda functions are billed per millisecond of execution time multiplied by memory allocated. Allocating more memory than needed wastes money, but more memory also means more CPU — so the right balance is the memory setting where cost per invocation is minimised. Compute Optimizer analyses Lambda invocation duration, error rate, and timeout metrics to recommend the optimal memory setting. The open-source Lambda Power Tuning tool can also invoke your function at different memory settings to find the cost-optimal configuration empirically.

EBS volumes are often over-provisioned on both size (unused disk space) and IOPS (provisioned IOPS that are never consumed). Compute Optimizer analyses VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes metrics. Common recommendation: migrate from gp2 to gp3 (which separates size from IOPS) — you can right-size IOPS independently, often saving 20%. Also identify unattached EBS volumes (instances terminated but volumes left behind) and snapshot or delete them.

Compute Optimizer analyses ASG utilisation across the entire group's instances and recommends launch template changes for the instance type. If all instances in an ASG are consistently over-provisioned, switching to a smaller instance type reduces cost at scale. For example, if an ASG averages 10 instances of m5.large, switching to m5.medium saves 50% per instance. Compute Optimizer also recommends Graviton-based instances when your software is compatible, providing both performance improvement and cost reduction.

AWS Trusted Advisor is another tool that provides cost optimisation insights alongside security, performance, fault tolerance, and service limit checks. Key cost checks: Low Utilization EC2 Instances (less than 10% CPU for 4+ days), Unassociated Elastic IP Addresses (charged when not attached), Underutilized EBS Volumes, Idle Load Balancers (no healthy targets), and Unused Reserved Instances. Trusted Advisor basic checks are free; the full set requires Business or Enterprise Support.

AWS regularly releases new, more efficient EC2 instance generations that offer better performance at lower or equal cost. Moving from 5th gen (m5, c5, r5) to 7th gen (m7g, c7g, r7g) can provide 40% better compute performance at similar or lower cost. Compute Optimizer specifically flags opportunities to upgrade to newer generations, including Graviton-based instances. Instance upgrades are often the simplest right-sizing action — same configuration, newer hardware, better performance, lower cost.

RDS instances are expensive and often over-provisioned. Use CloudWatch metrics to evaluate RDS utilisation: CPUUtilization, FreeableMemory, ReadIOPS, and WriteIOPS. If CPU stays below 20% and memory remains consistently high, consider downsizing. For production databases with Multi-AZ, right-sizing doubles the savings since both primary and standby change. Also consider switching from RDS MySQL/PostgreSQL to Aurora, which often provides better performance at similar cost and is more cost-efficient at scale.

Right-sizing should be an ongoing process, not a one-time exercise. Establish a monthly or quarterly review cadence: pull Compute Optimizer recommendations, evaluate which are safe to apply, implement changes in a maintenance window, and measure the savings. Automate the easy wins: unattached EBS volume cleanup, unused Elastic IP release, and idle load balancer removal can be scripted. Create a Cost Optimisation Dashboard in CloudWatch that tracks monthly spend by service and highlights unusual increases.

Right-sizing addresses over-provisioning within existing architectures, but sometimes the architecture itself is the problem. A single large EC2 instance running multiple applications might need architectural decomposition (microservices on Fargate) rather than just a smaller instance. A monolithic database might need sharding or caching rather than just an instance downsize. Right-sizing is the first, quickest step. Architecture optimisation (serverless, containers, caching) provides the deeper, more sustained savings but requires more effort. The Cost Optimisation pillar recommends pursuing both.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: AWS Compute Optimizer uses machine learning on CloudWatch metrics to recommend right-sized compute resources, right-sizing applies to EC2, Lambda, EBS, ASGs, and ECS on Fargate, and upgrading to newer instance generations (especially Graviton) provides both cost and performance improvements. Make right-sizing a recurring practice, not a one-time event. Next up we explore Reserved Instances, Savings Plans, and Spot purchasing models.