AWS vs. Azure vs. GCP Well-Architected Compared: The Pillars Converged, the Tooling Didn't

Every cloud vendor sells you the same promise with different branding: follow our architecture framework and your workloads will be secure, reliable, performant, and cheap. AWS has the Well-Architected Framework. Microsoft has the Azure Well-Architected Framework. Google has the Google Cloud Well-Architected Framework, formerly the Architecture Framework. If you read only the pillar prose, they are near-clones — because two of them are descendants of the first. The interesting differences are not in the pillars. They are in the review tooling, the extension model, and one genuinely divergent philosophy Google calls shared fate.

This comparison is written for the person who has to pick one and defend the choice: the platform engineer or architect who owns multi-cloud estate standards, and the engineering leader signing off on review spend. We verified every claim below against the live framework pages in October 2026, and we anchor each provider in a named, public deployment rather than vendor marketing.

TL;DR

• The pillars converged years ago. Five concerns — operations, security, reliability, performance, cost — appear in all three frameworks. Only sustainability splits the camp: AWS has it as a pillar, Google promoted it to a full pillar in January 2026, and Azure keeps a five-pillar structure without it.
• The review tooling is where they genuinely diverge. AWS ships a free console tool and now an AI agent behind a support-plan paywall. Azure ships the most productized free assessment suite. Google ships the best-written framework and no self-service review tool at all — GCP reviews are partner-delivered engagements.
• The extension models encode each vendor's worldview. AWS extends via lenses (domains like agentic AI and digital sovereignty), Azure extends via per-service best-practice guides, Google extends via cross-pillar perspectives and deployment archetypes.
• The receipts are real. Burns & McDonnell cut AWS costs 30% through a Well-Architected review. Paulig ran an Azure review during its MES/ERP testing phase and walked away with 13 prioritized findings. apree health built its HIPAA-regulated migration on Google's Enterprise Foundations Blueprint and consolidated 600 VMs into 287.
• Verdict: pick by tooling and extension fit for the cloud you actually run, not by pillar prose. On multi-cloud estates, run each provider's native review on its own estate and use the shared pillar vocabulary for reporting upward.

Why compare frameworks at all

A framework comparison sounds like an academic exercise. It is not, for three reasons. First, if your organization runs more than one cloud, someone has to decide whether "our internal review standard" maps cleanly onto all three vendors' checklists or just one. Second, reviews cost engineer-weeks — the cheapest review is the one your provider's own tooling automates, so tooling maturity directly determines your review bill. Third, the frameworks are the vendors' honest self-portraits: what each one measures, names, and omits tells you what that vendor believes architecture risk actually is.

One framing note: the common assumption that "all three have the same six pillars" is wrong, and the difference is not cosmetic. Azure — the framework Microsoft explicitly describes as "a set of quality-driven tenets, architectural decision points, and review tools" — is a five-pillar structure. That shapes what its review tooling asks you about.

The pillar maps: five shared concerns, one split

Here is the honest mapping, verified against each provider's own pillar pages in October 2026. Read it as three translations of the same underlying checklist:

Three observations that matter more than the table itself:

• Google names its security pillar "security, privacy, and compliance." That is not branding flourish — it is a statement that privacy and regulatory posture are first-class architecture concerns inside the pillar, which is also where Google's shared-fate model lives.
• Azure's five-pillar structure is a deliberate scoping decision. Microsoft's five tenets are workload-focused; environmental sustainability guidance exists in Microsoft's broader documentation but is not one of the five formal pillars of the framework. If your organization reports against sustainability metrics, on Azure you will be maintaining that reporting outside the WAF review itself.
• The convergence is the point. When five of six concerns are near-identical across vendors, the pillar prose stops being a differentiator — which is exactly why the rest of this comparison is about tooling, extensions, and process.

        THE CONVERGED CORE (5)                    THE DELTAS
  +-------------------------------------+   +---------------------------+
  |  operational excellence / ops       |   |  AWS:    sustainability   |
  |  security                           |   |  GCP:    sustainability  |
  |  reliability                        |   |           (full pillar   |
  |  performance (efficiency /          |   |            since 2026-01) |
  |           optimization)             |   |  Azure:  none - 5 pillars |
  |  cost optimization                  |   +---------------------------+
  +-------------------------------------+
      same concerns, same questions,
      three different tooling stacks  -->

The 2026 currency check: who is actually maintaining their framework

"Current framework version" is a hard requirement for any serious comparison, because all three frameworks now change monthly. Here is what each vendor shipped or revised in 2026, verified from each provider's own change log — this is the table to re-check every quarter:

