AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 58“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Well-Architected Reviews and Architecture Decision Records

TechLearningPro now spans multi-account landing zones, private networking, operational databases, hardened S3 lakes, Glue/Athena governance, Redshift metrics serving, and migration

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Well-Architected Reviews and Architecture Decision Records

AWS Cloud & DevOps Engineering · Lesson 58 · Advanced Platforms and Networking

Lesson Overview

TechLearningPro now spans multi-account landing zones, private networking, operational databases, hardened S3 lakes, Glue/Athena governance, Redshift metrics serving, and migration waves. Without a ritual for review and a habit of Architecture Decision Records (ADRs), every lesson’s wisdom evaporates into Slack folklore. This lesson teaches how TechLearningPro runs AWS Well-Architected Framework reviews (pillars, lenses, workload definition, risk register, improvement plans) and how ADRs capture context, decision, and consequences so future engineers do not silently reverse Object Lock, WLM, or 7 Rs choices.

Lesson AWS Well-Architected Framework and Cost Basics introduced pillars early; here you operationalize reviews on real Module 5 workloads and bind them to ADRs, FinOps, and security findings. Tag documentation Project=tlp-lesson58. Reviews themselves are mostly people-time; any Tool measurements or lab resources still need budgets and cleanup.

Learning Objectives

Define a workload boundary suitable for a Well-Architected Review (WAR).
Restate the six pillars and how they apply to TechLearningPro platforms.
Use the Well-Architected Tool concepts to capture answers and milestones (verify current Tool UX).
Prioritize high risks versus improvements with owners and dates.
Explain lenses (serverless, SaaS, etc.) at a high level without inventing questions.
Write ADRs in a standard template used by TechLearningPro.
Link ADRs to PRs, runbooks, and WAR risks.
Run a lightweight review cadence (e.g., quarterly per critical workload).
Separate decision records from meeting notes and design docs.
Record superseding ADRs when decisions change.
Integrate Config/Security Hub findings into review evidence.
Integrate FinOps and cost pillar questions with lesson 47 habits.
Avoid rubber-stamp reviews that create no backlog.
Facilitate blameless discussion of trade-offs.
Produce a sample WAR + ADR pack for the analytics platform.
Map migration wave decisions into ADRs (lesson 57).
Prepare interview answers on WAR and ADR practice.
Measure review effectiveness by closed risks, not slide count.
Store ADRs in version control with CODEOWNERS.
Close Module 5 with a durable decision culture.

Prerequisites

Pillar familiarity from lesson 11; Module 5 technical context (48–57).
Ability to write Markdown ADRs in a repo.
Optional WAR Tool access in sandbox/organization.

Detailed Core Concepts

Workload

A workload is a set of components delivering business value—e.g., “TechLearningPro analytics Monday board” spanning S3 curated, Glue jobs, Athena WG, Redshift mart, QuickSight. Too broad → shallow answers; too narrow → missed shared-platform risks.

Pillars (operationalized)

Operational Excellence: runbooks, ADRs, deployments. Security: IAM, encryption, public access, detections. Reliability: Multi-AZ, backups, cutover rollback. Performance Efficiency: dist/sort, partitions, rightsizing. Cost Optimization: tags, pause labs, scan limits. Sustainability: utilize well, retire waste—confirm current pillar framing in AWS docs.

Well-Architected Tool

AWS WA Tool stores workloads, answers milestone questions, and tracks improvement plans. Use it as a system of record, not a substitute for engineering judgment. Export milestones before major releases.

Risk register

Each “high” finding becomes a ticket with owner, severity, due date, and ADR link if a decision is required. Reviews without tickets are theater.

ADR

An Architecture Decision Record is a short, immutable (except status) document: title, status (proposed/accepted/deprecated/superseded), context, decision, consequences. TechLearningPro stores ADRs under docs/adr/NNNN-title.md with sequential numbers. Supersede; do not silently edit history.

Cadence and roles

Platform guild facilitates; workload owners answer; security/FinOps attend for their pillars. Quarterly for tier-1; after major migrations; before public launch. Timebox to 90 minutes + follow-up tickets.

Relationship to PRRs

Production Readiness Reviews (Module 6 lesson 63) consume WAR risks and ADRs as inputs—do not duplicate questionnaires forever.

Architecture and Design Diagrams

mermaid
flowchart TB
  WL[Define workload]
  Tool[WA Tool milestone]
  Rev[Facilitated review]
  Risks[Risk register / tickets]
  ADR[ADRs in git]
  Improve[Improvements shipped]
  Remeasure[Next milestone]

  WL --> Tool --> Rev --> Risks
  Rev --> ADR
  Risks --> Improve --> Remeasure
  ADR --> Improve

