Applies toAWS Well-Architected Tool, lenses (e.g. Serverless, SaaS, Generative AI, custom lenses), Trusted Advisor, Security Hub, Cost Explorer, Resilience Hub
When to run one
- Annually for Tier 1 and 2 workloads.
- Before major changes: migration, re-architecture, big traffic events.
- After a significant incident, to look beyond the immediate root cause.
1. Scope and set up
aws wellarchitected create-workload --workload-name "orders-platform" \
--description "Order capture and fulfilment APIs" --environment PRODUCTION \
--aws-regions eu-west-1 eu-central-1 --review-owner "team-orders@example.com" \
--lenses wellarchitected serverless --pillar-priorities reliability security costOptimization operationalExcellence performance sustainability
Define: business-critical flows, availability/RTO/RPO targets, accounts and regions in scope, and the attendees (owner, engineers on call, security, platform).
2. Gather evidence before the session
| Evidence | Source |
|---|---|
| Current architecture diagram | Owner; verify against resources |
| Resource inventory | AWS Config / Resource Explorer |
| Security findings | Security Hub, GuardDuty, IAM Access Analyzer |
| Cost and trends | Cost Explorer, Compute Optimizer |
| Resilience assessment | Resilience Hub (RTO/RPO estimate against targets) |
| Incidents and postmortems (12 months) | ITSM / incident tool |
| Trusted Advisor checks | Trusted Advisor (WA Tool can show related checks per question) |
3. Run the review
Six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability. Tips:
- Answer with evidence, not intentions ("we plan to" is a "no").
- Mark questions not applicable with a reason.
- Use lenses that match the workload (Serverless, SaaS, Generative AI…).
- Time-box: 2–3 hours per session; split pillars across sessions if needed.
High-value questions that often expose risks:
| Pillar | Question |
|---|---|
| Reliability | What happens when one AZ fails? When was a restore last tested? |
| Security | Who has standing admin access? Any long-lived access keys? |
| Operations | Is every change deployed by pipeline? Runbooks for top alerts? |
| Performance | When was it last load tested at expected peak? |
| Cost | What's idle or oversized? Commitments aligned with usage? |
| Sustainability | Are non-prod environments scheduled off? Is the right instance generation used? |
4. Improvement plan
The WA Tool marks high and medium risk issues (HRIs/MRIs) and links improvement guidance. For each:
- Create a backlog item with owner and target date.
- Accept risks explicitly where the business agrees, recording the reason.
- Save a milestone after the review and after major fixes to show progress:
aws wellarchitected create-milestone --workload-id <id> --milestone-name "2026-10 baseline review"
5. Follow up
- 30/60/90-day check of HRI count.
- Share themes across workloads with the platform team; repeated issues (e.g. no restore tests) become platform features or standards.
- Custom lenses can capture your organisation's own standards and reuse them in every review.
Tip
The engineers who carry the pager for the workload are the most valuable attendees. Their answers to "what worries you at 3 AM?" usually match the highest-risk findings.
Checklist
- Workload, targets and attendees defined
- Workload created in the WA Tool with relevant lenses
- Evidence gathered in advance
- Pillars answered with evidence
- HRIs/MRIs in backlog with owners; accepted risks recorded
- Milestones saved; follow-up scheduled