Read that table as a maintenance-budget signal, not a feature list. Google's change log shows the most granular cadence — dated revisions to individual recommendations, monthly. Azure batches updates into named monthly drops with concrete new guides. AWS updates the base framework document rarely (the core doc still carries its November 2024 publication date) but ships lenses continuously — the 2026 lens pipeline (agentic AI, digital sovereignty, streaming media) is where AWS's framework energy is going. If your review process bakes in specific checklist items, budget for re-validation quarterly on all three.

Extension models: lenses, service guides, and perspectives

When the base pillars converge, vendors differentiate in how they extend the framework into domains the pillars do not cover. The three models are structurally different:

• AWS lenses are downloadable domain overlays. A lens extends the six-pillar review with domain-specific questions — the current catalog covers ML, data analytics, serverless, HPC, IoT, SAP, streaming media, games, hybrid networking, financial services, Microsoft workloads, and, since June 2026, agentic AI. Lenses run inside the same review tooling as the base framework. The 2026 lens dates tell you where AWS sees review demand heading: agentic AI systems and digital sovereignty workloads.
• Azure service guides attach best practices to individual Azure services. Instead of domain overlays, Microsoft publishes "Architecture Best Practices" guides per service — AKS, Azure SQL Database, Azure SQL Managed Instance — that inherit the five pillars and get updated independently. The August 2026 AKS update, adding Azure Kubernetes Fleet Manager for policy-driven workload distribution across member clusters, is a service-guide change, not a pillar change. This model is operationally convenient: your AKS platform team reads one guide, not a domain lens.
• Google perspectives and deployment archetypes cut across all pillars. Google's cross-pillar perspectives (AI and ML; financial services) re-frame all six pillars for one workload class — the AI/ML perspective has its own operational excellence, security, reliability, cost, and performance chapters. Separately, Google's deployment archetypes (zonal, regional, multi-regional, global, hybrid, multicloud) encode the most useful idea in any of the three frameworks: your reliability and cost posture should match the blast radius of the deployment archetype you actually chose. A zonal workload reviewed against multi-regional expectations produces wasted spend, not better architecture.

For a platform team, the practical translation: AWS's model asks "what domain is this workload in?", Azure's asks "what services does this workload use?", and Google's asks "what class of deployment is this workload and what AI/vertical context does it carry?". None is strictly superior — but they produce very different review checklists, and multi-cloud standards documents that ignore this produce checklist soup.

Review tooling: the actual differentiator

Frameworks are prose; reviews are product. This is where the three vendors have genuinely different offerings, and where your review cost is decided:

• AWS ships the Well-Architected Tool — free, in-console, question-driven. You define a workload, answer pillar questions, and get a risk report with prioritized improvements. AWS's own framework document describes it as "a service for reviewing your workloads at no charge." The companion Well-Architected Labs provide hands-on remediation code. New in October 2026: the Well-Architected Agent preview automates review-remediate loops against live accounts — but it sits behind a Business+ (or higher) support-plan gate, which makes it a paywall on top of a free tool. We broke down the agent's quotas, IAM read surface, and pricing gate in our October 2026 deep-dive on the Well-Architected Agent.
• Azure ships the most productized free assessment suite. The Azure Well-Architected Review is a free 60-minute assessment — multiple-choice and multiple-response questions — returning personalized recommendations across the five pillars. Around it sit lifecycle-specific variants: a Mission Critical Well-Architected Review (30–60 minutes) for technical design areas and operational effectiveness, a Go-Live review (30–60 minutes) for pre-production evaluation, and an Azure Landing Zone Review (30 minutes, aimed at customers with two or more years of Azure experience) for platform readiness. The assessment tooling maps reviews onto your workload's lifecycle stage — that framing is genuinely useful and unique to Azure.
• Google ships the framework and no self-service review tool. The Cloud Architecture Center publishes the framework, the cross-pillar perspectives, and the Enterprise Foundations Blueprint — but there is no console equivalent of the AWS WA Tool or the Azure assessment suite. Framework reviews on GCP are delivered as engagements through Google Cloud and its partner ecosystem; partners like CloudKeeper market GCP framework reviews explicitly as a service. If you want an automated, recurring, zero-cost GCP review in the way AWS and Azure customers get one, that product does not exist — plan for either partner spend or an internal checklist built from the framework's published recommendations.

The tooling gap compounds: AWS and Azure reviews are cheap enough to run continuously (and the AWS agent pushes toward automation), while GCP reviews are structurally episodic. On a multi-cloud estate, expect your GCP estate to be reviewed less often than your AWS and Azure estates unless you consciously budget against that drift.

