Lesson 332 · AWS Learning Path

AWS 332: Architecture review and stakeholder presentation

Anil Jalela · Published May 23, 2026 · 7 min read

Why this lesson matters

An architecture review is a structured, blame-free conversation that improves customer outcomes. It is neither a presentation ceremony nor an audit designed to catch a team. The architect must expose evidence, uncertainty, trade-offs, risks, and decisions in language appropriate to executives, product, security, data, operations, finance, and delivery stakeholders.

Approval is meaningful only when the approver understands scope, consequences, unresolved risk, cost, and acceptance evidence. Silence, meeting attendance, or a polished diagram is not approval.

Learning outcomes

By the end, you can:

• define review scope, decision rights, participants, and readiness;
• prepare evidence rather than unsupported claims;
• conduct a consistent six-pillar review without blame;
• tailor one architecture to several stakeholder concerns;
• present decisions, alternatives, trade-offs, cost, and risk clearly;
• facilitate disagreement and record decisions or dissent;
• convert findings into prioritized owned improvements;
• preserve minutes, milestones, acceptance, and follow-up evidence.

1. Choose review purpose and timing

Reviews should occur early enough to change one-way-door decisions, before go-live, after major changes/incidents, and periodically during operation. The effort should match workload criticality, spend, change rate, and risk.

Define exactly what is in/out of scope and which decisions are requested. A review without a decision or improvement purpose becomes a status meeting.

2. Stakeholders and decision rights

Invite workload/business owner, architect, developers, operations/SRE, security, data/privacy, network/platform, finance/FinOps, product, support, delivery, and dependency owners according to scope. Include people who run the system, not only managers.

Record:

• facilitator and note owner;
• accountable decision owner;
• subject experts and control owners;
• risk/exception authority;
• business acceptance owner;
• action owners and due dates;
• attendees who must explicitly approve versus be informed.

A RACI can help, but specify exact decisions. Security cannot approve budget; finance cannot accept data risk; the architect should not silently accept business downtime.

3. Readiness package

Send a concise package before the review:

1. business outcome and critical journeys;
2. scope, assumptions, constraints, and open questions;
3. current/target diagrams with version/date;
4. requirements and acceptance criteria;
5. ADRs and rejected alternatives;
6. demand, quota, performance, and cost model;
7. threat model and data classification;
8. failure modes, availability, RTO/RPO, backup/restore and DR evidence;
9. observability, operations, deployment, rollback, and support plan;
10. risk register and requested decisions.

Label facts, assumptions, and unknowns. Cite source/date for metrics. Remove secrets, customer data, account IDs, and unnecessary internal addresses.

4. Well-Architected review behavior

AWS describes the review as a lightweight, consistent, blame-free conversation. The workload includes people, process, runbooks, and technology. Use the six pillars to find neglected risks and trade-offs, not to generate a ceremonial score.

The current WAFR flow is Prepare, Review, Improve. Define workload boundaries and stakeholders; discuss questions using evidence; then create actionable improvements. Save milestones at meaningful review points and after improvements so change can be tracked.

Do not answer optimistically to make a dashboard green. If evidence is missing, record the unknown and owner. Findings are risk signals to interpret in business context, not automatic instructions to implement every best practice.

5. Review agenda

A 90-minute example:

00-05 purpose, scope, decision rights
05-15 business outcome, users, requirements
15-30 architecture and critical flows
30-45 trust, data, and security
45-60 failure, recovery, and operations
60-70 performance, quota, cost, sustainability
70-80 options, trade-offs, and top risks
80-88 decisions, actions, owners, dates
88-90 playback and explicit acceptance path

Adjust time to risk. Park deep implementation issues with an owner instead of allowing one topic to consume the meeting. Do not park unresolved blockers needed for the requested decision.

6. Evidence-led questioning

Ask questions that expose behavior:

• Which user journey defines success, and where is it measured?
• What happens when this dependency times out after committing work?
• Which identity authorizes this cross-account data access?
• How was the restore time measured?
• What limits scale before the advertised demand?
• Which data leaves the jurisdiction through logs or backup?
• Who receives this alarm at 03:00 and what can they do?
• What changes after target writes make rollback difficult?
• Which assumption would reverse the selected architecture?
• Which cost grows nonlinearly during failure or peak load?

Separate observations from interpretations. “The dashboard shows 40% average CPU” is evidence; “the instance is right-sized” needs memory, IO, peaks, latency, and headroom analysis.

7. Present for different audiences

Executive view

Lead with outcome, decision requested, options, selected trade-off, investment range, top risks, delivery stage, and owner. Explain business impact rather than service configuration.

Product and business

Show user journeys, degraded modes, data use, delivery stages, dependencies, acceptance, and operational impact.

Security, privacy, and compliance