mermaid
flowchart LR
  Context[Context]
  Decision[Decision]
  Conseq[Consequences]
  Context --> Decision --> Conseq

Technical Explanation

How TechLearningPro records decisions

Example ADR-1042: “Use Object Lock Governance mode for certificates.” Context: compliance need + ops override path. Decision: Governance with break-glass role. Consequences: training required; Compliance mode rejected for now. WAR Security questions cite ADR-1042 as evidence.

Facilitating without blame

Ask “what happens when this Glue job fails at 05:55?” not “who forgot alarms?” Evidence from CloudWatch, Config, and Cost Explorer beats opinion. Capture disagreements in ADR consequences (“we accept Athena scan risk until Parquet backlog completes”).

Milestone discipline

Milestone “Pre-exam-season 2026” freezes answers; later milestone shows improvement. Executives see trend lines of open highs, not a one-time PDF.

When not to ADR

Trivial renames, personal preferences with no architectural blast radius. When in doubt, ADR—cheap insurance. Pair with RFCs for large debates; ADR is the decision outcome.

Lenses

Serverless lens questions hit Lambda/API workloads; machine learning lenses exist for other estates. Pick lenses that match the workload—do not answer every lens every time.

Multi-account reviews

Shared platform workloads (TGW, Lake Formation central) need cross-account attendees. Workload definition includes account IDs and ownership.

Connecting Module 5

Organizations SCPs, PrivateLink, TGW, Aurora ops, S3 Object Lock, LF grants, Redshift WLM, migration 7 Rs—each spawns ADRs; WAR verifies the living system still matches those ADRs.

Practical Implementation or Design Walkthrough

Problem

Produce an ADR and review findings for the TechLearningPro analytics system (S3+Glue+Athena+Redshift).

Steps

Write workload definition one-pager; tag Project=tlp-lesson58.
Create or design WA Tool workload; answer a representative subset of questions honestly.
List top 10 risks with severity.
File tickets for top 5 highs with owners/dates.
Write ADR for one contested decision (e.g., Redshift vs Athena-only Monday board).
Link ADR in repo README index.
Schedule follow-up milestone date.
Budget note if any lab infra used; cleanup.
Deliver pack: workload def, risk table, ADR, ticket links.
Teach-back facilitation tips to a peer.

Enterprise Real-World Scenarios

Rubber-stamp WAR

All greens; outage next month from missing alarm. Fix: require evidence links; external facilitator quarterly.

ADR wiki rot

Confluence pages contradict git. Fix: git is source of truth; wiki mirrors with links only.

Silent supersession

Engineer disables Object Lock “for debugging,” never updates ADR. Fix: change control + Config + ADR status deprecated with successor.

FinOps ignored in WAR

Cost pillar skipped; Athena bill explodes. Fix: FinOps attendee mandatory for analytics workloads.

Migration wave without ADR

Nobody remembers why rehost won. Fix: lesson 57 exit criterion includes ADR numbers.

Best Practices

Define workloads narrowly enough to act.
Timebox reviews; always emit tickets.
Store ADRs in git with numbers.
Supersede, do not rewrite history.
Cite evidence (metrics, Config, costs).
Include FinOps and Security seats.
Milestone before major launches.
Link ADRs from WAR notes.
Track open high risks as KPIs.
Train facilitators.
Align with PRR later—reuse artifacts.
Review shared platforms explicitly.
Keep ADRs short (one to two pages).
Record accepted risk consciously.
Close Module 5 with an ADR index current.

Common Mistakes and Anti-Patterns

WAR as annual PDF theater.
ADRs that are 40-page design docs.
No owners on risks.
Editing accepted ADRs in place.
Skipping Cost pillar.
Inventing WA Tool question IDs.
Reviews without workload boundaries.
Decisions only in Slack.
Ignoring sustainability/utilization waste.
Celebrating review completion over risk closure.

Troubleshooting and Design Review

Symptom	Cause	Action
No tickets after WAR	Theater review	Mandate ticket output
Conflicting ADRs	No index/status	ADR governance; supersede
Repeat outages	Risks not closed	Executive risk burn-down
Tool abandoned	UX friction	Lightweight Markdown + Tool hybrid
Endless scope	Workload too broad	Split workloads
Blame culture	Poor facilitation	Blameless charter

Interview Questions and Answers

