Cloud costs for a startup: AWS, Cloudflare or a plain server, and how to keep the bill in check

The bill is a product decision

Cloud spending follows architecture, and architecture gets decided early, usually by whoever set up the first environment in a hurry. Six months later the bill is a surprise, and the surprise is rarely the servers. It is the managed services nobody turned off, the data leaving the cloud, the database running an old version with a surcharge on it. This post is about where the money goes, what the three common choices cost you, and the habits that keep the bill boring.

What you actually pay for

Five things, in roughly this order of surprise.

Compute: the machines or functions that run the product. Predictable, and usually not the problem.

Databases: a managed database costs more than the same database on a server you run yourself, and it is worth it, because the thing you are buying is backups, patching and failover that somebody else operates. What is not worth it is paying for a bigger instance than the product needs, or for an old version. Since March 2025, a PostgreSQL 12 database on RDS pays Extended Support at $0.10 per vCPU per hour, rising to $0.20 in the third year, and on a small instance that surcharge costs more than the instance itself. A major version upgrade is planned work, not a project. Old versions are a tax that compounds.

Storage: cheap per gigabyte, expensive in volume when nobody deletes anything.

Data transfer: the line most founders do not know exists. Traditional clouds charge for data leaving their network, so an app that serves large files, images or video pays every time a user downloads one. Cloudflare's object storage charges nothing for egress, which changes the arithmetic for media-heavy products.

Managed services: queues, search, caches, email, monitoring, each a modest monthly line, each easy to add and easy to forget. A dozen of them is a real number.

And the sixth, which never appears on the invoice: the hours your team spends operating all of the above.

AWS: the right first choice for most products

AWS is where we start most products, and for reasons that have nothing to do with fashion. It has a managed version of almost everything a product will need, so the team builds the product instead of the plumbing. Its startup credits often cover the first year of a small product outright. And it is what the next engineer, investor or acquirer will expect to find.

Its cost problem is the opposite of a plain server's: it makes spending easy. Every service is a click, every click is a monthly line, and the defaults are sized for companies larger than yours. The discipline it needs is sizing things to the product, tagging everything so you know what a line is for, and reviewing the bill every month while it is still small enough to read.

Cloudflare: where it fits

Cloudflare is not an AWS replacement; it is the layer in front of your product and, increasingly, a place to run parts of it. DNS, caching and a web firewall come almost free and remove a class of problems. Its functions run at the edge, close to users, with a generous free tier and a pricing model that scales with requests rather than with idle servers. Its storage, as mentioned, does not charge for egress.

Where it fits: static and content sites, APIs that are light on state, media delivery, anything where being close to the user matters. Where it does not, yet: long-running jobs, heavy databases, the broad catalog of managed services. For most of the products we build it is a component alongside AWS, not instead of it.

A plain server: when it is the right size

A single virtual server with the product deployed in Docker containers costs a few tens of dollars a month and runs a first version with hundreds or a few thousand users without complaint. We have shipped products this way and they were not worse for it.

The trade is that you own everything: updates, backups, security patches, the 3 a.m. restart. That is fine when the product is small and the team knows what it is doing, and it stops being fine at the first outage nobody saw coming. The move to managed services should happen when the product earns it: real traffic, real data, a customer who asks about uptime.

One more consideration decides ahead of cost. If your customers' regulators require data to stay in a specific jurisdiction, that constraint picks the provider before the price does; sovereign European providers exist for exactly this, at a premium over the large clouds.

The habits that keep the bill in check

• Set a budget alert on day one. Not a limit, an alert. The point is to hear about the surprise in week two, not in month six.
• Turn off what is not serving users. Development and staging environments do not need to run at night or at weekends. Scheduling them off is often the single largest saving on an early bill.
• Tag everything. A line you cannot attribute is a line you cannot cut.
• Keep versions current. Databases, runtimes, frameworks. The surcharge for falling behind is real, and the security exposure is worse.
• Watch the data leaving. Put a cache or an egress-free store in front of anything users download in volume.
• Commit once you know. Reserved and committed pricing cuts compute costs substantially, and it is a bet you should place only after a few months of steady usage tell you what "steady" is.
• Read the bill. Monthly, by one named person, while it is short.

How we set it up

On the products we build, infrastructure lives in the client's own accounts from the first day. AWS first, Cloudflare where it fits, a plain server when that is the right size. Deployments are Docker-based, development, staging and production are separate, and every change goes through CI before it reaches any of them. Monitoring and error tracking are in place before the first user arrives, and the bill is one of the things it watches.

None of this is exotic. It is the difference between a cloud bill that grows with the product and one that grows on its own.