All posts
AWS Cost Optimization: 30 Proven Ways to Cut Your Cloud Bill
Cloud2026-09-23Agentixly Team

AWS Cost Optimization: 30 Proven Ways to Cut Your Cloud Bill

A practical AWS cost optimization guide: 30 verified tactics across compute, storage, data transfer, databases and Kubernetes, plus a 30-day FinOps plan.

AWS cost optimization means systematically removing idle and oversized resources, matching each workload's pricing model (On-Demand, Savings Plans, Reserved Instances or Spot) to how steady its usage actually is, and moving data to cheaper storage tiers and network paths, all without cutting into reliability. Most teams that have never run a dedicated review are overpaying because of a short list of repeat offenses: no tagging, no commitment discounts on steady-state compute, instances nobody rightsized since launch day, and log retention left at the default of forever. This guide covers 30 concrete tactics AWS itself documents, grouped by where the waste actually hides, plus the review cadence that keeps savings from creeping back.

Why Does AWS Spend Creep Even When Usage Doesn't?

Cloud bills grow for reasons that have nothing to do with growth. Every resource is provisioned at On-Demand list price by default, and nobody circles back to buy a discount once it proves durable. Engineers size instances for a launch-day guess or a traffic spike, then never revisit the number once the workload stabilizes. Teams multiply across accounts faster than anyone reviews spend, and by the time a monthly bill lands on a VP's desk, it is already an aggregate of a hundred small decisions nobody remembers making.

AWS's own architectural guidance treats this as a first-class design concern rather than an annual cleanup: the Well-Architected Framework's cost optimization pillar defines cost optimization as the ability to run systems that deliver business value at the lowest price point, reviewed continuously, not once a year. The tactics below are organized the way waste actually accumulates: first you need to see it, then you fix the resources themselves, then you fix the pricing model underneath them.

30 Ways to Cut Your AWS Bill, Grouped by Where the Waste Hides

Work through these roughly in order. Visibility comes first because you cannot prioritize what you cannot see, and governance comes last because it is what stops the other 29 from reversing themselves in six months.

Visibility: See Where the Money Actually Goes

  1. Enforce a tagging taxonomy and make it mandatory. Require at minimum a cost center, environment and owner tag on every resource, and use AWS Organizations tag policies to block non-compliant launches rather than asking politely after the fact.
  2. Turn on the Cost and Usage Report and query it. The CUR is the only source with full line-item detail (resource ID, usage type, amortized commitment costs); load it into Athena or a BI tool instead of relying on dashboard summaries alone.
  3. Turn on AWS Cost Anomaly Detection. It is a free, machine-learning based feature that learns your normal spend pattern per service or account and alerts you within hours of a spike, well before a monthly invoice would.
  4. Build unit economics, not just totals. Divide infrastructure cost by paying customers, tenants or transactions so you can tell whether spend is growing because the business is growing or because something is leaking.

Compute: Pay Only for What You Actually Use

  1. Run AWS Compute Optimizer and act on its recommendations. It is free and analyzes real CloudWatch utilization to flag over- and under-provisioned EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions and Fargate services.
  2. Rightsize before you commit to anything. Buying a Savings Plan against an oversized instance locks in the waste for one to three years; fix the size first, then buy the discount.
  3. Move eligible workloads to Graviton. AWS states its Graviton processors cost up to 20% less than comparable x86-based instances for the same workload and use up to 60% less energy, with no code change needed for most interpreted and JIT-compiled languages and a rebuild for compiled ones.
  4. Use Spot Instances for fault-tolerant workloads. Batch jobs, CI and CD runners, rendering and stateless web tiers can run at up to 90% off On-Demand pricing, with a two-minute interruption warning your automation needs to handle.
  5. Buy a Compute Savings Plan for your durable baseline. It applies automatically across EC2, Fargate and Lambda regardless of instance family, size or Region, at up to 66% off On-Demand.
  6. Reserve capacity you know will not change. For a pinned instance family in a fixed Region, an EC2 Instance Savings Plan or Standard Reserved Instance pushes the discount to up to 72%, see the comparison below before choosing.
  7. Schedule non-production environments off-hours. Dev, staging and QA environments that only need to run 50 hours a week instead of 168 cut their compute cost by roughly 70% just by stopping outside business hours.
  8. Eliminate zombie resources on a recurring basis. Unattached Elastic IPs, idle Application Load Balancers with zero targets, orphaned NAT gateways and forgotten proof-of-concept instances rarely show up in any single dashboard, which is exactly why they survive.

