The seven AWS cost fixes that actually move a bill — what each one is worth, how long it takes, and the order to do them in without hurting reliability.
Most AWS bills are not expensive because the architecture is wrong. They are expensive because nothing has been reviewed since it was launched — instances sized for a load test that ran once, storage that nobody set a lifecycle on, non-production environments running through the night, and logs kept forever by default. In our experience the first serious cleanup on a neglected account usually finds somewhere between 15% and 40% of monthly spend with no impact on users, and almost none of it requires re-architecting anything. This guide covers the seven fixes worth doing, in the order that keeps you safe.
Key takeaways: Start with one week of tagged, per-service visibility before you change anything. Then work in order — right-sizing, idle resources, storage lifecycle, non-production schedules, network path, log retention — and only commit to Savings Plans once a stable baseline is proven. The savings ranges below are the planning ranges INFOCRUD works with, reviewed in August 2026; they are editorial estimates for budgeting, not audited averages or a guarantee for your account.
Why AWS bills drift upward on their own
Cloud spend rarely jumps. It creeps, because every default in AWS favours availability over economy, and because deleting things feels riskier than leaving them running.
Four patterns cause most of the drift:
- Resources are provisioned for a peak that was estimated, not measured — and never revisited afterwards
- Deleting a server does not delete its volume, its snapshots, its load balancer, or its elastic IP
- Storage and logs have no expiry unless someone sets one, so they only ever grow
- Nobody owns the bill, so a ₹40,000 increase looks like normal growth rather than a specific resource
None of this shows up as a failure. That is exactly why it survives — the system works fine, it just costs more each month than it needs to.
Before you cut anything: get one week of visibility
The single most common mistake is cutting first. Without knowing which service, environment, and team the spend belongs to, teams tend to shrink whatever looks big — which is usually production — and discover the cost of that during the next traffic spike.
Spend a week doing four things, all of which are free:
- Turn on AWS Cost Explorer and group spend by service, then by usage type. Two or three line items almost always dominate
- Apply a tagging standard (
Environment,Owner,Service) and activate those as cost allocation tags. Untagged spend is the part you will not be able to explain - Enable AWS Compute Optimizer, which analyses CloudWatch metrics and recommends right-sized instances at no charge
- Enable AWS Cost Anomaly Detection so the next unexplained increase reaches you by email rather than at the end of the month
By the end of that week you should be able to name the top five line items on the bill and say which environment each one belongs to. If you cannot, fix that before touching anything.
The 7 fixes that actually move an AWS bill
1. Right-size the instances nobody has looked at since launch
Over-provisioning is the largest single source of waste on most accounts. A database sized for a launch that never came, an EC2 fleet chosen by copying a blog post, a staging instance identical to production — each one bills at full rate whether it is at 4% CPU or 40%.
Compute Optimizer will list the candidates. Look at sustained utilisation over at least two weeks rather than a single day, keep headroom for genuine peaks, and change one workload at a time so a performance regression is traceable. On modern workloads, also check whether the instance family can move to Graviton — AWS positions its Graviton instances at up to 40% better price-performance than comparable x86 instances, which is worth testing for anything running on a supported runtime.
2. Delete what is running for nobody
Every account accumulates resources that bill without serving traffic. They are safe to remove and they are pure margin:
- Unattached EBS volumes left behind when an instance was terminated, and the snapshot chains nobody has pruned
- Load balancers with no healthy targets, still charging an hourly rate
- Public IPv4 addresses — since February 2024 AWS charges an hourly rate for every public IPv4 address, in use or idle
- Old AMIs and their backing snapshots, plus development databases kept "just in case" after a migration
- Duplicate NAT Gateways created per-AZ during a proof of concept and never consolidated
Take a snapshot before deleting anything you are unsure about, and check CloudTrail for recent access. The rule that keeps this safe: nothing gets deleted the same day it is found.
3. Put storage on a lifecycle instead of a habit
Storage grows quietly and never shrinks by itself. Three changes cover most of it.
Move EBS gp2 volumes to gp3 — AWS prices gp3 at up to 20% lower per GB than gp2, and it lets you set IOPS and throughput independently of volume size, so you stop over-provisioning capacity just to buy performance. It is an online change on most volumes.
For S3, apply lifecycle rules that move objects to Standard-Infrequent Access or Glacier by age, and enable Intelligent-Tiering for buckets with unpredictable access — it moves objects between tiers automatically for a small per-object monitoring charge. Also add a rule to expire incomplete multipart uploads, which are invisible in the console and bill indefinitely.
Finally, check snapshot and backup retention. Daily backups kept forever are a policy nobody chose; they are simply the absence of one.
4. Switch non-production off outside working hours
Development and staging environments typically run 24×7 while being used roughly 45 hours a week. Shutting them down on nights and weekends removes about two-thirds of their runtime cost, and it is the highest-return change relative to effort on this list.
Use an EventBridge schedule with a small Lambda, or AWS Instance Scheduler, to stop EC2 and RDS instances outside working hours. Two cautions: RDS automatically restarts an instance stopped for seven days, so schedule around that; and make the schedule easy to override, because an engineer blocked from their own staging environment at 9pm will disable the whole thing rather than fight it.
5. Fix the network path before you blame the servers
Data transfer is the line item founders least expect and most often misread as compute. Three costs dominate:
- NAT Gateway charges both an hourly rate and a per-GB processing fee — so private-subnet traffic to S3, DynamoDB, or ECR is paying twice for something that could be free
- Cross-AZ traffic between your own services is billed in both directions, which adds up quickly for chatty microservices spread across availability zones
- Internet egress to users, which is where an unoptimised media or API response shows up on the bill
The fixes are well understood: add VPC gateway endpoints for S3 and DynamoDB (no hourly charge) and interface endpoints for the AWS services you call most; keep tightly-coupled services in the same availability zone where your resilience requirements allow it; and put CloudFront in front of static and cacheable content so the same bytes are not served from origin repeatedly.
6. Cap log and metric sprawl
CloudWatch Logs bills mainly on ingestion, and log groups are created with retention set to never expire. A verbose debug logger left on after an incident can therefore cost more than the service producing the logs.
Set a retention period on every log group — 30 days for application logs and longer only where compliance requires it. Review custom metrics and high-resolution metrics, which are individually cheap and collectively significant. Where you need long-term history, export to S3 with a lifecycle policy instead of paying CloudWatch retention rates for data nobody queries.
7. Commit — but only to the baseline you have proven
Savings Plans and Reserved Instances trade a one- or three-year commitment for a lower rate; AWS advertises up to 72% off on-demand pricing for Compute Savings Plans. The saving is real, and it is also the one item on this list that can lose you money.
The order matters: commit last, after right-sizing. Committing first locks you into paying for the over-provisioned baseline you were about to remove. Cover only the floor of your usage — the capacity that runs every hour of every month — and leave variable load on on-demand or Spot. For fault-tolerant, interruptible work such as batch processing and CI runners, Spot instances remain the largest discount available without any commitment at all.
| Fix | Effort | Typical saving | Risk |
|---|---|---|---|
| Right-size compute | Medium | 10–25% of compute | Low, if changed one workload at a time |
| Delete idle resources | Low | 3–10% of total | Low, with a snapshot-first rule |
| Storage lifecycle and gp3 | Low | 10–20% of storage | Very low |
| Non-production schedules | Low | Up to 65% of non-prod runtime | Low, if overrides are easy |
| Network and NAT path | Medium | 5–20% of transfer | Low |
| Log retention | Low | Varies; often significant | Low, check compliance first |
| Savings Plans | Low | Up to 72% on committed baseline | Real — commitment is binding |
Effort and saving ranges are INFOCRUD planning figures reviewed in August 2026, based on typical small and mid-sized AWS accounts. Your account will differ; the point of the visibility week is to find out by how much.
How this runs in practice
- Phase 01Days 1–7 — measure. Cost Explorer grouped by service and usage type, cost allocation tags applied, Compute Optimizer and anomaly detection enabled. No changes yet, only a baseline and a ranked list of candidates.
- Phase 02Days 8–21 — take the safe wins. Idle resources removed, gp2 volumes moved to gp3, S3 lifecycle rules applied, log retention set, non-production put on a schedule. Everything reversible, nothing touching production capacity.
- Phase 03Days 22–45 — right-size, then commit. Instance families and sizes adjusted one workload at a time with metrics watched after each change, network path fixed, and only then Savings Plans purchased against the proven baseline.
The sequence is the safeguard. Every step before day 22 is reversible within minutes; the only irreversible decision — the commitment — is made last, against a baseline that has already been cleaned.
Mistakes that make cloud bills worse
- Cutting production capacity to hit a number. A savings target met with an outage is not a saving. Headroom is a reliability requirement, not waste
- Buying Savings Plans first. It is the easiest button to press and it locks in the exact over-provisioning you were about to remove
- Optimising once. Without tags, alerts, and a monthly review, an account returns to its previous shape within two quarters
- Trusting a fixed savings percentage. Any provider quoting a guaranteed number before looking at your usage is guessing, and the guess is being priced into their fee
Frequently asked questions
How much can we realistically save on AWS?
On an account that has never been reviewed, 15–40% of monthly spend is a reasonable planning range, with most of it coming from right-sizing, idle resources, and non-production schedules. On an account already managed well, expect single digits — and treat any number promised before an assessment as marketing rather than analysis.
Will cost optimization hurt performance or uptime?
It should not, if you sequence it correctly. Deleting unattached volumes, setting log retention, and scheduling staging environments carry effectively no production risk. Right-sizing does carry risk, which is why it is done one workload at a time with metrics watched afterwards and a documented rollback.
Are Savings Plans or Reserved Instances better?
Compute Savings Plans are more flexible — they apply across instance families, sizes, regions, and to Fargate and Lambda — while Reserved Instances can price slightly lower for a workload you are certain will not change. For most growing teams the flexibility is worth more than the last few percent.
Do we need a dedicated FinOps person for this?
Not at our scale. The first cleanup is a project, not a role. What you do need afterwards is a monthly review of cost, reliability, and risk attached to whoever owns operations — which is one of the things a managed DevOps engagement is normally scoped to include.
How often should we review AWS cost?
Monthly, alongside reliability. Anomaly detection covers the sudden spikes; the monthly review catches the slow drift, which is the more expensive of the two over a year.
The bottom line
AWS cost optimization is not a clever architecture problem. It is a maintenance problem — measure for a week, take the reversible wins, right-size carefully, fix the network path, cap retention, and commit only to the baseline you have proven. Done in that order, a neglected account commonly gives back 15–40% of its monthly spend without a single user noticing, and the review rhythm afterwards is what stops it coming back.
If your cloud bill is rising and nobody can explain which resources are driving it, the practical next step is an independent look at the account. You can explore Managed DevOps to see how assessment, foundation, and ongoing operations fit together, or book a free infrastructure review and we will tell you where your waste and your real risks are — before you commit to any monthly scope.
