Applying the Well-Architected Framework: A Worked Example
Walking through a real architecture review against all six Well-Architected pillars, showing exactly what kind of gaps a real review actually surfaces.
Want a visual for this topic?
Generate a diagram tailored to Applying the Well-Architected Framework: A Worked Example — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Apply the six Well-Architected pillars to a concrete, specific architecture rather than in the abstract
- •Identify realistic gaps a review would surface in a plausible, imperfect real-world architecture
- •Practice prioritizing which surfaced gaps matter most and why
What is it?
This is a worked example applying the AWS Well-Architected Framework's six pillars (covered conceptually in the Cloud Fundamentals category) to a specific, concrete sample architecture, showing exactly what a real review process surfaces and how to prioritize the findings — turning the abstract framework into a concrete, practiced skill.
Why it exists
Knowing the six pillars' names and definitions is different from actually being able to apply them critically to a real architecture and identify genuine gaps — this worked example exists to close that gap by walking through the actual review process against a specific, plausible (and deliberately imperfect) architecture, the way you'd genuinely need to in a real job or interview.
Problem it solves
It solves the 'I can recite the six pillars but can't apply them' problem — many learners can list Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability, but freeze when asked to actually find and prioritize real gaps in a specific architecture, which is the practical skill both interviews and real Well-Architected Reviews actually test.
Intuition
Memorizing the six pillars is like memorizing a building inspector's checklist categories. Actually being able to walk through a specific building and identify genuine, specific problems in each category is a meaningfully different and more valuable skill — this worked example is the guided practice that builds that second skill.
Analogy
A medical student who has memorized every symptom category versus one who can actually examine a specific patient and identify which symptoms are present and how serious each one is — the framework knowledge is necessary but the applied diagnostic skill is what actually matters in practice.
Technical explanation
Reviewing against Operational Excellence: is infrastructure defined as code (CloudFormation/CDK), or was it clicked together manually with no reproducible record? Security: are IAM roles least-privilege, is data encrypted at rest and in transit, are Security Groups scoped tightly? Reliability: is the database Multi-AZ, are backups configured and tested, is there a real DR strategy for a whole-Region event? Performance Efficiency: is the database/instance type actually matched to observed load (via Compute Optimizer data), is caching used where it would meaningfully help? Cost Optimization: are Savings Plans/Reserved capacity purchased for confirmed steady-state usage, are unused resources being cleaned up? Sustainability: is compute utilization reasonably efficient, or is capacity significantly over-provisioned relative to actual need? Each pillar surfaces genuinely different findings because they're asking genuinely different questions of the same underlying architecture.
Architecture
The sample architecture under review: the EC2-based scalable web application from the earlier end-to-end example, but as it might realistically exist mid-way through a fast-moving startup's growth — functional and serving real traffic, but with several genuine gaps accumulated from moving quickly without yet circling back for a deliberate review.
Workflow
- Take a specific, real (or realistic) architecture rather than reviewing in the abstract. 2) Go through each of the six pillars' key questions systematically against that specific architecture, resisting the urge to skip pillars that feel less interesting or less familiar. 3) Document each concrete gap found, tied to a specific pillar. 4) Prioritize findings — not every gap is equally urgent; a missing backup on a production database is a very different priority than a minor cost optimization opportunity. 5) Propose specific, concrete fixes for the highest-priority findings, not just a vague 'improve security' recommendation.
Example
Reviewing the sample architecture surfaces: under Reliability, the RDS instance has automated backups configured but retention is set to only 1 day (far below what any real recovery scenario would need) and Multi-AZ was never enabled despite this being a production database — a high-priority finding given the direct availability and data-loss risk. Under Security, a Security Group still has an inbound SSH rule open to 0.0.0.0/0 left over from initial setup — also high priority given the direct exposure. Under Cost Optimization, six months of stable EC2 usage has never been covered by a Savings Plan — a real but lower-urgency finding (it's a cost inefficiency, not a risk) appropriately prioritized below the security and reliability gaps.
Real-world usage
This is exactly the process AWS Solutions Architects and internal platform/security teams run during actual Well-Architected Reviews using the AWS Well-Architected Tool, and is a common style of system-design interview exercise — being handed a specific architecture and asked to find and prioritize its gaps, rather than being asked to design one from a blank page.
Trade-offs
Spending study time working through concrete review examples like this one, versus purely memorizing the six pillars' definitions abstractly, is a real tradeoff in study time allocation — but the concrete, applied practice is what actually transfers to both real interviews and real job performance, making it generally the better investment of study time once the pillar definitions themselves are reasonably familiar.
Visual explanation
Picture the end-to-end scalable web app architecture from the earlier topic, but with several deliberately introduced gaps: no automated backups configured on the RDS instance, an overly permissive security group rule left over from initial development, no CloudWatch alarms configured at all, and Reserved capacity never purchased despite six months of stable, predictable traffic. Walking through each of the six pillars against this specific architecture surfaces each of these concrete gaps, one pillar at a time, rather than as a vague general impression.
Advantages
- —
Builds the actual applied review skill, not just abstract framework recall
- —
Practicing prioritization (not every finding is equally urgent) is a genuinely important, often under-practiced part of the skill
- —
Directly transferable to real on-the-job architecture reviews, not just interview performance
- —
Reinforces the six pillars far more effectively than passive memorization, since each is tied to a concrete, specific finding
Disadvantages
- —
Requires already having reasonably solid grounding in the individual services/topics each pillar's questions touch on
- —
A single worked example can't cover every possible type of gap a real review might surface — it's a starting pattern to practice with, not an exhaustive checklist
- —
Without practicing against multiple different sample architectures, the specific findings from one example can be over-memorized rather than the underlying reviewing skill actually being internalized
Common mistakes
- —
Only memorizing the six pillars' names and one-line definitions without ever practicing applying them to a specific, concrete architecture
- —
Treating every finding from a review as equally urgent, without prioritizing based on actual risk/impact (a missing backup on a production database deserves more urgency than a minor cost optimization)
- —
Reviewing only the pillars one feels most comfortable with (often Cost Optimization or Performance) while skipping less familiar ones (often Security or Operational Excellence), missing genuine gaps in those skipped areas
- —
Proposing vague recommendations ('improve security') instead of specific, concrete fixes tied to the actual finding ('restrict the SSH security group rule to a specific IP range instead of 0.0.0.0/0')
🎤 Interview questions
Given this architecture [reference the end-to-end scalable web app example], walk through what you'd check under the Reliability pillar specifically. (Listen for: Multi-AZ configuration, backup configuration and retention, whether a DR strategy exists for a whole-Region event, whether failover has actually been tested.)
You find two issues during a review: an open SSH port and an unpurchased Savings Plan for six months of stable usage. Which do you prioritize, and why? (Listen for: the security exposure (open SSH) is prioritized higher — it's a direct risk, versus the cost optimization opportunity, which is real but not urgent/risky in the same way.)
How would you check whether an architecture is well-optimized under the Performance Efficiency pillar? (Listen for: comparing actual observed resource utilization (e.g. via Compute Optimizer) against provisioned capacity, checking whether caching is used where it would meaningfully help, confirming instance/database types actually match the workload's real characteristics.)
Why is it important to review ALL six pillars systematically, rather than just the ones you're most comfortable with? (Listen for: skipping pillars you're less familiar with (often Security or Operational Excellence) means genuinely missing real gaps in exactly those areas — the discomfort is itself a signal of where a blind spot might be.)