Choosing a Cloud Vendor — AWS / Azure / GCP

About this article

This article is the third deep dive in the “System Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering how to choose a cloud vendor.

A casual “AWS, I guess” decides hiring, monthly cost, incident response, and regulatory handling for the next 10 years. AWS / Azure / Google Cloud are among the highest-exit-cost selections in software; later migration is essentially a system rebuild. This article covers each vendor’s strengths and weaknesses, world share, major services, and recommendations by scale and industry.

What is a cloud vendor in the first place

A cloud vendor is, roughly speaking, “a company that rents you servers and databases over the Internet.”

Imagine a rental apartment management company. Instead of buying land and building your own office (on-premises), you rent rooms (servers) prepared by the management company and pay utilities (pay-as-you-go). Floor-plan changes (configuration) are fairly flexible, but you follow the building’s rules (vendor specifications). The top three are AWS, Azure, and Google Cloud, together holding about 70% of the world cloud market.

Why cloud vendor selection matters

Once operations begin, hundreds of services interlock and migration to another vendor becomes nearly impossible — this is vendor lock-in. The abstraction of “always keeping migration possible” almost always ends as over-engineering. Vendor selection fixes your tech stack, talent strategy, and cost structure for a decade. Lock-in is not something to avoid but to accept and leverage deeply. That’s why the initial selection is critical.

The character of the big three

AWS — the lowest probability of regretting the choice

AWS launched in March 2006, the cloud-computing pioneer. It has held #1 world share into 2026. Originally Amazon’s internal e-commerce infrastructure released externally — technical reliability and scale are overwhelming.

Information density, adoption, ease of hiring — all surpass competitors. The lowest-regret pick. “Default new projects to AWS unless specified otherwise” is the rule. The downside: the service catalog itself is a learning wall.

AWS’s strength is “being the de facto standard.” Article counts on books, blogs, Stack Overflow; Terraform module counts on GitHub; new-grad and mid-career hires with AWS experience — all 2-3x the #2 (Azure). In the AI era this gap deepens: AI’s accuracy on AWS code is one tier above other vendors.

Default new builds to AWS. Deviate only when you can write the reason.

Azure — the main candidate for Microsoft-based companies

Microsoft Azure launched in February 2010, an enterprise-strong cloud. World #2, closing on AWS without slowing.

For companies on Office 365 / Microsoft 365, Azure is the natural unification target. Active Directory (Microsoft’s integrated identity)-anchored SSO and permission management work seamlessly — a direct reason many enterprises pick Azure. Industries with strict compliance (finance, healthcare, government) also lean here.

Azure’s growth post-2023 is also driven by the exclusive partnership with OpenAI. ChatGPT / GPT-4 / GPT-5 family models offered to enterprises via Azure OpenAI Service produced a new market, “Azure for embedding generative AI in operations.” AWS Bedrock and GCP Vertex AI have caught up substantially, but the OpenAI exclusive remains an Azure strength as of 2026.

Microsoft-centric companies and compliance-heavy industries: Azure is the favorite.

Google Cloud — the technical lead in AI, data and Kubernetes

Google Cloud (GCP) launched in April 2008, the third of the big three. Originally Google’s own infrastructure (YouTube, Gmail, search) opened externally. Has overwhelming technical leadership in containers, Kubernetes, AI/ML.

Kubernetes was originally developed by Google; the GKE (Google Kubernetes Engine) is the industry’s most polished. BigQuery and Gemini sit at a level that competitors haven’t matched.

On the other hand, GCP carries a historical reputation for “shutting things down.” The Cloud IoT Core wind-down (announced 2022, ended 2023) and a string of consumer-side closures (Reader, Hangouts, Inbox, Wave) left enterprises with the lingering doubt “Google shuts things down when they get bored.” Even on equal feature comparisons, this “personality” difference matters in long-term operations.

For analytics-, AI-, or Kubernetes-centric projects, the top choice. The long-term-reliability concern needs to be evaluated separately.

On global share the ordering is as follows.

World cloud market share, 2025 Q3. The big three together hold ~70% — the “three giants” era continues.

Azure’s catch-up comes from migrating Microsoft 365 customers and OpenAI-driven generative-AI adoption. GCP grows on AI-domain presence but the gap to #2 remains large.

A correspondence table of the main services

Functions are largely equivalent across vendors despite different names. Each vendor races to match competitor features, so basic system construction is covered everywhere.

Compute and storage line up like this.

The impression that “AWS has more features” applies to niches. Basics are covered by all three; differentiation lands at “ML -> GCP, identity -> Azure, overall -> AWS.”

Databases, CDN and AI follow the same pattern.

In NoSQL, AWS DynamoDB leads on stability and large-scale references. Azure Cosmos DB supports multi-model (document, graph, key-value, etc.); GCP Firestore is strong for mobile-app integration.

Basics line up everywhere. The difference is maturity and fit of individual services.

How to choose — three scenarios by scale

If you are building solo or at a startup — AWS, for the sheer volume of information

