How to choose between AWS, Azure and Google Cloud

The problem

Most teams do not pick a cloud from a clean sheet. They inherit an account, a partner, or a hire who knows one platform. AWS, Azure and Google Cloud cover the same basics: virtual machines, object storage, managed databases, Kubernetes and serverless. At that level the choice is close to a tie. The differences that matter show up later: identity flow, data location, network cost, and which managed services your team can run.

Sales pressure makes it worse. AWS has the widest catalog. Azure fits companies deep in Microsoft 365 and Entra ID. Google Cloud fits data teams that want BigQuery and a clean Kubernetes story. None of those is a reason on its own. A reason is a requirement you can test.

The costly mistake is choosing on a demo, then finding the real bill or the skills gap a year later. Egress charges, support plans, minimum commitments and retraining rarely appear in a slide deck. The goal is not the best cloud. It is the cloud that fits your workloads, your people and your contracts, with a known cost to leave.

What a good solution looks like

A good decision looks boring on paper. You get a one-page decision record that names the primary cloud, the workloads that will not use it, and the reasons. You get a weighted scorecard tied to real requirements, not a vendor feature list. You get a cost model that includes compute, storage, egress, support and staff time.

Identity comes first. If your staff live in Microsoft Entra ID, Azure removes friction. If you run Google Workspace, Google Cloud is a natural fit. AWS IAM Identity Center works with most directories, but test sign-in, group mapping and role assignment before you commit. A cloud that fights your identity provider costs you every day.

Set an exception path. Pick one primary cloud. Allow a second only for a named reason, such as an acquired product, a data partner or a regulated region. Write down who approves exceptions and how controls stay consistent. This avoids accidental multi-cloud, where two teams build two platforms and neither is well run.

A good choice is proven, not argued. A two-week spike with one real workload tells you more than a month of meetings. You want a deploy pipeline, a network path, a database and a bill for that workload. If the team cannot ship in two weeks, the problem is skills or process, not the logo.

How to build it

Start with a workload list. Group applications by pattern: web app, batch job, data warehouse, Kubernetes platform, Windows domain, AI training. For each group, note latency, data residency, peak load and the owning team. This list feeds every comparison. Do not compare providers in the abstract.

Run four checks in order. First, identity and network: can you federate to your directory, connect to your data centers and set up private networking without an exception? Second, data gravity: where the data lives, how big it is, and what it costs to move or query. Third, managed services: list the five you will actually use, such as managed PostgreSQL, a queue, Kubernetes, a data warehouse or an AI endpoint. Confirm each provider has a credible option your team can operate. Fourth, regions: confirm the region and service set you need, not just a dot on a map.

Run a bake-off on one representative workload. Build the same small slice on two providers, not three. Use the same infrastructure as code tool and pipeline. Measure time to first deploy, manual steps and bill clarity. On Kubernetes, compare EKS, AKS and GKE for upgrade effort and identity integration. On serverless, compare Lambda, Azure Functions and Cloud Run for cold starts and local testing. On data, compare Redshift, Synapse and BigQuery for how your analysts write queries.

Build the commercial model, but do it last. Model three years with expected usage. Include support, committed use discounts, savings plans or reservations, and egress. Check exit terms: the cost to move data out and the notice you must give. Get quotes in writing for the same scope. If a term is not in the contract, treat it as absent.

Risks and how to manage them

The skills gap is the most common failure. A team that knows one cloud well beats a team that knows three poorly. Count the engineers who can debug IAM policies, network routes and Kubernetes upgrades on the chosen platform. If the number is low, budget for training and a slower first quarter. Bring help for the landing zone, then take it over with runbooks.

Hidden costs bite later. Egress, cross-zone traffic, idle load balancers and forgotten snapshots add up. Tag every resource with owner, environment and cost center from day one. Set budget alerts and review them monthly. Check commitment utilization every quarter; unused commitments are a sunk cost.

Lock-in is a design choice. Managed services save time, and that is the point. Keep the exit path clear for what matters: portable data formats, infrastructure as code, and no deep coupling in the core transaction path unless the benefit is proven. Write a one-page exit plan for each critical workload and review it yearly.

Watch for organization drift. A second cloud arrives through an acquisition or a side project, and soon you have two identity systems and two security baselines. Add a rule: no new cloud account without an owner and a budget. Review the exception list each quarter and close what no longer earns its place.

How to measure success

Measure the decision, not the logo. Track time to first production deploy, the share of workloads on the primary cloud, and the number of approved exceptions. A good result is a falling exception count and a stable platform team, not a long list of services in use.

Track cost against the model. Review the bill by workload, not just by account. Watch egress as a share of spend, commitment utilization, and cost per request or per job. If the bill runs well above the model for two months, find the driver before you renegotiate.

Track reliability and people. Use incident count, mean time to restore and change failure rate for moved workloads. Ask engineers how long a new environment takes and how often they hit a permissions wall. Those answers predict whether the platform holds up as the team grows.

Review at 90 days and again at 12 months. At 90 days, check whether the spike assumptions held. At 12 months, check the commitment, support plan and exception list. If you want a structured start, the Discovery and roadmap sprint from Cloudverg is a two-week fixed-price engagement at $9,500 that ends with an architecture, a phased roadmap and a fixed price for phase one. It is one option among others.

Frequently asked questions