Show actors, trust, authorization, data classes, residency, encryption/key ownership, audit, threats, controls, exceptions, response, and evidence.

Operations and delivery

Show failure domains, SLOs, telemetry, alarm action, runbooks, deployment, capacity, quotas, backup/restore, incident authority, rollback, and support.

Finance

Show assumptions, normal/peak/failure cost, data transfer, commitments, allocation, unit cost, migration/coexistence, uncertainty, and optimization triggers.

Use one consistent architecture truth but different views. Do not alter facts to satisfy an audience.

8. Defend a trade-off

Use this structure:

Requirement and constraint
Options considered
Evidence and uncertainty
Selected option and why
Disadvantages introduced
Compensating controls
Cost and operating ownership
Validation and revisit trigger

State disadvantages before reviewers discover them. “We selected warm standby to meet the one-hour RTO; it adds continuous secondary cost and failover operations. Quarterly recovery tests and replication-lag alarms control the risk.”

9. Handle challenge and disagreement

Listen, restate the concern, identify requirement/evidence, answer within your confidence, and record unknowns. Do not bluff. If a challenge reveals a violated constraint, pause the decision. If it represents a preference, compare consequences transparently.

Use a decision owner to resolve value conflicts. Record dissent, not just the majority view. Psychological safety improves risk discovery; critique architecture and evidence, not competence.

Five useful challenge categories are hidden dependency, security bypass, quota/scale, data/recovery, and operating/cost ownership.

10. Findings and prioritization

Every finding should state condition, evidence, affected outcome, scenario, likelihood/impact, proposed treatment, owner, date, acceptance test, and status. Distinguish:

• launch blocker;
• high/medium risk improvement;
• assumption/unknown requiring research;
• accepted risk with authority and expiry;
• decision required;
• documentation correction.

Prioritize by customer/business impact and risk, then dependencies, effort, and reversibility. A long list with no capacity is not an improvement plan. Integrate work into team backlog and save review milestones as evidence evolves.

11. Minutes and approval

Minutes capture date, scope, participants, evidence versions, facts, decisions, objections, risks, actions, owners/dates, unanswered questions, acceptance conditions, and next review. Send playback promptly.

Use explicit statuses: approved, approved with conditions, changes required, decision deferred, or rejected. State who approved what scope. Track conditions to closure; conditional approval is not unconditional launch authorization.

12. Read-only Well-Architected evidence

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws wellarchitected list-workloads --output table
aws wellarchitected list-milestones \
  --workload-id replace-with-approved-workload-id \
  --output table
aws service-quotas list-requested-service-quota-change-history --output table

Do not create or change a workload during this T0 lesson. Tool state is supporting evidence, not proof that runbooks, restore, or business acceptance work.

13. Guided review workshop

Use one prior architecture and produce:

1. review charter and requested decisions;
2. scope and workload-boundary statement;
3. stakeholder/decision-rights map;
4. readiness checklist and evidence index;
5. one-page executive view;
6. technical appendix;
7. six-pillar question map;
8. top-ten evidence-led questions;
9. two defended trade-offs;
10. five challenge cards with responses;
11. 20-minute presentation recording or facilitator notes;
12. fact/assumption/unknown log;
13. finding/risk register;
14. prioritized improvement plan;
15. decision and dissent log;
16. meeting minutes and explicit approval status;
17. corrected diagrams/ADRs;
18. follow-up milestone and closure evidence plan.

14. Failure patterns

Avoid surprise reviews without pre-read, unbounded scope, architecture-by-slide animation, service acronyms without outcomes, unsupported “highly available” claims, hiding unfavorable cost, treating findings as blame, allowing hierarchy to silence operators, confusing attendance with approval, and never closing actions.

Cost and cleanup

This T0 lesson creates no resources. Review work has people cost; focus effort by workload importance and decision consequence. Delete sanitized temporary exports when no longer needed and retain approved artifacts according to governance.

Knowledge check

1. Is a WAFR an audit? No; it is a blame-free review conversation that drives improvement.
2. What does silence mean? Nothing; obtain explicit approval or record no decision.
3. Why tailor views? Stakeholders decide different aspects using different detail.
4. What makes a finding actionable? Evidence, impact, treatment, owner, date, and acceptance.
5. What follows review? Prioritized implementation, milestone tracking, and evidence-based closure.

Lesson acceptance

Submit all 18 artifacts. The review must be scoped, evidence-led, blame-free, and decision-oriented; stakeholder concerns and dissent must be visible; findings need owners and acceptance; and approval conditions must be tracked through corrected artifacts and milestones.

Official sources

• AWS Well-Architected review process
• Well-Architected Framework Review phases
• Workload and review scope
• Implement and track improvements
• SAP-C02 exam guide