AWS cost optimization: every lever, in the order to pull it.

IWhere AWS waste lives, and why bills drift up

AWS is billed by consumption and defaults to on. You provision for peak, traffic falls back, and nobody scales the resource down. The leaks are consistent across companies, which is why the same seven levers work almost everywhere.

The usual pattern: an instance sized "to be safe" and never revisited; a load balancer, NAT Gateway and Elastic IPs that outlived their service; snapshots that pile up; logs kept forever. None of it is a single mistake. It is what happens when provisioning is one API call and de-provisioning is nobody's job.

The other drift is pricing. On-Demand is the most expensive way to buy almost everything on AWS. It exists so you can start with no commitment. Once your usage has a predictable floor, paying On-Demand for that floor is overpayment. Closing that gap is the biggest single lever, so it comes first below.

IICommitments: Savings Plans and Reserved Instances

If you do one thing, do this. Commitments change what you pay, not what you run, and they apply to spend you already have.

A commitment is a promise to spend a set amount per hour (Savings Plans) or to run a given instance type (Reserved Instances) for one or three years. In return AWS discounts matching usage. Per AWS's Savings Plans guide, EC2 Instance Savings Plans and Standard RIs save up to 72% off On-Demand; Compute Savings Plans save up to 66%. The discount applies at billing time. Nothing is migrated.

Compute Savings Plans are the flexible default: the discount floats across EC2 (any Region, family, size or OS), Fargate and Lambda. They survive a family change or a Graviton migration. EC2 Instance Savings Plans lock you to one family in one Region for a deeper discount; use them only for a baseline you are sure will not change.

Reserved Instances are still the commitment tool for managed data services: RDS, ElastiCache, Redshift and OpenSearch. Savings Plans do not cover those. A steady production database left On-Demand is often the second-largest avoidable line on the bill.

If you are spending AWS credits, plan the cash: AWS promotional credits do not pay Savings Plans or Reserved Instance upfront fees. (AWS credit terms). No Upfront commitments avoid the problem.

IIIRight-sizing and deleting idle resources

Commitments make the rate cheaper; right-sizing makes the quantity correct. Do the right-sizing analysis first so you commit to the right baseline.

AWS Compute Optimizer reads CloudWatch metrics and flags over-provisioned EC2 instances, EBS volumes, Lambda memory, ECS services and RDS instances, with a target size and projected savings. An instance at 8% CPU for a month is a clear downsize; one size down roughly halves its cost.

Deleting what should not run at all is cheaper still: dev instances left on overnight, load balancers and NAT Gateways with no targets, unattached EBS volumes, old snapshots and AMIs, idle RDS instances from a finished migration. They cost money and deliver nothing.

Scheduling is the close cousin. A dev environment that runs 12 hours a day on weekdays uses 60 of the 168 hours in a week, so stopping it outside those hours removes about 64% of its compute cost. Production behind an Auto Scaling group pays for the capacity demand needs, not a fixed peak.

This lever is low-risk and reversible, which is why it belongs with the quick wins. The EC2 right-sizing guide goes deeper.

IVSpot Instances and Graviton: structurally cheaper compute

Right-sizing and commitments optimize the compute you run today. Spot and Graviton change the compute itself: bigger savings, more engineering, real tradeoffs.

Spot Instances are spare EC2 capacity at up to 90% off On-Demand (AWS EC2 Spot). AWS can reclaim one with a two-minute warning. That suits interruptible, stateless or retry-tolerant work: batch, CI runners, data processing, and stateless services behind a queue or load balancer. On Kubernetes, Karpenter or EKS managed node groups mix Spot and On-Demand and drain Spot nodes on the reclaim signal. Keep stateful singletons such as a primary database off Spot. See the Spot guide.

Graviton is AWS's ARM processor line. AWS says Graviton instances give up to 40% better price-performance than comparable x86 instances (AWS Graviton). Interpreted and managed runtimes (Python, Node, Java, Go, .NET) and most managed services port with little or no code change; native dependencies and x86-only agents need a rebuild and a test pass. Move to Graviton before you buy EC2 Instance Savings Plans, or you commit to a family you are about to leave. See the Graviton migration guide.

They combine well: a Savings-Plan-covered Graviton baseline for steady services, Spot for everything interruptible, and On-Demand only for the spiky top layer.

