Lesson 196 · AWS Learning Path

AWS 196: AWS Well-Architected Framework

Anil Jalela · Published Jan 7, 2026 · 7 min read

Why this lesson matters

Use the six pillars and review process to expose risk, make trade-offs, assign improvements, and revisit architecture rather than chase a perfect score.

What you will be able to do

By the end, you can:

• explain aws well-architected framework in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+---------------------------------+
|  Workload and business context  |
+---------------------------------+
                |
                v
+------------------------+
|  Six-pillar questions  |
+------------------------+
            |
            v
+------------------------------------+
|  Prioritized risk and improvement  |
+------------------------------------+
                  |
                  v
+------------------------------------------+
|  Milestone evidence and repeated review  |
+------------------------------------------+

The six pillars are decision lenses

Pillars interact. Reducing capacity can increase failure and latency; retaining every log forever increases cost and footprint; multi-Region improves some resilience while adding spend and complexity. Document trade-offs and business owners instead of maximizing each pillar independently.

Run an evidence-based review

1. Define workload, lifecycle stage, owners, business criticality, architecture diagram, data classification and objectives.
2. Choose the Framework plus only applicable lenses; a lens adds domain questions rather than replacing the core Framework.
3. Interview builders/operators/security/finance/business stakeholders. Reviews are collaborative and blameless, not audits of individuals.
4. Answer questions from current architecture and evidence. Record unknown as unknown - not “not applicable.”
5. Identify high/medium risks and improvement items with owner, priority, due date, cost and success measure.
6. Export/save review milestone before major architecture change, launch or incident follow-up.
7. Implement improvements in the normal delivery backlog, validate outcomes and create the next milestone.

The AWS Well-Architected Tool stores workloads, lens answers, risks, milestones and improvement plans. It does not automatically inspect every resource or certify compliance. Review answers become stale as traffic, services, teams and requirements change.

Write useful risks

A useful risk states condition, consequence and evidence: “The only NAT gateway is in AZ-a; private workloads in other AZs depend on cross-AZ routing, so an AZ-a failure removes outbound patch/API access; route-table inventory and game-day result attached.” The improvement then has an owner and measurable outcome.

Avoid service-list answers (“we use CloudWatch”) without retention, coverage, alarms, owner and response proof. Avoid marking a question complete because a service is enabled. Never hide risk to improve a dashboard score.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open AWS Well-Architected Tool, Workloads and Lenses; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws wellarchitected list-workloads --query 'WorkloadSummaries[].{Name:WorkloadName,Owner:Owner,Review:ReviewOwner,Updated:UpdatedAt}' --output table
aws wellarchitected list-lenses --lens-type AWS_OFFICIAL --query 'LensSummaries[].{Name:LensName,Status:LensStatus,Version:LensVersion}' --output table

Expected interpretation

A review records answers, notes, risks, milestones, and improvement items. It does not certify the workload or remove the need for measurement and engineering judgment.

Practical work

Review P05 across operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Record one high risk, one medium risk, owner, due date, evidence, and trade-off per pillar.

Diagnose this topic from its own evidence

• Review has no risks: inspect whether answers are generic, evidence absent, scope narrow or “not applicable” abused.
• Improvement plan never changes: connect items to backlog owners/dates and review in architecture/operations cadence.
• Milestones cannot explain change: create before/after milestones around launch, migration, incident and major design revision.
• One pillar improves while incident risk rises: re-evaluate cross-pillar trade-offs and business objectives.
• Tool says complete but runtime disagrees: runtime/configuration/test evidence overrides self-attestation; update the review.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Use the six pillars and review process to expose risk, make trade-offs, assign improvements, and revisit architecture rather than chase a perfect score.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Well-Architected Framework.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Well-Architected Framework.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid answering for the desired score, hiding risk, or applying a best practice without workload context.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

• Explain all six pillars using workload decisions rather than memorized definitions.
• Facilitate a scoped, blameless review with current architecture and stakeholder evidence.
• Write at least six condition/consequence/evidence risks and owned improvements.
• Analyze cross-pillar trade-offs and record accepted residual risk.
• Create review milestones and prove one improvement through measured before/after evidence.

Official sources

• AWS Well-Architected Framework
• AWS Well-Architected Tool
• Well-Architected Tool