We've reviewed hundreds of AWS bills, and the savings that add up are rarely where teams look first: not in compute, but in the storage and cleanup nobody reviews. You can run most of these AWS cloud cost reduction strategies natively. The one that keeps growing after everything else is optimized is backup, which is where we spend ours.
1. Read and understand your bill
One team spent three weeks onboarding a cost tool. The whole time, four unused MSSQL Server Enterprise instances from an old testing project were sitting on their bill. Finding and terminating those instances removed $80k/month, more than any automated tool had flagged. Know what's on your bill before you buy something to manage it.
Here's how to understand what you're paying for:
- Enable AWS Cost and Usage Reports (CUR): More granular than Cost Explorer and the foundation for any real cost analysis.
- Activate cost allocation tags in the Billing console so spend maps to teams, environments, and applications.
- Deploy CUDOS (short for AWS Cloud Intelligence Dashboards): What most FinOps practitioners use day-to-day, rather than Cost Explorer alone.
- Use Cost Explorer, filtered by service and account, to find where the largest numbers are.
For multi-account environments, consolidate billing under AWS Organizations. You can't optimize what you can't see in full.
No tool finds your biggest wins faster than looking at the bill yourself. Spend an hour in Cost Explorer before evaluating any third-party platform.
2. Delete idle and orphaned resources
Idle resources are charged at full price and deliver zero value, and they accumulate in environments that haven't been audited recently. The first clean-up audit in a long-running environment almost always surfaces more than anyone expected.
Resources to audit and cut:
- Unattached Elastic Block Store volumes (EBS): left behind when instances are terminated. AWS Trusted Advisor flags these automatically.
- Unused Elastic IPs: billed whenever they're not attached to a running instance
- Idle load balancers: processing fewer than 100 requests/day, also flagged by Trusted Advisor
- Stopped EC2 instances: no compute charge, but attached EBS storage still bills
- Old Amazon Machine Images (AMIs) and their snapshots: most teams skip snapshot deletion when deregistering AMIs, and those accumulate for years
- gp2 EBS volumes: migrating to gp3 cuts storage costs by 20% with no downtime. It's one of the cleanest wins we see in almost every environment we audit.
We run this cleanup on every account at least quarterly. The first pass in a long-running environment often surfaces more than anyone expected.
3. Fix CloudWatch log retention
CloudWatch log groups default to "never expire," which means every log ever written is billing you indefinitely. In environments that have been running for two or more years, this is often a high, invisible cost.
Setting retention is a five-minute fix per log group, and most of that data has no operational value after 30-90 days. We've seen teams wipe out hundreds of dollars a month from this alone, sometimes more.
Here is what to do:
- Go to CloudWatch, then Log Groups, and sort by stored bytes.
- Set retention periods on every group (30 days for debug, 90 days for application logs, 365 days where compliance requires).
- Use AWS Config or a Lambda function to enforce retention on new log groups going forward.
4. Eliminate NAT Gateway charges with VPC endpoints
NAT Gateway traffic to S3 or DynamoDB incurs a $0.045/GB charge and can be eliminated for free. This gets missed because it shows up as a networking line item, not compute or storage, and it's one of the more common surprises we find when digging into a bill for the first time.
A Virtual Private Cloud Gateway Endpoint (VPC) for S3 and DynamoDB routes that traffic through AWS's private network instead. No charge, no performance tradeoff.
Here is what to do:
- Run Cost Explorer filtered to "NAT Gateway" to size the opportunity.
- Create VPC endpoints for S3 and DynamoDB in every VPC, routing traffic to those services.
- Use VPC Flow Logs (stored in S3, not CloudWatch, to keep analysis costs low) to map other high-volume Network Address Translation (NAT) traffic before making further changes.
5. Cut backup and snapshot storage costs
Backup storage is one of the most underestimated line items on any AWS bill because the cost mechanics differ by storage type, and no native tool shows the full picture. Most teams treat it as one problem. It is four.
Problem 1: EBS snapshot sprawl. Snapshots are incremental, and manual ones have no automatic expiry. Unless you schedule them through Amazon Data Lifecycle Manager or AWS Backup, they persist until someone deletes them, so terminated volumes and abandoned projects leave snapshots behind that nobody owns.
Problem 2: S3 versioning without lifecycle rules. Versioning with no lifecycle rule lets every overwrite and delete marker pile up indefinitely. Lifecycle rules work on a daily cadence, so the soonest you can expire a noncurrent version is 24 hours out.
Cross-Region Replication doubles the problem unless rules are set on both buckets, and it bills as storage rather than backup, which is why it gets missed.
Problem 3: Forgotten RDS retention. RDS defaults to 7-day retention that most teams never revisit. Automated backups are incremental, so cost scales with change rate and retention window, not a flat multiple of database size, and AWS only includes free backup storage up to your provisioned size. On a growing production database, longer windows add up quietly.
Problem 4: Glacier retrieval and request costs. Glacier’s three tiers price differently, and expedited retrievals (about $0.03/GB) are charged whether or not the restore completes. Archive and infrequent-access tiers also bill a 128KB minimum per object and charge for PUT and transition requests, which punishes buckets full of small backup objects.
None of these sit in the same place. EBS, RDS, S3, and Glacier charges scatter across separate Cost Explorer line items and accounts, with no native view of your full backup footprint.
That fragmentation is the visibility gap Eon’s Cloud Backup Posture Management (CBPM) closes. Where AWS tools scatter backup charges across EBS snapshots, RDS backups, and S3 versioning, Eon gives you one view of your entire backup footprint across accounts and regions: what is protected, what is drifting out of policy, and what is growing your bill.
It discovers and classifies every resource without manual tagging, enforces backup policies automatically, and surfaces coverage gaps next to cost waste, with no agents, appliances, or hidden API fees.
Because backups are searchable and queryable, you restore only the records you need, rather than rehydrating entire snapshots. NETGEAR, for instance, recovered a 10TB SQL Server database 88% faster after switching, while cutting backup storage costs 35%. Across teams that switched to Eon, these savings reach up to 50% through cloud-native deduplication, compression, and incremental snapshots, without losing coverage.
If you're working with native AWS tools for now:
- Delete EBS snapshots outside your retention window, then put new ones on a Data Lifecycle Manager schedule.
- Set lifecycle rules on every versioned S3 bucket, source, and replication destination; expiring old versions is the biggest win.
- Review RDS automated-backup retention per database, not by account default.
- Check the Glacier retrieval tier before any large restore, and watch for sub-128KB objects in archive tiers.
6. Switch from on-demand to Savings Plans
The most common pattern we see: teams that have been running production workloads for 12+ months and are still paying on-demand rates because committing to a Savings Plan felt risky. It's not. On-demand is the expensive default, not the safe one, and every month without a commitment is money that doesn't come back.
According to AWS, Compute Savings Plans cut EC2 costs by up to 66% compared to on-demand pricing. They apply automatically across instance families, sizes, regions, OS types, and Fargate, making them more flexible than older Reserved Instance contracts.
They're also easier to commit to because you're not locking into a specific configuration.
How to buy a Savings Plan in four steps:
- Open Cost Explorer and go to Savings Plans recommendations.
- Set parameters: Compute, 1-year, no upfront.
- Review the recommended hourly commitment based on your trailing usage.
- Purchase.
One rule worth following: Commit to 70-80% of your stable baseline, not 100%. Over-committing means paying for capacity you can't utilize. We've seen teams lock in too aggressively on a Savings Plan, then get burned when they need to terminate underused instances. Leave room for that.
For databases and managed services (RDS, ElastiCache, OpenSearch), use Reserved Instances instead. Same process, same recommendations tab in Cost Explorer.
7. Right-size your EC2 instances
AWS Compute Optimizer analyzes CloudWatch metrics and automatically identifies over-provisioned EC2 instances, including cross-family recommendations such as moving from M5 to M7g Graviton, which can improve price-performance by up to 40%.
Always right-size before buying a Savings Plan or Reserved Instance. Committing to an over-provisioned resource locks in the waste.
Here is what to do:
- Enable Compute Optimizer (free) in the AWS Console.
- Filter for instances flagged as over-provisioned by 30% or more.
- Validate against memory and I/O, not just CPU. A CPU-idle instance can still be memory-constrained, and we've caught that more than once.
- Test in non-production first, then roll to production.
Most teams are surprised by how many over-provisioned instances Compute Optimizer flags on the first run, and even more surprised that nobody flagged them sooner.
8. Right-size your databases
RDS and Aurora clusters are among the most over-provisioned resources we see, and the pattern is almost always the same: sized for peak load at launch and never revisited.
The database team knows the utilization is low, but nobody wants to be the person who downsizes a production database before a busy period.
Before buying Reserved Instances, check:
- Performance Insights and Enhanced Monitoring for actual utilization over the last 30 days.
- Multi-AZ on non-production databases doubles instance costs and isn't justified outside production.
- Aurora Serverless v2 for variable-load workloads, which scales to near-zero during off-hours.
For dev and test databases that are not in active use, the RDS Instance Scheduler stops and starts instances on a schedule. Most teams see a 60-70% cost reduction on non-production databases from this alone.
9. Run non-critical workloads on Spot Instances
Most teams run everything on on-demand instances out of habit, even workloads that don't need guaranteed availability. The clearest sign this is happening: CI/CD pipelines, batch jobs, and data processing workloads running on on-demand EC2 that could be interrupted without any user impact.
That's purely a configuration choice, and it's an expensive one. Spot Instances save up to 90% compared to on-demand and are the right choice for workloads that can handle a 2-minute interruption. That includes batch processing, data pipelines, CI/CD build jobs, dev and test environments, stateless application tiers, and ML training with checkpointing enabled.
The practical setup: use EC2 Auto Scaling groups with mixed instance types and purchase options. Savings Plans cover the stable baseline; Spot handles variable demand.
10. Fix your auto-scaling configuration
Most teams enable auto-scaling but set minimum instance counts too high, so environments run at peak sizing around the clock even when demand is low. It's one of those things that looks fine in the console but shows up clearly in the bill once you know what to look for.
Three auto-scaling settings that are usually misconfigured:
- Minimum capacity: should reflect true off-hours demand, not a static safety buffer set once and forgotten.
- Target tracking scaling over step scaling: more responsive and simpler to manage.
- Predictive scaling for workloads with consistent daily patterns: it provisions ahead of demand rather than reacting after the fact.
Properly configured auto-scaling typically cuts compute costs by 20-35% on variable workloads compared to static peak sizing.
11. Enable S3 Intelligent-Tiering
S3 cost optimization breaks into two distinct problems, depending on whether the data is active or backup-related, and the fixes differ for each.
For active data with unpredictable access patterns, S3 Intelligent-Tiering automatically moves objects to lower-cost tiers based on actual access frequency, with no manual management needed.
According to AWS's pricing page, objects move to the Infrequent Access tier after 30 days of inactivity, offering 40% savings, and to the Archive Instant Access tier after 90 days, offering 68% savings.
For backup-related object storage, the cost drivers are different. Versioning growth, replication overhead, and missing lifecycle policies are the areas backup readers should focus on.
Buckets used for backups often have versioning enabled with no expiry rule, replication running to a second region with no lifecycle rules on the destination, and Glacier transitions set without a clear restore plan.
Those three issues together can make S3 backup costs grow faster than any other line item on the bill.
Here is what to do:
- Enable S3 Intelligent-Tiering for active buckets with unpredictable access patterns
- Set lifecycle rules on every backup bucket, both source and destination, if replication is enabled
- Use S3 Storage Lens to identify your highest-cost buckets and whether the cost is from active storage, versioning, or replication
S3 costs for object versioning, replication, and stored backup data are significant line items that are often overlooked entirely. We cover how to manage S3 backup costs and coverage here.
How to prioritize these 11 strategies
Not all 11 strategies deliver equal results at the same time. Here's the order that works:
Weeks 1-2: Strategies 1-5 (read the bill, delete idle resources, fix CloudWatch, fix NAT Gateway, cut backup costs). These require no architectural changes and no spending commitments. Most teams find their biggest wins here.
Months 1-2: Strategies 6-8 (Savings Plans, right-size EC2, right-size databases). These require utilization data from the cleanup phase first. Committing before you right-size locks in waste.
Ongoing: Strategies 9-11 (Spot instances, auto-scaling, S3 tiering). These are architectural and operational habits that compound over time rather than one-time fixes.
Build cost reviews into your operations
AWS environments drift. New resources get provisioned, workloads scale, and last quarter's right-sized instance is this quarter's bloated one. The teams we've seen sustain real savings treat cost reviews the same way they treat security reviews: scheduled, documented, and owned.
Build quarterly reviews into your operations cycle:
- Savings Plans coverage check: Are commitments still matching actual usage?
- Compute Optimizer: Have new rightsizing recommendations surfaced since last quarter?
- Idle resource sweep: Have you audited for orphaned resources in the last 90 days?
- Tagging compliance: Are untagged resources creating blind spots in your cost attribution?
Where Eon fits
Optimize everything on this list, and one line item still climbs: backup storage. It grows until someone looks, and most teams look too late.
That is the layer Eon focuses on: backup cost and coverage, not general cloud spend. Where native AWS tools scatter backup charges across EBS, RDS, and S3, CBPM shows the full footprint in one place and enforces policy as your environment changes.
Ready to cut backup cost and complexity? Book a demo and see your full backup footprint and what it's costing you in one view.
Frequently asked questions
What is the fastest way to reduce AWS cloud costs?
Deleting idle resources is the fastest way to reduce AWS costs. Unattached EBS volumes, unused Elastic IPs, stopped instances, and orphaned snapshots typically represent 5–15% of total spend in environments older than 18 months. Most can be identified and removed within days using AWS Trusted Advisor and Cost Explorer.
How much can Savings Plans reduce AWS cloud costs?
Compute Savings Plans reduce EC2, Fargate, and Lambda costs by up to 66% compared to on-demand pricing. A 1-year no-upfront plan typically delivers savings of 40-54%. The exact amount depends on how closely the commitment matches your stable baseline usage.
Do Savings Plans and Reserved Instances work together?
Yes. Savings Plans cover EC2, Fargate, and Lambda. Reserved Instances cover RDS, ElastiCache, Redshift, and OpenSearch. Most environments use both: Savings Plans for compute and Reserved Instances for managed database services. AWS Cost Explorer provides separate recommendations for each.
Are backup and snapshot costs a significant part of an AWS bill?
Yes, especially in data-intensive, multi-account environments. Backup costs are distributed across EBS, RDS, and S3 versioning line items with no native unified view, making them easy to underestimate. In environments running hundreds of TBs with undefined snapshot retention, backup storage can account for 15–25% of total cloud spend.
What is the difference between AWS Savings Plans and Reserved Instances?
The main difference between AWS Savings Plans and Reserved Instances is flexibility. Savings Plans apply automatically across instance families, sizes, regions, and OS types, whereas Reserved Instances lock you into specific configurations in exchange for a higher discount. Use Savings Plans for EC2, Lambda, and Fargate; use the latter for RDS and other managed databases.
