Most UK startups choose a cloud provider before they know what will actually cost them money. You have a prototype, a demo next month and a technical co-founder who has used AWS before, so that is where the database goes. Sensible enough. But once you are paying for a Kubernetes cluster, a managed Postgres instance, a NAT gateway and a few terabytes of egress a month, the choice becomes much harder to unpick. Add an enterprise security questionnaire, a first platform hire and a term sheet with credits attached, and a decision made in a hurry in month one starts shaping your gross margin in year three. Here is how the big three compare on the four things UK founders actually ask about: price, UK regions, compliance support and startup credits.

Pricing: where the bills actually come from

All three bill in broadly similar ways. Compute is charged by the second or the hour, storage by the gigabyte-month, and network traffic in both directions. The differences that hurt small teams are rarely the headline price of a virtual machine. They are the extras that accumulate quietly.

• Egress. Every provider charges for data leaving to the internet, at different rates and with different free allowances. A product that serves video, images or large API payloads feels this immediately.
• Traffic between availability zones. Chatty architectures generate real money here, in both directions. Microservices spread across three zones can spend more on talking to each other than on running.
• NAT gateways and load balancers. Hourly charges that run whether or not you have traffic, plus per-gigabyte processing on top. A NAT gateway sitting idle overnight still appears on the invoice.
• Managed services. You pay for the database or queue, plus storage, plus backups, plus the compute underneath it, plus the read replica you added for confidence.
• Observability. Log ingestion, retention and custom metrics are billed by volume, and they are the line item founders most often forget to model.
• Support. Sometimes charged as a percentage of monthly spend, so it grows as you do, whether or not you open tickets.

Discounts differ too. AWS has Savings Plans and Reserved Instances, Azure has reserved capacity and savings plans, and Google Cloud applies automatic sustained use discounts on top of committed use discounts. Google's automatic discount is the friendliest for a young company because it needs no forecasting and no commitment — you simply pay less once a machine has run for most of the month. All three sell interruptible capacity — Spot on AWS and Azure, Spot VMs on Google — at a steep reduction, which suits batch jobs, CI runners and stateless workers rather than your primary database.

It helps to price a realistic stack rather than a single instance. Take two application instances behind a load balancer, a managed Postgres with one read replica and point-in-time recovery, object storage for uploads, a NAT gateway, a container registry and 500GB of outbound traffic a month. On all three providers that usually lands in a similar order of magnitude, but the split is revealing: one charges more for compute and less for network, another does the reverse, and a third hides the cost inside the managed database tier. At small scale the totals converge. The gap opens up when your architecture gets chatty, your data grows, or your support tier steps up with your spend.

The practical move: build a small, representative version of your workload and price it in each provider's own calculator, including the boring parts. Start with no commitments and buy reservations only once usage has been stable for two or three months. Review the bill line by line for the first quarter, because the first invoice almost always contains something nobody planned for.

UK regions and data residency

AWS runs a London region (eu-west-2) alongside Ireland (eu-west-1). Azure has UK South in London and UK West in Cardiff. Google Cloud's London region is europe-west2, with Belgium and the Netherlands nearby for failover. All three give you multiple availability zones inside London, which is what you actually want for a production database: synchronous replication across zones a few miles apart, not across the Irish Sea.

Two caveats matter more than the region list itself.

First, not every service is available in every region. New GPU families, the newest managed database engines and some AI services often land in Ireland, Frankfurt or the US before they reach London. A startup building an AI feature can find itself architecting around a service that simply is not offered in eu-west-2 yet. Check the regional service list for the specific products on your shortlist, not just the region name.

Second, "hosted in the UK" and "UK data residency" are not identical claims. Read the data processing addendum and the sub-processor list. Support staff, backup replication and telemetry can all cross borders, and enterprise customers will ask exactly that question in procurement.

For most UK startups, UK GDPR is the governing regime, and the UK's adequacy position with the EU means transferring personal data to Ireland or the Netherlands is not the problem it was in 2021. What is a problem is being unable to answer a customer's question about where their data sits. Pick a primary UK region, document your failover, and keep the answer short.

