The Well-Architected Mindset

Use the six pillars of the Well-Architected Framework as a running checklist, run periodic reviews, and remember that every design is a trade-off you should make on purpose.

The AWS Well-Architected Framework is not a certification hoop — it is a shared vocabulary for the questions good engineers ask anyway. Internalise the six pillars and you have a design review you can run in your head.

The six pillars

Operational Excellence — can you run, monitor and improve this? Automate, and treat operations as code.
Security — least privilege, encryption everywhere, traceability.
Reliability — recover from failure automatically; test your recovery.
Performance Efficiency — use the right resource for the job and let it evolve.
Cost Optimization — pay only for what delivers value.
Sustainability — minimise the environmental footprint of what you run.

It is trade-offs, not a scorecard

The pillars pull against each other — more reliability often costs more, tighter security can add latency. The point is not a perfect score; it is making each trade-off consciously, tied to a real business requirement, instead of by accident.

Make it a habit

Run a Well-Architected Review (the tool is free in the Console) at real milestones — before a big launch, after an incident, each quarter. It surfaces the risks you stopped seeing because you look at the system every day.

Example

# Start a Well-Architected review against the standard lens
aws wellarchitected create-workload \
  --workload-name acme-checkout \
  --description "Checkout service, prod" \
  --environment PRODUCTION \
  --lenses wellarchitected \
  --aws-regions us-east-1 \
  --review-owner [email protected]

# List the pillars/questions so the team can walk them together
aws wellarchitected list-answers \
  --workload-id 893d8e3f... \
  --lens-alias wellarchitected \
  --query 'AnswerSummaries[].[PillarId,QuestionTitle]' --output table

When to use it

An engineering team runs a quarterly Well-Architected review of their platform and converts each HIGH-risk finding into a tracked engineering ticket.
Before launching a new product, an architect uses the Well-Architected Tool to walk through all six pillars and document design decisions and trade-offs.
A compliance team uses the AWS Well-Architected custom lens feature to add industry-specific questions (e.g., PCI-DSS) on top of the default framework.

More examples

Create and Review a Workload

Creates a workload in the Well-Architected Tool with multiple lenses so both general and serverless best practices are evaluated.

aws wellarchitected create-workload \
  --workload-name "payments-service" \
  --description "Core payment processing microservice" \
  --environment PRODUCTION \
  --aws-regions us-east-1 eu-west-1 \
  --lenses wellarchitected serverless \
  --review-owner [email protected]

List Risk Counts for a Workload

Shows the workload's risk counts by severity across all reviewed pillars, giving a single-number health score.

aws wellarchitected get-workload \
  --workload-id abc123def456 \
  --query 'Workload.{Name:WorkloadName,High:RiskCounts.HIGH,Medium:RiskCounts.MEDIUM,None:RiskCounts.NONE}' \
  --output table

Export Milestone Report as JSON

Creates a named milestone to snapshot the current review state, then exports the lens definition for offline archiving.

WORKLOAD_ID=abc123def456

# Create a milestone snapshot
aws wellarchitected create-milestone \
  --workload-id $WORKLOAD_ID \
  --milestone-name "Q1-2024-Review"

# Export the workload to JSON for archiving
aws wellarchitected export-lens \
  --lens-alias wellarchitected \
  --output text > wa-lens-export.json

Discussion

Be the first to comment on this lesson.