Six months after a successful AWS migration, almost every workload we review has the same complaint: the bill is bigger than it should be, and the team cannot pinpoint the leak. The good news is that the leaks are predictable. The Cost Optimization pillar of the AWS Well-Architected Framework is the closest thing the industry has to a checklist for them. Here are the patterns we surface most often during a Well-Architected review — none of which require trading off performance, security, or reliability. They just require looking.
Right-sizing is the boring fix that pays first
The single biggest line item on most AWS bills is compute, and the single biggest mistake on most compute lines is choosing an instance family by habit. Workloads sized in the data-centre era often migrate as m5.large when an m6i.large (newer Intel, same price) or a t3a.medium (AMD, lower price) would do the work.
Where the compute profile is stable rather than spiky, the largest single optimisation move available today is AWS Graviton: the Arm-based instance families (m7g, c7g, r7g) typically cost ~20% less than the equivalent x86 instances and run most modern workloads without code changes. The reason teams do not take the saving is rarely technical; it is that nobody owns the migration in the backlog. A Well-Architected review surfaces the candidates; the project plan finishes the job.
Want a fact-based list of Graviton and right-sizing candidates in your account? Book a Well-Architected Review →
Storage tiering: S3, EBS, and the data nobody touches
S3 is cheap, but only at the right tier. Almost every S3 bucket we look at contains data that has not been read in a year sitting in S3 Standard at $0.023/GB-month when S3 Glacier Deep Archive at $0.00099/GB-month would do. The fix is S3 Lifecycle policies: rules that automatically transition objects to Standard-IA after 30 days, Glacier Instant Retrieval after 90, and Deep Archive after a year.
EBS volumes have the equivalent. io1 volumes provisioned for peak IOPS that never come, where a gp3 volume with on-demand throughput costs a fraction. The migration-time trap is lift-and-shift from an on-prem SAN that was overprovisioned for the worst day of the year: it becomes an io1 volume that is overprovisioned for the worst day of the year — only now you pay for the overprovision every minute.
A note on prices. The figures cited above are us-east-1 list. Pricing in af-south-1 (Cape Town), me-south-1 (Bahrain), and me-central-1 (UAE) runs ~15–25% higher on storage and similar margins on some data-transfer lines — but the structural picture (Standard → IA → Glacier, io1 → gp3) is identical. The right move is the same in every region; only the absolute numbers shift.
Idle resources: the long tail
The third pattern is the long tail of small things nobody owns. Orphaned EBS volumes attached to instances that no longer exist; NAT Gateways in development VPCs running 24/7 (~$32/month each, before data-processing fees); RDS instances spun up for a proof-of-concept three quarters ago and never turned off; CloudWatch log groups with no retention policy growing forever. None of these line items are large individually. Together they are usually 10–20% of a development account’s spend.
AWS Trusted Advisor and AWS Compute Optimizer find most of them automatically. The actual work is doing something about the findings — turning them into a tagging policy, an owner per tag, and a monthly review.
Need a partner to stand up the tagging policy and FinOps cadence? Talk to us →
Data transfer: the architectural choices that cost forever
Cross-AZ data transfer is $0.01/GB. NAT Gateway data processing is $0.045/GB. Cross-region transfer is $0.02/GB. These look like small numbers until you have a database in one AZ and an application in another doing a million queries an hour.
The architectural patterns that fix this — read replicas in the same AZ as the consumer; VPC Gateway endpoints for S3 and DynamoDB (free); Interface endpoints for other AWS services that would otherwise traverse a NAT Gateway; multi-AZ designs that fail over rather than chat across — are well documented and rarely retrofitted. A Well-Architected review names the worst offenders and recommends specific changes. Egress savings here often pay for the review within a quarter. (For analytical data movement specifically, see our note on building a data platform the business trusts.)
Commitments: Savings Plans, done right
Once the architecture is right-sized, the next question is commitments. A 1-year Compute Savings Plan typically yields ~27% off compute that runs reliably; a 3-year term lifts that to ~45%. The mistakes are committing too early (before there is a year of stable usage to size against) or too late (paying on-demand for predictable workloads forever).
Talk to us about sizing your Savings Plan once your post-migration usage is stable. Schedule a call →
Mapping this back to the Well-Architected Framework
Every pattern above maps directly to the Cost Optimization pillar’s design principles: practise cloud financial management, measure efficiency, implement consumption-based pricing, analyse and attribute expenditure. The pillar exists because these patterns are common. The review exists because most teams do not have the time to surface them on their own — and because cost optimisation is not a one-off project. It is a discipline that needs an outside eye every six to twelve months to stay honest.
If your AWS bill has grown faster than your traffic or your headcount in the last year, the leak is almost certainly here. (Running SAP on AWS? The right-sizing patterns above apply just as much — see our SAP-on-AWS playbook.) We would be glad to find it for you.
Where this applies: the patterns above are industry-agnostic, but we see them surface most often in financial services, real estate, and tech & SaaS portfolios.