Q1: WAR purpose? A: Structured risk discovery across pillars with improvement plans.
Q2: ADR? A: Short record of a significant architecture decision and consequences.
Q3: Pillars? A: OE, Security, Reliability, Performance, Cost, Sustainability (confirm current).
Q4: Workload? A: Bounded set of components delivering business value.
Q5: Why git ADRs? A: Reviewable, versioned, linkable from PRs.
Q6: Supersede? A: New ADR replaces old; status updated—history preserved.
Q7: Lens? A: Specialized question set for technology domains.
Q8: Success metric? A: Closed risks and better outcomes, not slide decks.
Q9: Who attends? A: Owners + platform + security/FinOps as needed.
Q10: Relation to PRR? A: WAR/ADR evidence feeds readiness reviews.
Q11: Accepted risk? A: Conscious, documented risk with rationale and expiry.
Q12: Milestone? A: Point-in-time WAR answers for comparison.
Q13: Cost pillar link? A: FinOps tags, budgets, rightsizing evidence.
Q14: Facilitation tip? A: Ask failure-mode questions with evidence.
Q15: Module 5 close? A: Platforms without decision memory regress.

Hands-On Exercises

Exercise: ADR + review findings pack

Deliverable: workload definition, risk table (≥10), 5 tickets, 1 full ADR, WA Tool notes or Markdown questionnaire sample, cleanup if any.

Challenge ADR

Accept temporary Athena-only Monday board for 60 days with explicit Cost risk and Redshift target ADR supersession date.

Lab evidence checklist

Workload def; risks; ADR merged to git; ticket IDs; budget/cleanup if infra used.

Narrative: ADR stops a bad rollback

New hire nearly reopens public S3 for “simpler demos.” ADR-0911 + Config rule block the change; review cites near miss.

Continuity

Module 5 ends: advanced platforms and networking decisions are now reviewable. Next module begins production projects and interview prep—Linux Administration for Cloud Engineers—with ADRs and WAR habits carried forward.

Deep dive: ADR template (TechLearningPro)

text
# ADR-NNNN: Title
Date:
Status: Proposed | Accepted | Deprecated | Superseded by ADR-XXXX
Context:
Decision:
Consequences:
Evidence / links:

Deep dive: Mapping pillars to Module 5 controls

Security→LF/Object Lock/SG; Reliability→CRR/snapshots/cutover rollback; Performance→dist/sort/partitions; Cost→WG limits/pause Redshift; OE→runbooks/ADRs; Sustainability→retire dual-run waste.

Deep dive: Executive reporting

One page: open highs, burn-down, accepted risks, FinOps outliers—no 60-page appendix.

Extended enterprise scenario: acquisition integration WAR

Northline Learn workload reviewed in first 30 days; risks feed migration waves (lesson 57).

Extended enterprise scenario: disputed decision

Two guilds disagree on Transit Gateway vs peering mesh; RFC debate → ADR-1050 accepted with revisit date; WAR Reliability tracks blast radius.

Extended practice scenario 1 — 58 well architected reviews and architecture decision records

Confirm AWS Budgets alerts exist for the sandbox; tag every resource Project=tlp-lesson58. Do not proceed without a budget subscriber.

In a timed drill for Well-Architected reviews and ADRs at TechLearningPro, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: workload definition, risk table, ADR Markdown, ticket IDs, and destroy confirmation for any lab resources.

Discuss how WAR/ADRs bind lessons 48–57 (landing zones through migration), FinOps (47), incidents (40), and upcoming PRRs in Module 6. List two risks you would raise on the analytics workload, including owners and due dates.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating Well-Architected reviews and ADRs as a mystery.

Extended practice scenario 2 — 58 well architected reviews and architecture decision records

Document the lesson's primary architecture decision in a ten-line ADR: context, decision, status, consequences.

Extended practice scenario 3 — 58 well architected reviews and architecture decision records

Map identity paths: who can create/modify the resources in this lesson; which IAM roles are least privilege.

Extended practice scenario 4 — 58 well architected reviews and architecture decision records

Design observability: CloudWatch metrics/alarms or equivalent signals that prove the control works.

Extended practice scenario 5 — 58 well architected reviews and architecture decision records

Run or design a negative test: denied access, misconfiguration, or failed dependency—capture evidence.

Extended practice scenario 6 — 58 well architected reviews and architecture decision records

Estimate cost dimensions for this lesson's activities (migration tooling, dual-running environments, data transfer). Label figures illustrative; verify pricing pages with dates.

Extended practice scenario 7 — 58 well architected reviews and architecture decision records

Produce a cleanup checklist and execute destroy for any billable lab resources created for lesson 58.

