Well-Architected frameworks are among the most useful free resources in cloud architecture, yet many teams treat them as something to read once during certification and then forget. That is a mistake, especially now. Between 2025 and 2026, AWS, Microsoft and Google all made substantial changes to their frameworks, adding guidance for AI and agentic systems, elevating sustainability, introducing maturity models and expanding resilience testing practices. The frameworks have become living documents that reflect how architecture is actually changing.
This article summarizes the most significant updates across the three major frameworks, explains the common themes, and offers practical advice on how architecture teams can use them in reviews, standards and roadmaps rather than leaving them on the shelf.
Why the Frameworks Matter More Than Ever
The core purpose of a Well-Architected framework has not changed: it provides a structured set of design principles and questions, organized by pillars such as reliability, security, cost, performance and operations, that help teams make and document trade-offs. What has changed is the breadth of workloads they now cover and the pace at which providers update them.
Three forces explain the acceleration. First, AI workloads introduce new architectural concerns, such as model selection, evaluation, data pipelines for retrieval, GPU capacity and responsible AI controls, that older guidance did not address. Second, high-profile cloud outages and resilience regulation have pushed reliability guidance toward explicit testing rather than assumed redundancy. Third, sustainability has moved from a niche topic to a design pillar as emissions reporting has matured. Each provider has responded in its own way, but the direction is remarkably consistent.
A Well-Architected framework is most valuable not as a checklist you pass once, but as a shared vocabulary for the trade-offs your teams make every week.
AWS: Three AI Lenses and an Agentic Preamble
At re:Invent 2025, AWS announced three AI-focused Well-Architected lenses in a post published on November 19, 2025. The new Responsible AI Lens provides a structured way to assess AI workloads against responsible AI best practices and is positioned as the foundation for the other two AI lenses. AWS frames responsible AI as a built-in part of system design rather than an add-on, noting that AI systems can be used beyond their original intent and that their probabilistic nature can produce unexpected outcomes even within intended use.
The updated Machine Learning Lens provides best practices organized by the framework pillars for each phase of the ML lifecycle, covering both traditional supervised and unsupervised learning and modern AI applications. AWS describes this guidance as cloud-agnostic in its principles, while also adding service-specific practices for areas such as distributed training, inference components, bias detection and cost options for training.
The updated Generative AI Lens covers model selection, prompt engineering, model customization, workload integration and continuous improvement. Notable additions include an expanded responsible AI preamble covering eight core dimensions, an updated data architecture preamble for generative AI workloads, a new agentic AI preamble introducing architecture paradigms for agentic systems, and eight architecture scenarios such as autonomous call centers, knowledge worker copilots and multi-tenant generative AI services.
Azure: Maturity Models, AI Personas and Health Models
Microsoft publishes a detailed change log for the Azure Well-Architected Framework, and the list of changes since mid-2025 is long. Several stand out for architects:
- Maturity models for all five pillars were introduced in June 2025, along with an assessment, giving teams a way to judge progress rather than just compliance with individual recommendations.
- AI workload guidance expanded steadily: sustainable design for AI workloads in June 2025, a refreshed responsible AI article covering agentic systems, auditability and human oversight in July 2025, agentic personas added to AI workload team guidance in August 2025, expanded AI application design and training data guidance in October 2025, AI data platform guidance in November 2025 and a new AI architecture pattern article in May 2026.
- Reliability and operations deepened, with new articles on multi-region disaster recovery planning, incident response, incident management, monitoring design, testing and a throttling design guide added between late 2025 and mid-2026.
- Health models became the basis for refreshed monitoring guidance in April 2026, and Microsoft updated its architect-role guidance to recommend treating the architecture decision record as an append-only log.
- Sustainability gained a dedicated sustainable workloads section covering all five pillars in June 2026.
- New workload sets were added for HPC workloads in March 2026 and Microsoft Fabric in May 2026.
Microsoft also retired some service guides, such as the Azure OpenAI Service guide in September 2025, and renamed Azure AI Foundry to Microsoft Foundry in its guidance in April 2026. Teams that copied guidance into internal standards should check whether their references are still current.
Google Cloud: Sustainability Becomes a Pillar
The Google Cloud Well-Architected Framework is organized into pillars for operational excellence; security, privacy and compliance; reliability; cost optimization; performance optimization; and, since January 2026, sustainability as a full pillar. It also offers perspectives that apply the pillars to specific contexts, including an AI and ML perspective and a financial services perspective added in July 2025.
Google’s change log shows a steady sequence of major updates to the AI and ML perspective across 2025 and early 2026, covering operational excellence, cost optimization, reliability, security and performance optimization. Other notable updates include expanded guidance on measuring and improving sustainability in June 2026, information on periodic zone and region disconnect testing in the reliability pillar in July 2026, expanded zero trust guidance on network segmentation and data exfiltration prevention in August 2026, and new cost optimization guidance on unit economics in August 2026.
The Common Themes Across All Three
Read side by side, the updates reveal five shared shifts that architecture teams should internalize.
- AI is now a first-class workload type. All three providers have dedicated AI guidance organized by their standard pillars, and both AWS and Microsoft now explicitly address agentic systems.
- Responsible AI is treated as architecture, not policy. Human oversight, auditability and evaluation are framed as design decisions with architectural consequences.
- Sustainability has moved into the core. Google made it a full pillar, Microsoft added a sustainable workloads section across all pillars, and AWS has had a sustainability pillar for several years.
- Resilience means testing. Zone and region disconnect testing, failure mode analysis, multi-region disaster recovery planning and safe deployment practices all received attention.
- Maturity and economics complement checklists. Maturity models and unit economics guidance help teams prioritize improvements rather than chase every recommendation.
Which Framework Should a Multicloud Team Follow?
Many organizations run workloads on more than one provider and ask whether they should adopt one framework as the standard or follow each provider’s guidance separately. In practice, a hybrid approach works best. The pillar structures are similar enough that you can define a single internal set of pillars and principles, mapping each to the corresponding sections in the AWS, Azure and Google Cloud frameworks. Provider-specific guidance then applies at the service level, where it is genuinely different.
When choosing which framework to treat as the primary reference for cross-cutting topics, consider where each currently goes deepest. Based on their published change logs and announcements, AWS offers the most structured lens-based approach for responsible AI and generative AI reviews, Microsoft offers pillar maturity models and a detailed set of operational and reliability design guides, and Google offers a dedicated sustainability pillar and a financial services perspective. Borrowing the strongest elements from each is perfectly legitimate, as long as your internal baseline is coherent and teams know which document is authoritative.
The main risk in multicloud estates is inconsistency: the same kind of workload reviewed against different expectations depending on where it runs. A single internal baseline with provider mappings prevents that.
How to Use the Frameworks in Practice
The frameworks only create value when they shape decisions. The following practices help embed them into everyday architecture work.
Build an internal baseline, not a copy
Rather than asking teams to read three sets of provider documentation, create a concise internal architecture baseline that references the relevant framework guidance for each pillar and adds your own standards: approved services, regions, identity patterns, data classification rules and resilience tiers. Review it twice a year against provider change logs, because the frameworks now change frequently.
Use lenses and perspectives for specialized workloads
For AI applications, run reviews using the relevant AI lens or perspective in addition to the general pillars. The AWS Generative AI Lens scenarios and the Azure AI workload series are especially useful for teams designing retrieval-augmented generation systems or agents, because they surface concerns such as evaluation, grounding data quality and human oversight that general reviews tend to miss.
Make reviews proportional
A full framework review for every workload is unrealistic. Tier your workloads by business criticality and run comprehensive reviews for the top tier, lighter reviews for the middle tier and automated checks for the rest. The AWS Well-Architected Tool supports custom lenses, and AWS publishes a sample repository for implementing custom lens guidance, which can help you encode your internal baseline as reviewable questions.
Record decisions, not just findings
Every review should produce architecture decision records for the significant trade-offs. Microsoft’s recommendation to treat the decision record as an append-only log is a practical one: rather than rewriting history when a decision changes, add a new record that supersedes the old one, so future teams understand both what was decided and why it changed.
Track maturity over time
Use the Azure pillar maturity models, or a similar internal model, to score workloads periodically. Plotting maturity over time is more motivating and more informative than a list of open findings.
A Hypothetical Review Using the Updated Guidance
Consider a hypothetical financial services firm building a customer-facing assistant that answers account questions and can initiate simple service requests. The architecture team runs a review that combines the general pillars with AI-specific guidance.
The reliability review, informed by recent guidance on zone and region testing, reveals that the assistant depends on a single model endpoint region without a tested fallback. The security review, drawing on agentic guidance, flags that the agent’s permissions to initiate service requests are broader than necessary and that there is no human approval step for higher-risk actions. The responsible AI review highlights the absence of an evaluation dataset covering edge cases such as vulnerable customers. The cost review, using unit economics guidance, establishes cost per resolved conversation as the key metric. And the sustainability review prompts the team to evaluate whether a smaller model can handle most queries with routing to a larger model only when needed.
The outcome is a set of decision records and a prioritized backlog: add a secondary model region with a tested failover, narrow agent permissions and add approval for sensitive actions, build an evaluation suite, implement model routing and publish cost per conversation on the team dashboard.
Pitfalls to Avoid
- Treating framework reviews as audits. If teams feel judged, they will hide problems. Frame reviews as design support.
- Relying on stale internal copies. Service guides are retired and renamed regularly; link to the source guidance and review it on a schedule.
- Ignoring the AI-specific guidance. General pillars do not capture evaluation, grounding or agent oversight concerns.
- Pursuing every recommendation. Trade-offs are the point. Use maturity models and business criticality to prioritize.
- Skipping sustainability. With all three providers now treating it as core, it belongs in every substantial review.
Outlook
The pace of change seen in 2025 and 2026 is likely to continue. Expect more guidance on agentic systems, including how agents interact with each other and with enterprise systems, deeper integration of AI assistance into the review process itself, and closer alignment between architecture guidance and regulatory expectations for resilience and AI governance. Google’s October 2026 addition of information about Well-Architected Framework agent skills hints at a future in which AI assistants help teams apply framework guidance directly during design and review.
Conclusion
The Well-Architected frameworks from AWS, Microsoft and Google have evolved from static best-practice documents into actively maintained guidance that tracks the biggest shifts in cloud architecture: AI and agents, responsible AI, sustainability, tested resilience and unit economics. Architecture teams that build an internal baseline on top of them, use the specialized lenses for AI workloads, run proportional reviews and record decisions carefully will get far more value than those that treat the frameworks as a one-time certification topic. Revisit them now; they have probably changed since you last looked.
How Hanoi Technology Can Help
Hanoi Technology runs Well-Architected reviews for cloud and AI workloads and helps teams turn findings into architecture decisions and prioritized backlogs, through projects, dedicated teams or managed services.