AWS Well-Architected Framework: The Architecture Layer It Leaves to You

The AWS Well-Architected Framework is AWS’s guidance for evaluating cloud workloads against a set of design principles and best practices, organized into six pillars, with a review process and a free tool for running it.

Our argument is narrower and, if you run Well-Architected reviews, probably familiar. The framework tells you what to review and how, and AWS explicitly recommends reviewing continually rather than at a meeting. What it does not hand you is the thing you would review against in between: a current model of the architecture itself, as distinct from the state of individual resources. We build that model for a living, so read this as a piece written from one side of the problem.

What the Framework Contains

The six pillars are operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Underneath them sit design principles and numbered best practices grouped under review questions. AWS pairs the guidance with the AWS Well-Architected Tool, a free service for reviewing workloads against the framework.

Two of those pillars carry the argument here. AWS defines operational excellence around supporting development, running workloads effectively, gaining insight into how they operate, and continuously improving the processes behind them. It defines reliability around a workload performing its intended function correctly and consistently when it is expected to.

Reliability therefore depends on the intended behavior as well as the deployed configuration.

AWS Already Told You Not to Treat This as an Annual Event

AWS recommends that the people building an architecture review it continually and update their answers as it evolves. Its review process is intended to support ongoing improvement, not only periodic meetings.

The same page pairs that with milestone reviews rather than replacing them. Reviews should be applied at key milestones, early in the design phase to avoid one-way doors, and then before the go-live date. The review itself is described as a lightweight process, hours not days, a conversation and not an audit.

It also anticipates the failure mode a critic would reach for. After you go into production, the page says, your workload continues to evolve as you add features and change technology implementations. A workload’s architecture changes over time, and you must follow good hygiene practices to keep its architectural characteristics from degrading.

AWS also notes that reviews often help a team understand what it has actually implemented for the first time. That observation highlights the value of keeping current-state evidence available between reviews.

The Question the Framework Leaves Open

Continual review requires something to review continually. AWS’s recommendation is that the building team keeps updating their answers as the architecture evolves, which is sound advice that depends entirely on the team knowing the architecture has evolved.

That is the open question. The remedy the review process page offers for degradation between milestones is “good hygiene practices” and “a set of hygiene processes including a Well-Architected review.” The only mechanism it names there is running the review again.

AWS is not leaving you empty-handed, so be precise about where the gap sits. Resource discovery and architecture visualization options exist for AWS estates, ours among them, and they are good at enumerating the resources behind a workload. Enumeration is where the harder work starts rather than where it ends. A list of resources is not by itself a model of how the architecture fits together, or of the intent it was reviewed against, and that is what a review answer rests on.

Take a reliability question about failover topology. The honest input is whatever the person answering believes to be deployed. AWS supplies the questions, and they are good ones. What you supply, every time, is the current state of the system you are answering about.

Where Drift Sits in the Framework, and Where It Does Not

The framework does address drift, at length, and it is worth being exact about where, because the loose version of this argument is checkable and wrong. In the framework’s own vocabulary, set out under REL08-BP04, “Drift is defined as any change that causes an infrastructure resource to have a different state or configuration to what is expected.” Read that scoping carefully: an infrastructure resource, its state, its configuration.

Read the best practices for drift, and the guidance lands where the definition points. Configuration parity between a disaster recovery site and its primary, hardened baselines and immutable infrastructure, detection built into the pipeline that produced the resource. That coverage is real, detailed, and extended over successive revisions rather than left alone.

The level above has no equivalent. A resource can be perfectly compliant with its declared configuration while the system around it has changed. The change might be a new downstream dependency, a queue inserted between two services, or a failover path that now crosses an availability zone it did not cross at review time. Resource-level configuration checks alone do not establish whether the system still matches the intended architecture.

The design principles for operational excellence and reliability include observability, anticipating failure, testing recovery procedures, and managing change through automation. Applying them requires teams to combine current-state evidence with the intended design.

Where the Gap Bites Hardest

These two pillars carry the gap worse than the others, for different reasons.

