How to Reduce AWS Cloud Spend: A Practical FinOps Playbook (2026)

Why AWS bills grow faster than usage

AWS costs rarely rise because of a single bad decision. They grow through accumulation: test environments nobody turns off, snapshots retained forever, instances sized for a launch-day peak, logs ingested at full verbosity and data that crosses Availability Zones on every request. Each line item is small; together they routinely add up to a fifth or more of the bill.

The fix is not a one-time cleanup but an operating model. The FinOps Foundation frames it as three continuous phases — Inform, Optimize, Operate — and this playbook follows the same order.

Step 1: Get visibility before you cut anything

You can’t reduce what you can’t attribute. Before touching resources:

1. Enable Cost and Usage data exports (Data Exports / CUR 2.0) to an S3 bucket. This is the most detailed billing data AWS provides.
2. Activate cost allocation tags such as team, service and environment in the Billing console. Tags only appear in billing data after activation.
3. Use AWS Cost Categories to group accounts and tags into business-friendly owners.
4. Publish one report per owning team and review it with them monthly.

AWS Cost Explorer covers a single AWS organization well. If you also run Azure, GCP, Kubernetes, Snowflake or LLM APIs — or need to split shared costs fairly — a platform such as Vantage (opens in a new tab, affiliate link) gives every team its own cost report in hours, including Kubernetes namespaces and unit costs such as cost per customer or per 1,000 requests. Our cloud cost tool comparison covers the alternatives.

Step 2: Delete idle resources (the quick wins)

These carry almost no risk and often fund the rest of the program:

• Unattached EBS volumes — volumes in the available state are billed but serve nothing.
• Old EBS and RDS snapshots — set retention policies with Amazon Data Lifecycle Manager or AWS Backup.
• Idle load balancers and NAT Gateways in abandoned environments.
• Unused public IPv4 addresses — AWS charges for every public IPv4 address, attached or not, so release the ones you don’t need.
• Forgotten dev/test stacks — find them by last-modified date or by owner tag.
• Non-production schedules — stopping dev and test instances outside a 12-hour weekday window removes roughly two-thirds of their running hours.

Step 3: Rightsize compute and databases

Most instances are sized for a peak that rarely happens. Use AWS Compute Optimizer (free for its default recommendations) to find over-provisioned EC2, Auto Scaling groups, EBS, Lambda and ECS on Fargate.

• Start with instances averaging under about 40% CPU with low memory pressure over 14 or more days.
• Downsize one size at a time and watch latency and error rates for a week.
• For RDS, check CPU, memory, IOPS and connections together — databases are often over-sized for storage IOPS rather than compute.
• In Kubernetes, rightsize container requests, not just nodes; inflated requests strand capacity the cluster autoscaler can’t reclaim.

Step 4: Move to cheaper compute — Graviton and Spot

Graviton. AWS reports up to 40% better price-performance for Graviton-based instances compared with similar x86 instances. Managed services — RDS, Aurora, ElastiCache, OpenSearch, MSK — are usually the easiest wins because the change is an instance-type swap. For your own code, interpreted and JVM languages typically move with little effort; compiled native dependencies need multi-architecture builds.

Spot Instances. Spot capacity can be up to 90% cheaper than On-Demand. It suits stateless, fault-tolerant work: CI runners, batch and data processing, rendering, and Kubernetes worker pools spread across several instance types. Avoid it for single-instance databases or anything that can’t tolerate a two-minute interruption notice.

Step 5: Commit to your baseline with Savings Plans

Only after Steps 2–4 should you commit. Compute Savings Plans offer discounts of up to 66% versus On-Demand and apply flexibly across EC2 families, sizes, Regions, Fargate and Lambda. EC2 Instance Savings Plans reach up to 72% in exchange for less flexibility.

A practical approach:

1. Look at the lowest steady hourly compute spend over the last 30–60 days — that floor is your safe commitment.
2. Commit to roughly 70–80% of that floor first; layer additional commitments quarterly as usage stabilizes.
3. Use Reserved Instances for services Savings Plans don’t cover — RDS, ElastiCache, OpenSearch and Redshift.
4. Track coverage (percentage of eligible spend covered) and utilization (percentage of commitment used) monthly. Aim for high utilization first; coverage second.

Step 6: Fix storage

• Migrate gp2 to gp3. gp3 is about 20% cheaper per GB and lets you provision IOPS and throughput independently. The migration is online.
• Use S3 Intelligent-Tiering for data with unknown or changing access patterns, and lifecycle policies to move or expire objects you know age out.
• Clean up incomplete multipart uploads with a lifecycle rule — they are invisible in the console but billed.
• Review EFS for files that belong in infrequent-access storage classes.

Step 7: Cut data transfer and networking costs

Networking is the line item teams understand least:

• NAT Gateway data processing is charged per GB. Route S3 and DynamoDB traffic through gateway VPC endpoints, which have no hourly or data-processing charge.
• Cross-AZ traffic is billed in both directions. Keep chatty services and their databases in the same AZ where availability requirements allow, and enable topology-aware routing in Kubernetes.
• Serve public content through CloudFront; origin fetches from AWS origins are free and edge egress is generally cheaper than direct internet egress.

Step 8: Control logging and observability spend

• Set CloudWatch Logs retention on every log group — the default is to keep logs forever.
• Drop debug-level logs in production, sample high-volume access logs, and move archives to S3.
• Watch custom metrics and high-cardinality dimensions, which multiply costs quietly.

Step 9: Make it stick — governance and unit economics

Savings decay without an operating rhythm:

• AWS Budgets per team with alerts at 80% and 100% of forecast.
• AWS Cost Anomaly Detection monitors routed to the owning team’s channel.
• A monthly cost review — 30 minutes per team, top movers, open actions, realized savings.
• Unit-cost metrics such as cost per customer, per transaction or per 1,000 API calls. Absolute spend can rise while unit cost falls; that’s healthy growth.
• Guardrails via Service Control Policies and tag policies — for example, requiring an owner tag at creation time.

Vantage (opens in a new tab, affiliate link) helps here with per-team reports, anomaly alerts and unit-cost tracking across AWS and everything else you pay for, so the monthly review runs on one shared source of truth.

A 90-day AWS cost reduction plan

Phase	Weeks	Focus	Typical outcome
Inform	1–3	Data exports, tagging, owners, team reports	Every dollar has an owner
Quick wins	3–5	Idle resources, schedules, gp3	Fast, low-risk savings
Optimize	5–9	Rightsizing, Graviton, Spot pilots	Lower usage cost
Commit	9–11	Savings Plans and RIs on the new baseline	Lower rate cost
Operate	11–13	Budgets, anomaly alerts, monthly reviews	Savings that persist

Want to estimate the opportunity before you start? Use the ROI estimator with your monthly cloud spend.

The bottom line

Reducing AWS spend is a sequence, not a scramble: see it, clean it, shrink it, swap it, commit to it, then govern it. Start with free native tools such as AWS Cost Explorer and Compute Optimizer, and bring in a platform such as Vantage (opens in a new tab, affiliate link) when you need allocation and reporting that every team — and finance — will actually use.