AWS and Azure Well-Architected Framework Compared - Part I: Overview
Comparing Amazon and Microsoft's architecture frameworks
Introduction
Before we begin, what is architecture?
Architecture is concerned with the “tasteful application of scientific and traditional rules of good construction to the materials at hand”. And even in the term’s origins from Greek we find the sense of a craftsman weaving together disparate elements into a cohesive, unified whole. Such an idea is engrained directly into the etymology of “architecture”.
For most of its history in the English language, this term was of course applied to physical construction, but much like “engineering” and “infrastructure” these metaphors have evolved into an abstraction which applies just as much now to the digital landscape as it did to the material world before.
The quality of building can take a variety of forms.
You can build out of cheap necessity, hodge-podge ideas, a desire for experimentation, reckless urgency to meet a demand, or just to get by. But to build well is different than to build something at all.
This was well understood by the early pioneers of computing when architecture was applied to new things like software and networks.
At the core, you need architecture to undergird these complex, expensive, and massively scaled expanses of the digital fabric that clothes our world.
Cloud systems are no different in this regard.
Quality in cloud “construction” can vary widely as well.
When you wake up Day 1 in the AWS or Azure ecosystem, even if you are a fairly experienced software engineer, you can quite easily work yourself into a five or six digit monthly invoice.
Or something that breaks half the time.
Or something with a gaping security flaw.
You can build in the cloud, but to tastefully apply those rules of good construction using the materials at hand, is its own art and science, that of cloud architecture.
The Advent of the Well-Architected Framework
You do not need to go far to find a large pool of anecdotes from individuals and businesses over the past dozen years, who from some cost or configuration blunder, would never go back to the cloud again.
Like many new technologies, especially those that are neither foolproof nor user-friendly, it is easy for many with negative experiences with such technology to discount it because “it doesn’t work”.
For vendors like Amazon and Microsoft, you want long-term lock in from your customers.
This is why there was a concerted effort to both devise common architectural principles and designs and then to provide an educational system and robust credentialing (Solutions Architect) around new “roles” in the labor market earmarked to accelerate the advance of cloud migrations globally.
To this end, each cloud provider has published their own “Well-Architected Framework” to help consolidate in a holistic manner, all the consideration that should go into designing, implementing, and maintaining cloud systems within their specific ecosystems.
By paying attention to specific pillars such as Operational Excellence, Security, Reliability, Performance efficiency, Cost optimization, and (for AWS) Sustainability, each WAF provides a broad classificatory system that enables focus on particular key areas while maintaining a lens for the general big picture as well.
This post is the beginning of a series that will compare and contrast the AWS and Azure Well-Architected Frameworks (hereafter referred to as WAF). With Google Cloud’s WAF potentially at some future date.
We will look at not only the content but the format, the philosophy, and the structure of such frameworks and how they mesh with the opinionated ways each vendor cultivates their own offerings.
Revision History
AWS
Important to analyzing any publication is an assessment of its history. The differences here between the AWS and Azure WAF already appear quite stark.
AWS offers a designated “Document Revisions” page which outlines both the history of the AWS WAF from its initial publication in October 1, 2015 with each subsequent update notated with a description and change date. Most recently, a “major update” refresh in November 6, 2024 to refresh many of the WAF pillars, particularly in light of the advanced around generative AI.
Alongside this are framework versions with the first specified as 2022-03-31 and the most recent one as 2024-06-27. Four in total are noted though without any description or title attached to these versions.
What remains unclear from this view is what constitutes a change in framework versions versus the document revisions.
The first framework version 2022-03-31 does not even have a changelog entry for that date.
The subsequent three framework versions do have changelog notes that describe pillar refreshes or updates to best practices, but this does not alone seem to increment the framework version as the most recent changelog from November 6, 2024 has the most expansive description of changes but apparently does not constitute any change in the framework version.
There is a level of irony that a document or framework exclusively concerned with architectural best practices should itself have an unclear and confusing versioning system, but this irony is all the deeper with the Azure WAF which has no explicit revision history whatsoever.
Azure
The closest Azure comes to this is a “What’s new” page which offers a month-by-month view of changes to the WAF up to the last 12 months.
From a standpoint of comprehensive documentation, this is a fairly weak approach to documenting version history, particularly as the press release announcing the Azure WAF is dated July 20, 2020, and the public GitHub repo attached to this documentation received its first commit on December 1, 2021. Even using the Wayback Machine, the current URL for the WAF home page had its first snapshot on April 23rd, 2023.
There simply has not been a dedicated effort by Azure to provide a systematic view of the evolution of architectural best practices in the way that AWS has.
This irony is further underscored by the Azure WAF’s explicit recommendation to provide architecture decision records (ADRs) that provide an auditable tracking system for stakeholders to maintain accountability during architectural changes.
This is common sense in the profession and though it is applicable to all joint architectural decision, Microsoft does not seem to apply this principle to the WAF itself.
Compared
I think this truthfully reflects on the nature of the AWS and Azure ecosystems respectively around change control. At least from anecdotal practitioner experience, AWS has an at least somewhat clear process about AWS service changes and the ability to toggle between versions and UI interfaces in the AWS portal.
Azure is much more cluttered and opaque in this regard as services sometimes have preview options while at other times options and features get whisked in and out of the Azure portal. If you get really nitty-gritty you can use explicit API versioning to get Azure do what you want it to do, but it is often a moderate inconvenience at best when these changes do occur.
Architecture Fundamentals
Both WAF’s have a collection of pages in their overview sections concerned with the fundamentals of architecture, before it enters into the individual pillars. Here again we see broad differences between the AWS and Azure approach.
AWS
“Good intentions never work, you need good mechanisms to make anything happen” — Jeff Bezos
The AWS WAF focuses on architecture as a practice. Not in the sense of practicing piano before a recital, but in the sense that as a doctor practices medicine, so too will you practice architecture, as something between art and science.
For the AWS WAF, this begins with definitions both of the WAF pillars as well as of the terms contained therein.
This is an appropriate starting point as terminology often serves as an anchor to help plant the mind in the right kinds of words and concepts that are the most applicable to thinking through the problems of cloud architecture.
Following these definitions, come notes “On architecture” which provide a definitive statement I would consider fundamental to the nuance of the AWS WAF.
This page begins by describing a traditional “on-prem” customer who centralizes technology architecture into a single team which operates as the gatekeeper working in conjunction with isolated product or feature teams. It explicitly calls out TOGAF and Zachman as operating under this paradigm.
Amazon rejects this approach.
“At AWS, we prefer to distribute capabilities into teams rather than having a centralized team with that capability.”
Of course the risk of this approach is having an independent voice that can judiciously ensure adherence to standards. However, AWS says that they are effectively able to mitigate insider bias from these individual service teams by holding them accountable to centralized practices and mechanisms that ensure standards continue to be met.
This and much of the AWS WAF in general, is an outworking of Amazon’s famous leadership principles.
It is this strongly opinionated view of how the business as a whole should be run (i.e. the Amazon philosophy) which has shaped and determined the best practices that AWS prescribes itself.
For example, “Every Day is Day 1” emerges in how strongly AWS advocates for thinking in terms of cloud-native systems. Workloads need to continuously be reinvented so that they are not hampered by years of vestigial accrual. That is why cloud-native design is part and parcel of the AWS package.
This is further expounded upon in the next page “general design principles” which enumerates six general architectural principles:
“Stop guessing your capacity needs” - Cloud enables on-demand elasticity
“Test systems at production scale” - Testing production scale is far easier with Pay-As-You-Go cloud computing costs.
“Automate with architectural experimentation in mind” - Automations should be build in such a way as to provide architectural extensibility and modification
“Consider evolutionary architectures” - Architecture is not an event but a process. Cloud-native thinking enables this kind of elastic evolution.
“Drive architectures using data” - Architectural choices can be judged quantitatively and this can be leveraged for continuous improvement
“Improve through game days” - Test and simulate various cases through game days to see how the architecture holds up.
For the AWS WAF, architecture is not a theory or a science but a practice guided by general, flexible best-practice patterns which may evolve over time.
Azure
By contrast, the Azure WAF overview focuses on architecture as a role. The doctor may practice medicine, but what does that look like day-to-day? What is it to be a medical professional? What is it to be a professional cloud architect?
This is the anchor point for the Azure WAF.
These responsibilities are listed in the fundamentals of the solution architect:
“Have a decision-making framework”
Identify expected decisions in advance.
Make informed decisions, considering limitations, constraints, tradeoffs, effort reversability, and risk.
Document decisions in an architecture decision record (ADR) along with the justification.
Follow up on implementation
“Know cloud design patterns”
Evaluate a workload’s functional and nonfunctional requirements to recognize patterns.
“Be forward-thinking”
Growth model, how will workloads scale
Compliance changes and the roadmap
Regional expansion for locally-based companies.
Product roadmaps. What will deprecate and what will expand
“Design for supportability”
Cloud provider support
Operational visibility
Customer support capabilities
“Maintain and enhance your skills”
Education
Community participation
Explanatory exercises
“Collaborate for success”
Maximize cloud provider and community leverage
“Be methodical in your design approach”
Combine frameworks such as the TOGAF with WAF.
All of these are geared toward professionalism in the cloud architect world.
Alongside these fundamentals, are sections detailing the “Deliverables” of the architect, wrapped up in a checklist format which is a core part of the Azure WAF’s structure in general. Each pillar of excellence will get its own checklist as well.
This kind of list provides a far more concrete sense of what an architect does day-to-day. Meetings, presentations, reports, documentation. These are part and parcel of the architect lifestyle, most particularly in the corporate and enterprise environments where Microsoft is so deeply embedded, and Azure drew its initial customer base from.
I will not go into each of these deliverables individually here, but I do find the Azure WAF approach to be more robust in providing guidelines for how to document things like architecture decisions via the ADR (which again ironic as the WAF does not have a robust version history system).
Compared
These overview sections are particularly crafted to fit different audiences.
The AWS WAF is more focused on the technologist, how to speak to someone in technical leadership with the appropriate forms of abstraction to describe varying technology stacks.
By contrast, the Azure WAF explicitly notes that cloud architecture must comprise both the technical and the business dimension for it to work at all, which again makes sense based on Microsoft’s history of partnerships.
But beyond that, the Azure WAF is more helpful in this section because it specifically documents the architect’s role as a professional, which is sometimes the more difficult part in contrast to the more logical dimensions of architecture as a practice, in the way the AWS WAF focuses on it.
Perhaps most importantly when considering the foundations of the AWS and the Azure WAF in parallel, the AWS WAF exhorts their customers to partake fully in the Amazon model in order to thrive in the AWS ecosystem. This means decentralized architecture.
The Azure WAF explicitly calls attention to its compatibility with many architectural frameworks including TOGAF (see Fundamentals 7a above).
It does not aim to be a comprehensive philosophy that commandeers how the business is run. It rather seeks to negotiate with business stakeholders with where they are at and how they currently operate, something which enterprise management and leadership teams would probably prefer over the more abrasive Jeff Bezos/AWS tone.
This is a contrast that will appear even more clearly when considering how AWS and Azure respectively consider the first pillar of “Operational Excellence”.