The scenario is a common one. The AWS bill has been rising month after month, faster than the business. Finance asks why; the technical team opens the console and sees a total, a few services at the top of the list, but no clear explanation: which application, which environment, which decision is behind the increase?
Knowing how much a bill is and understanding what drives it are two different things. To reduce an AWS bill, you first need to link each cost to a resource, an application and real usage. Only then can you separate immediate savings from those that require testing, and from architecture changes that carry a risk for production.
This article sets out that method: what you are really paying for, eight optimisation levers with their precautions, a six-step audit, how to measure real savings, and when a move away from AWS deserves a closer look.
Understanding what the business is really paying for
An AWS bill breaks down into a handful of spending families. Identifying them is easy; attributing them to an application or a team is much harder without a prior structure of accounts and tags.
| Cost area | What it covers | Common source of drift |
|---|---|---|
| Compute | EC2 instances, containers (ECS, EKS, Fargate), Lambda functions | Oversized or forgotten instances |
| Storage | S3, EBS volumes, snapshots | Detached volumes, piled-up snapshots, data never archived |
| Databases and managed services | RDS, Aurora, DynamoDB, ElastiCache, OpenSearch | Capacity provisioned for a peak that never returns |
| Networking | Data transfer, NAT Gateway, load balancers | Internal traffic routed through a billed gateway |
| Observability | CloudWatch logs, metrics and traces | Logs kept with no retention limit |
| Non-production environments | Development, test, staging | Resources running day and night with no users |
The tools that show where the money goes
- AWS Cost Explorer: costs by service, account, region or tag, with rightsizing and commitment recommendations.
- AWS Data Exports (CUR 2.0): the most detailed export, delivered to an S3 bucket, with hourly granularity and resource IDs. It is the source AWS recommends for detailed analysis.
- Cost allocation tags: they link a cost to a project or environment, but must be activated in the Billing console before they show up in Cost Explorer, which can take up to 24 hours.
- Budgets and anomaly detection: threshold alerts and automatic detection of unusual increases.
These dashboards have a limit: an identified cost does not prove a resource is useless. A lightly used database may be a standby, a detached volume may hold the only copy of some data. The decision requires knowing the business use, not just the utilisation curve.
The 8 AWS cost optimisation levers
No lever is universal. Each one must be assessed on its likely gain, the effort required and the risk to production. The last two criteria matter as much as the first.
1. Unused or underused resources
- Problem: stopped instances with attached volumes, detached EBS volumes, reserved public IP addresses, load balancers with no targets.
- Detection: Cost Explorer, a resource inventory, Trusted Advisor cost checks. Note that the full set of Trusted Advisor checks requires a paid support plan (Business Support+ or higher).
- Action: assign an owner to every resource, then remove whatever has neither owner nor use.
- Precaution: take a snapshot and get written sign-off before any deletion.
- Measure: number of ownerless resources and their cost, tracked over time.
2. Instance sizing
- Problem: instances sized for a one-off peak or "just in case".
- Detection: AWS Compute Optimizer, which shares its recommendation engine with Cost Explorer. By default it analyses 14 days of history; 32 days at no extra cost, or 93 days with a paid option.
- Action: change instance size or family, step by step.
- Precaution: 14 days do not cover a month-end close or a seasonal peak. According to the service FAQ, the default metrics cover CPU, network and local storage: check that memory is actually measured before downsizing an instance.
- Measure: instance cost and performance indicators (latency, errors) before and after.
3. Savings Plans and Reserved Instances
- Problem: steady usage paid at On-Demand rates, or conversely a commitment bought too early.
- Detection: commitment coverage and utilisation reports in Cost Explorer.
- Action: a Savings Plan is an hourly spend commitment over one or three years in exchange for a lower rate. AWS advertises discounts of up to 66% (Compute) or 72% (EC2 Instance): these are maximums, not averages.
- Precaution: a Savings Plan cannot be cancelled during its term. Optimise resources first, then commit on the remaining stable baseline.
- Measure: commitment coverage and utilisation rates.
4. EBS volumes, snapshots and S3 storage classes
- Problem: legacy gp2 volumes, snapshots never purged, cold data kept in the standard class.
- Detection: Cost Explorer by usage type, snapshot inventory, bucket access analysis.
- Action: AWS states that gp3 volumes offer a price per GB up to 20% lower than gp2, with conversion requiring no restart. For S3, lifecycle rules or the Intelligent-Tiering class.
- Precaution: check performance (IOPS, throughput) after conversion. According to S3 pricing, some classes carry a minimum billed storage duration (30 or 90 days) and retrieval fees; Intelligent-Tiering charges a per-object monitoring fee.
- Measure: storage cost per GB kept and number of restores.
5. Data transfer, NAT Gateway and network costs
- Problem: traffic to S3 or DynamoDB routed through a NAT Gateway, cross-AZ traffic, unplanned internet egress.
- Detection: "DataTransfer" and "NatGateway" usage types in Cost Explorer, VPC Flow Logs.
- Action: a NAT Gateway is billed per hour and per GB processed, whatever the destination. A gateway-type VPC endpoint avoids those processing charges for traffic to S3 and DynamoDB.
- Precaution: any routing change is tested outside production and deployed with a rollback plan.
- Measure: volume processed by the NAT Gateway and network cost per application.
6. Databases and managed services
- Problem: oversized database instances, unnecessary replicas, fixed provisioned capacity.
- Detection: Compute Optimizer also covers RDS and Aurora; connection, CPU and I/O metrics.
- Action: resize, review storage, consider Database Savings Plans (one-year commitment) for a stable load.
- Precaution: a database is rarely isolated. Test heavy queries and failover before any reduction.
- Measure: cost per database and response time of critical queries.
7. Development and test environments
- Problem: environments identical to production, switched on around the clock.
- Detection: cost breakdown by account or environment tag.
- Action: scheduled shutdowns outside working hours, smaller sizes, ephemeral environments created on demand.
- Precaution: keep performance tests representative.
- Measure: share of non-production cost in the total bill.
8. Financial visibility and ownership
- Problem: nobody owns a given cost line.
- Detection: share of untagged spend.
- Action: tagging rules, per-team budgets and anomaly detection, which analyses costs roughly three times a day from data that can lag by up to 24 hours. For logs, CloudWatch keeps logs indefinitely by default: set a retention period per log group.
- Precaution: tags do not apply retroactively by default; legal log retention obligations take precedence over savings.
- Measure: share of costs attributed to an owner.
How to run an AWS cost audit
A serious audit follows six steps, from data collection to ongoing monitoring. It produces a list of actions ranked by impact, effort and risk, not a list of deletions.
| Step | Analysis performed | Expected deliverable | Risk avoided |
|---|---|---|---|
| 1. Collect | Detailed billing data, usage metrics over a representative period | Baseline dataset | Deciding on an atypical week |
| 2. Identify | Main cost areas and how they evolve | Costs ranked by service and usage type | Optimising a marginal line |
| 3. Correlate | Mapping to applications, teams and environments | Cost-to-application map | Deleting a resource still in use |
| 4. Prioritise | Estimated gain, effort, operational risk | Ranked action plan | Starting with the riskiest change |
| 5. Test | Changes on a controlled scope | Measured results, rollback procedure | A production incident |
| 6. Measure and monitor | Before/after comparison, alerts, periodic review | Indicators, budgets and alerts in place | Drift returning a few months later |
This table describes recommended practice. At CERVOX Services, two engagements match this need. The AWS bill analysis covers the last 90 days: main cost items and their origin, possible fixes with their trade-offs, application of only the fixes you approve, alerts and a budget configured within the agreed scope, documentation and handover. The AWS account audit, carried out read-only, delivers an inventory of the analysed resources, the main points of attention and recommendations.
How to measure real savings
Comparing two monthly bills is misleading: load, seasonality, commitments and one-off costs all distort the picture. The reliable measure is a unit cost, related to a relevant unit of activity.
Several effects blur a bill: rising or falling traffic, seasonal peaks, upfront commitment payments, one-off migration or dual-running costs, and operational time added to or removed from the team. Unit cost divides cloud spend by a measure of activity: active user, order, document processed, hour of useful compute.
An entirely hypothetical example. Before optimisation: €12,000 per month for 400,000 orders, or €0.030 per order. Three months later: €12,600 for 520,000 orders, or about €0.024. The bill rose by 5%, but the cost per order fell by about 19%. The reverse also happens: a bill down 15% (€10,200) with only 300,000 orders gives €0.034 per order, a deterioration of about 13%. Limits: the example assumes a unit representative of consumption and ignores people costs.
When should you consider moving off AWS?
Optimising AWS is often enough when the increase comes from oversized, forgotten or poorly allocated resources. A hybrid architecture or a partial migration deserves a study when the problem is structural: governance requirements, a dependency to avoid, or a cost gap that remains after optimisation.
The price of an instance does not represent the total cost of an infrastructure. A serious comparison includes technical dependencies, networking, security, governance requirements and operating costs. Our article on migrating from AWS to a European cloud details that method, with a 36-month total cost calculation. To decide, CERVOX Services also offers a "Move to AWS, stay, or leave" assessment, which compares three costed 12-month options.
Mistakes to avoid
| Mistake | Consequence | Prevention |
|---|---|---|
| Downsizing without observing load peaks | Slowdowns or outages at the next peak | An observation period covering business cycles |
| Buying commitments without understanding usage | A commitment paid for but unused | Optimise first, commit the stable baseline afterwards |
| Deleting data or backups without sign-off | Irreversible loss, non-compliance | Named owner, written sign-off, prior copy |
| Overlooking network costs | Compute savings wiped out by transfer charges | Analysis of network usage types |
| Optimising one service in isolation | Cost shifted to another service | Measurement across the whole application |
| Confusing a lower bill with a lower total cost | Apparent saving, heavier operations | Unit cost and operating time tracked together |
Checklist: a first review of your AWS bill
- The last twelve months of costs are visible by service in Cost Explorer.
- A detailed export (Data Exports, CUR 2.0) is enabled to an S3 bucket.
- The five most expensive services and their trend are identified.
- Each AWS account has a named owner.
- Project and environment tags are defined and activated for billing.
- The share of untagged spend is known.
- Detached volumes, unused IPs and old snapshots are listed, each with an owner.
- Non-production environments have shutdown schedules.
- NAT Gateway and data transfer costs are isolated.
- Every log group has a defined retention period.
- A budget and anomaly detection send alerts to someone who acts on them.
- Commitment coverage and utilisation are monitored.
Frequently asked questions
Why is my AWS bill going up?
The most common causes are growing activity, resources created then forgotten, sizing chosen for a peak, unplanned data transfer and logs kept with no limit. Only a breakdown by service, usage type and application can tell normal growth from drift.
Is AWS Cost Explorer enough to audit a bill?
It is enough for a first read by service and tag. To link a cost to a specific resource on an hourly basis, the detailed export (Data Exports, CUR 2.0) is better suited. Neither tells you whether a resource is still needed: you also have to ask the teams.
Are Savings Plans always worth it?
No. They make sense for steady, predictable usage. Bought before optimising, or on a load that is about to fall, a non-cancellable commitment can cost more than it saves.
How do you reduce AWS costs without disrupting production?
By ranking every action by risk, starting with those that have no impact (tags, retention, validated orphan resources), testing the others outside production, and planning a rollback for each change.
Do you need to leave AWS to cut your bill?
Not necessarily. Optimisation may be enough. A migration is justified after comparing total cost, including dependencies, networking and operations, and sometimes for reasons that are not financial.
When should you commission an AWS audit?
When the bill grows faster than the business, when nobody can explain its main items, before buying a multi-year commitment, or before a migration decision.
Conclusion: understand before you change
Before changing its infrastructure or its provider, a company needs to know exactly what it pays for, why it pays for it and what risk comes with each optimisation. Lasting savings come from that understanding, not from cutting resources across the board.
CERVOX Services works on this through scoped engagements, on your own AWS account and with no subscription: only the fixes you approve are applied, and you receive a written estimate within 24 business hours after a first 20-minute conversation. If your AWS bill keeps rising without explanation, describe your situation in a few lines: we will tell you whether we can help, and how.