AWS Cost Optimisation · AWS
Published
Most AWS cost optimisation effort goes where the tooling points: oversized instances, idle resources, the recommendations tab. That work is worth doing, but it has a ceiling. The estates we have reduced by 75% and 90% did not get there through recommendations; they got there because the architecture changed. This guide sets out the three layers of AWS cost work and what each one is worth.
Layer one: hygiene
Hygiene is the waste nobody decided to have. It accumulates in every estate and it is the fastest money in cloud cost work:
- Idle and orphaned resources. Unattached EBS volumes, aged snapshots, idle load balancers, unassociated Elastic IPs and stopped-but-provisioned capacity. Individually small, collectively real.
- Non-production running like production. Development and test environments billed 168 hours a week for a 45-hour working week. Scheduling them off outside working hours removes most of that cost with no engineering risk.
- Right-sizing against real load. Instances are sized at launch, on a guess, and rarely revisited. Compute Optimizer and CloudWatch data show what a workload actually uses; the judgement call is how much headroom is deliberate.
- Storage defaults. Migrating gp2 volumes to gp3 cuts the per-gigabyte price by roughly 20% and decouples performance from size. It is close to free money and a surprising number of estates have not done it. The rest of the storage levers, from tiering to snapshot retention, are in our storage costs guide.
Hygiene typically trims a meaningful slice off an unmanaged bill, but it does not change what the platform fundamentally costs. That is the job of the next two layers.
Layer two: pricing
The same workload can be billed at very different rates depending on how you buy it:
- Commitments. Reserved Instances and Savings Plans discount steady-state compute by up to around 72% against on-demand rates. They deserve their own discipline, covered in our commitment strategy guide. The cardinal rule: right-size first, commit second, so the discount compounds the optimisation instead of freezing waste in.
- Spot. For stateless, fault-tolerant or batch workloads, Spot instances run at discounts that frequently exceed 70%. The constraint is architectural: the workload has to tolerate interruption, which is a design property, not a setting.
- Graviton. AWS’s ARM-based instances offer up to around 40% better price performance. Managed services move with little friction; self-managed workloads need an ARM build.
Pricing work is high-value and low-risk, but it optimises the cost of the architecture you already have. If that architecture is wrong, a discount just makes the wrong thing cheaper.
Layer three: architecture
This is where the large percentages live, and where no tool can follow:
- Data transfer. NAT gateway processing charges, cross-availability-zone traffic and internet egress are billed per gigabyte and are invisible in most teams’ mental model of the bill. Moving a chatty workload’s traffic through VPC endpoints, or simply co-locating components that talk constantly, can remove entire line items.
- Storage and query patterns. How data is stored, partitioned and queried often matters more than what it is stored on. We have redesigned a platform projected to cost €1 million a year on Google Cloud down to a fraction of the projection, and rebuilt an inherited AWS estate to run at a quarter of its previous cost; both were storage and data-flow redesigns.
- Removing components. Estates accumulate services the way lofts accumulate boxes. A component that no longer earns its place costs money every hour it exists. Deleting things is the most underrated optimisation in cloud computing.
- Matching the compute model to the load. Always-on capacity serving occasional traffic is the classic mismatch. Serverless and scale-to-zero designs charge for work done rather than time elapsed, and for spiky workloads the difference is dramatic.
Architecture work needs engineers who can hold cost and reliability in the same design conversation. It is the part of cloud cost reduction that cannot be bought as software, and it is where Cloudreason spends most of its time.
The order of operations
Run the layers in sequence: hygiene first, because it is fast and safe; architecture next, so you are not discounting waste; commitments last, sized to the estate that remains. Then keep watching, because every one of these gains erodes if nobody owns it — and ownership starts with the cost allocation that shows each team its own number. The same layers apply on Azure and Google Cloud, with different levers at each layer.
That ongoing ownership is our Managed FinOps service. If you want to know what your own estate should cost before committing to anything, the three-day Cloud Cost Health Check exists to answer exactly that question, or you can just talk to us.