Compliance and the paperwork that follows the sale

Compliance is where the three diverge in ways that matter commercially rather than technically. All of them hold ISO 27001, SOC 2 and the usual security certifications, and all will sign a data processing addendum. The differences show up in tooling and in the specific certifications your buyers ask for.

• AWS has the deepest catalogue of accreditations, the largest partner network and the most third-party tooling that assumes you are on it. Compliance reports are self-service through AWS Artifact.
• Azure is often the easiest conversation for UK public sector, healthcare and enterprise buyers, partly because those organisations already run Microsoft estates. If your customers are councils, NHS trusts or large corporates, Azure removes friction you would otherwise spend months clearing.
• Google Cloud is strong on analytics, data and AI workloads and has invested heavily in UK public sector and financial services relationships, but it has a smaller pool of UK partners and contractors to draw on when you need to move quickly.

Support contracts are part of compliance too. A business-grade plan on any of the three typically buys faster response times, a named contact and access to architecture reviews — and it is often a hard requirement before an enterprise customer will sign. Budget for it before you need it, because the upgrade takes effect on a billing cycle, not overnight.

Startup credits and what they are really worth

All three run generous programmes, and the headline numbers move often enough that you should check current terms rather than trust a blog post. Broadly: AWS Activate offers a smaller self-serve tier and a much larger tier available through approved accelerators, incubators and investors. Microsoft for Startups Founders Hub offers tiered Azure credits that scale with funding stage and eligibility. Google for Startups Cloud Program has a self-serve entry tier and a larger tier for venture-backed companies, with extra credit for AI-focused startups.

Two things matter more than the number.

Credits expire, usually within one or two years, and they rarely cover everything — Marketplace purchases, certain support plans and some third-party services are typically excluded. A team that builds on a service their credits do not cover can be surprised in month three.

And credits create a cliff. An architecture that costs nothing in year one and several thousand pounds a month in year two is a budgeting problem, not a bargain. Model the list-price bill before you commit, and treat credits as runway for experimentation rather than as a permanent subsidy.

Credits pay for the experiment. They do not pay for the business.

Lock-in, exit costs and the hiring question

Portability is often sold as the deciding factor and rarely is. Kubernetes runs anywhere, but the services around it — managed queues, identity, serverless functions, proprietary databases like DynamoDB, Cosmos DB and BigQuery — do not. Realistically, moving a startup's production workload between clouds costs a quarter of engineering nobody wants to fund. The sensible posture is not to avoid managed services, which would be expensive, but to avoid putting your core differentiator inside a proprietary one, and to keep your data in formats you can export.

The hiring market matters just as much. In the UK, AWS skills are the most widely available, Azure skills cluster around enterprise and public sector contractors, and Google Cloud skills are scarcer and often more expensive per day. If you are a five-person team hiring your first platform engineer, that is a real consideration — and so is the fact that your investors' technical advisers will have opinions formed on whichever cloud they last scaled.

A short decision checklist

Strip the marketing away and the decision usually comes down to a handful of questions.

1. Price your actual workload on all three, egress and observability included.
2. Confirm every service on your shortlist runs in a UK region, in production, with the redundancy you need.
3. Ask your two biggest prospective customers which providers their security teams have already approved.
4. Check which credit programme you qualify for, when it expires and what it excludes.
5. Look at the UK job market for the skills you will hire in the next twelve months.
6. Choose, then commit: multi-cloud at seed stage is a way of paying twice for the same problem.

None of the three is a mistake. AWS remains the default with the widest ecosystem, Azure wins where the customer is enterprise or public sector, and Google Cloud is compelling if your product is data or AI heavy. The founders who save the most money are rarely the ones who picked the cheapest provider. They are the ones who priced the whole system, in the region they actually needed, before they wrote the first line of infrastructure code.

Photo: kewl / Pixabay