Storage: Stop Paying Standard Prices for Cold Data

  1. Set S3 Lifecycle policies on every bucket. Transition objects to a cheaper storage class or expire them automatically instead of leaving everything in S3 Standard indefinitely.
  2. Use S3 Intelligent-Tiering for unpredictable access patterns. AWS states it automatically saves up to 40% on infrequently accessed objects, up to 68% once data moves to the Archive Instant Access tier, and up to 95% in the Deep Archive Access tier, with no retrieval fees on the frequent-access tiers.
  3. Migrate EBS gp2 volumes to gp3. AWS confirms gp3 costs 20% less per GB than gp2 while including a baseline of 3,000 IOPS and 125 MB/s throughput at any volume size, provisionable independently of capacity.
  4. Delete orphaned snapshots and unattached volumes. Automated backup tools create EBS snapshots faster than anyone deletes them; a scheduled cleanup job against snapshot age and source-volume existence recovers this quietly every month.
  5. Right-size provisioned IOPS and throughput instead of over-buying. With gp3's independent provisioning, most workloads no longer need to over-provision capacity just to get acceptable performance, which was the main reason gp2 volumes ran oversized.

Data Transfer: The Line Item Nobody Reviews

  1. Replace NAT Gateway routes to AWS services with Gateway Endpoints. AWS confirms there are no hourly or data processing charges for Gateway Type VPC endpoints to S3 and DynamoDB, while NAT Gateway traffic is billed hourly plus per gigabyte processed regardless of direction.
  2. Add Interface Endpoints for other chatty AWS API calls. Services like Secrets Manager, ECR and CloudWatch Logs support AWS PrivateLink interface endpoints, which keep traffic off the NAT gateway path entirely for API-heavy workloads.
  3. Put CloudFront in front of public content and APIs. Serving cacheable content from the edge reduces repeated origin data transfer and often reduces total egress cost compared to serving every request directly from a Region.
  4. Keep high-volume service-to-service traffic inside one Availability Zone. Cross-AZ data transfer is billed in both directions; AZ-aware routing or co-locating chatty services measurably reduces this for high-throughput internal traffic.

Databases: Right-Size and Right-Buy

  1. Right-size RDS and Aurora instances using real utilization data. Performance Insights plus Compute Optimizer's RDS recommendations catch the same over-provisioning pattern common in EC2, just less visible because nobody watches database instance metrics as closely.
  2. Move spiky or dev and test database workloads to Aurora Serverless v2. It scales capacity up and down automatically in fine-grained increments, so you stop paying for peak capacity that only exists a few hours a day.
  3. Commit to RDS Reserved Instances only after two or three months of stable data. Databases are expensive to resize compared to stateless compute, so buy the commitment after you trust the number, not before.

Kubernetes: Bin-Pack and Autoscale Instead of Over-Provisioning Nodes

These tactics assume Kubernetes is already the right call for the workload; if you are still deciding between Kubernetes, serverless containers and a PaaS, work through our Kubernetes vs serverless vs PaaS decision guide first, since the wrong platform choice costs more than any tuning below can recover.

  1. Replace static node groups with Karpenter. Karpenter is an open-source Kubernetes node autoscaler, governed under the Kubernetes SIGs project with stable AWS support, that provisions right-sized nodes just in time for unscheduled pods instead of scaling a fixed instance-type node group.
  2. Mix Spot capacity into Karpenter node pools with automated consolidation. Karpenter continuously looks for cheaper instance-type combinations and consolidates workloads onto fewer nodes as pods scale down, which a static Cluster Autoscaler configuration does not do on its own.
  3. Set pod resource requests to match real usage, not launch-day guesses. Over-requested CPU and memory blocks bin-packing regardless of how good your node autoscaler is; fix requests before tuning the autoscaler further.

