Choosing a Cloud Provider: One Cloud or Several

Most teams answer two questions about cloud providers, usually a year or two apart. The first is “which one?” The second, after an acquisition, a new data team or an outage, is “should we be on more than one?” They look like separate decisions, but they rest on the same analysis: what your workloads need, what your organization already has, and what you are willing to pay in money and complexity. This article covers both.

It deliberately avoids a feature-by-feature comparison. AWS, Google Cloud and Azure all offer compute, storage, databases, Kubernetes, serverless and AI services that are good enough for the vast majority of workloads, and AWS vs. GCP vs. Azure: Core Differences already maps one to the other. What actually decides the choice is usually something outside the feature list.

Start with constraints, not features

Before comparing services, write down the things that rule options out. In practice, one or two of these settle the decision far more often than any benchmark does.

• Existing contracts and licensing. If your company already has a Microsoft enterprise agreement and runs Windows Server and SQL Server, Azure Hybrid Benefit lets you bring those licenses to Azure, which can change the cost picture considerably. Committed-spend agreements with any provider work the same way: money already promised is money you’ll want to use.
• Where your data must live. Data residency rules, customer contracts and sector regulation can require specific countries. Check that each provider has a region there, and that the specific services you need are offered in that region, not just the region itself.
• Compliance attestations. All three publish long lists of certifications, but if you need a particular one (FedRAMP High, a national health-data standard, PCI DSS for a specific service), confirm it covers the exact services you plan to use.
• A service you genuinely depend on. Sometimes one service is the reason: BigQuery for a data team, a specific foundation model available through Amazon Bedrock or Microsoft Foundry, or deep integration with Microsoft 365 and Entra ID.
• The skills you already have. A team that knows one provider well will ship faster and make fewer expensive mistakes there. Retraining is possible, but it’s a real cost, and it belongs in the comparison.
• Latency to your users. If most users are in one geography, check region locations and the network path from there.

flowchart TD
    A["New workload"] --> B{"Hard constraint rules out a provider?"}
    B -->|Yes| C["Remove it from the list"]
    B -->|No| D{"Team already skilled on one provider?"}
    C --> D
    D -->|Yes| E["Default to it unless a constraint says otherwise"]
    D -->|No| F["Shortlist two, run a proof of concept"]
    F --> G["Score on weighted criteria"]
    E --> H["Check total cost, not list price"]
    G --> H
    H --> I["Decide and document why"]

The default in the middle of that diagram matters. Without a specific reason to choose differently, the provider your team already knows is usually the right answer. The differences between providers are real but rarely large enough to outweigh experience.

Where each provider tends to fit

These are tendencies, not rules. Each provider is capable across the board, and each has customers who break every pattern in this table.

The free tiers and account setup differ too; Setting Up Free Accounts on AWS, GCP and Azure is the quickest way to try all three before deciding.

Check the details that matter to you

A useful early test is whether the specific resources you need exist in the region you need. Each CLI can answer that in one command:

# AWS: is m7i.large offered in Canada (Central)?
aws ec2 describe-instance-type-offerings \
  --region ca-central-1 \
  --location-type region \
  --filters Name=instance-type,Values=m7i.large

# Google Cloud: which zones in Montreal offer n4-standard-4?
gcloud compute machine-types list \
  --filter="name=n4-standard-4 AND zone~northamerica-northeast1"

# Azure: is Standard_D4s_v5 available in Canada Central, and with what restrictions?
az vm list-skus --location canadacentral --size Standard_D4s_v5 --output table

The same goes for managed services and AI models: check the provider’s “products by region” page for every service on your list.

Score the shortlist

When constraints don’t settle it, compare the remaining options on weighted criteria. Pick the weights before you look at the results, or the scoring turns into a justification for whatever you already wanted.

A tie like this one is common, and it is useful information: it tells you the choice matters less than you feared, and that execution will decide the outcome. Break the tie with a short proof of concept that builds one real piece of the workload on each candidate.

Compare total cost, not list prices

Hourly VM prices are easy to compare and rarely decide the bill. A realistic three-year estimate includes:

• Commitment discounts: savings plans, reserved instances and committed-use discounts, which differ in flexibility between providers.
• Data transfer: especially data leaving the cloud to users or to other clouds, which is often the most underestimated line.
• Managed services: a managed database or Kubernetes control plane costs more per hour than self-managed VMs and much less in engineering time.
• Support plans: production workloads usually need a paid tier, typically priced as a percentage of spend.
• People: training, hiring, and the time spent operating the platform.

Each provider has a pricing calculator for the first four. The fifth is usually the largest number, and it is the one the calculators can’t show. The broader shift from up-front capital spending to pay-as-you-go operating costs is covered in Benefits and Challenges of Cloud Computing.

What multi-cloud actually means

“Multi-cloud” covers several different situations, and they have very different costs. It’s also distinct from hybrid cloud, which combines a public cloud with your own data centers; Deployment Models: Public, Private, Hybrid, and Multi-Cloud covers the definitions.

Most organizations that call themselves multi-cloud are in the first two rows, and that’s fine. The fourth row is the one vendors’ marketing tends to imply, and it’s the one that rarely pays off.

The real costs of running on several clouds

Every additional provider multiplies certain kinds of work. Before adding one deliberately, account for these:

• Skills. Each cloud has its own identity model, networking model, CLI and failure modes. Two clouds means either two sets of experts or a team that knows both less deeply.
• Identity and access. Users, service accounts, roles and policies all differ between providers. Without central identity, access reviews and offboarding become error-prone. The IAM articles for AWS, Google Cloud and Azure show how differently each one works.
• Networking and data transfer. Traffic between clouds usually leaves one provider’s network and is billed as outbound data transfer. Dedicated private links exist, such as Google’s Cross-Cloud Interconnect and AWS Interconnect – multicloud, but they add their own fees and design work.
• The lowest common denominator. Code written to run anywhere can’t use the managed services that make each cloud productive. Portability has a price in features.
• Observability and security posture. Logs, metrics, alerts and security findings live in different tools unless you centralize them, and gaps between tools are where incidents hide.

