The AWS Bill Problem
Every company that runs on AWS has the same experience. The first few months, costs are manageable. Then adoption grows, teams spin up resources, and twelve months later someone asks why the bill tripled. The answer is almost always the same: no one was paying attention.
Cloud cost management is not about being cheap. It is about spending intentionally. At DevOpsVibe, we regularly help clients reduce their AWS spend by 30-50% without sacrificing performance or reliability. Here are the strategies that consistently deliver results.
Start with Visibility: The Tagging Strategy
You cannot optimize what you cannot measure. A consistent tagging strategy is the foundation of every FinOps practice:
# Enforce these tags on every resource
Required Tags:
- Environment: dev | staging | production
- Team: platform | backend | data | ml
- Service: api-gateway | user-service | analytics
- CostCenter: CC-1001 | CC-1002
- ManagedBy: terraform | manual | cdk
Enforce tagging with an AWS Organization SCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireTags",
"Effect": "Deny",
"Action": [
"ec2:RunInstances",
"rds:CreateDBInstance",
"elasticloadbalancing:CreateLoadBalancer"
],
"Resource": "*",
"Condition": {
"Null": {
"aws:RequestTag/Environment": "true",
"aws:RequestTag/Team": "true",
"aws:RequestTag/Service": "true"
}
}
}
]
}
Then set up AWS Cost Explorer with tag-based grouping. Within a week, you will know exactly which team and service is responsible for every dollar.
Rightsizing: The Biggest Quick Win
In our experience, 40-60% of EC2 instances are oversized. Teams provision for peak load and never revisit the decision.
How to Identify Oversized Instances
Use AWS Compute Optimizer or query CloudWatch directly:
# Find instances with average CPU below 20% over 14 days
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc123def456 \
--start-time $(date -d '14 days ago' --iso-8601) \
--end-time $(date --iso-8601) \
--period 3600 \
--statistics Average \
--query 'Datapoints[?Average<`20.0`]'
Before and After
A real example from a client engagement:
| Resource | Before | After | Monthly Savings |
|---|---|---|---|
| API servers (12x) | m5.2xlarge | m6i.xlarge | $2,880 |
| Worker nodes (8x) | c5.4xlarge | c6i.2xlarge | $3,520 |
| RDS Primary | db.r5.4xlarge | db.r6g.2xlarge | $1,840 |
| Redis cluster | cache.r5.2xlarge | cache.r7g.xlarge | $960 |
| Total | $9,200/mo |
Key observations:
- Moving to current-generation instances (m6i, c6i, r6g) gives better performance at lower cost due to improved price-performance ratios.
- Graviton-based instances (the "g" suffix) are typically 20-30% cheaper with equal or better performance for most workloads.
- Rightsizing is not a one-time event. Build it into a quarterly review process.
Reserved Instances and Savings Plans
Once your baseline is rightsized, commit to capacity for predictable workloads:
Savings Plans vs. Reserved Instances
| Feature | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instances |
|---|---|---|---|
| Flexibility | Any instance family, region, OS | Specific instance family, any size | Specific instance type and AZ |
| Discount | Up to 66% | Up to 72% | Up to 72% |
| Best for | Variable workloads | Stable instance families | Highly predictable workloads |
Our recommendation: start with Compute Savings Plans for their flexibility. They apply automatically to EC2, Fargate, and Lambda usage across any region or instance family.
# Check current coverage and recommendations
aws ce get-savings-plans-coverage \
--time-period Start=$(date -d '30 days ago' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
--granularity MONTHLY
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT \
--lookback-period-in-days SIXTY_DAYS
A practical approach to commitment coverage:
- 70-80% of stable baseline: 1-year no-upfront Savings Plans
- 10-15% of predictable peaks: 1-year partial-upfront Reserved Instances
- Remaining 10-20%: On-demand and Spot for burst capacity
Spot Instances for Non-Critical Workloads
Spot instances offer up to 90% savings. They work well for:
- CI/CD build runners
- Batch processing jobs
- Development and testing environments
- Stateless worker nodes in Kubernetes
Configure a mixed-instance ASG for resilience:
{
"MixedInstancesPolicy": {
"InstancesDistribution": {
"OnDemandBaseCapacity": 2,
"OnDemandPercentageAboveBaseCapacity": 20,
"SpotAllocationStrategy": "capacity-optimized"
},
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateId": "lt-0abc123",
"Version": "$Latest"
},
"Overrides": [
{ "InstanceType": "m6i.xlarge" },
{ "InstanceType": "m5.xlarge" },
{ "InstanceType": "m5a.xlarge" },
{ "InstanceType": "m6a.xlarge" }
]
}
}
}
This keeps 2 on-demand instances as a baseline, fills 20% of additional capacity with on-demand, and uses Spot for the remaining 80%. Listing multiple instance types maximizes Spot availability.
Storage Cost Optimization
S3 and EBS costs accumulate silently. Address them with lifecycle policies and tiering:
S3 Intelligent Tiering
For buckets where access patterns are unpredictable, enable Intelligent-Tiering:
aws s3api put-bucket-intelligent-tiering-configuration \
--bucket my-data-bucket \
--id entire-bucket \
--intelligent-tiering-configuration '{
"Id": "entire-bucket",
"Status": "Enabled",
"Tierings": [
{ "AccessTier": "ARCHIVE_ACCESS", "Days": 90 },
{ "AccessTier": "DEEP_ARCHIVE_ACCESS", "Days": 180 }
]
}'
S3 Lifecycle Rules
For buckets with known access patterns:
{
"Rules": [
{
"ID": "archive-old-logs",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "GLACIER" },
{ "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
],
"Expiration": { "Days": 730 }
}
]
}
EBS Volume Cleanup
Unattached EBS volumes are pure waste. Find and clean them:
# Find unattached volumes
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
--output table
# Also check for old snapshots
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[?StartTime<`2025-06-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
--output table
Automate this with a weekly Lambda function or use AWS Trusted Advisor.
Implementing a FinOps Practice
Tools and tactics matter, but lasting cost optimization requires organizational change:
The FinOps Team Structure
- FinOps Lead -- owns the practice, sets targets, reports to leadership
- Engineering Champions -- one per team, responsible for their team's cost awareness
- Finance Partner -- translates technical savings into business metrics
The Monthly FinOps Cycle
- Week 1: Report. Generate cost reports by team, service, and environment. Compare to budget and previous month.
- Week 2: Analyze. Identify the top 5 cost anomalies and optimization opportunities.
- Week 3: Optimize. Implement rightsizing, update reservations, clean up unused resources.
- Week 4: Review. Present results to stakeholders. Celebrate wins.
Cost Anomaly Detection
Set up AWS Cost Anomaly Detection to catch unexpected spikes before they become expensive:
aws ce create-anomaly-monitor \
--anomaly-monitor '{
"MonitorName": "service-monitor",
"MonitorType": "DIMENSIONAL",
"MonitorDimension": "SERVICE"
}'
aws ce create-anomaly-subscription \
--anomaly-subscription '{
"SubscriptionName": "cost-alerts",
"MonitorArnList": ["arn:aws:ce::123456789:anomalymonitor/abc123"],
"Subscribers": [
{ "Address": "[email protected]", "Type": "EMAIL" },
{ "Address": "arn:aws:sns:us-east-1:123456789:cost-alerts", "Type": "SNS" }
],
"Threshold": 100,
"Frequency": "DAILY"
}'
Quick Wins Checklist
If you want to start saving money this week, here are the highest-impact actions:
- Delete unattached EBS volumes and old snapshots
- Stop or terminate non-production instances outside business hours
- Enable S3 Intelligent-Tiering on large buckets
- Remove unused Elastic IPs (they cost money when unattached)
- Review and delete old AMIs and their backing snapshots
- Switch NAT Gateways to NAT instances for dev environments
- Enable gp3 volumes instead of gp2 (20% cheaper, better performance)
- Review data transfer costs -- use VPC endpoints for S3 and DynamoDB
The Numbers That Matter
Track these metrics monthly:
- Unit cost -- cost per transaction, per user, or per request (not just total spend)
- Coverage ratio -- percentage of compute covered by Savings Plans or RIs
- Waste ratio -- idle resources as a percentage of total spend
- Cost per environment -- production vs. non-production ratio (aim for 70/30 or better)
Conclusion
AWS cost optimization is not a project with an end date. It is an ongoing practice that requires visibility, accountability, and regular attention. The strategies in this guide -- tagging, rightsizing, commitment discounts, Spot instances, storage optimization, and organizational FinOps practices -- work together to create a culture where cost efficiency is a feature, not an afterthought.
At DevOpsVibe, we run comprehensive AWS cost audits and implement FinOps practices that deliver measurable savings. Our clients typically see 30-50% cost reductions within the first quarter. If your AWS bill is growing faster than your business, reach out and let us help you take control.
awsfinopscloudcost-optimizationinfrastructuregovernance