Logs and Observability: Retention Has a Price Tag

  1. Set CloudWatch Logs retention explicitly on every log group. Log groups default to never expiring, which means you pay indefinite storage for debug-level logs from a feature nobody remembers shipping.
  2. Route high-volume, rarely queried logs to S3 with Athena instead of CloudWatch Logs Insights. For audit trails and verbose application logs you query a few times a year, object storage plus a query engine costs a fraction of paying premium log-ingestion rates indefinitely.

Governance: Make the Savings Stick

  1. Set AWS Budgets with alerts per team, environment or cost center, and run a recurring review. A budget without a named owner and a standing meeting is a dashboard nobody opens; the review cadence is what turns a one-time cleanup into a lasting reduction.

Which Tactics Are Quick Wins and Which Take Real Engineering Time?

Not every tactic deserves the same priority. Quick wins fund the strategic work: start with the left column, use the recovered budget and credibility to justify the right column.

| Category | Example Tactics | Typical Effort | Commitment Risk | | --- | --- | --- | --- | | Quick win | Zombie resource cleanup, log retention, Gateway Endpoints, non-prod scheduling | Hours to days | None | | Quick win | S3 lifecycle policies, gp2 to gp3 migration | Days | None | | Strategic | Compute and EC2 Instance Savings Plans | Days to model, 1 to 3 year commitment | Medium, based on usage stability | | Strategic | Graviton migration | Days to weeks per service | Low, mostly testing effort | | Strategic | Karpenter adoption, Aurora Serverless v2 migration | Weeks | Low to medium, architecture change | | Strategic | FinOps governance cadence and unit economics | Ongoing | None, but requires organizational buy-in |

How Much Could You Actually Save?

The honest answer is that it depends entirely on how much waste and un-optimized pricing exists in your account today, and any total-bill percentage you see quoted without those assumptions stated is not a fact, it is a guess. The math below is illustrative only, built from the individual AWS-published figures cited earlier in this guide, not a guarantee.

Illustrative scenario: assume a mid-market SaaS company spends approximately USD 40,000 a month on AWS: 55% compute (EC2 and Fargate), 20% databases (RDS), 15% storage (S3 and EBS) and 10% data transfer and other services. Assume it is currently 100% On-Demand with average CPU utilization near 35%, no lifecycle policies, and NAT Gateway routing all S3 traffic.

  • Rightsizing the compute layer to real utilization: roughly 20 to 30% of the USD 22,000 compute line, based on typical over-provisioning gaps AWS's own Compute Optimizer commonly surfaces.
  • Applying a Compute Savings Plan to the now-rightsized steady-state baseline (assume 70% of compute is steady, 30% is bursty): up to 66% off that 70% slice per AWS's published rate.
  • Storage lifecycle policies and gp3 migration on the USD 6,000 storage line: 20% from the gp3 switch alone, per AWS's published rate, before any Intelligent-Tiering effect.
  • Gateway Endpoints removing NAT Gateway charges for S3 and DynamoDB traffic: a smaller absolute number, but often a surprising percentage of the data-transfer line specifically.

Stacking effects do not simply add, since rightsizing changes the base that a Savings Plan percentage applies to. Treat any total-bill figure, including ones in this example, as a hypothesis to validate against your own Cost and Usage Report, not a number to put in a budget.

What Does a 30-Day FinOps Action Plan Look Like?