VStorage tiering and data transfer

Compute gets the attention, but storage and data transfer are where bills quietly grow, and where a few configuration changes recover money with little risk.

S3: Intelligent-Tiering moves objects between access tiers based on use, so cold data drifts to cheaper storage without lifecycle rules. Where access patterns are known, explicit lifecycle policies (Infrequent Access, then Glacier classes, then expiry) do the same more aggressively. See the S3 cost guide.

EBS: moving volumes from gp2 to gp3 is the cleanest single win. AWS prices gp3 20% lower per GB than gp2 and lets you set IOPS and throughput separately from size (AWS EBS). Add deleting unattached volumes and pruning old snapshots.

Data transfer is the line nobody planned. The usual causes: NAT Gateway data processing (billed per GB on top of the hourly charge), cross-AZ traffic between services or replicas, and internet egress. The fixes are architectural: send S3 and DynamoDB traffic through gateway endpoints, which have no extra charge (AWS VPC docs), keep chatty components in one AZ where resilience allows, and put a CDN in front of egress-heavy traffic. The data transfer and NAT Gateway pages break it down line by line.

VIVisibility and governance: the FinOps operating model

Every lever above is a one-time recovery. Governance stops the waste from coming back.

You cannot manage what you cannot see, and you cannot allocate what you do not tag. The native visibility layer:

• Cost Explorer: spend by service, account and tag, plus Savings Plans and right-sizing recommendations. AWS Cost Explorer forecasts spend up to 18 months ahead (monthly view). See the Cost Explorer guide.
• AWS Budgets: thresholds per team, account or service, with forecast alerts before month-end and optional Budget Actions.
• Cost Anomaly Detection: machine-learning monitors that flag unusual spend (a runaway job, a leaked key, a data-transfer leak) instead of waiting for the invoice.
• Cost allocation tags: tag by team, environment, product and cost center so spend can be shown back or charged back to whoever incurred it.
• Cost and Usage Report (CUR): the most detailed billing data AWS produces, queryable in Athena or a FinOps tool.

Tie the tools together with the FinOps operating model, which runs in three repeating phases. Inform: visibility and allocation, so every team sees what it spends. Optimize: act on it with the levers above. Operate: keep it running with anomaly alerts, regular commitment reviews, and cost as a metric in engineering decisions. The native tools guide and the FinOps page go deeper.

VIIQuick wins vs structural work, and the order to do them in

Sequence is what separates a small dent from a large reduction. Run the levers in an order where each step sets up the next.

Quick wins are cheap and reversible: turn on Cost Explorer and a budget so you can measure, delete idle resources, move gp2 to gp3, enable S3 Intelligent-Tiering, prune volumes and snapshots, and schedule non-production environments off outside working hours. None of it needs an architecture change.

Structural work pays back more but takes real engineering: the commitment portfolio sized to your right-sized baseline, Graviton for eligible workloads, Spot for interruptible compute, and data-transfer re-architecture. It needs testing and sometimes a rollback plan.

The order that works: (1) measure; (2) clean up; (3) right-size; (4) re-architect compute with Graviton and Spot; (5) commit against the stable baseline; (6) govern with anomaly detection, tagging and a review cadence. Commit last, not first.

VIIIHow to find the waste, and who can do the work

The levers are known. The hard part is finding which ones apply to your bill, sizing them, and doing the rework while the team ships product.

A first pass you can do yourself: sort Cost Explorer by service to see where the money sits, pull Compute Optimizer's recommendations, list unattached EBS volumes and idle Elastic IPs, check whether steady compute is covered by commitments, and trace the data-transfer line to NAT Gateways and cross-AZ traffic.

The structural work is where most teams stall, not for lack of knowledge but for lack of time. A vetted AWS partner can run a structured cost audit (often anchored on the Cost Optimization pillar of a Well-Architected Review), hand you a prioritized list with dollar estimates, and do the rework. The bill audit page covers the scope.

Who pays. CloudRoute is free for startups; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. The partner's audit and rework are an engagement you agree with the partner before work starts, and the savings usually pay for it. AWS funding that only partners can file attaches to qualifying work, not to cost work on its own: MAP if you are moving more workloads onto AWS, POC if you are testing a new setup, or incremental workload (IW) funding if you are launching new work on AWS. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. Founders apply for AWS Activate credits themselves (how Activate works).