Operational excellence is the pillar most about process, and its design principles lean on observability, on gaining a comprehensive understanding of workload behavior, performance, reliability, cost, and health. Telemetry does real structural work here, and a service map built from traces is a genuine picture of what called what. It is a picture bounded by its window and its coverage. It shows the paths exercised while it was watching, not every path that exists, and not the shape the system was meant to have.

Reliability carries it more sharply, because of that definition: performing its intended function correctly and consistently. Intent is the half of that definition which only exists in a design document, a review answer, or somebody’s memory. Testing recovery procedures is excellent advice that presumes you know what you are recovering and against which topology.

Both pillars assume an accurate current-state model as an input, and the framework treats supplying it as your job. The general name for what happens to that model when nobody maintains it is configuration drift, and it applies to the architecture as much as to the resources.

Three Ways Teams Answer the Question

The input row is where the practical choice sits, and teams fill it in three broad ways.

None of the three is dishonest work. The first two are what most teams have, and the third column is where we work.

Filling the Gap With a Derived Model

The alternative to remembering your architecture is deriving it from what is running, which is why we built Stacks. It is not a diagramming tool. It is our live model of your architecture as it actually runs, and it is the constraint set every recommendation, design, and answer gets checked against.

The design choice that makes it relevant to the reliability pillar is physical-first modeling. We wrote about this at length: traditional diagrams are built from a logical perspective, with VPCs as primary containers, subnets as their children, and availability zones tucked inside like footnotes. Starting there obscures what shares a physical fate, which components are truly redundant, and where security boundaries blur. We invert the hierarchy, so availability zones are the physical anchors and logical VPCs are replicated within them where needed.

To assess whether an application could survive the loss of an availability zone, locate the services in that zone and check where the failover resources sit. That supplies topology evidence for a reliability review. Confirming recovery still requires testing failover behavior, capacity, and dependencies.

Set that against how AWS defines reliability, performing its intended function, and the two halves line up. AWS defines the pillar around intent, and the gap is that intent usually has no representation you can check against. Our Context layer is where the objective and the settled judgment live alongside the observed constraint model. Holding both is what lets you see where execution has diverged from intent and keep the system aligned over time.

Reviews are conversational, and so is the follow-up. Archie, our conversational entry point, sits over the same model. A question like which services share an availability zone is answered by the model rather than by whoever happens to be in the room. That is a narrow claim on purpose: Archie answers from what we have modeled, and we do not offer it as a scoring engine for the pillars.

Coverage and product scope belong here, not in small print. Our analysis is bounded by the connected sources and context you provide; infrastructure integrations are read-only, so coverage is bounded by what you have connected. We work with architecture teams beyond AWS-only estates; we need to confirm available integrations and evidence coverage for your environment. And what we offer is a live model with drift identification, not a real-time compliance monitor for the six pillars, which is a different product and not one we claim to be.

Putting It Into Motion

This layers on top of AWS’s process rather than replacing it. Three things, in order.

Keep running the review, and take AWS’s cadence advice seriously. The model AWS recommends is continual self-review by the building team, with answers updated as the architecture evolves. Milestone reviews still matter for the one-way doors.

Derive the current-state input rather than recalling it. A review question that begins “how do you” almost always rests on a factual premise about what is deployed. Answer the premise from the estate, not from the design document.

Watch the two pillars where intent is load-bearing. If your answers on reliability or operational excellence would change on discovering an undocumented dependency, that is the pillar to instrument first.

If you are assessing tooling more broadly than AWS-specific practice, our guide to enterprise architecture tools covers the wider category.

Conclusion

The framework tells you what well-architected means. AWS is clear that the answer changes as your workload evolves, and clear that you should keep checking. What no framework and no scan hands you for free is a reconciled picture of the thing you are checking. That is why AWS can honestly report that a review is often the first time a team understands what it built.

That picture is the layer left to you. You can maintain it by hand, which works until the estate outgrows the person maintaining it, or you can derive it from what is running. Seeing the second option against a real AWS environment is what our platform is for, and a walkthrough is the fastest way to test it against your own estate.