Use this as a starting checklist. It follows the FinOps Foundation's Inform, Optimize, Operate structure: you cannot optimize what you have not measured, and you cannot sustain a discount you never turned into a habit.

  1. Days 1 to 3: Turn on the data sources. Enable the Cost and Usage Report, Cost Anomaly Detection and Compute Optimizer if they are not already on; none of the three cost anything extra to enable.
  2. Days 4 to 7: Establish the tagging baseline. Audit current tag coverage, define the mandatory tag set, and enforce it going forward with an Organizations tag policy.
  3. Days 8 to 10: Run the zombie-resource sweep. Identify and remove unattached EIPs, idle load balancers, orphaned snapshots and unused NAT gateways.
  4. Days 11 to 14: Ship the free architecture wins. Apply S3 lifecycle policies, migrate gp2 volumes to gp3, add Gateway Endpoints for S3 and DynamoDB, and set explicit CloudWatch Logs retention.
  5. Days 15 to 18: Rightsize compute and databases. Work through Compute Optimizer's EC2, EBS and RDS recommendations, prioritized by dollar impact.
  6. Days 19 to 23: Model the commitment purchase. Use 60 to 90 days of post-rightsizing usage data to size a Savings Plan or Reserved Instance purchase; buy in stages rather than all at once.
  7. Days 24 to 26: Schedule non-production environments and evaluate Spot. Turn off dev and staging outside business hours, and move eligible batch or CI workloads onto Spot.
  8. Days 27 to 30: Stand up the governance layer. Set AWS Budgets with alert thresholds per team, assign an owner, and put a monthly cost review on the calendar with engineering and finance both in the room.

Savings Plans vs Reserved Instances: Which Should You Buy?

Both structures trade a time commitment for a discount off On-Demand pricing, but they trade flexibility differently, and picking wrong is expensive for one to three years.

| Factor | Compute Savings Plans | EC2 Instance Savings Plans | Standard Reserved Instances | | --- | --- | --- | --- | | Maximum discount (AWS-published) | Up to 66% | Up to 72% | Up to 72% | | Applies across instance families | Yes | No, one family per Region | No, one family per Region and AZ | | Applies across EC2, Fargate, Lambda | Yes | No, EC2 only | No, EC2 only | | Best fit | Mixed or evolving architectures | Stable, pinned EC2 workloads | Stable, pinned EC2 workloads | | Commitment term | 1 or 3 years | 1 or 3 years | 1 or 3 years |

Most companies with more than one workload type should split the commitment: cover the truly durable, pinned baseline with EC2 Instance Savings Plans or Standard Reserved Instances for the deeper discount, and cover everything else with a Compute Savings Plan sized conservatively, since it is easier to add a second commitment later than to unwind one that no longer matches your architecture.

How Agentixly Approaches AWS Cost Optimization

At Agentixly, cost work sits inside our cloud and DevOps engineering practice, not as a separate audit that hands you a PDF and disappears. A typical engagement runs in five phases:

  1. Cost and architecture audit. We pull your Cost and Usage Report, tag coverage and Compute Optimizer output into a single prioritized backlog, ranked by dollar impact and implementation effort.
  2. Quick-wins sprint. Zombie resource cleanup, lifecycle policies, gp3 migration, Gateway Endpoints and log retention typically ship within the first two weeks, with no commitment risk.
  3. Commitment strategy. We model Savings Plan and Reserved Instance purchases against 60 to 90 days of your actual usage, then bring the purchase plan to your finance stakeholders for sign-off before anything is bought.
  4. Architecture-level changes. Where they make sense for your stack, we implement Graviton migrations, Karpenter adoption and database right-sizing as part of your existing infrastructure-as-code, not a side branch.
  5. FinOps handoff. You get budgets, alerts and a documented monthly review cadence owned by your team, plus the runbook to keep running it without us.

Everything is implemented in your own AWS account and your own repositories, consistent with how we handled the operational side of migrations in our cloud migration strategy guide. If your team needs the discipline maintained after the engagement, that cadence can continue under a DevOps as a service arrangement instead of falling back to nobody's job.

The Bottom Line

AWS cost optimization is not one project with an end date. It is visibility work, rightsizing work and a pricing-model decision repeated across every workload, backed by a governance cadence that stops the savings from quietly reversing. Start with the free wins (tagging, Cost Anomaly Detection, Compute Optimizer, Gateway Endpoints), rightsize before you commit to anything, and only then buy Savings Plans or Reserved Instances against numbers you trust. The same discipline matters more, not less, as you scale: see our guide to scaling SaaS architecture for what breaks (and what it costs) at each growth stage, and if disaster recovery standing costs are part of your bill, our cloud disaster recovery guide covers that trade-off directly.

If you want an outside team to run this audit, model your commitment purchases or take the ongoing FinOps cadence off your plate, Agentixly's cloud and DevOps team can help. Get in touch and tell us what your last AWS bill actually included.

All Posts