Evaluation guide

How to evaluate cloud infrastructure providers

This guide is for infrastructure, platform and cloud leads choosing a primary cloud, adding a second provider, or placing a specific workload such as GPU training or a regulated system. It assumes you already run workloads in at least one cloud and want a comparison that holds up with finance and risk.

By Techarda editors · Updated · How we rank

In short

Use this guide to compare public, sovereign and specialist cloud providers on what decides the outcome: the services you need in the regions you must use, total cost including data transfer, how outages are contained and reported, shared security responsibility, residency and the cost of leaving. Then shortlist three to five providers on Techarda and compare them side by side.

What’s changing in Cloud Infrastructure

Before you compare anyone, it helps to know what has shifted in the market, because it changes which questions matter.

Specialist clouds compete on accelerators

Providers focused on GPU compute now compete with the large clouds for training and inference work. They can be quicker to supply hardware and lighter on surrounding services, so check what else the workload needs.

Sovereign cloud offers have multiplied

Providers now market sovereign regions, local partnerships and in-country operations. The details differ widely: who operates the region, where the control plane sits and who can be compelled to hand over data.

Data transfer charges are under scrutiny

Egress and cross-region charges shape architecture and make leaving expensive. Some providers have eased transfer charges for customers moving out, usually with conditions, so read the terms closely.

Cost management is a standing discipline

FinOps has moved from occasional clean-ups to a continuous practice with its own roles and tooling. Providers differ in how much cost detail they expose and how quickly it arrives.

What to judge vendors on

Those shifts shape the criteria below. Each one says why it matters and what to ask, so you can take it straight into a vendor call.

CriterionWhy it mattersWhat to ask vendors
1Services available in your regionsA provider’s full catalogue is not available everywhere. Newer, local and sovereign regions often launch with a subset.“Which of the specific services we need are generally available in the regions we must use, and which are in preview or missing?”
2Total cost including data transferCompute and storage prices are easy to compare. Egress, cross-zone traffic, support plans and managed service fees are where estimates go wrong.“Using our architecture, what would we pay each month including data transfer, support and managed services, and which discounts need a commitment?”
3Reliability and outage handlingOutages happen at every provider. What matters is how failures are contained, how fast you are told and what the service credits are really worth.“How are regions and zones isolated from each other, how do you communicate during an incident, and what would your SLA pay out against our cost of downtime?”
4Security and shared responsibilityThe provider secures the platform and you secure what you build on it. Confusion about where that line sits causes many cloud incidents.“For each service we plan to use, which security controls are yours and which are ours, and what defaults do new accounts start with?”
5Residency, sovereignty and legal accessWhere the data sits is only part of the question. Control-plane metadata, support access and foreign legal orders matter too.“Where are our data, backups and control-plane metadata held, who can reach them from outside the country, and how do you handle government requests for data?”
6Capacity and quotasGetting the instances you need, especially accelerators, can be harder than the price list suggests.“Can you commit capacity for the instance types we need in our regions, and how quickly are quota increases approved?”
7Cost visibility and controlsYou cannot manage what you cannot see. Delayed or coarse billing data turns small mistakes into large bills.“How quickly does cost data appear, can we allocate it by team and workload, and can we set limits that stop spending rather than only send alerts?”
8Exit and portabilityEvery managed service you adopt raises the cost of leaving. Know that cost before you depend on the service.“What tooling and terms do you offer for moving data and workloads out, and what transfer charges apply when we do?”

Trade-offs to settle early

No vendor does well on every criterion, and some pull against each other. Decide where you stand on these before the demos start, or the demos will decide for you.

One primary cloud or several

One provider means deeper skills, simpler networking and better volume discounts. Several reduce dependence on one supplier and duplicate tooling, skills and security work.

Hyperscaler breadth or specialist focus

The largest providers offer nearly every service in one place. Specialist and regional providers can be simpler, cheaper or closer for a specific need, and you build more around them yourself.