Choose AWS for the volume of material available. Almost any problem you hit has been hit before and written up, and that alone saves more time than any feature comparison. The free tier covers a surprising amount, and the managed services remove the operations you would otherwise be doing yourself.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS — pick one and use it deeply

Concentrate on one vendor and use it deeply. Spreading across two doubles the IAM, the monitoring and the IaC, and the second one is rarely used well. Accept the lock-in and take the integration benefits; the cost of an abstraction layer written to avoid it exceeds the cost it avoids.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large enterprise — fit with the existing estate is the strongest axis

Fit with what you already own outweighs any feature comparison. For a company built around Microsoft 365, the answer is Azure: the integration savings from Entra ID, Active Directory federation and Teams reverse AWS’s advantage in sheer volume of information. Core systems in finance and insurance go to AWS or Azure, whichever has the FISC compliance track record; the public sector starts from the government-cloud certified vendors. And if you have already been running on AWS for several years, staying on AWS is rational because the migration cost is simply too high. Judge on both the present state and the next five years. The era of choosing on feature differences is over — fit with the existing estate is now the strongest axis.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

Multi-cloud adopted for the purpose of “avoiding vendor lock-in” is only effective when there is a clear reason — a regulatory requirement, systems scattered after an acquisition, partial use of one vendor’s specific AI capability, or a BCP requirement. Choose it because “lock-in just feels wrong” and you end up having to hire specialists for both, doubling the cost and the operational difficulty.

AI decision axes — Does the AI know that vendor?

With AI-driven development as the assumption, the selection axis pivots to “how well does AI know this vendor?”

Niche domestic / mid-tier vendors have thin training data. Generated code that doesn’t run or calls non-existent APIs (hallucination) becomes more frequent. The lock-in problem is not solved by AI — “the weight of the first selection hasn’t changed.”

1. Affinity with existing assets (Microsoft / Google / none).
2. Engineer hiring / training feasibility (AWS is most favorable).
3. AI fluency in the vendor as the final differentiator.
4. Multi-cloud only with a clear reason.

AI training-data volume differs significantly between vendors

When you have AI write Terraform code, AWS resource generation accuracy is clearly higher than Azure or GCP. This is because the absolute volume of AWS-related code in public GitHub repositories is 3-5x that of Azure or GCP.

Specifically, instructing AI to “write VPC + ALB + ECS Fargate in Terraform” produces nearly-working code for AWS in one shot. The equivalent Azure configuration (Virtual Network + Application Gateway + Container Apps) sees higher frequency of parameter combination mistakes and deprecated API usage.

This gap may narrow in the future, but as of 2026, AWS is overwhelmingly favorable.

The meaning of vendor lock-in changed in the AI era

Traditional lock-in discussion focused on “can we technically migrate to another target.” In the AI era, “can AI accurately write for the migration-target vendor” becomes a new risk axis.

When migrating from AWS to GCP, having AI rewrite Terraform is technically possible. However, GCP-specific IAM design (Workload Identity Federation, etc.) and network design (Shared VPC) best practices have sparse training data, creating risk that post-migration operational quality degrades.

Pitfalls and forbidden moves

Aiming at “an abstraction that lets us move any time” fails almost without exception. Here are the five most dangerous.

The rule is to start only after producing the numbers for “migration cost versus three years of lock-in cost.”

Author’s note — the fear of being “dropped”

Google Cloud IoT Core’s wind-down was announced August 2022 and ended August 2023. Companies running it in production scrambled to pick a replacement and rewrite. Google has a history of closing consumer services (Reader, Hangouts, Inbox, Wave), and the doubt “Google shuts things down when they get bored” doesn’t go away — a frequent enterprise complaint.

AWS strongly emphasizes “once shipped, generally doesn’t get killed” as a stance, and the difference shows up in long-term-operations confidence. Even with feature parity, layering in “will this service exist in 10 years?” changes the picture. After IoT Core, “will this still be here in 5 years?” became unavoidable in GCP service selection.

Vendor selection means looking past the feature table to the vendor’s “personality.” Features look similar, but corporate culture and operating posture differ.

Cloud selection is a judgment about “personality,” not “features.” Vendors that kill things vs vendors that don’t.

What to decide — what is your project’s answer?

Articulate your project’s answer in 1-2 sentences for each:

• Primary cloud vendor (AWS / Azure / GCP)
• Region (Tokyo / Osaka / overseas)
• Existing-system integration
• Compliance (finance, healthcare, public)
• Whether multi-cloud is on the table
• Domestic-data-sovereignty requirement
• Engineer-supply realism

Write your answers down as an ADR. A concrete guide to writing them is here.

[DevOps Architecture] Documentationen.senkohome.com/arch-intro-devops-docs/

Related Articles

Summary

This article covered how to choose a cloud vendor — strengths of the big three, recommendations by scale and industry, the lock-in posture, and AI-era judgment.

The era of choosing on features is over; affinity with existing assets and AI’s information density now decide it. New, no constraint -> AWS. Microsoft stack -> Azure. AI / data -> GCP. Lean on one and use it deeply — the realistic answer for 2026.

The next article covers the major decision after vendor: the runtime (VM / container / serverless / Wasm).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.