It usually starts the same way: a cloud bill arrives that is 30% higher than last month, nobody can explain exactly why, and a meeting gets booked to “look into it”. The answer is rarely one big mistake. It is usually a dozen small ones — oversized instances, forgotten storage, and services that never got switched off.
The good news is that most of those are fixable without slowing your team down. The nine steps below are the ones we run first when a client asks us to reduce AWS and GCP costs, in the order that usually pays back fastest.
A quick note on scope: every figure in this guide is the kind of result you can check in your own billing console. If you want help with the review, our services page lists what we do, or you can book a free strategy call and we will walk through your bill with you.
1. Right-size before anything else
Start with the instances and databases you already have. Most teams pick a size when they launch, then never revisit it, even as traffic patterns change. On AWS, Compute Optimizer will tell you which EC2 instances are underused; on GCP, the recommender in the console does the same for Compute Engine. Drop a size, or a family, and measure the effect for a week before deciding.
The safest way to right-size is in stages: lower one step at a time, watch latency and error rates, and keep a note of what you changed. Teams that right-size carefully often save 20–30% on compute without users noticing anything at all.
2. Kill idle resources
Every cloud account accumulates them: test databases nobody has connected to in months, load balancers serving a single health check, unattached disks from instances that were deleted long ago. They are small individually and expensive together.
Run a quick sweep: look for resources with no traffic in the last 30 days, tag them, and give the owner a week to claim them. Anything unclaimed gets stopped, then deleted. This is the fastest saving in this guide, and the one most teams can do in an afternoon.
3. Use savings plans and committed use discounts
On-demand pricing is convenient and expensive. If a workload runs all the time, you should not be paying the on-demand rate for it.
On AWS, Savings Plans and Reserved Instances can cut compute costs by 30–70% depending on the commitment. On GCP, committed use discounts do the same for Compute Engine, Cloud SQL, and other services. The trick is to commit only to the baseline you are certain of: the load that is always there. Leave the variable part on demand, and re-check your commitments every quarter as usage changes.
4. Choose the right storage tier
Storage costs are easy to ignore because each gigabyte is cheap. Add them up across backups, snapshots, logs, and old datasets, and they are often the second-biggest line on the bill.
Move data you rarely touch to cheaper tiers: S3 Infrequent Access or Glacier on AWS, Nearline or Coldline on GCP. Set lifecycle rules so the move happens automatically, for example, anything untouched for 90 days drops a tier, and anything untouched for a year moves to archive. Also check your snapshots: old, unneeded snapshots are a common source of quiet waste.
5. Put autoscaling on everything that varies
If your traffic doubles at lunchtime and halves overnight, your infrastructure should follow it. Fixed capacity sized for the peak means you pay for the peak all day.
Set up autoscaling groups on AWS, or managed instance groups on GCP, with sensible minimums and maximums. The same applies to databases: serverless or autoscaling database tiers handle spikes without you paying for a large instance 24 hours a day. Autoscaling is not a nice-to-have; for variable workloads it is often the single biggest saving.
6. Pick the cheapest region that meets your needs
Prices for the same service vary between regions, sometimes by 20% or more, and data transfer costs differ too. If your users are mostly in one place, hosting in a region close to them is usually both cheaper and faster.
This does not mean moving everything. It means checking the obvious: a database in an expensive region when your users are elsewhere, or backups stored in a premium region when a cheaper one would do. Before any migration, check data residency requirements: some clients, especially in regulated industries, need data to stay in a specific country or region.
7. Watch data transfer costs
Data transfer is the cost teams most often overlook. Moving data between regions, or out of the cloud to the public internet, is charged, and the charges grow quietly with traffic.
A few habits help: keep services that talk to each other in the same region and availability zone where possible, use a CDN for public content rather than serving it directly from your instances, and compress what you send. If a single service is responsible for a large share of transfer costs, that is usually a sign its architecture needs a look.
8. Delete zombie load balancers and unused IPs
A load balancer that serves almost nothing still costs money every hour, and the same goes for unused elastic IPs, NAT gateways with no traffic, and VPN connections nobody uses. These are small line items that survive because nobody owns them.
Once a quarter, list every load balancer, NAT gateway, and public IP, and check which ones have no real traffic. Delete or consolidate what is not needed. It is unglamorous work, and it is also money back every month.
9. Use both clouds’ native cost tools
Both AWS and GCP give you the tools to see where money goes; most teams simply do not look at them often enough.
Set a budget alert at 80% of your expected spend so you hear about a spike before the bill arrives. Turn on cost allocation tags so every resource carries an owner or project, and review Cost Explorer on AWS or the cost management reports on GCP weekly until the pattern is clear. A five-minute look each week catches most problems while they are still small.
Every billing system has a cost explorer or equivalent. Use it weekly, tag everything, and set an alert at 80% of your monthly budget so a surprise never reaches the invoice.
What to review every month
- Check for resources created in the last 30 days that have no owner and no traffic.
- Look at the top five services by cost and ask whether the top one grew.
- Check your storage tiers: data that has not been touched in 90 days usually belongs in a cheaper tier.
- Confirm that any commitment you bought is still being used.
- Look at data transfer costs, especially traffic leaving the cloud to the public internet.
A simple way to start
If your bill jumped recently, do not start with a big migration. Do the audit first: look at your top five services, check for idle resources, and right-size the obvious cases. That usually recovers a meaningful share of the increase, and it gives you the evidence to decide whether deeper changes, like commitments or a region move, are worth it.
We run this review for clients as part of our regular development and cloud work, and the first pass usually finds something worth fixing.
Frequently asked questions
Is it safe to right-size a production database?
Yes, if you do it in stages. Lower one size at a time, watch performance for a week, and keep a backup and a rollback plan. Never right-size several services at once, or you will not know which change caused a problem.
How much can we realistically save?
It depends on how the account has been managed. Accounts that have never been reviewed often save 20–40% in the first pass. Well-managed accounts save less, usually 5–15%, and mostly from commitments and storage tiers.
Do savings plans lock us in?
They commit you to a level of usage, not to a specific instance. A one-year commitment on your stable baseline is usually safe; a three-year commitment deserves a careful look at how certain your usage is.
Should we use a third-party cost tool?
Start with the native tools. They are free, they are accurate, and they cover most of what a small or mid-size team needs. Third-party tools are worth it when you have many accounts, many teams, or need chargeback reporting across departments.
What if our bill is mostly one service?
Focus there. If, say, BigQuery or RDS is 60% of your bill, optimising anything else first is a distraction. Understand that service’s pricing in detail, check for unused capacity, and look at whether a different tier or query pattern would cost less.
Talk to us about your cloud bill
Cloud costs rarely fall because someone found one big saving. They fall because someone looked at the bill properly, fixed the obvious waste, and set up the habits that stop it coming back. Start with the audit and rightsizing, commit to the savings that are already safe, and put the monthly review in the calendar before this month’s bill becomes next month’s surprise.
If you would like a second pair of eyes on your AWS or GCP bill, book a free strategy call and tell us what you are spending. We will give you an honest view of what can be saved and what it would take, whether or not you hire us to do it.
Top comments (0)