flowchart TB
    W[Workload under review] --> AWS_PATH
    W --> AZ_PATH
    W --> GCP_PATH
    subgraph AWS_PATH ["AWS"]
        A1["Well-Architected Tool
(console, free)"] --> A2["Lenses per domain
(agentic AI, sovereignty, ...)"]
        A2 --> A3["Agent preview, 2026-10
(Business+ support gate)"]
    end
    subgraph AZ_PATH ["Azure"]
        B1["Free assessment suite
(60-min WAF review, Go-Live,
Mission Critical, Landing Zone)"] --> B2["Per-service best practice guides
(AKS, Azure SQL, ...)"]
    end
    subgraph GCP_PATH ["Google Cloud"]
        C1["Framework + Foundations Blueprint
(documentation, no console tool)"] --> C2["Partner-delivered review
(paid engagement)"]
    end

The one philosophy gap: shared fate

Google is the only vendor of the three that has formalized something beyond shared responsibility: the shared-responsibility-and-shared-fate model states that Google accepts part of the accountability for your workload outcomes — the provider's own reliability engineering, abuse detection, and operational practices are part of your risk surface, so Google commits to operating its side well enough that your workload inherits it. In practice that shows up in the framework's reliability guidance: Google documents how it runs periodic zone and region disconnect testing in a production-equivalent environment — a 2026 addition to the reliability pillar — because the customer's recovery design depends on the provider behaving predictably during real failures.

Treat this as a real but bounded difference. Shared fate does not transfer liability for your misconfigured VPC, and it is not a contractual SLA clause you can invoke. It is a different review lens: on GCP, part of your reliability review is verifying that your design consumes the provider-side resilience features (zone-redundant services, automatic regional failover behaviors) rather than rebuilding them yourself. AWS and Azure framework reviews ask similar questions implicitly; Google is the only one that names and documents the philosophy.

The receipts: three named deployments

Framework comparisons rot into marketing if nobody can point to production outcomes. All three frameworks have public, named deployments — here is one per vendor, with the numbers each organization published:

• AWS — Burns & McDonnell cut AWS costs 30%. The Kansas City engineering firm (founded 1898, employee-owned) had used AWS since the early 2010s and wanted better visibility into cloud practices; by 2019 it ran a Well-Architected review alongside AWS partner Trend Micro, whose Cloud One-Conformity product handled real-time posture checking against the framework's recommendations. Published results: AWS costs reduced 30%, mean time to fix misconfigurations reduced 50%, plus faster vulnerability remediation and compliance support. This is the canonical AWS review outcome: the review's value concentrates in security and cost findings you already suspected but could not prioritize.
• Azure — Paulig reviewed a MES/ERP renewal mid-testing and got 13 prioritized findings. Paulig, the Finnish company renewing its global manufacturing-execution and ERP systems, ran an Azure Well-Architected Review with Knowit during the testing phase — before production existed. Networking (the original motivation) was in good order; most findings landed in operational excellence, especially roles and responsibilities. The review produced a 13-point prioritized report, and Paulig's own staff recommended the two-phase pattern: review early with trimmed scope, review again at go-live. A second named Azure outcome: Australian packaging manufacturer National Can Industries explicitly aligned its post-migration platform to the five pillars via partner Oreta — governance, tagging standards, identity, and cost optimization as a formal Phase 2, not an afterthought.
• Google Cloud — apree health built its HIPAA migration on the Enterprise Foundations Blueprint. The healthcare company (over a million patients and providers on its platform, PHI regulated under HIPAA) faced a $5 million hardware refresh and instead migrated to Google Cloud using the Enterprise Foundations Blueprint as its roadmap: Cloud HSM with customer-managed keys, VPC Service Controls perimeters, Security Command Center, and a defense-in-depth model mirroring Google's own. Published results: 600 VMs and 135 services consolidated to 287 VMs in a 100% Terraformed environment, migrated with zero downtime. This is the strongest demonstration of what GCP's framework ecosystem does best — the Blueprint turns framework guidance into a deployable landing-zone pattern.

One practitioner data point that tempers the vendor stories: an Azure review practitioner's account of running Well-Architected reviews by hand documents the gap between automated recommendations and real reviews — in one client environment, Azure Advisor had effectively run out of cost recommendations while the manual review kept finding them (an orphaned SignalR service, an older App Service generation, scaling ahead of real traffic). The same account describes a medical company keeping an application alive with 20 instances across two regions — until the review traced the crashes to a single outdated NuGet package. Reviews are diagnosis; the automation is a starting sweep, not the review itself.

Cost math: what a review actually costs (October 2026)

Order-of-magnitude economics, dated 2026-10-12, because the tooling landscape moved this month:

• Tooling cost: AWS Well-Architected Tool — free. Azure assessment suite (WAF review, Go-Live, Mission Critical, Landing Zone) — free. Google — no free self-service tool; partner-delivered framework reviews are priced per engagement, and like the rest of the consulting market, no GCP review partner publishes a rate card — budget a scoped engagement, not a listed price.
• Labor cost: the real line item. A workload-level review consumes days of senior-architect and stakeholder time — Paulig's review ran during a testing phase with the project team in the room, and practitioner accounts describe days of manual digging per review even when the automated sweeps come back clean. Multiply by workload count before promising your leadership a "free review program."
• Remediation cost: the review is the cheap part. The 13-finding Paulig report and Burns & McDonnell's misconfiguration backlog both required an owner and a backlog after the review ended. A review without a remediation owner is a very expensive PDF.
• Cost of not reviewing: the counterfactual is what makes reviews defensible — running 20 instances across two regions to compensate for one outdated package is pure waste, and Burns & McDonnell's 30% cost reduction is the measured version of the same effect. No framework review is cheaper than the waste it catches.

The verdict: which framework to run, when

When NOT to use each framework

• Skip the review entirely on workloads scheduled for decommission. Reviews generate remediation backlogs; a workload leaving the estate should not inherit one. AWS's own framing — the framework document calls the review process "a constructive conversation about architectural decisions, and not an audit mechanism" — is the right mental model: no conversation, no review.
• Do not run a full six-pillar (or five-pillar) review before an architecture exists. Azure's Go-Live assessment and Paulig's two-phase pattern exist precisely because reviews timed to a lifecycle stage produce cheap-to-fix findings. A review of a whiteboard is ceremony.
• Do not buy a partner review without a remediation owner. This applies triple on GCP, where partner-delivered reviews are the only structured option — the engagement produces findings, and findings without an owner decay into the expensive-PDF pattern.
• Do not treat any of the three as a compliance certification. None of them certifies anything. If your regulator or your enterprise customer demands attestation, you need the actual compliance program (SOC 2, ISO 27001, HIPAA, regional sovereignty regimes) — the frameworks feed it, they do not replace it.
• Do not adopt the AWS agent as your only review mechanism. It is a preview, it is paywalled behind Business+ support, and its automated findings are a starting sweep — the practitioner evidence above shows provider-native automation reliably runs out of recommendations before a real review does.

The operating cadence that survives production

If you run reviews once and stop, you bought a snapshot. The pattern that holds up in the named cases above is:

• Per workload, at lifecycle milestones. Review at go-live (Azure's Go-Live assessment is purpose-built for this; Paulig's two-phase pattern is the manual version), and re-review on major architecture change — new multi-region posture, new AI serving tier, new data-regime obligations.
• Per estate, quarterly. Re-validate your checklists against each provider's change log — Google publishes dated recommendation revisions monthly, Azure batches named monthly drops, AWS ships lenses continuously. A checklist item retired by the vendor is worse than a missing one.
• Per finding, with an owner and a date. Burns & McDonnell's 50% faster misconfiguration fixes came from Trend Micro's continuous checking after the review — findings moved into the same loop as vulnerabilities. If you want the durable version of that on Kubernetes estates, our security baseline guide covers the continuous side; for the landing-zone patterns that make reviews pass cleanly in the first place, see landing zones that survive year two.
• Report upward in the converged vocabulary. Five concerns — operations, security, reliability, performance, cost — plus sustainability where you track it. Your steering committee does not need to know which vendor's tool produced which finding, and the convergence shown above means you never have to explain the difference.

The bottom line

All three frameworks will make your workloads better, and none of them is a moat. Choose by the tooling your team will actually run: AWS if you want free automation with an optional AI upgrade path, Azure if you want the most productized free assessments and service-level guidance, Google if you want the best-written guidance and a deployable blueprint and are willing to pay humans for the review part. Then keep the cadence — the frameworks change monthly now, and a 2025 checklist reviewed in 2026 is how the waste they exist to catch gets back in.

References & further reading

• AWS Well-Architected Framework — official framework document (AWS documentation; publication date November 6, 2024)
• AWS Well-Architected — pillars, lenses, and whitepapers (AWS)
• Announcing the AWS Well-Architected Agent (preview) — AWS News Blog, October 1, 2026
• Burns & McDonnell Reduces Costs by 30% by Following AWS Well-Architected Framework Best Practices (AWS case study)
• Azure Well-Architected Framework (Microsoft Learn)
• What's new in the Azure Well-Architected Framework (Microsoft Learn; August 2026 updates)
• Azure Well-Architected Review — free assessment (Microsoft Learn Assessments)
• Paulig's new system architecture underwent an Azure Well-Architected Review during the testing phase (Knowit case study)
• NCI builds a scalable, secure and cost-optimised platform on Azure (Oreta case study)
• What I actually learned running Well-Architected reviews by hand (Spotto engineering blog)
• Google Cloud Well-Architected Framework (Cloud Architecture Center)
• What's new in the Google Cloud Well-Architected Framework (2026 change log)
• Shared responsibilities and shared fate on Google Cloud (Cloud Architecture Center)
• apree health case study — Google Cloud
• Google Cloud Architecture Framework Reviews (CloudKeeper — example partner-delivered review offering)
• AWS Well-Architected Labs — hands-on remediation guides