For an early-stage startup, the cloud bill starts as a rounding error and becomes, without anyone deciding it should, one of the largest costs in the company. It grows with every feature, every environment, every "we'll clean that up later". The bill for a product with a few thousand users can quietly reach the cost of a senior engineer — and unlike the engineer, nobody can say exactly what it is buying. Cloud cost optimisation is the discipline of knowing what you spend, why, and whether each dollar is doing useful work. It is engineering work, not accounting, and it pays back faster than almost anything else a small team can do.
First, find out where the money goes
You cannot optimise a bill you cannot read. The first step is always visibility: tag every resource with the service, environment and team that owns it, turn on the provider's cost explorer, and look at the breakdown by service and by tag for the last three months. Most startups doing this for the first time find the same things — a database instance sized for a launch that never came, a development environment that has run around the clock for a year, storage that grows and is never deleted, and a line item nobody recognises at all.
Set a budget alert at the same time. Every major provider will email you when spend crosses a threshold or is forecast to. It costs nothing, and it turns a surprise at month-end into a question you can answer on the day it happens.
Understand what you are actually paying for
AWS, Azure and Google Cloud each price hundreds of services, but the bill for most startups is dominated by a handful of categories: compute (virtual machines, containers, serverless functions), managed databases, storage, and data transfer out of the cloud. Understanding the pricing model for each of these four is enough to make good decisions about ninety percent of the spend.
- Compute is billed by the second or hour for as long as an instance exists, whether or not it is doing anything. Idle compute is pure waste.
- Managed databases are billed for the instance, the storage, the backups and often the I/O. Oversized database instances are the single most common waste we find.
- Storage is cheap per gigabyte and expensive in aggregate when nothing is ever deleted. Logs, old snapshots, orphaned volumes and unused buckets accumulate silently.
- Data transfer out to the internet, and between regions, is priced separately and surprises everyone the first time. Serving large files or media directly from a compute region instead of a CDN is a classic and expensive mistake.
Right-size everything
Right-sizing means matching the resources allocated to a service to the work it actually does. The starting point is utilisation data: if a server has averaged eight percent CPU for three months, it is several sizes too large. Providers now recommend downsizing automatically; take the recommendations seriously and test them in staging.
The second half of right-sizing is autoscaling. A web application that sees ten times more traffic at lunchtime than at three in the morning should not run its peak capacity all night. Configure scaling on real demand signals — request rate, queue length, CPU — with a sensible minimum, and let the platform add and remove capacity as needed. Serverless and container platforms make this nearly free to set up; virtual machines need an autoscaling group and a load balancer.
- Monitor utilisation for every instance and database; downsize anything consistently under thirty percent
- Use autoscaling for anything with variable traffic, and set the minimum low
- Schedule non-production environments to shut down outside working hours — this alone often saves a third of the compute bill
- Delete unattached volumes, old snapshots and unused load balancers on a monthly review
Use commitments and spot capacity deliberately
Once the baseline is right-sized, commit to it. Reserved instances and savings plans offer discounts of up to around seventy percent in exchange for a one- or three-year commitment to a level of usage. The trick is to commit only to the floor — the capacity you are certain to run all year — and keep everything above it on demand. Committing before right-sizing locks in the waste.
Spot instances (preemptible VMs on Google Cloud) offer even steeper discounts for capacity the provider can reclaim at short notice. They are ideal for batch jobs, CI runners, data processing and anything that can be interrupted and restarted. They are wrong for a database or a single web server. Used for the right workloads, spot capacity is the largest discount available anywhere in the cloud.
Fix the architecture, not just the bill
Some of the biggest savings come from changing how the system works rather than what size it runs at:
- Put a CDN in front of static assets and media. It serves them closer to users, faster, and at a fraction of the egress cost of serving from origin.
- Cache aggressively. A cache in front of an expensive query or API call cuts database load, which lets you run a smaller instance.
- Move logs and old data to cold storage. Object storage tiers priced for infrequent access are ten times cheaper than the default tier. Set lifecycle rules so data moves automatically.
- Consolidate. Five tiny services on five tiny instances often cost more, and are harder to run, than one appropriately sized service. Microservices are an organisational tool, not a cost-saving one.
- Consider serverless for spiky or low-volume workloads. Paying per invocation beats paying for an idle server, right up until the volume is high and constant — at which point the maths flips.
Watch the line items that grow on their own
A few categories of spend increase without any decision being made, and they are worth checking specifically:
- Logging and monitoring. Ingesting every debug line into a hosted log platform is cheap at launch and startling at scale. Sample verbose logs, set retention to days rather than months, and keep only what you would actually search.
- Snapshots and backups. Automated daily snapshots with no expiry become terabytes within a year. Keep a sensible window and delete the rest.
- NAT gateways and load balancers. Fixed hourly charges plus per-gigabyte processing, often left running for environments that no longer exist.
- Third-party SaaS billed through the cloud marketplace. Easy to add, easy to forget, and invisible if you only look at the provider's own services.
- Egress from managed services. Databases and storage in one region talking to compute in another quietly pay for every byte crossing the boundary.
Make it a habit, not a project
A one-off cost-cutting exercise saves money once. What keeps the bill under control is a lightweight routine: a monthly review of spend by service, a rule that every new resource is tagged with an owner, a dashboard the whole engineering team can see, and a per-customer or per-request unit cost that the team watches over time. When cost is visible, engineers make better decisions without being asked. When it is hidden in a finance spreadsheet, it grows.
Two guardrails are worth adding early. First, a quota or approval step for the expensive resource types — large instances, big databases, new regions — so an experiment cannot become a permanent line item by accident. Second, a rule that every environment other than production has an expiry, and is torn down when its work is done.
Do not optimise past the point of sense
Cloud cost is a means to an end. Cutting it to the bone at the expense of reliability, or spending three engineer-weeks to save two hundred dollars a month, is a bad trade. The goal is to eliminate waste — spend that buys nothing — while keeping the headroom that lets the product survive a good day. A startup whose site goes down under its first burst of real traffic has not saved money; it has spent its most valuable moment.
Frequently asked questions
How much can a typical startup save?
A first pass on an unmanaged account commonly finds savings of twenty to forty percent, mostly from idle and oversized resources and non-production environments running around the clock. Commitments and architectural changes add to that over the following months.
Should we switch cloud providers to save money?
Rarely. The list prices are similar, and the cost of migrating is almost always higher than the difference. Optimise where you are first. The exceptions are credits programmes for startups, which can be substantial and are worth applying for, and specific services that are dramatically cheaper on one provider.
Is a cloud cost tool worth paying for?
At small scale, the provider's built-in cost explorer and budget alerts are enough. Third-party tools earn their price once the bill is large enough that a few percent of savings covers them, or once there are multiple accounts and teams to reconcile.
At Inverge Tech we help startups build cloud infrastructure that is right-sized from the start, and we audit existing accounts to find where the money is going. The result is a bill the founders can explain — and a product with the headroom to grow.