Most engineering teams believe they have a reasonable handle on their AWS spend. Then someone runs a proper cost audit and discovers that 30–45% of their bill is attributable to resources nobody is actively monitoring — oversized instances running at 8% CPU utilization, forgotten development environments, data transfer patterns that made sense two years ago but were never revisited, and S3 buckets accumulating objects that should have been deleted or tiered six months ago. This is not a rare situation. It is, by most accounts, the default state of any AWS account that has been running for more than 18 months without a dedicated cost review process.
The Anatomy of an Oversized AWS Bill
Before prescribing fixes, it helps to understand where the money actually goes. For most application workloads, the breakdown looks roughly like this:
- EC2 compute: typically 40–60% of total spend
- RDS and managed databases: 15–25%
- Data transfer (egress): 10–20%, often underestimated
- S3 storage: 5–15% depending on data volume
- Support plan, NAT Gateway, and miscellaneous: 5–10%
The optimization levers differ by category. Compute waste is largely a rightsizing and commitment problem. Database waste is frequently an instance class problem. Data transfer waste is usually an architecture problem. Storage waste is a lifecycle policy problem. Treating all of them with the same tool — say, just moving everything to Reserved Instances — misses most of the saving opportunity.
Rightsizing: The Fastest Win
Rightsizing means matching your instance types and sizes to actual measured utilization rather than to peak theoretical demand or to the spec your engineer requested when capacity was less predictable.
AWS Cost Explorer's rightsizing recommendations and AWS Compute Optimizer both surface instances where average CPU utilization is below 40% over a 14-day window. The typical finding: a meaningful portion of running instances are one or two size categories larger than necessary. Downsizing an m5.2xlarge ($0.384/hr) to an m5.xlarge ($0.192/hr) cuts that instance's cost exactly in half, with no impact on an application running at 15% CPU.
Rightsizing checklist
- Enable AWS Compute Optimizer across all accounts in your organization
- Review recommendations weekly for the first month, then monthly
- Test downsized instances in staging before promoting to production
- Automate rightsizing triggers using AWS Systems Manager or a third-party tool like Spot.io or Densify for continuous enforcement
- Apply the same analysis to RDS instance classes — database CPU utilization above 30% is genuinely unusual for most transactional workloads
Savings Plans and Reserved Instances: Commit to What You Know
On-demand pricing is the most expensive way to run steady-state compute. AWS offers two main commitment-based discount mechanisms, and the choice between them matters.
| Mechanism | Discount Range | Flexibility | Best For |
|---|---|---|---|
| EC2 Instance Reserved Instances (1-yr, no upfront) | ~40% off on-demand | Locked to instance family and region | Stable, predictable workloads with known instance types |
| Compute Savings Plans (1-yr) | ~30–40% off on-demand | Applies across EC2, Fargate, Lambda regardless of instance family | Most production workloads; recommended default choice |
| EC2 Instance Savings Plans (1-yr) | Up to 72% off (3-yr, all upfront) | Flexible within an instance family in one region | Long-running, stable instance families where you have confidence |
| Spot Instances | 60–90% off on-demand | Interruptible with 2-minute notice | Batch processing, CI/CD runners, fault-tolerant stateless services |
A common mistake is buying Reserved Instances before rightsizing. If you commit to 20 m5.xlarge RIs and then discover that 12 of those instances should actually be m5.large, you have locked in overspend for a year. Always rightsize first, then commit.
Spot Instances: Where the Real Savings Live for Variable Workloads
Spot Instances are AWS's mechanism for selling unused capacity at dramatically reduced prices. The trade-off is that AWS can reclaim them with a two-minute warning when capacity is needed elsewhere. This sounds alarming, but for the right workloads it is entirely manageable.
Workloads well-suited to Spot:
- CI/CD build runners (GitHub Actions self-hosted, Jenkins agents, CodeBuild)
- Batch data processing (ETL pipelines, image resizing, report generation)
- Stateless API tier behind a load balancer with multiple instances
- Machine learning training jobs with checkpoint support
- Containerized workloads on ECS or EKS with mixed node groups
EKS managed node groups with Spot capacity and Karpenter for node provisioning is currently one of the most effective patterns for reducing compute costs on containerized workloads — Karpenter selects the optimal Spot instance type from a diversified pool, which dramatically reduces interruption rates while maintaining the cost benefit.
Eliminating Data Transfer Waste
NAT Gateway charges are among the most frequently cited "surprise" line items in AWS bills. Every byte that flows from a private subnet through a NAT Gateway to the internet (or to AWS services) incurs a data processing fee on top of normal data transfer costs.
Common fixes:
- VPC Endpoints: Traffic to S3 and DynamoDB can be routed through free gateway endpoints rather than through NAT Gateway, eliminating data processing charges on that traffic entirely
- Interface Endpoints: For other AWS services (Secrets Manager, SSM, ECR), interface endpoints cost a fixed hourly rate that is often cheaper than equivalent NAT Gateway data processing fees at scale
- CloudFront for egress: Traffic served through CloudFront is billed at CloudFront's lower egress rates rather than EC2's direct internet egress rates — and CloudFront's free tier covers 1 TB/month
- Avoid cross-AZ traffic where possible: Cross-availability-zone data transfer within a region costs $0.01/GB each direction. For high-throughput services, co-locating components in the same AZ reduces this charge at the cost of reduced redundancy — a trade-off to evaluate consciously
Storage Lifecycle Policies: Automate the Obvious
S3 Standard storage is priced at approximately $0.023/GB/month. S3 Intelligent-Tiering automatically moves objects between access tiers based on usage patterns, and objects that haven't been accessed for 90 days move to the Glacier Instant Retrieval tier at roughly $0.004/GB/month. For large repositories of infrequently accessed data — backups, logs, archived assets — this represents a substantial reduction.
Specific actions that take under an hour to implement and often generate immediate savings:
- Enable S3 Intelligent-Tiering on buckets containing objects older than 30 days that are accessed unpredictably
- Set lifecycle rules to expire or transition CloudWatch Logs log groups — default retention on log groups is "Never Expire", which means every debug log from 2021 is still accumulating storage costs
- Delete unattached EBS volumes. Volumes that were attached to terminated instances are not automatically deleted by default. Use AWS Trusted Advisor or a Lambda function to find and delete them.
- Release unassociated Elastic IPs — AWS charges $0.005/hr per unused EIP, which amounts to roughly $43.80/year per forgotten address
Building a Cost Governance Culture
One-time optimization projects produce one-time savings. Sustained cost reduction requires treating cloud spend as an engineering concern, not just a finance concern. That means tagging every resource with environment, team, and service tags from day one; setting AWS Budgets with 80%/100% alerts (free and five minutes to configure); including a cost check in sprint reviews; and assigning cloud cost ownership to a named engineer rather than leaving it as nobody's specific responsibility. Teams that do this consistently maintain lower waste ratios long after the initial optimization sprint is done.
Frequently Asked Questions
How do I find out which AWS services are driving my highest costs right now?
Go to AWS Cost Explorer, filter by the current month, and group by "Service". This gives you an immediate breakdown. Then drill down into the top two or three services by grouping by "Usage Type" to understand what specific usage is generating cost within each service. This two-level breakdown usually identifies the highest-leverage optimization targets within 30 minutes.
Is it safe to use Spot Instances for production web traffic?
Yes, with the right architecture. Run multiple Spot Instances across two or three Spot capacity pools (different instance types in different AZs), place them behind an Application Load Balancer, and configure your Auto Scaling Group to replace interrupted instances automatically. With capacity diversification, interruptions are infrequent (typically under 5% of instance-hours in most regions) and the ALB handles them gracefully. Many high-traffic production systems run their stateless tier entirely on Spot.
What is the difference between a Savings Plan and a Reserved Instance?
Reserved Instances commit you to a specific instance type, size, and region (or availability zone). Savings Plans commit you to a dollar-per-hour spend level in exchange for a discount, but that discount applies flexibly across any instance type, size, or region. For most teams, Compute Savings Plans are preferable to RIs because they do not become stranded when you change instance types — which happens more often than you would expect as your architecture evolves.
How quickly can I realistically expect to see savings after implementing these changes?
Rightsizing and lifecycle policies take effect within days. NAT Gateway optimization and VPC endpoints reduce costs immediately upon deployment. Savings Plans and Reserved Instance discounts apply from the hour of purchase. A focused two-week cost optimization sprint typically yields 25–45% reduction in the first monthly bill — the exact figure depends heavily on how much technical debt has accumulated in your account and whether your workloads are steady-state or highly variable.
Mexilet Technologies supports teams on exactly this kind of work through our cloud & DevOps services and software engineering team.
If your AWS bill feels higher than it should but you are not sure where to start, Mexilet Technologies has helped software teams across multiple industries restructure their cloud architecture for cost efficiency without downtime. Reach out to our Cloud and DevOps team — we will run a structured cost review, identify your top five waste categories, and give you a prioritized action plan with realistic saving estimates before any engagement begins.