Exit costs are falling, though. All three major providers now offer some form of free data transfer for customers moving their data off the platform, with conditions that vary by provider. In the EU, the Data Act limits switching charges to the provider’s direct costs during a transition period and bans them entirely from 12 January 2027. That ban covers the switch itself, not ongoing traffic between clouds, so a running multi-cloud setup still pays for data transfer.

Patterns that work

If you do run on more than one cloud, a few patterns keep it manageable.

flowchart LR
    IDP["Central identity provider"] -->|"SAML or OIDC"| AWS["AWS: applications"]
    IDP -->|"SAML or OIDC"| GCP["Google Cloud: analytics"]
    AWS -->|"private interconnect"| GCP
    IAC["Terraform or OpenTofu"] --> AWS
    IAC --> GCP
    AWS --> OBS["Central logging and monitoring"]
    GCP --> OBS
    CI["CI/CD pipeline"] -->|"workload identity federation"| AWS
    CI -->|"workload identity federation"| GCP

• One identity provider for people. Federate every cloud from a single directory, such as Entra ID, Okta or Google Workspace, so joining, leaving and access reviews happen in one place.
• No long-lived keys for machines. Use workload identity federation so CI/CD pipelines and services in one cloud get short-lived credentials in another. AWS IAM roles, Google Cloud Workload Identity Federation and Microsoft Entra workload identities all accept OIDC tokens from external issuers. This site’s own deploy pipeline works this way: GitHub Actions gets short-lived Google Cloud credentials without any stored key.
• One infrastructure-as-code tool. Terraform and OpenTofu manage all three providers with the same workflow, review process and state handling, even though the resources themselves differ:

terraform {
  required_providers {
    aws    = { source = "hashicorp/aws", version = "~> 6.0" }
    google = { source = "hashicorp/google", version = "~> 7.0" }
  }
}

provider "aws" {
  region = "ca-central-1"
}

provider "google" {
  project = "analytics-prod"
  region  = "northamerica-northeast1"
}

# Application data lands in S3 on AWS...
resource "aws_s3_bucket" "events" {
  bucket = "example-app-events"
}

# ...and is analyzed in BigQuery on Google Cloud.
resource "google_bigquery_dataset" "events" {
  dataset_id = "app_events"
  location   = "northamerica-northeast1"
}

• Containers where portability matters. Packaging services as containers on Kubernetes or a serverless container platform keeps the application layer movable. Be realistic, though: the databases, queues and identity around those containers are still provider-specific.
• Centralized observability and security findings. Send logs, metrics and security alerts to one place, whether that is a third-party platform or one provider’s tools ingesting from the others.
• Keep data close to compute. Design so that large datasets cross the cloud boundary rarely, in batches, rather than on every request.

Do you need cross-cloud failover?

Usually not. A full outage of a major provider across every region is far rarer than a problem in one zone or one region, and those are handled within a single provider: run across at least two availability zones, and for critical systems, add a second region. That covers the vast majority of real incidents at a fraction of the cost and complexity of running on two providers.

Cross-cloud failover starts to make sense in narrower cases:

• A regulator asks for it. Financial services regulators in particular increasingly ask firms to assess concentration risk and maintain credible exit plans for critical cloud providers. Often a tested exit plan satisfies this without active-active operation.
• The cost of downtime is extreme and the application is simple enough to replicate, such as a stateless API or a static site.
• The data layer allows it. Replicating a relational database across providers with low data loss is hard. If you can’t solve that part, failing over the application tier alone achieves little.

If you go this route, test the failover regularly. An untested failover plan is a document, not a capability.

A short checklist before you commit

• Write down the hard constraints first: regions, compliance, contracts, must-have services.
• Default to the provider your team knows, unless a constraint or a key service says otherwise.
• Compare three-year total cost, including data transfer, support and people.
• Treat multi-cloud as a choice for specific workloads, not a goal in itself.
• If you run more than one cloud, centralize identity, use one infrastructure-as-code tool, avoid long-lived keys, and centralize logs and security findings.
• Keep an exit plan for each provider, even if you never expect to use it: what you’d move, in what order, and what it would cost.

For skills, each provider has an entry-level certification that teaches its vocabulary and core services: AWS Certified Cloud Practitioner, Microsoft Certified: Azure Fundamentals and Google Cloud Digital Leader. Engineers then usually move to the associate-level architect or administrator certifications for the provider they use most.

Further reading

• AWS Regional Services List, Google Cloud locations and Azure products by region
• Pricing calculators: AWS, Google Cloud and Azure
• Google Cloud Cross-Cloud Interconnect and AWS Interconnect
• Workload Identity Federation on Google Cloud
• EU Data Act (Regulation (EU) 2023/2854)

Key takeaways

• Hard constraints such as region, compliance, existing contracts and must-have services settle most provider choices before features do.
• Without a specific reason to choose otherwise, the provider your team already knows is usually the right one.
• Score shortlisted providers on weights you set in advance, and compare three-year total cost, including data transfer, support and people.
• Multi-cloud comes in several kinds. Placing specific workloads on the best-fit cloud is common and manageable; active-active across providers is rarely worth its cost.
• Every extra cloud adds skills, identity, networking and observability work. Centralize identity, use one infrastructure-as-code tool and avoid long-lived keys.
• Multi-zone and multi-region designs on one provider handle most outages. Keep a tested exit plan rather than assuming you need cross-cloud failover.