Skip to content
iMOBDEV
DevOps & CloudDevOpsAWS

AWS Cost Optimization: How We Cut Our Cloud Bill by 40%

AWS bills grow organically with your business. Without active cost management, you'll overspend by 30–50%. Here are the specific techniques we used to reduce a $180K/month AWS bill to $108K without sacrificing performance.

Vikram Patel

DevOps & Cloud Architect

11 min read

Cost Visibility First

You can't optimize what you can't measure. The first step is enabling AWS Cost Explorer with detailed billing, creating cost allocation tags for every resource, and setting up AWS Budgets with alerts at 50%, 80%, and 100% of forecasted spend. We tag every resource with team, environment, and project — this enables chargeback and makes teams accountable for their infrastructure costs.

The biggest cost surprise we found: 23% of our bill was for resources that no one could identify. Untagged resources, abandoned snapshots, unattached EBS volumes, and idle load balancers. A cleanup sprint eliminated $18K/month in wasted spend within the first week.

Right-Sizing Compute

AWS Compute Optimizer analyzes CloudWatch metrics and recommends right-sized instance types. We found that 60% of our EC2 instances were over-provisioned — running at under 20% CPU utilization on average. Downsizing from m5.xlarge to m5.large saved $22K/month with zero performance impact. The key metric is P99 CPU utilization, not average — an instance that averages 15% CPU but hits 90% at P99 shouldn't be downsized.

Auto-scaling was the second compute optimization. Three services running 24/7 on fixed instances had clear usage patterns — high during business hours, near-zero at night. Implementing time-based auto-scaling (scale down to 1 instance at night, scale up to 4 during peak) saved $14K/month.

Spot Instances Strategy

Spot instances are 60–90% cheaper than on-demand. For fault-tolerant workloads — batch processing, CI/CD runners, data processing pipelines — spot instances are an obvious win. We moved our entire CI/CD pipeline (200 GitHub Actions runners) to spot instances, saving $12K/month. The implementation: use EC2 Fleet with diversified instance type selection to minimize interruption risk, and implement graceful interruption handling with the Spot termination notice.

For stateful services, we use a mixed strategy: on-demand instances for the primary (stateful) nodes and spot instances for read replicas and stateless workers. If spot capacity is interrupted, on-demand instances handle the load until spot is available again.

Reserved Instances and Savings Plans

For predictable, steady-state workloads, Compute Savings Plans (1-year, all-upfront) provide 30–40% discount vs on-demand. We analyzed our 12-month usage history and committed to Savings Plans for our baseline usage. The commitment was $45K/month — less than our previous on-demand baseline of $72K/month for the same compute. The remaining variable usage runs on on-demand or spot.

Storage Optimization

S3 storage costs grow silently. We implemented S3 Lifecycle policies: objects older than 90 days move to S3 Standard-IA (60% cost reduction), objects older than 365 days move to S3 Glacier Deep Archive (90% cost reduction). For our data lake (40TB of historical data), this saved $8K/month. We also enabled S3 Intelligent-Tiering for access patterns we couldn't predict — it automatically moves data between tiers based on actual access patterns.

EBS volumes were the second storage optimization. Unattached volumes, oversized volumes, and volumes using gp2 instead of gp3 (20% cheaper with better performance) accounted for $6K/month in savings.

Data Transfer Costs

AWS data transfer costs are notoriously opaque. Inter-region data transfer, NAT Gateway data processing, and cross-AZ traffic add up. We reduced data transfer costs by: moving to VPC endpoints for AWS services (eliminating NAT Gateway charges for S3 and DynamoDB traffic), consolidating regions (we were running in 3 regions when 2 would suffice), and implementing VPC flow logs to identify unexpected cross-AZ traffic patterns.

Architectural Changes

The biggest savings came from architectural changes, not configuration tweaks. Moving three always-on services to AWS Lambda (pay-per-invocation) eliminated $15K/month in idle compute. Moving our primary database from RDS to Aurora Serverless v2 (which scales compute capacity automatically) saved $9K/month by eliminating over-provisioned database instances during off-peak hours. These changes required engineering investment but paid for themselves within 3 months. This is the same architectural review our AWS consulting team runs for clients before recommending any managed AWS services engagement, often alongside a broader DevOps services audit of the CI/CD pipeline.

Tags

DevOpsAWSCost OptimizationCloudFinOps
Share:

Vikram Patel

Author

DevOps & Cloud Architect

Vikram designs zero-downtime infrastructure on AWS and Kubernetes for high-traffic SaaS products. AWS Solutions Architect certified.

Need Expert Development Help?

From AI agents to mobile apps — iMOBDEV builds what your business needs.