Extended practice scenario 8 — 58 well architected reviews and architecture decision records

Cross-link prior course lessons that this design depends on; list two failure modes inherited from those layers.

Extended practice scenario 9 — 58 well architected reviews and architecture decision records

Security review: encryption at rest/in transit, public exposure checks, CloudTrail visibility for management events.

Extended practice scenario 10 — 58 well architected reviews and architecture decision records

Reliability review: cutover rollback, dual-run risk, how detection and recovery work.

Extended practice scenario 11 — 58 well architected reviews and architecture decision records

Performance review: bandwidth, replication lag, or cutover windows relevant to Well-Architected reviews and ADRs at TechLearningPro.

Extended practice scenario 12 — 58 well architected reviews and architecture decision records

Write a runbook section for on-call during migration cutover: symptoms, first three diagnostic steps, escalation, rollback.

Extended practice scenario 13 — 58 well architected reviews and architecture decision records

Config/compliance angle: which controls must be true before production cutover.

Extended practice scenario 14 — 58 well architected reviews and architecture decision records

Multi-account consideration: landing zone readiness from lessons 48–49 before migrating workloads.

Extended practice scenario 15 — 58 well architected reviews and architecture decision records

Interview drill: explain Well-Architected reviews and ADRs at TechLearningPro to a hiring manager in three minutes without inventing APIs.

Extended practice scenario 16 — 58 well architected reviews and architecture decision records

Pair review: partner stops any invented CLI flags, hardcoded secrets, or fake current prices.

Extended practice scenario 17 — 58 well architected reviews and architecture decision records

FinOps continuity from lesson 47: dual-running cost and when to decommission source.

Extended practice scenario 18 — 58 well architected reviews and architecture decision records

DR continuity from lesson 45: migration must not destroy recoverability mid-cutover.

Extended practice scenario 19 — 58 well architected reviews and architecture decision records

Produce evidence pack: diagrams, wave plans, test results, cleanup proof.

Extended practice scenario 20 — 58 well architected reviews and architecture decision records

Challenge constraint: tighter monthly budget—what do you sequence differently?

Extended practice scenario 21 — 58 well architected reviews and architecture decision records

Challenge constraint: stricter compliance—what evidence gates cutover?

Extended practice scenario 22 — 58 well architected reviews and architecture decision records

Challenge constraint: shorter maintenance window—what pre-staging changes?

Extended practice scenario 23 — 58 well architected reviews and architecture decision records

Teach-back: recite the Lesson Overview paragraph, then check against the text; flashcard gaps.

Extended practice scenario 24 — 58 well architected reviews and architecture decision records

Dress rehearsal: cutover tabletop under a timer with observer notes.

Extended practice scenario 25 — 58 well architected reviews and architecture decision records

Final synthesis note: one paragraph connecting Well-Architected reviews and ADRs at TechLearningPro to TechLearningPro production ownership.

Compliance evidence pack for auditors / platform leads

Budget configs, tagging proof (Project=tlp-lesson58), architecture diagram, ADR, negative-test evidence, encryption settings notes, CloudTrail/Config references where applicable, pricing-page retrieval dates for any dollar claims, cleanup confirmation.

Glossary drill

Review every bold term introduced in Detailed Core Concepts and Interview Q&A. Write one sentence definitions from memory; correct against the lesson. Unfamiliar AWS console navigation becomes a lab note, not a guess.

Budget and cleanup sworn statement

I verified budgets remain enabled with alert subscribers. I deleted or scheduled deletion for orphan lab resources from lesson 58 named ____. I labeled every savings or cost figure with pricing-page retrieval dates or marked it illustrative. Signed ________ date ________.

Interview story to memorize

Craft a 60-second story: TechLearningPro needed Well-Architected reviews and ADRs at TechLearningPro; you chose a design with explicit trade-offs; you proved it with tests; you governed cost with budgets and tags; you left an ADR so the next engineer does not reverse the decision blindly.

Self-assessment rubric

Area	Weight
Conceptual accuracy and service selection	20%
Working design/lab and reproducibility	25%
Security and least-privilege	20%
Reliability, observability, troubleshooting	20%
Documentation, ADR, cleanup	15%

Final synthesis before summary

Mastery of Well-Architected reviews and ADRs at TechLearningPro is not logo recognition—it is owning failure modes, cost meters, identity boundaries, and the written decision that keeps TechLearningPro coherent under change.

Extended facilitation script (print for guild leads)

