How to Choose a Cloud Provider: The Criteria That Actually Matter

Choosing where to host a website, an application, or an entire company system is one of those decisions that look purely technical but weigh on the budget for years. The cloud market offers dozens of providers, each with its own price list, and the risk is comparing them by looking at the wrong line item. This guide lays out the criteria that actually matter, without pushing any particular provider: the goal is to help you reason, not to sell.

By “cloud provider” we mean a company that rents out computing resources over the Internet: processing power, storage, networking. Instead of buying a server and keeping it in the office, you pay a fee to use one (or a thousand) remotely. So far, so simple. The complexity shows up when you try to work out what it really costs.

The pricing model: hyperscaler versus VPS

Simplifying a lot, providers fall into two big families. On one side, the hyperscalers - the global giants like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud - which sell a catalog of hundreds of separate services, from traditional compute instances to the new ARM chips built to cut costs. On the other, the VPS providers (Virtual Private Server, a virtual machine on a flat fee) with an almost all-inclusive price.

The difference isn’t just scale, it’s philosophy. A hyperscaler doesn’t sell you “a machine”: it sells you the compute instance, and then - as separate line items - the public IP address, disk storage, backups, the load balancer, network traffic, and the support plan. The instance price is the tip of the iceberg. A VPS starts from the opposite idea: one fee that already includes disk, traffic, and an IP address. Less flexible, but far easier to budget for.

Neither model is “right” in absolute terms. The point is that comparing them only on the hourly instance price is misleading, because that price covers different things in each case.

The hidden cost: data egress

If there’s one line item that blows up estimates, it’s outbound bandwidth, or egress: the data traffic that leaves the cloud toward the Internet, that is, toward your users. Every image, video, download, or API response that reaches a visitor is outbound traffic.

On hyperscalers this traffic is metered, charged per gigabyte. AWS, for example, includes 100 GB per month for free, aggregated across all services, and then bills every gigabyte after that. It sounds like little, but a website with lots of images or a service that distributes files can move terabytes a month: at that point bandwidth becomes one of the heaviest items on the bill, sometimes more than the instance itself.

VPS providers usually flip the logic: they bundle a very generous traffic allowance into the fee and charge very little for any overage. The practical consequence is simple: if your application moves a lot of data outward, the metered model can cost orders of magnitude more. If instead it mostly burns CPU and database with little traffic, the gap narrows. The rule is to estimate outbound bandwidth before you choose, not after the first bill.

Managed or self-managed?

Here the comparison flips. A managed service is a resource the provider maintains on your behalf: a managed database, for instance, is updated, backed up, and replicated automatically, with the node replaced if it fails. The alternative is self-managed: the provider hands you a bare machine, and the database, updates, backups, and monitoring are yours to configure and keep running.

Hyperscalers excel at managed services, from the fully administered database to serverless GPUs for AI inference: they have enormous catalogs that take operational work off your plate. VPS providers mostly offer raw material - excellent and cheap, but yours to administer. The right question isn’t “who has more of them,” but “how much is my time worth.” A managed database costs more than one you install by hand, but that premium is the work (and the 3 a.m. on-call) you don’t have to do yourself. If the skills to run infrastructure exist in-house, self-managed saves money; if they don’t, the managed service often costs less than the staff you’d otherwise need. Self-managed isn’t free: it’s a cost that shifts from the cloud bill to the hours of whoever runs it.

A provider has data centers - the warehouses full of servers - in geographic zones called regions. The choice of region matters for two reasons. The first is latency: the closer the server is to your users, the faster the responses arrive. The second, often more important, is legal.

The GDPR, the European data protection regulation, sets precise rules on where personal data can end up. Its Chapter V (Articles 44 and following) establishes that transferring personal data outside the European Union is prohibited unless specific conditions are met. In plain terms: if you handle data belonging to European citizens, the physical location of that data is not a detail.

There’s a subtlety that many people miss, though. Choosing a European region isn’t enough to shield the data from every outside request. Because of the U.S. CLOUD Act, American jurisdiction follows the company, not the server: a provider subject to U.S. law can be compelled to hand over the data it controls even if it’s stored in a European data center. This doesn’t mean American hyperscalers are “outlaws” - they’ve built dedicated offerings to address the issue - but that data sovereignty has to be judged on the specific product and the legal entity that runs it, not on the flag in the logo.

The risk of lock-in

Lock-in means technical dependence: how costly and complicated it is to switch providers once you’re in. On a VPS it’s low, because it’s usually a standard Linux machine you can migrate elsewhere in an afternoon. On a hyperscaler it can be high, because proprietary services - bespoke databases, serverless functions, message queues - don’t exist in the same form elsewhere, and rewriting them costs.

There’s also a subtler form of lock-in: data gravity. The more data you accumulate in a service, the more it costs to take it out, because moving those terabytes goes through that same billable outbound bandwidth. The cost of egress thus doubles as a toll that discourages migration. The defense is architectural: prefer standard, open components where you can, describe your infrastructure with Infrastructure as Code tools instead of by hand, and know from the start what a move would cost. Lock-in isn’t a moral flaw, it’s a choice to make with your eyes open.

Support

The last criterion, often underrated: what happens when something breaks at 3 a.m. Support levels vary enormously. Some providers include basic assistance in the fee; hyperscalers sell support plans separately, often as a percentage of monthly spend. It’s worth reading the SLA (Service Level Agreement): it promises a certain uptime and certain response times, but often the “refund” for an outage is just a credit on the bill, not compensation for the real damage. Support isn’t judged by the phone number on the homepage, but by what’s written in the contract.

In short

There’s no “best cloud”: there’s the right model for a specific workload. It pays to go in order. First, estimate outbound bandwidth, the variable that most often overturns the math. Then decide how much operational work to delegate, choosing between managed and self-managed based on the skills available. Next, check where the data has to live and who can be compelled to hand it over. Finally, factor in the risk of lock-in and actually read the support terms. The hourly instance price, the one everyone compares first, is almost always the least important item.

# How to Choose a Cloud Provider: The Criteria That Actually Matter