Has your AWS bill crept up month after month while traffic stayed roughly the same? You are not alone, and the cause is rarely one big mistake but many small ones left running.
The fastest way to cut an AWS bill is to see where the money goes (Cost Explorer and tagging), remove what you do not use, rightsize what you keep, and then commit to Savings Plans for steady workloads. After that, storage tiers, data transfer, NAT gateways and log retention are the usual hidden costs worth fixing.
Where does AWS spending usually go?
For most web and mobile backends, the biggest lines are compute (EC2, ECS, Lambda), databases (RDS, Aurora, DynamoDB), storage (S3, EBS, snapshots) and networking (data transfer, NAT gateways, load balancers). The exact mix depends on your architecture, so the first job is always to measure rather than guess.
12 ways to reduce your AWS bill
1. Get visibility with Cost Explorer and tags
Enable AWS Cost Explorer and apply consistent cost allocation tags such as project, environment and owner. Without tags, you cannot tell whether staging or production is driving costs.
2. Set budgets and alerts
AWS Budgets can email or notify you when actual or forecast spend crosses a threshold. AWS Cost Anomaly Detection can flag unusual spikes, such as a runaway job or a misconfigured service.
3. Delete idle and orphaned resources
Look for unattached EBS volumes, old snapshots, unused Elastic IP addresses, idle load balancers and forgotten test environments. These are often small individually and meaningful together.
4. Rightsize instances and databases
Many instances are sized for a launch-day guess and never revisited. AWS Compute Optimizer analyses utilisation and recommends smaller or different instance types. Apply the same thinking to RDS instance classes.
5. Use Savings Plans or Reserved Instances for steady workloads
If part of your usage runs around the clock, Compute Savings Plans or Reserved Instances give a discount in exchange for a one- or three-year commitment. Commit only to the baseline you are confident about, not your peak.
6. Run interruptible work on Spot Instances
Batch jobs, CI runners, data processing and some stateless workers can run on EC2 Spot capacity at a lower price, as long as they tolerate interruption. Fargate Spot offers a similar option for ECS tasks.
7. Consider Graviton (Arm) instances
AWS Graviton instances often offer better price performance than comparable x86 instances. Most Node.js, Python, Java and Go workloads run on Arm with little or no change, but test your dependencies and container images first.
8. Switch off non-production environments out of hours
Development and staging environments rarely need to run at night or at weekends. Scheduled scaling, the AWS Instance Scheduler solution or a simple pipeline job can stop and start them.
9. Use the right S3 storage classes
Apply S3 lifecycle rules to move older objects to cheaper classes or expire them. S3 Intelligent-Tiering is useful when access patterns are unpredictable. Also clean up incomplete multipart uploads.
10. Move EBS volumes from gp2 to gp3
gp3 volumes are generally cheaper than gp2 and let you set performance independently of size. The migration can be done in place without detaching the volume.
11. Reduce data transfer and NAT gateway charges
NAT gateways charge for data processed, which adds up when private services pull large amounts of data from S3 or DynamoDB. VPC gateway endpoints for S3 and DynamoDB route that traffic privately and avoid NAT processing charges. A CDN such as CloudFront can also reduce origin traffic.
12. Control logging and monitoring costs
CloudWatch Logs groups keep data forever by default. Set a retention period, reduce noisy debug logging in production, and archive what you must keep to S3.
Which optimisations should you do first?
| Action | Effort | Risk | When to do it |
|---|---|---|---|
| Tags, Cost Explorer, Budgets | Low | None | Immediately |
| Delete idle resources | Low | Low (check owners first) | Immediately |
| Log retention and gp3 migration | Low | Low | First month |
| Schedule non-production shutdowns | Low to medium | Low | First month |
| Rightsizing | Medium | Medium (test under load) | After a few weeks of metrics |
| VPC endpoints and CDN | Medium | Low to medium | When networking costs stand out |
| Graviton migration | Medium | Medium | When compute is a large share |
| Savings Plans or Reserved Instances | Low | Commitment risk | After usage is stable and rightsized |
Note the order: rightsize before you commit. Buying a Savings Plan for an oversized fleet locks in waste.
Can architecture choices lower AWS costs?
Yes, often more than any single setting. A small product may not need a Kubernetes cluster, multiple NAT gateways or an always-on database cluster. Serverless options such as Lambda, or managed containers on ECS with Fargate, can suit spiky or modest traffic. Our article Do you really need Kubernetes? looks at simpler alternatives that are also easier on the budget.
How do you keep cloud costs under control over time?
- Review monthly. A short cost review with the engineering lead catches drift early.
- Make costs visible to developers. When teams see the cost of their services, they make better trade-offs.
- Define infrastructure as code. Terraform or AWS CDK make it easier to see and remove what exists.
- Include cost in maintenance. Cost checks belong in a regular maintenance routine; see what a maintenance plan should include.
Key takeaways
- Measure first with tags, Cost Explorer and Budgets, then remove idle resources.
- Rightsize before committing to Savings Plans or Reserved Instances.
- Hidden costs often sit in NAT gateways, data transfer, old snapshots and log retention.
Want an expert review of your AWS account and a clear plan to reduce spend? Request a DevOps and cloud quote from AppifyDevs, or browse our case studies to see how we work on real projects.