Most British startups pick a cloud provider the way they pick a bank: whichever one they already know, or the one a friendly engineer used at their last job. That instinct is not unreasonable. AWS, Microsoft Azure and Google Cloud are all reliable, well documented, and more than capable of running a small product.

The differences that matter to a team of eight with eighteen months of runway are narrower and more practical: what the free tier genuinely covers, where the servers sit, what paperwork your clients will ask for, and which line items quietly grow once you are live. Here is how the three compare on the questions UK founders actually ask.

Free tiers: credits with an expiry date

All three use the same trick, in slightly different packaging. You get a welcome credit, a set of services that are free for twelve months, and a smaller "always free" allowance that never expires.

AWS reshaped its free tier for new accounts. If you signed up recently, expect a credit allowance and a limited window rather than the old twelve-month list of services; accounts opened earlier keep the previous arrangement. Azure's free account works the same way, with a modest first-month credit, a twelve-month selection that includes a burstable virtual machine, and a handful of always-free services. Google Cloud gives new customers a substantial credit with a 90-day clock, plus an always-free tier that includes a small instance — but in US regions only, so a London team does not get a free VM in London.

The genuinely useful part of every free tier is the boring bit: a small database, a serverless function allowance, a logging quota. That is where the value sits. Treat the time-limited credits as a subsidy for a prototype, not as a business model.

Startup programmes are worth a look — AWS Activate, Microsoft for Startups and Google for Startups Cloud all hand out credits to eligible companies. Read the conditions. Credits usually expire within a year or two, rarely cover support plans, and often exclude marketplace purchases.

UK regions: pick London unless you have a reason not to

All three have a London region with multiple availability zones:

• AWS — London (eu-west-2), with Ireland (eu-west-1) a short hop away.
• Azure — UK South (London) and UK West (Cardiff), which gives you a genuine in-country pair for disaster recovery.
• Google Cloud — London (europe-west2), plus Belgium and the Netherlands nearby.

Two practical warnings. First, not every service launches in every region; newer managed offerings often land in Ireland or a US region first, so check availability before you design around one. Second, the same instance type can be priced differently between London and Ireland. If your workload is not latency-sensitive, running batch jobs or non-production environments in Ireland is a legitimate saving.

Latency from London to London is negligible for almost any web application. Ireland adds a handful of milliseconds, which matters if you are building real-time trading tools, multiplayer games, or a microservice mesh that chats to itself constantly.

Residency is not the same as compliance

Choosing a UK region keeps data at rest in the UK. It does not make your provider a British company, and it does not automatically settle the questions your enterprise clients will ask.

Under UK GDPR and the Data Protection Act 2018 you still need a data processing agreement, a record of what you process and why, and a clear list of sub-processors. Where data or support access crosses borders, you need a transfer risk assessment. The UK's adequacy status with the EU has been extended on a rolling basis rather than settled permanently, so check the current position before you build an EU-client story on it.

Residency is a design decision. Compliance is a paper trail. Your clients want both.

Some public sector and financial services buyers ask for UK-only support staff, specific certifications, or a listing on the Crown Commercial Service's G-Cloud framework. All three providers have compliance portals listing which services are in scope for which certification, and frame contract terms vary. Ask early — retrofitting a service into a stricter boundary six months in is expensive. For regulated work, take proper legal advice on the contracts; this is a summary, not a substitute for it.

Support: the subscription your credits will not cover

AWS and Google charge a percentage of your monthly spend for business-tier support, with a monthly minimum. Azure uses fixed monthly tiers, with a percentage element once spend passes a threshold. In every case, the entry-level free or basic plan covers billing questions only — not "my production database is down".

For most small teams, a paid business support plan is not worth it in year one. A better use of money is an engineer who knows the platform and a startup programme contact who can escalate. Revisit the maths once you have paying customers with contractual uptime commitments.

Pricing traps that catch small teams

Compute is rarely what blows the budget. These are:

• Cross-zone and cross-region traffic. All three have softened charges for customers leaving entirely, but everyday traffic between zones, or to another cloud, still bills.
• NAT gateways and load balancers. Hourly charges that can exceed the cost of the tiny instances behind them.
• Idle storage. Old snapshots, unattached disks, container images nobody deletes, and logs set to retain forever.
• Commitments. Savings plans and reserved instances cut the bill sharply but lock you into a shape your architecture may outgrow.
• Serverless at volume. Almost free when quiet, sometimes pricier than a VM when busy. Watch the per-invocation maths.
• Free-tier clocks. The twelve-month window starts when you open the account, not when you launch.

A short routine prevents most of this. Turn on budgets and alerts before you deploy anything. Tag every resource by project and environment, and enforce the tags with policy. Review the two or three services that dominate your bill weekly for the first month. Set log retention and snapshot lifecycles on day one rather than during your first cost review.

How to decide without regretting it later

Run a two-week spike. Deploy the same small workload — a container, a managed Postgres database, a queue — in two of the three using Terraform. Measure the bill, the deploy time and how quickly your team gets unstuck when something breaks. The cheaper provider that your developers fight every day is not the cheaper provider.

Then keep your exit cheap. Standard containers, standard databases and object storage move reasonably well; proprietary managed services are comfortable and sticky. Whichever you choose, your team should be able to run it at two in the morning without a support ticket. That is the real test.

Photo: Elchinator / Pixabay