AWS cost optimization gets sold as a dashboard. It is really a sequence. Buying a tool that colours your spend red does not lower it; a handful of specific, ordered moves does. And the order matters: rightsize before you commit, or you lock a one-year Savings Plan to capacity you were about to delete. This page walks the real AWS cost levers, roughly in the order we pull them on an engagement, so your team can run them alone or hold any vendor, us included, to them.
Start with the shape of the bill, not the discount
Before any lever, pull the Cost and Usage Report (CUR) into Athena or QuickSight and see where the money actually goes. On a typical bill, EC2 plus its attached EBS and data transfer is 50 to 70 percent; the rest is RDS, S3, networking, and a long tail of small line items. The classic mistake is optimising in the wrong order: teams buy Reserved Instances first because it is one click, then spend a year rightsizing around a commitment they cannot unwind. Rightsize and schedule first, then commit to the floor that remains. A read-only cloud bill audit produces that map without touching production.
Commitments: Savings Plans versus Reserved Instances
The single biggest lever, and the most misunderstood. Compute Savings Plans discount EC2, Fargate and Lambda across any instance family, region and OS: maximum flexibility, a slightly smaller discount, and the sane default for most workloads. EC2 Instance Savings Plans trade that flexibility for a deeper discount by locking to one family in one region, worth it when a workload is genuinely stable. Reserved Instances remain the only commitment vehicle for RDS, ElastiCache, Redshift and OpenSearch, so you will own a mix whether you planned to or not. The discipline that matters is matching term to confidence: one-year, no-upfront is the honest default, committed to your steady-state floor while the spiky top runs on-demand or on Spot. Chasing 100 percent coverage is how you end up paying for idle commitments.
Rightsizing and scheduling
Most instances are sized for a peak that never arrives. Compute Optimizer reads CloudWatch history and flags over-provisioned EC2, EBS, Lambda and ECS; treat its findings as a worklist, not gospel, and enable the CloudWatch agent so memory metrics inform the call. Scheduling is the free win almost nobody takes: non-production environments rarely need to run nights and weekends, and a stop schedule on dev, staging and CI runners cuts roughly 65 percent off those hours with one EventBridge rule and a Lambda. Push fault-tolerant and batch work to Spot, where interruption is survivable for anything with a queue in front of it.
Graviton: the migration that pays for itself
AWS's ARM-based Graviton instances run 20 to 40 percent cheaper than the Intel or AMD equivalent at similar or better price-performance. For managed engines the switch is nearly free: RDS, ElastiCache and OpenSearch move to a Graviton instance class with a class change and a failover window. For your own services it is real work: rebuild images for arm64 or multi-arch, test any dependency that ships native code, and benchmark before you trust the numbers. Start with stateless services and managed engines, where the risk is lowest and the discount is immediate, then work outward.
Storage: S3 lifecycle and the EBS snapshot graveyard
S3 grows quietly. Turn on Storage Lens to see access patterns, then either write explicit lifecycle rules (Standard to Standard-IA around 30 days, Glacier tiers for cold archives, expiry for logs and for multipart uploads that never completed) or hand unpredictable data to Intelligent-Tiering. On block storage, almost every gp2 volume should be gp3: the same baseline performance, about 20 percent cheaper, with IOPS provisioned separately. And every account grows an EBS snapshot graveyard: snapshots of volumes deleted years ago, orphaned AMIs, and unattached volumes billing since a half-finished migration. A Data Lifecycle Manager policy stops the bleeding; a one-time sweep recovers what has already pooled.
The lines nobody reads: data transfer and NAT gateways
Data transfer is the least-read section of the bill and one of the most fixable. The usual culprits are cross-AZ chatter between services that could be co-located or made zone-aware, and the NAT gateway, which bills an hourly fee plus a per-gigabyte processing charge on everything private subnets send out. Route traffic to S3, DynamoDB, ECR and other AWS services through VPC gateway and interface endpoints instead of the NAT, and much of that processing charge simply disappears. Put CloudFront in front of egress-heavy content to cut the per-gigabyte rate. These are architecture changes, not toggles, but the routing fixes often pay back within weeks.
Tagging, allocation, and anomaly detection
Untagged spend is unmanageable spend. Enforce a small, mandatory tag set (team, environment, product, cost-centre) with tag policies and Service Control Policies, activate them as cost allocation tags, and slice the bill with Cost Categories so every increase has an owner. That attribution is the denominator that turns raw dollars into cost-per-customer or cost-per-request, the FinOps unit economics that make cloud spend a business conversation instead of a spreadsheet argument. Then switch on AWS Cost Anomaly Detection so a surprise 3x spike is caught by an alert within a day rather than by next month's invoice. None of this needs a third-party platform; the AWS-native tooling covers most mid-size estates for free.
Where AI and GPU spend fits
If you train or serve models on AWS, GPU compute is probably the most expensive line on the bill, and it obeys different rules: utilisation and batching matter more than instance discounts, and inference is too often running on hardware sized for training. We treat it as its own workstream. The specific levers are in our GPU cost teardown, and FinOps for AI runtime cost covers the governance that keeps it from drifting.
How an InfraZen AWS engagement runs
Week one is read-only by policy: billing exports and read-only roles, no agent installed, nothing touched in production. Within 48 hours you get a written finding set, quantified as conservative-to-average ranges with their assumptions stated, ordered by return on effort. From there the paths fork honestly: your team executes the report alone (a genuine success, and we say so), or we run a 90-day cloud billing and FinOps engagement that buys the commitments, does the rightsizing and Graviton moves, and stands up the tagging and anomaly rituals so the savings hold. Estimate the prize first with the free cloud waste calculator.
What to expect: honest ranges
Industry analyses put recoverable waste at roughly a third of cloud spend, and our published client average across FinOps engagements from 2021 to 2025 is 45 percent (see the case-studies disclaimer; the number depends heavily on how optimized you already are). If you have never bought a Savings Plan or rightsized an instance, expect the high end. If you are already committed and rightsized, expect single to low-double digits from the harder architectural levers. Anyone quoting one big percentage before reading your bill is selling, not measuring, and that is the opposite of how we would want to be remembered.
Related: Cloud Billing & FinOps engagement · What a cloud bill audit covers · What is FinOps? · Cloud waste calculator