Managed services or portable building blocks

Managed databases, queues and AI services save a great deal of engineering time. Sticking to virtual machines and containers keeps you portable and leaves more for your team to run.

Commitments or flexibility

Reserved and committed-use pricing cuts the cost of steady workloads. It also ties you to a provider, and sometimes an instance family, for the term.

Sovereign region or full catalogue

Sovereign and local regions can meet residency rules that standard regions cannot. They may lag on services and capacity, so confirm the exact services you need.

Red flags

As the answers come back, watch for these. One on its own isn’t a deal breaker, but it deserves a follow-up question in writing.

  • Cost estimates that leave out data transfer, support or managed service fees.
  • Sovereignty claims where the control plane or the support team sits offshore.
  • Regional service lists that mix generally available and preview services without saying which is which.
  • No reference customers in your country or sector using the regions you would use.
  • No clear answer on exit transfer charges, or on the conditions for waiving them.
  • SLA credits presented as protection when they cover a small share of your cost of downtime.

Build your shortlist

Start with the workloads and where they must run, then use Techarda to narrow the field to three to five providers.

  1. List the workloads, the services each depends on and the regions or countries each must run in.
  2. Keep providers that offer those services as generally available in those regions today.
  3. Price one representative workload end to end with each provider, including data transfer and support.
  4. Read recent stories on Techarda for outages, pricing changes and new regions, and turn them into questions.
  5. Use the practitioner questions below to see what teams like yours ran into, then compare side by side.

Companies to consider in Cloud Infrastructure

Listed by recent activity on Techarda (what people are reading, following and discussing). The order says nothing about quality, market share or fit for your needs.

Compare Amazon Web Services, Google Cloud and Cloudflare

Latest Cloud Infrastructure stories

Once you have names, recent news is where pricing changes, acquisitions and outages show up first. These are the five newest stories in this category.

All stories in the feed →

What practitioners are asking

News tells you what vendors announced. These open questions show what teams are still trying to work out, with the least-answered first.

Open the community space →

Where evidence is thin

A shortlist is only as good as the evidence behind it, and ours is still growing category by category. Here is what’s missing in Cloud Infrastructure right now.

20 of 20 companies have no published reviews

If you’ve run one of these in production, a short review helps the next team decide. Reviews are moderated before they appear.

3 questions with no answers yet

An answer from someone who has made the same decision is often more useful than any guide. Share what worked, what didn’t and what you’d check next time.

Answer a Cloud Infrastructure question
FAQ

Frequently asked questions

What should I ask Cloud Infrastructure vendors about services available in your regions?

A provider’s full catalogue is not available everywhere. Newer, local and sovereign regions often launch with a subset. Ask: Which of the specific services we need are generally available in the regions we must use, and which are in preview or missing?

What should I ask Cloud Infrastructure vendors about total cost including data transfer?

Compute and storage prices are easy to compare. Egress, cross-zone traffic, support plans and managed service fees are where estimates go wrong. Ask: Using our architecture, what would we pay each month including data transfer, support and managed services, and which discounts need a commitment?

What should I ask Cloud Infrastructure vendors about reliability and outage handling?

Outages happen at every provider. What matters is how failures are contained, how fast you are told and what the service credits are really worth. Ask: How are regions and zones isolated from each other, how do you communicate during an incident, and what would your SLA pay out against our cost of downtime?

What should I ask Cloud Infrastructure vendors about residency, sovereignty and legal access?

Where the data sits is only part of the question. Control-plane metadata, support access and foreign legal orders matter too. Ask: Where are our data, backups and control-plane metadata held, who can reach them from outside the country, and how do you handle government requests for data?

New to some of the terms in this guide? The glossary explains Egress fees, FinOps, Serverless computing, Shared responsibility model and Sovereign cloud.

This guide is written by Techarda editors to our editorial standards. No vendor paid to appear in it or saw it before publication. See our methodology, the trust dashboard or go back to the Cloud Infrastructure hub.