What do you do when AWS costs grow faster than revenue?
A rising cloud bill is not a problem in itself, as long as it grows more slowly than revenue. The alarm goes off when cost per unit of value (per user, per transaction) starts to climb. At that point the question is not “how do we pay less” but “where is the money leaking and what do we recover first without risk”. This article lays out the answer as a concrete FinOps plan, ordered by return and risk.
Is your AWS bill growing faster than the business?
Book a free 30-min call
Visibility first: you cannot cut what you cannot see
Before you switch anything off, you need to know where the money goes. Surprisingly often the biggest line items are not compute but the peripheral costs: data transfer, NAT Gateway, orphaned EBS volumes and snapshots, unused Elastic IPs. Start with:
- Cost Explorer and tags - break the bill down by service, account and team; without tagging you cannot assign cost to an owner.
- Data-transfer anomalies - traffic through NAT Gateway and across zones can quietly lead the bill; we set this out in our article on the hidden costs of NAT Gateway.
- Storage costs - mismatched or orphaned EBS volumes and old snapshots; the detail is in our article on EC2 and EBS costs.
This step costs nothing but time, and it usually shows straight away where 20-30% of the bill is waiting to be recovered.
A four-step plan, ordered by return and risk
The most common mistake is starting with commitments (Savings Plans) or with rewriting the architecture. The right order runs from lowest risk to highest:
| Step | What you do | Risk | Typical return |
|---|---|---|---|
| 1. Visibility | Tags, Cost Explorer, detect anomalies and waste | None | Maps 100% of the bill, points to targets |
| 2. Quick savings | Switch off the unused, rightsize oversized instances, remove orphaned resources, schedule dev/test environments | Low | Usually the single biggest line item |
| 3. Commitments | Savings Plans and Reserved Instances for stable, predictable workload; Spot for interruption-tolerant jobs | Medium (financial commitment) | Up to tens of percent on covered compute |
| 4. Architecture | Structural changes: serverless, managed services, changing the data-storage pattern | Higher (engineering work) | Highest long-term, but the slowest |
You do steps 1 and 2 first because they are cheap, fast and safe. Only once you know what you actually consume do commitments (step 3) make sense, because you do not want to reserve for three years a resource that turns out to be half the size after rightsizing.
Which FinOps actions matter most
If you only have time for a few moves, the highest return-to-risk ratio usually sits with:
- Rightsizing compute and databases - most instances are oversized; matching them to real usage saves money without changing how the application behaves.
- Scheduling non-production environments - dev, test and staging rarely need to run after hours and at weekends; switching them off is a quick, safe saving.
- Savings Plans on the stable core - commit only the part of the workload that is certainly staying, and only that.
- Eliminating transfer waste - VPC endpoints instead of NAT Gateway traffic where it makes sense.
- A cycle, not a one-off - FinOps is a process: a monthly review catches new waste before it grows.
Not all of these are equal for everyone. That is why step one (visibility) matters so much: it shows which of these levers is the thickest for you.
How to cut the bill without risking production
The biggest fear when cutting costs is “what if something stops working”. So safe optimisation follows a few rules:
- Start with resources carrying no traffic - orphaned volumes, unused IPs, old snapshots and inactive environments are zero-risk savings.
- Rightsize gradually, with metrics - scale down based on real CPU/RAM usage from monitoring, one change at a time, with a quick way back.
- Commitments cover only the certain core - do not reserve peaks or workloads that may disappear.
- Touch production last and reversibly - as in modernisation, make changes so they can be rolled back, not hard-wired.
Cost optimisation is not the same as cutting costs by force. FinOps done well lowers the bill without touching reliability.
A special case: SaaS after a traffic spike
When a SaaS application suddenly grows (a successful launch, a season, a big new customer), the bill can shoot up faster than the revenue from that growth. The order of actions is the same, but the emphasis differs: first check whether the spike is real demand or inefficiency (missing caching, chatty queries, cross-zone transfer), then tune autoscaling so you pay for the peak only while the peak lasts, and only at the end cover the new stable baseline with commitments. Panicking and reserving for three years at the peak is the most expensive move possible.
How Devopsity runs cost optimisation
Devopsity starts with a cost review: tagging, Cost Explorer, catching anomalies and waste, then a plan ordered by return and risk. That first review typically finds 15-30% in savings, mostly on quick, safe moves, before we even reach for commitments or architecture. We run FinOps as a cycle, not a one-off, and we deliver the changes rather than just recommending them. The scope is on our FinOps and cost optimisation page, and for architectural savings the starting point is often an AWS Well-Architected Review.
Is your AWS bill growing faster than the business?
Book a free 30-minute call. We will run a cost review, show where the money leaks, and propose a savings plan ordered by return and risk.
Frequently asked questions
What do you do when AWS costs grow faster than revenue?
Act in order of cheapest and safest move first. Start by getting visibility: tags and Cost Explorer, to see exactly where the money goes (often it is data transfer, NAT Gateway and orphaned resources, not compute). Then reach for quick savings with no risk: switch off the unused, rightsize oversized instances, schedule dev/test environments. Next, cover the stable core of the workload with commitments (Savings Plans, Reserved Instances), and leave architectural change for last. Most companies recover the most on the first two steps. Devopsity’s first cost review typically finds 15-30% in savings, without touching production.
Which FinOps actions matter most when costs are rising?
The highest return-to-risk ratio usually sits with: rightsizing oversized instances and databases, scheduling non-production environments (dev, test, staging) to switch off outside working hours, Savings Plans covering only the certain, stable core of the workload, and eliminating data-transfer waste (for example VPC endpoints instead of NAT Gateway traffic). It is also key to treat FinOps as a cycle rather than a one-off, because a monthly review catches new waste before it grows. Which of these levers is thickest for you only becomes clear from a review with cost visibility.
How do you lower a cloud bill without risking production?
Safe optimisation follows an order from zero risk upward. Start with resources carrying no traffic: orphaned EBS volumes, unused IPs, old snapshots and inactive environments, since removing them breaks nothing. Rightsize gradually, based on real usage metrics from monitoring, one change at a time and with a quick way back. Cover only the certain core with commitments, not peaks. Touch production last and reversibly. FinOps done well lowers the bill without touching reliability, because cost optimisation is not the same as cutting by force.
What is FinOps, and is it a one-off exercise?
FinOps is the practice of managing cloud cost as a continuous process, bringing engineering, finance and the business together around cost visibility and accountability. It is not a one-off cut but a cycle: a regular review shows where the money goes, flags waste and savings levers, and later iterations catch new costs before they grow. Devopsity runs FinOps on a retainer, where the first review typically finds 15-30% in savings and later ones keep the bill under control as the company grows.
