How to Cut Your AWS Bill: 7 Steps That Work in Practice

The cloud is pay-as-you-go – which is exactly why the bill tends to grow quietly. A server someone launched for a test a year ago, a volume left behind by a deleted instance, backups that are never cleaned up. Each item is small, but together they make up a big part of the invoice.

When we audit infrastructure for clients, we follow much the same path every time. Here are seven steps, in the order we recommend taking them.

1. Visibility first: who pays for what

You can’t save what you can’t see. So the first step isn’t switching anything off – it’s finding out where the money goes:

• AWS Cost Explorer breaks costs down by service, region and over time.
• Tags (for example project, environment, owner) assign costs to a specific project or team. Activate them as cost allocation tags.
• AWS Budgets alerts you when spend approaches a limit – before the invoice arrives.

Visibility alone often reveals surprises, such as a forgotten test environment running around the clock.

2. Clean up what nobody uses

The quickest saving is deleting things that have no value:

• unattached EBS volumes and old snapshots,
• unused Elastic IP addresses (since 2024 AWS charges for every public IPv4 address, attached or not),
• forgotten load balancers, NAT Gateways and databases in test environments,
• old object versions and incomplete multipart uploads in S3.

Tip: test environments don’t need to run at night and on weekends. Shutting them down automatically outside working hours saves roughly two thirds of their cost.

3. Right-size your servers

Servers are usually ordered “on the big side, to be safe”. After a few months in production, though, you have precise data on how much capacity you really need. AWS Compute Optimizer recommends smaller instances based on actual CPU and memory usage.

If a server runs at 10–15% CPU over the long term, a smaller type is almost certainly enough. We make the change step by step and watch the metrics so performance never drops.

4. Newer, cheaper instance types

AWS regularly releases newer generations that do more for the same price. Two quick wins:

• Graviton (ARM) – according to AWS, up to 40% better price-performance. Most containerised, Python, Node.js or Java workloads run on it without changes.
• gp3 instead of gp2 – gp3 EBS volumes cost less per GB and let you set performance (IOPS) independently of volume size.

5. Commit and save: Savings Plans and Reserved Instances

If you know you will still need a certain amount of compute a year from now, there’s no point paying the full on-demand price. Savings Plans give you a discount in exchange for committing to a set hourly spend for 1 or 3 years. The most flexible are Compute Savings Plans (up to 66%), which apply to EC2, Fargate and Lambda across regions and instance types. EC2 Instance Savings Plans go up to 72% but are tied to an instance family in one region.

We recommend starting carefully: commit only to the stable baseline that always runs, not the peaks. On-demand or Spot covers the rest.

6. Spot instances for work that can wait

Spot instances use spare AWS capacity at up to 90% off. AWS can reclaim them with a two-minute warning, but for CI/CD builds, batch data processing, rendering or test environments that doesn’t matter. In Kubernetes, ECS and Nomad you can mix them with regular instances so that losing one never puts anything at risk.

7. Data and transfers: the silent budget eaters

The invoice often surprises people with how much simply moving data costs:

• NAT Gateway charges for every gigabyte it processes. For access to S3 and DynamoDB, add a free VPC Gateway Endpoint.
• S3 Intelligent-Tiering or lifecycle rules automatically move old data to cheaper storage classes such as Glacier.
• CloudFront in front of a website or API reduces data transfer out of AWS and speeds things up for users.
• CloudWatch Logs keep data forever by default. Set a sensible retention period, such as 30–90 days.

Saving is not a one-off

The biggest difference doesn’t come from one big intervention but from regular reviews. Infrastructure changes with every new project, so it pays to check the trends in Cost Explorer once a month and review Compute Optimizer recommendations and Savings Plans coverage once a quarter.

If you manage infrastructure as code (Terraform, Pulumi), you set most of these rules – tags, log retention, lifecycle rules, volume types – once, and they apply automatically to everything new.

💸 Want to know how much you could save?

As part of our IT and cloud consulting we review your AWS account, show you where the savings are and prepare a concrete action plan. If you are planning new infrastructure, we build savings in from the start with our AWS architecture design. Get in touch – the first consultation is free and comes with no obligation.