AWS Cost Optimization Strategies

Cost optimisation on AWS is not one technique but six, and they are worth attacking roughly in this order — the earlier ones cost nothing to apply and the later ones require architectural change.

1. Provision only what is running

The largest single line on most bills is something nobody is using.

• Shut down non-production environments outside working hours. An instance running 168 hours a week when it is needed for 45 is paying nearly four times what it should.
• Delete unattached EBS volumes, unassociated Elastic IPs, idle load balancers and old snapshots.
• Use CloudWatch to find low-utilisation resources, and AWS Compute Optimizer to have them found for you — it now reports idle resources, not just oversized ones.

Consolidation is the same idea one level up. Many services have a per-resource floor: a provisioned DynamoDB table, a multi-AZ database instance, a NAT gateway. Several small ones cost more than one adequately sized one carrying the same load, because each pays the floor separately. Consolidating four small multi-AZ database instances into one larger one is a routine saving; so is putting several low-traffic tables behind one on-demand-capacity table.

2. Rightsize

• Choose the smallest resource that meets the technical requirement, then verify against real utilisation rather than against the requirement document.
• Move to current-generation instance families. Newer generations are usually cheaper per unit of work, and Graviton-based instances more so again for workloads that can run on Arm.
• Design for consistent utilisation. Loosely coupled architectures — a queue between producer and consumer, an Auto Scaling group instead of a fixed fleet — flatten the demand curve, and a flat curve can be provisioned for its average instead of its peak.

The saving from smoothing demand is often larger than the saving from any single rightsizing decision, because it changes what “right-sized” means.

3. Choose the right purchase option

• Reserved Instances or Savings Plans for the steady baseline. See Savings Plans.
• Spot Instances for anything interruptible — batch, CI, rendering, analytics. AWS advertises savings of up to 90% off On-Demand.
• EC2 Fleet or an Auto Scaling group with a mixed instances policy to express a target mix of On-Demand and Spot in one place, so the elastic portion of a fleet is cheap and the baseline is reliable.

Details and trade-offs are in instance purchasing options.

4. Consider Region

Prices vary by Region, sometimes substantially, for the same service. Where a workload has no data-residency or latency requirement tying it to a location, the cheaper Region is free money.

Two constraints, though. Latency to users still matters — CloudFront and Route 53 latency-based routing mitigate it, they do not eliminate it. And data protection law usually decides this question before economics does: for UK and EU personal data, Region choice is a compliance decision, not a cost one.

Check current per-Region rates on the AWS pricing pages or in the AWS Pricing Calculator. Regional price relationships change, so a Region that was cheapest for a service some years ago is not necessarily cheapest now.

5. Use managed services

Running your own MySQL on EC2 costs less per hour than RDS and more per year than RDS, once patching, backup, failover testing and the engineer’s time are counted. The same argument applies to Fargate rather than self-managed container hosts, EMR rather than a hand-built Hadoop cluster, and OpenSearch Service rather than a self-run cluster.

The comparison to make is total cost of ownership, not instance-hour price. See cloud cost fundamentals.

6. Watch data transfer

Data transfer is the cost line that surprises people, because it does not appear next to the resource that caused it.

• Inbound transfer to AWS is free.
• Outbound to the internet, and transfer between Regions, is charged.
• Transfer between Availability Zones within a Region is charged in both directions.
• NAT gateways charge per hour and per gigabyte processed, which makes a chatty private subnet expensive; VPC endpoints for S3 and DynamoDB remove that traffic from the NAT gateway entirely.

CloudFront in front of an origin reduces egress cost as well as latency. AWS Direct Connect has a higher fixed cost than internet egress but a lower per-gigabyte rate, so it pays back above a volume threshold that depends on your traffic profile — model it rather than assuming either way.

Keeping it optimised

Cost optimisation is not a project that finishes. Review utilisation on a schedule, keep budgets and alerts in place so a regression is noticed within days rather than at month end, and make someone accountable for the number. See AWS cost management tools.