Your AWS Bill Is Somebody’s Problem
Here’s a stat that should make you uncomfortable: according to the FinOps Foundation’s 2026 State of FinOps report — based on $83 billion in tracked cloud spend across 1,192 organizations — somewhere between 27% and 35% of all cloud spending is waste. Not “could be optimized.” Waste. Resources running that nobody uses, instances sized for traffic that never came, snapshots from databases you deleted two years ago.
For a long time, developers got to ignore this. The bill went to finance, finance complained to management, management sent a Slack message that everyone ignored, and the cycle repeated. That era is over. FinOps — the practice of bringing financial accountability to cloud spending — has gone mainstream. 93 of the Fortune 100 have FinOps teams now. And increasingly, those teams are asking developers pointed questions about why their staging environment costs more than production.
This guide is the practical version. No frameworks, no maturity models, no “align your stakeholders.” Just the stuff that actually moves the needle on an AWS bill.
Why Developers, Specifically?
Because you’re the ones creating the resources. Every terraform apply, every “I’ll just spin up a quick RDS instance,” every Lambda function that calls another Lambda function that calls DynamoDB — that’s all developer decisions that show up on the bill.
Finance can see the numbers. They can’t fix them. Only the people writing the infrastructure code can do that. And here’s the uncomfortable truth: compute alone typically represents 50-70% of AWS spend, and studies consistently find that 60-70% of instances are oversized. You probably launched a t3.xlarge when a t3.medium would’ve been fine, because who has time to benchmark during a sprint?
The FinOps Foundation’s report also flagged something interesting this year: practitioners say they’ve already tackled the “big rocks” of waste — the obviously idle resources, the forgotten environments. What’s left is a high volume of smaller opportunities that take more effort to capture. That’s code-level optimization. That’s your territory.
Five Quick Wins That Actually Matter
Before getting into commitment strategies and tooling, here are the changes that typically cut 20-30% off an AWS bill with minimal effort. I’m listing these in order of effort-to-impact ratio.
1. Kill Your Zombie Resources
Ghost resources are the easiest win that somehow never gets tackled. Unattached EBS volumes, old snapshots, Elastic IPs not associated with running instances, load balancers pointing at nothing. They cost money every hour of every day, and they provide exactly zero business value.
Run this in your AWS account right now:
# Find unattached EBS volumes
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
--output table
# Find snapshots older than 90 days
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[?StartTime<=`2026-01-20`].{ID:SnapshotId,Size:VolumeSize,Start:StartTime}' \
--output table
# Find unassociated Elastic IPs
aws ec2 describe-addresses \
--query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocID:AllocationId}' \
--output tableI’ve seen teams recover $500-2,000/month just from cleaning up EBS volumes alone. It’s boring work, but it’s free money.
2. Right-Size Your Instances
AWS Compute Optimizer analyzes 14 days of CloudWatch metrics (CPU, memory, network) and tells you exactly which instances are oversized. Enable it account-wide — it’s free for basic recommendations.
The typical finding? You launched an m5.2xlarge because the app was slow one time during a load test, and it’s been running at 12% CPU utilization ever since. Drop it to an m5.large, save 75% on that instance, and the app won’t notice.
For containers on EKS or ECS, the same principle applies but it’s trickier. You need to look at both pod resource requests and node utilization. Tools like CAST AI can automate this specifically for Kubernetes — they’ll continuously right-size pods and rebalance nodes. More on tools later.
3. Schedule Non-Production Environments
Your staging environment doesn’t need to run at 3 AM on a Sunday. Neither does your dev environment, your QA environment, or that “temporary” demo environment from six months ago.
Instance Scheduler on AWS (the official solution) or a simple Lambda function with EventBridge rules can shut down non-production resources during nights and weekends. A typical work schedule is roughly 45 hours out of 168 hours in a week. That’s a potential 73% cost reduction on non-production compute — just by turning things off when nobody’s using them.
4. Move to Graviton
This one’s easier than you’d think and the savings are real. AWS Graviton processors (ARM-based) cost 20-40% less than equivalent x86 instances while delivering comparable or better performance. The m7g family, for example, is meaningfully cheaper than m7i for most workloads.
If your app runs on Linux and doesn’t depend on x86-specific compiled binaries, the migration is often just changing the instance type. Docker images need to be multi-arch, but if you’re building on a modern CI pipeline, that’s a one-line change in your Dockerfile (FROM --platform=linux/arm64).
Not everything works on ARM. Windows workloads, some legacy Java apps with native dependencies, and anything compiled against x86-specific instructions will need more work. But for typical web services, APIs, and containerized workloads? Just do it.
5. Review Your Data Transfer Costs
Data transfer is the sneakiest line item on your AWS bill. It’s free going in, but going out? That’s where AWS gets you. Cross-AZ traffic, NAT Gateway charges, CloudFront to origin — it all adds up.
A few things to check:
- NAT Gateway: At $0.045/GB processed plus hourly charges, a busy NAT Gateway can easily hit $500-1,000/month. Consider VPC endpoints for S3 and DynamoDB — they’re free and eliminate NAT Gateway charges for those services.
- Cross-AZ traffic: Each direction costs $0.01/GB. If your microservices are chatty across AZs, this adds up fast. Consider service mesh locality-aware routing.
- S3 storage classes: If you’re storing logs or backups in S3 Standard that nobody accesses after a week, S3 Intelligent-Tiering or lifecycle policies to Glacier can cut storage costs by 60-80%.
Commitment Strategies: Savings Plans vs. Reserved Instances
Once you’ve cleaned up the waste, the next big lever is commitment-based pricing. AWS gives you a significant discount in exchange for committing to a certain level of usage for 1 or 3 years. There are two main mechanisms, and the choice between them matters.
Reserved Instances (RIs)
The old way. You commit to a specific instance family, size, and region. Standard RIs offer up to 75% off On-Demand, which is the deepest discount AWS offers. But they’re rigid — if you change your architecture, move regions, or switch instance types, you’re stuck paying for something you’re not using.
Convertible RIs give you some flexibility to exchange for different instance types, but the discount drops to around 66%.
Savings Plans
The newer, better option for most teams. Instead of committing to specific instances, you commit to a dollar amount of compute usage per hour. Two flavors:
- Compute Savings Plans: Up to 66% off. Applies across EC2, Fargate, and Lambda. Region-flexible, instance-family-flexible. This is the one most teams should start with.
- EC2 Instance Savings Plans: Up to 72% off. Locked to a specific instance family and region, but flexible on size, OS, and tenancy.
What to Actually Buy
Here’s my recommendation: layer them. Start with a Compute Savings Plan that covers your baseline — the minimum compute you know you’ll always need. Then add EC2 Instance Savings Plans for specific instance families where you’re confident the architecture won’t change.
Don’t commit to 100% of your usage. A good target is covering 60-70% of your steady-state compute with commitments, and leaving the rest as On-Demand (or Spot, which we’ll get to). Over-committing is how you end up paying for Reserved Instances that sit unused after a migration.
Use AWS Cost Explorer’s Savings Plans recommendations — they analyze your last 7, 30, or 60 days of usage and suggest optimal commitment levels. It’s not perfect, but it’s a solid starting point.
Spot Instances: The Wild Card
Spot Instances offer up to 90% off On-Demand pricing, but AWS can reclaim them with 2 minutes’ notice. They’re great for:
- Batch processing and data pipelines
- CI/CD build workers
- Stateless web servers behind an auto-scaling group (mix Spot with On-Demand)
- Dev/test environments where interruption is fine
They’re terrible for databases, single-instance applications, or anything that can’t handle sudden termination. Use Spot for what it’s good at, and don’t try to force it where it doesn’t belong.
AWS Native Tools You Should Be Using
AWS gives you a solid set of cost management tools for free (or nearly free). Most developers I talk to use maybe one of them.
Cost Explorer
The basics, but more useful than most people realize once you learn the filters. Group by service, then by usage type, to find where money actually goes. The “Daily unblended costs” view over the last 3 months usually tells a clear story.
As of April 2026, Cost Explorer now has natural language query support powered by Amazon Q. You can literally type “Why did my EC2 costs increase last week?” and get a root cause analysis with visualizations. It’s free — included with both the free tier and Q Developer Pro.
Compute Optimizer
Free basic recommendations for EC2, EBS, Lambda, and ECS on Fargate. Analyzes CloudWatch metrics and recommends right-sized resources. Enable it across all accounts in your organization — there’s no reason not to.
Cost Anomaly Detection
Uses ML to detect unusual spending patterns, running roughly three times daily. Set up SNS notifications so you hear about cost spikes before they become a billing surprise. It catches things like a runaway Lambda function, an accidentally public S3 bucket being scraped, or someone launching GPU instances for “testing.”
AWS Trusted Advisor
The cost optimization checks in Trusted Advisor overlap with some of the above, but it’s worth enabling for its idle resource detection: low-utilization EC2 instances, idle RDS instances, and underutilized EBS volumes. The Business and Enterprise support plans get the full set of checks.
Billing Conductor
If you’re running multiple teams or projects in the same AWS account (or Organization), Billing Conductor lets you create custom billing groups and allocate costs to specific teams. It makes the “who’s spending what” conversation much easier.
Third-Party Tools Worth Evaluating
The AWS native tools are good for visibility, but if you need automation, multi-cloud support, or deeper cost attribution, third-party tools fill real gaps.
Vantage
Best for multi-cloud visibility and SaaS cost tracking. Vantage connects to AWS, Azure, GCP, Kubernetes, and 15+ SaaS integrations (Snowflake, Datadog, Databricks). It’s the only FinOps platform with a native Terraform provider, which is genuinely useful if you’re managing infrastructure as code.
The free tier covers up to $2,500/month in tracked cloud spend. For larger deployments, the Pro tier starts at $7,500/month. They also have an Autopilot feature that takes 5% of verified savings as its fee — essentially pay-for-performance cost optimization.
For AI cost tracking, Vantage connects to OpenAI and Anthropic billing APIs and shows provider-level cost trends. Token-level attribution isn’t available yet, but the billing-level visibility is useful if you’re running multiple AI workloads.
CAST AI
If you’re running Kubernetes, CAST AI is worth a serious look. It goes beyond monitoring — it actively optimizes by right-sizing pods, scaling nodes in and out, and automatically using Spot instances where safe. Think of it as an autopilot for your Kubernetes cluster costs.
The catch is it’s Kubernetes-only. If your workload runs on plain EC2, Lambda, or ECS without EKS, CAST AI won’t help. But for K8s-heavy teams, the savings can be dramatic — they claim 50%+ reductions, and from what I’ve seen with teams using it, 30-40% is realistic.
CloudZero
CloudZero’s angle is unit economics. Instead of just showing your total bill, it helps you understand cost per customer, cost per feature, cost per API call. If your business cares about gross margins per customer segment (and it should), CloudZero gives you the data to make those calculations.
It’s enterprise-focused, with contracts typically starting at $20,000-30,000/year. Overkill for small teams, but valuable once you’re at the scale where understanding per-customer cloud costs matters for pricing decisions.
Building Cost Awareness Into Your Workflow
Tools and tactics are useless without a culture that cares. Here’s what actually works based on what I’ve seen across different teams.
Tag Everything
Without consistent tags, you cannot attribute costs to teams, projects, or environments. Period. At minimum, tag every resource with team, environment, project, and managed-by. Use AWS Service Control Policies (SCPs) to block resource creation without required tags. If you’re using Terraform, add tag validation with Sentinel or OPA policies.
This isn’t optional. It’s the foundation of everything else. Skip this, and you’ll spend months arguing about whose EBS volumes are costing $3,000/month.
Make Costs Visible
Set up a weekly Slack report (or whatever your team uses) showing each team’s cloud spend and week-over-week changes. AWS Cost Anomaly Detection can feed into this. When engineers see the numbers regularly, behavior changes. Nobody wants to be the team that doubled their spend because someone forgot to shut down a load test environment.
Add Cost Checks to PR Reviews
This is the “shift-left” part of FinOps that actually works. When someone opens a PR that changes Terraform or CloudFormation, ask: “What does this cost?” Tools like Infracost can estimate the cost impact of infrastructure changes right in the PR. It’s not about blocking PRs — it’s about making cost a visible part of the engineering decision.
Set Budgets and Alerts
AWS Budgets lets you set monthly spending thresholds and get alerts at 50%, 80%, and 100%. Set them per team or per project (this is where tagging pays off). The alerts should go to the team responsible, not just to finance. If your team’s budget is $5,000/month and you hit 80% on the 15th, you should know about it immediately.
The AI Cost Problem Nobody’s Talking About
One more thing. If your team is integrating LLMs — whether through Bedrock, SageMaker, or direct API calls to OpenAI/Anthropic — you’ve got a new cost category that doesn’t behave like traditional compute. Token-based pricing is unpredictable, usage spikes when features go viral, and most existing cost tools don’t track it well.
The FinOps Foundation flagged AI as the top future priority in their 2026 report, and for good reason. Teams are scrambling to track and allocate AI costs that can swing wildly based on prompt length, model choice, and user adoption.
My advice: treat AI costs like a separate line item from day one. Tag your Bedrock invocations, track token usage per feature, and set hard spending limits before that internal chatbot prototype becomes a $20,000/month production cost. Vantage and CloudZero are starting to offer AI-specific cost views, but the tooling is still catching up to the need.
Where to Start Tomorrow
If you’ve read this far and you’re wondering what to do first, here’s the order I’d recommend:
- Run those zombie resource commands from the quick wins section. Delete what’s dead. This takes 30 minutes and will probably save you something.
- Enable Compute Optimizer across your accounts. Read the recommendations next week.
- Set up Cost Anomaly Detection with SNS alerts to your team’s Slack channel. Free and takes 10 minutes.
- Look at your Savings Plans recommendations in Cost Explorer. If you’ve been running workloads for 30+ days, the data will be meaningful.
- Schedule your non-production environments to shut down on nights and weekends. The savings here are usually embarrassingly large.
None of this requires a FinOps team, a maturity model, or a quarterly planning session. It just requires someone on the team to look at the bill and decide to do something about it. Might as well be you.