Your AWS bill has grown every quarter, but nobody can say which product, team or forgotten test caused it. Finance sees one large number on the invoice, engineering sees hundreds of line items, and the conversation usually ends with “we will look into it”.
This checklist is the order in which we would work through a rising AWS bill: get visibility first, remove waste, rightsize, and only then commit to discounts. Each step is something your own team can start this week, and none of it needs a new tool.
Quick answer: To reduce your AWS bill, first make costs visible with Cost Explorer, Budgets and cost allocation tags. Then delete idle resources such as unattached EBS volumes, old snapshots and unused public IPs, rightsize instances using real usage data, and only after that buy Savings Plans or Reserved Instances for your steady baseline. Finally, fix data transfer and storage costs in the architecture.
Step 1: See where the money goes
You cannot cut what you cannot see. Before changing anything, spend an hour in the Billing console and answer three questions: which services cost the most, which accounts or environments they belong to, and which regions they run in.
- Cost Explorer: group last month's spend by service, then by usage type. Usage types such as data transfer, NAT gateway hours and EBS snapshots often explain a jump better than the service name does.
- Cost allocation tags: agree on two or three tags, for example
project,environmentandowner, apply them to every resource and activate them in the Billing console so they appear in cost reports. - AWS Budgets: set a monthly budget per account with email alerts on actual and forecasted spend, so a runaway resource is noticed in days, not at month-end.
- Cost Anomaly Detection: turn it on so unusual spikes by service or account are flagged automatically.
- Separate accounts: production, staging and sandbox in separate accounts under AWS Organizations, with consolidated billing, make it obvious which environment is spending.
Two Indian specifics are worth checking. If your account is billed in India, make sure your GSTIN is added in the account's tax settings so your finance team can check input tax credit eligibility on the invoices. And confirm that nothing is running in a US or Singapore region because someone followed a tutorial with default settings.
Step 2: Remove what nobody uses
Waste is the cheapest saving, because removing it changes nothing for your users. Look for these in every region you use:
- Stopped instances: compute charges stop, but the attached EBS volumes are still billed every month.
- Unattached EBS volumes: volumes left behind when an instance was terminated. Snapshot them if unsure, then delete.
- Old snapshots and AMIs: automated snapshots with no retention policy keep growing quietly. Use Amazon Data Lifecycle Manager or AWS Backup with a retention rule.
- Public IPv4 addresses: AWS charges for public IPv4 addresses, whether they are in use or not. Release the Elastic IPs you no longer need.
- Idle load balancers and NAT gateways: each has an hourly charge even with little traffic, so remove the ones left over from old projects.
- Non-production servers running 24x7: development and staging rarely need to run at night or on Sundays. Stop them outside working hours with EventBridge Scheduler or the Instance Scheduler on AWS solution.
- Log groups that never expire: CloudWatch Logs keeps data indefinitely by default. Set a retention period that matches your audit needs.
Step 3: Rightsize before you commit
Most instances are sized by guesswork on launch day and never revisited. Rightsizing means matching size to what the workload actually uses, measured over at least a few weeks that include your busiest days, such as month-end billing runs.
- Use AWS Compute Optimizer: it gives recommendations for EC2, EBS, Lambda and Auto Scaling groups. Treat them as a starting point, not an instruction.
- Measure memory too: EC2 does not report memory usage by default. Install the CloudWatch agent so you do not shrink a server that is already short of RAM.
- Move to current-generation instances: newer families usually give better price-performance than the ones launched years ago.
- Test Graviton: Arm-based Graviton instances are often cheaper for the same work, provided your runtime and libraries support Arm. Test in staging first.
- Switch EBS gp2 volumes to gp3: gp3 lets you set IOPS and throughput separately from size and is usually cheaper per GB. The change can be made without detaching the volume.
- Review databases: RDS instances are often among the largest line items. Check CPU, connections and storage before choosing a smaller class, and remove read replicas nobody queries.
Step 4: Commit only to your steady baseline
Savings Plans and Reserved Instances give a lower rate in exchange for a one- or three-year commitment. They are valuable, but buying them before Steps 2 and 3 locks in waste. Commit to the usage that has stayed steady over the last few months, not to your peak.
| Option | How it works | Fits | Watch out for |
|---|---|---|---|
| On-Demand | Pay for what you run, no commitment | New, spiky or short-lived workloads | Highest unit rate |
| Compute Savings Plans | Commit to a fixed hourly spend for one or three years; applies across EC2 families and regions, Fargate and Lambda | A steady baseline whose shape may change | You pay the commitment even if usage falls |
| EC2 Instance Savings Plans | Commit to one instance family in one region | A stable fleet you do not expect to change | Less flexible than Compute Savings Plans |
| Reserved Instances | Commitment for specific services and configurations, such as RDS databases | Long-running databases and caches | Check which services and payment options apply today |
| Spot Instances | Spare capacity at a discount that AWS can reclaim with a two-minute warning | Batch jobs, CI runners, stateless workers | Not for single databases or stateful servers |
If cash flow matters, a one-year term with no upfront payment is a cautious first step. Buy commitments in the management account so the discount can apply across linked accounts, and set a reminder well before each one expires.
Step 5: Fix the costs hidden in the architecture
Some charges come from how the system is built, and no amount of rightsizing removes them.
- Data transfer: traffic out to the internet, between availability zones and between regions is charged. Chatty services split across zones, or backups copied across regions every hour, add up quickly.
- NAT gateway processing: private servers pulling large amounts of data from S3 through a NAT gateway pay for every GB processed. A VPC gateway endpoint for S3 or DynamoDB avoids that charge.
- Static files: serve images, downloads and scripts through CloudFront instead of directly from your servers.
- S3 storage classes: use lifecycle rules to move old objects to Infrequent Access or Glacier classes, or use Intelligent-Tiering when access patterns are unknown. Add a rule that cleans up incomplete multipart uploads.
Mumbai or Hyderabad, and what it means for cost
AWS has regions in Mumbai (ap-south-1) and Hyderabad (ap-south-2). Prices for the same resource can differ between regions, and not every service or instance type is available in both, so check the AWS pricing pages for your exact resources. A common pattern is one region as primary and the other for disaster recovery copies. Replication between them is charged as inter-region transfer, so copy what your recovery plan needs, not everything.
Make cost review a monthly habit
Costs creep back unless someone owns them. Name one owner per account or product and hold a 30-minute review each month with engineering and finance. A simple agenda works:
- Compare this month with last month by service and by tag.
- Explain every increase that is not linked to business growth.
- Review Compute Optimizer and Trusted Advisor findings.
- Check Savings Plans coverage, utilisation and upcoming expiries.
- Agree two or three actions, each with an owner and a date.
If nobody in-house has time to run this, an outside AWS cost and architecture review can set up the tags, budgets and first round of savings for your team to continue. Cost work also overlaps with security, because an account full of unknown resources is usually an account full of unknown risks; our guide to cloud security posture assessment covers that side.
How EthicsComputer can help
Our AWS consulting team runs cost and architecture reviews inside accounts you own, with role-based access you can revoke at any time. An assessment typically takes one to two weeks and ends with a prioritised list of savings and the effort each one needs. Your AWS bill stays in your own account, and we never mark up provider charges. If the review shows deeper issues, we can also help with DevOps automation or a cloud security assessment.
Do you know which three line items drive your AWS bill?
Share your monthly spend pattern and setup, and we will tell you where we would look first.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