Open with the workload one-pager and the business consequence of failure (exam week board wrong, certificates mutable, migration dual-run forever). Remind attendees that Well-Architected is a risk discovery ritual, not a compliance sticker. For each pillar, ask one failure-mode question tied to Module 5: Security—“Who can disable Object Lock Governance or widen Lake Formation grants?” Reliability—“What is the rollback clock for the next migration wave?” Performance—“What happens to Redshift WLM when ETL slips into the executive query window?” Cost—“Which Athena workgroup still lacks a bytes-scanned limit?” Operational Excellence—“Where is the ADR index, and is it greppable from the repo root?” Sustainability—“Which dual-run systems missed their decommission date?” Capture answers as risks with owners. End by scheduling the next milestone and merging any new ADRs the same week—reviews that do not change git or tickets did not happen.

Lesson Summary

Well-Architected Reviews and ADRs turn TechLearningPro’s Module 5 platforms into a governed system of memory: define workloads, assess pillars with evidence, file risks, and record decisions in git so Object Lock, Lake Formation, Redshift WLM, and migration Rs survive staff changes. Tag Project=tlp-lesson58; close risks, not ceremonies.

Module 5 complete—carry decision discipline into Module 6 production projects and interviews. Next: Linux Administration for Cloud Engineers.

Well-Architected Reviews and Architecture Decision Records

Well-Architected Reviews and Architecture Decision Records

Lesson Overview

Learning Objectives

Prerequisites

Detailed Core Concepts

Workload

Pillars (operationalized)

Well-Architected Tool

Risk register

ADR

Cadence and roles

Relationship to PRRs

Architecture and Design Diagrams

Technical Explanation

How TechLearningPro records decisions

Facilitating without blame

Milestone discipline

When not to ADR

Lenses

Multi-account reviews

Connecting Module 5

Practical Implementation or Design Walkthrough

Problem

Steps

Enterprise Real-World Scenarios

Rubber-stamp WAR

ADR wiki rot

Silent supersession

FinOps ignored in WAR

Migration wave without ADR

Best Practices

Common Mistakes and Anti-Patterns

Troubleshooting and Design Review

Interview Questions and Answers

Hands-On Exercises

Exercise: ADR + review findings pack

Challenge ADR

Lab evidence checklist

Narrative: ADR stops a bad rollback

Continuity

Deep dive: ADR template (TechLearningPro)

Deep dive: Mapping pillars to Module 5 controls

Deep dive: Executive reporting

Extended enterprise scenario: acquisition integration WAR

Extended enterprise scenario: disputed decision

Extended practice scenario 1 — 58 well architected reviews and architecture decision records

Extended practice scenario 2 — 58 well architected reviews and architecture decision records

Extended practice scenario 3 — 58 well architected reviews and architecture decision records

Extended practice scenario 4 — 58 well architected reviews and architecture decision records

Extended practice scenario 5 — 58 well architected reviews and architecture decision records

Extended practice scenario 6 — 58 well architected reviews and architecture decision records

Extended practice scenario 7 — 58 well architected reviews and architecture decision records

Extended practice scenario 8 — 58 well architected reviews and architecture decision records

Extended practice scenario 9 — 58 well architected reviews and architecture decision records

Extended practice scenario 10 — 58 well architected reviews and architecture decision records

Extended practice scenario 11 — 58 well architected reviews and architecture decision records

Extended practice scenario 12 — 58 well architected reviews and architecture decision records

Extended practice scenario 13 — 58 well architected reviews and architecture decision records

Extended practice scenario 14 — 58 well architected reviews and architecture decision records

Extended practice scenario 15 — 58 well architected reviews and architecture decision records

Extended practice scenario 16 — 58 well architected reviews and architecture decision records

Extended practice scenario 17 — 58 well architected reviews and architecture decision records

Extended practice scenario 18 — 58 well architected reviews and architecture decision records

Extended practice scenario 19 — 58 well architected reviews and architecture decision records

Extended practice scenario 20 — 58 well architected reviews and architecture decision records

Extended practice scenario 21 — 58 well architected reviews and architecture decision records

Extended practice scenario 22 — 58 well architected reviews and architecture decision records

Extended practice scenario 23 — 58 well architected reviews and architecture decision records

Extended practice scenario 24 — 58 well architected reviews and architecture decision records

Extended practice scenario 25 — 58 well architected reviews and architecture decision records

Compliance evidence pack for auditors / platform leads

Glossary drill

Budget and cleanup sworn statement

Interview story to memorize

Self-assessment rubric

Final synthesis before summary

Extended facilitation script (print for guild leads)

Lesson Summary

Further Reading