# AWS Well-Architected Review: [Workload name]

> Review workbook for one workload running on Amazon Web Services, organised on the six pillars of the AWS Well-Architected Framework (operational excellence, security, reliability, performance efficiency, cost optimization and sustainability) and on the lenses of the AWS Well-Architected Tool Lens Catalog (16 official lenses as listed in October 2026). For each pillar it records the design principles, the best practice areas with their AWS question identifiers (OPS 1 to OPS 11, SEC 1 to SEC 11, REL 1 to REL 13, PERF 1 to PERF 5, COST 1 to COST 11, SUS 1 to SUS 6), original review questions, current state, evidence and a rating. It ends with a risk register (high and medium risk), an improvement plan, a Well-Architected Tool milestone record and a re-review plan. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use this workbook when the workload runs mainly on AWS and the team will record the review in the AWS Well-Architected Tool. For a provider-neutral or multi-cloud review use the Cloud architecture review (`architecture/cloud-architecture-review`); when this workload is the AWS component of such a review, run this workbook for the component and link its findings register from the cloud review instead of repeating findings. For a workload whose behaviour depends on a foundation model, run the Generative AI Well-Architected review (`architecture/genai-well-architected-review`) as well, and do not repeat general findings there.
- The review questions in sections 4 to 9 are original to this collection. They point to AWS question identifiers so the team can open the matching question and best practices in the WA Tool. Answer in the tool too; this document holds the reasoning, the evidence and the decisions that the tool does not capture well.
- Fill sections 1 to 3 with the workload team before the session. A review without agreed business targets becomes a generic checklist.
- Rate on evidence, not intention. "We plan to" means "not in place".
- Every High risk needs an action in section 12 with an owner and a date, or a signed acceptance in section 14.
- Save a WA Tool milestone when the first pass is complete and after each batch of improvements (section 13).
-->

## Document control

<!-- Guidance: Identify the workload, the AWS accounts and Regions, the framework and lens versions used and the people who took part. Each review cycle is a new version of this document. -->

| Field | Value |
|---|---|
| Document ID | [AWR-PAYMENTS-2026-01] |
| Workload | [Payments API] |
| WA Tool workload name and ARN | [payments-api-prod], [arn:aws:wellarchitected:region:account:workload/id] |
| AWS accounts in scope | [111111111111 (prod), 222222222222 (shared services)] |
| AWS Regions in scope | [eu-west-1 primary, eu-central-1 recovery] |
| Environment | [Production / Pre-production] |
| Review type | [Initial / Periodic / Pre-launch / After major incident / Lens deep dive] |
| Framework version in WA Tool | [Version shown on the workload's lens page, YYYY-MM-DD] |
| Lenses applied | [AWS Well-Architected Framework, Serverless Applications, Financial Services Industry] |
| Review date | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner (workload owner) | [@workload-owner] |
| Lead reviewer | [@lead-reviewer] |
| Approvers/reviewers | [@engineering-manager], [@security-lead], [@finops-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Next review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Workload owner | [@name] | [Accepted plan / Changes requested] | YYYY-MM-DD |
| Lead reviewer (solution architect) | [@name] | [Decision] | YYYY-MM-DD |
| Security representative | [@name] | [Decision] | YYYY-MM-DD |
| Engineering manager | [@name] | [Decision] | YYYY-MM-DD |
| FinOps representative | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record each review cycle, the WA Tool milestone it corresponds to and the movement in risk counts. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Pre-review questionnaire filled by the workload team |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Ratings after review session; 5 High, 11 Medium; milestone MS-001 saved |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Improvement plan approved |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Re-review after quarter; 1 High, 6 Medium; milestone MS-002 saved |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Review scope and method](#1-review-scope-and-method)
2. [Workload definition](#2-workload-definition)
3. [Framework, lenses and tooling](#3-framework-lenses-and-tooling)
4. [Operational excellence](#4-operational-excellence)
5. [Security](#5-security)
6. [Reliability](#6-reliability)
7. [Performance efficiency](#7-performance-efficiency)
8. [Cost optimization](#8-cost-optimization)
9. [Sustainability](#9-sustainability)
10. [Lens review](#10-lens-review)
11. [Risk register](#11-risk-register)
12. [Improvement plan](#12-improvement-plan)
13. [Milestones and re-review](#13-milestones-and-re-review)
14. [Risk acceptance and sign-off](#14-risk-acceptance-and-sign-off)
15. [Glossary and references](#15-glossary-and-references)

## 1. Review scope and method

<!-- Guidance: State what was reviewed, how, with whom and what was excluded, so a reader can judge how much weight to give the findings. Pitfall: reviewing a diagram instead of the running system. -->

### 1.1 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Payments API, its Amazon Aurora cluster, Amazon SQS queues, AWS Lambda workers and CI/CD pipeline in the production account | Organisation-wide landing zone controls (reviewed by the platform team against the Landing zone design, `architecture/landing-zone-design`) |
| *Example:* Pre-production account, only where it affects release safety | Corporate identity provider and workforce SSO configuration |
| [Item] | [Item] |

### 1.2 Method

1. The workload team completes sections 2 and 3 and a first pass of the questions in sections 4 to 9, with links to evidence.
2. The lead reviewer runs a session of [3 to 4 hours] with the workload owner, an engineer who operates the system, a security representative and a FinOps representative.
3. Each question is answered in the WA Tool and in this document. The document records the reasoning and evidence; the tool records the selected best practices and computes the risk.
4. Findings rated High or Medium go to the risk register (section 11) and the improvement plan (section 12).
5. The lead reviewer saves a WA Tool milestone and records it in section 13.

```mermaid
flowchart LR
  A[Define workload and targets] --> B[Select lenses and lock versions]
  B --> C[Team pre-fill with evidence]
  C --> D[Review session]
  D --> E[Rate questions: High, Medium, None, N/A]
  E --> F[Risk register and improvement plan]
  F --> G[Save milestone MS-NNN]
  G --> H[Implement actions]
  H --> I[Re-review and new milestone]
  I --> E
```

### 1.3 Rating scale

| Rating | Meaning in this workbook | WA Tool equivalent | Expected response |
|---|---|---|---|
| High risk | Gap that can plausibly cause serious customer, financial, security or compliance impact within 12 months | High risk issue (HRI) | Action this quarter, or signed acceptance |
| Medium risk | Gap that raises impact or effort but is unlikely to cause a severe event alone | Medium risk issue (MRI) | Action within two quarters |
| None | Practice in place with evidence | No risk identified | No action |
| Not applicable | Question does not apply, with a stated reason | Question marked not applicable | Reason recorded |

### 1.4 Identifiers

Review questions use `AWR-[pillar]-NN` (OPS, SEC, REL, PERF, COST, SUS) and lens questions use `AWR-LNS-NN`. The column "AWS ref" gives the AWS question identifier, such as SEC 2, so the team can find the matching question in the tool. Findings use `FND-NNN`, actions `ACT-NNN`, risk acceptances `RA-NNN` and milestones `MS-NNN`.

## 2. Workload definition

<!-- Guidance: Describe what the workload does, for whom, how critical it is and the numbers that define good enough. The WA Tool asks for a workload definition too; keep the two consistent. Pitfall: no stated recovery objectives, which makes every reliability answer arguable. -->

### 2.1 Business context

| Item | Value |
|---|---|
| Purpose | *Example:* Authorises and captures card and wallet payments for web and mobile checkout |
| Users and consumers | *Example:* 4 internal services; about 2 million end customers per month indirectly |
| Business criticality | *Example:* Tier 1: checkout stops if the API is unavailable |
| Impact of an outage | *Example:* Lost orders at peak; contractual penalties with two merchants |
| Regulatory context | *Example:* PCI DSS scope reduced by tokenisation; EU data protection |
| Industry type in WA Tool | [Financial services] |
| Change frequency | *Example:* 15 to 20 production deployments per week |
| Architectural design link | [Link to the current diagram or Solution architecture, `architecture/solution-architecture`] |

### 2.2 Targets

| Target | Value | Source |
|---|---|---|
| Availability objective | *Example:* 99.95% monthly for the authorise flow | SLO document (`dev/slo-doc`) |
| Latency objective | *Example:* p99 below 400 ms for authorise | SLO document |
| Recovery time objective (RTO) | *Example:* 1 hour for a Region-level event | Disaster recovery plan (`ops/disaster-recovery-plan`) |
| Recovery point objective (RPO) | *Example:* 5 minutes | Disaster recovery plan |
| Peak load | *Example:* 900 requests per second, seasonal peak in November | Capacity plan (`ops/capacity-plan`) |
| Monthly cost envelope | *Example:* USD 42,000 including support | FinOps cost review (`ops/finops-cost-review`) |
| Sustainability goal | *Example:* Reduce vCPU hours per 1,000 transactions by 20% in 12 months | Sustainability assessment (`architecture/sustainability-architecture-assessment`) |

### 2.3 Architecture summary

| Layer | Services and configuration |
|---|---|
| Edge and ingress | *Example:* Amazon CloudFront, AWS WAF, Amazon API Gateway (Regional) |
| Compute | *Example:* AWS Lambda for workers; Amazon ECS on AWS Fargate for the API |
| Data | *Example:* Amazon Aurora PostgreSQL with a cross-Region replica; Amazon DynamoDB for idempotency keys |
| Integration | *Example:* Amazon SQS, Amazon EventBridge |
| Identity and secrets | *Example:* AWS IAM Identity Center, IAM roles per service, AWS Secrets Manager, AWS KMS customer managed keys |
| Observability | *Example:* Amazon CloudWatch, AWS X-Ray, centralised logs in the log archive account |
| Delivery | *Example:* Infrastructure as code with AWS CDK; pipeline with staged promotion |

## 3. Framework, lenses and tooling

<!-- Guidance: Lock the versions you review against and choose lenses deliberately. A lens adds questions; applying every lens dilutes the session. Pitfall: upgrading a lens mid-review, which changes the questions and the risk counts. -->

### 3.1 Framework version

The AWS Well-Architected Framework is versioned. The document revisions page lists dated framework versions, and the most recent major update of the whitepaper at the time of writing is dated 6 November 2024 (check the current page). In the WA Tool, each workload uses a specific version of each applied lens. When a newer version is available, the tool offers an upgrade; AWS documents that after upgrading a workload to a new lens version you cannot go back to the previous one. Record the version here and upgrade only at the start of a review cycle.

### 3.2 Lens selection

The Lens Catalog in the WA Tool listed the following 16 official lenses in October 2026. Mark each one and give the reason. The AWS Well-Architected Framework lens is applied to every workload by default.

| Lens (Lens Catalog name) | Apply? | Reason |
|---|---|---|
| AWS Well-Architected Framework | Yes (default) | Baseline for all workloads |
| Connected Mobility | [Yes / No] | [Reason] |
| Container Build | [Yes / No] | *Example:* No: images are built by the platform team's shared pipeline |
| Data Analytics | [Yes / No] | [Reason] |
| DevOps | [Yes / No] | [Reason] |
| Financial Services Industry | [Yes / No] | *Example:* Yes: regulated payments workload |
| Generative AI | [Yes / No] | Use with the GenAI review (`architecture/genai-well-architected-review`) |
| Government | [Yes / No] | [Reason] |
| Healthcare Industry | [Yes / No] | [Reason] |
| IoT | [Yes / No] | [Reason] |
| Mergers and Acquisitions | [Yes / No] | [Reason] |
| Machine Learning | [Yes / No] | [Reason] |
| Migration | [Yes / No] | [Reason] |
| SaaS | [Yes / No] | Pair with Multi-tenancy design (`architecture/multi-tenancy-design`) |
| SAP | [Yes / No] | [Reason] |
| Serverless Applications | [Yes / No] | *Example:* Yes: Lambda workers and API Gateway carry the critical flow |

AWS also publishes lenses as whitepapers that may not appear in the Lens Catalog, for example the Agentic AI Lens (published 10 June 2026) and the Digital Sovereignty Lens (last updated 15 September 2026). Use them as reading for the session, import the AWS-published custom lens JSON (github.com/aws-samples/sample-well-architected-custom-lens) into the WA Tool, or load a team-maintained custom lens if the organisation has one. Record any custom lens (name, version, owner, purpose) in the lens selection table above as an extra row.

### 3.3 WA Tool features used

| Feature | Use in this review | Setting |
|---|---|---|
| Profiles | Capture business context and priorities so the tool can prioritise questions | [Profile name] |
| Review templates | Pre-fill answers shared by several workloads (for example, landing zone controls) | [Template name or none] |
| AWS Trusted Advisor integration | Show resource checks next to related questions as evidence | [On / Off] |
| AWS Service Catalog AppRegistry | Associate the application's resources with the workload | [Application name] |
| Jira connector | Sync improvement items to the team's backlog | [Project key or none] |
| Workload sharing | Give read or contribute access to reviewers in other accounts | [Accounts] |
| Milestones | Snapshot the state after each cycle | Section 13 |

### 3.4 AWS Well-Architected Agent (preview)

AWS released the AWS Well-Architected Agent in preview on 1 October 2026. It analyses an AWS environment on a weekly cadence, produces recommendations across cost, security, performance and resilience at resource, application and architecture level, and can review AWS CloudFormation, Terraform and AWS CDK code on demand. It requires an AWS Support plan at the Business+ tier or higher (Business+, Enterprise On-Ramp, Enterprise Support or Unified Operations). Treat its output as evidence for sections 5 to 8, not as a replacement for the review conversation: it does not cover the organisational and process questions that drive most operational excellence findings. Because the feature is in preview, check its current scope and availability before relying on it.

## 4. Operational excellence

<!-- Guidance: Can the team run and change the workload safely, and does it learn? Look for business-aligned priorities, observability tied to outcomes, safe deployment, operational readiness and a learning loop. Pitfall: answering for the tooling and not for the team's actual habits. -->

### 4.1 Design principles

| AWS design principle | What the reviewer looks for |
|---|---|
| Organize teams around business outcomes | Goals and operational KPIs traceable from leadership to the team; a cloud operating model with clear ownership |
| Implement observability for actionable insights | KPIs defined from business outcomes and telemetry that triggers decisions, not only dashboards |
| Safely automate where possible | Operations defined as code, with guardrails such as rate limits, error thresholds and approvals on automation |
| Make frequent, small, reversible changes | Small batches, automated deployment and fast rollback, with a limited blast radius per change |
| Refine operations procedures frequently | Runbooks reviewed on a schedule and after use, with game days that keep them familiar |
| Anticipate failure | Failure scenarios exercised and procedures tested against them, with open risks decided explicitly |
| Learn from all operational events and metrics | Post-incident analysis shared beyond the team, with tracked follow-up actions |
| Use managed services | Managed services preferred where they meet requirements, with procedures built around them |

Best practice areas and AWS question identifiers: Organization (OPS 1 to OPS 3); Prepare (OPS 4 to OPS 7); Operate (OPS 8 to OPS 10); Evolve (OPS 11).

### 4.2 Review questions

| ID | Question | AWS ref | Current state | Evidence | Rating |
|---|---|---|---|---|---|
| AWR-OPS-01 | Are the workload's priorities agreed with the business, written down and used to settle conflicts between features and operational work? | OPS 1 | *Example:* Priorities live in the product owner's head | Interview | Medium |
| AWR-OPS-02 | Does every resource, alarm and runbook have a named owning team, and do teams know who to contact for shared dependencies? | OPS 2 | [State] | [Evidence] | [Rating] |
| AWR-OPS-03 | Can engineers stop a risky change or raise an operational concern without escalation friction, and is that behaviour encouraged? | OPS 3 | [State] | [Evidence] | [Rating] |
| AWR-OPS-04 | Are business and technical KPIs defined for the critical flows, emitted as telemetry and traced end to end across services? | OPS 4 | [State] | [Evidence] | [Rating] |
| AWR-OPS-05 | Are infrastructure, configuration and application changes version controlled, tested and promoted through the same pipeline? | OPS 5 | [State] | [Evidence] | [Rating] |
| AWR-OPS-06 | Do deployments use a progressive pattern (canary, linear or blue/green) with automatic rollback on alarm? | OPS 6 | *Example:* All-at-once deploys; manual rollback takes 25 minutes | Pipeline definition | High |
| AWR-OPS-07 | Is there an operational readiness check before launch and before major changes, covering runbooks, on-call and support plans? | OPS 7 | [State] | [Evidence] | [Rating] |
| AWR-OPS-08 | Do alarms map to customer impact, route to an owner and link to a runbook, with low noise? | OPS 8 | [State] | [Evidence] | [Rating] |
| AWR-OPS-09 | Does the team measure its own operational health (deployment failure rate, toil, alert volume) and review it regularly? | OPS 9 | [State] | [Evidence] | [Rating] |
| AWR-OPS-10 | Is there a documented incident process with severities, roles, communication templates and escalation to AWS Support? | OPS 10 | [State] | [Evidence] | [Rating] |
| AWR-OPS-11 | Are post-incident reviews blameless, are their actions tracked to closure and are lessons shared with other teams? | OPS 11 | [State] | [Evidence] | [Rating] |

Record runbooks with the Runbook template (`dev/runbook`) and post-incident reviews with the Postmortem template (`dev/postmortem`).

## 5. Security

<!-- Guidance: Protect data, systems and assets. Look for a governed multi-account foundation, workforce and workload identities without long-term keys, detection wired to response, layered network and compute protection, classified and encrypted data, rehearsed incident response and a secure software supply chain. Pitfall: citing a control that exists in the organisation but is not applied to this workload. -->

### 5.1 Design principles

| AWS design principle | What the reviewer looks for |
|---|---|
| Implement a strong identity foundation | Centralised identity, least privilege, separation of duties and no long-term static credentials |
| Maintain traceability | Actions and changes logged, monitored and alerted in near real time, with automated investigation |
| Apply security at all layers | Defence in depth from the edge through network, compute, operating system, application and code |
| Automate security best practices | Controls defined as code, versioned and applied by pipeline |
| Protect data in transit and at rest | Data classified by sensitivity, with encryption, tokenisation and access control chosen per class |
| Keep people away from data | Tools and automation replace direct human access to production data |
| Prepare for security events | Incident response process aligned to the organisation, rehearsed in simulations, with automated tooling |

Best practice areas and AWS question identifiers: Security foundations (SEC 1); Identity and access management (SEC 2 and SEC 3); Detection (SEC 4); Infrastructure protection (SEC 5 and SEC 6); Data protection (SEC 7 to SEC 9); Incident response (SEC 10); Application security (SEC 11).

### 5.2 Review questions

| ID | Question | AWS ref | Current state | Evidence | Rating |
|---|---|---|---|---|---|
| AWR-SEC-01 | Is the workload isolated in its own accounts under AWS Organizations, with preventive guardrails (service control policies) and a documented threat model? | SEC 1 | [State] | Threat model (`security/threat-model`) | [Rating] |
| AWR-SEC-02 | Do humans sign in through a central identity provider with MFA, and do workloads use IAM roles instead of access keys? | SEC 2 | *Example:* Two CI users still hold access keys older than 400 days | IAM credential report | High |
| AWR-SEC-03 | Are permissions scoped to least privilege, reviewed on a schedule and checked with policy analysis tooling? | SEC 3 | [State] | [Evidence] | [Rating] |
| AWR-SEC-04 | Are AWS CloudTrail, service logs and threat detection enabled in all accounts and Regions, with findings routed to an owner? | SEC 4 | [State] | [Evidence] | [Rating] |
| AWR-SEC-05 | Is network access layered (edge protection, private subnets, security groups, endpoints for AWS services) and is egress controlled? | SEC 5 | [State] | [Evidence] | [Rating] |
| AWR-SEC-06 | Are compute resources built from hardened, scanned images, patched automatically and free of interactive access where possible? | SEC 6 | [State] | [Evidence] | [Rating] |
| AWR-SEC-07 | Is data classified, and does the classification drive storage location, retention and access? | SEC 7 | [State] | [Evidence] | [Rating] |
| AWR-SEC-08 | Is data at rest encrypted with keys whose policies and rotation are managed, and is encryption enforced, not optional? | SEC 8 | [State] | [Evidence] | [Rating] |
| AWR-SEC-09 | Is all traffic encrypted in transit, with certificates managed and renewed automatically? | SEC 9 | [State] | [Evidence] | [Rating] |
| AWR-SEC-10 | Is there a workload-specific incident response playbook, with pre-provisioned access for responders and a recent simulation? | SEC 10 | [State] | Incident response plan (`compliance/incident-response-plan`) | [Rating] |
| AWR-SEC-11 | Does the pipeline scan code and dependencies, sign or verify artefacts and block releases on critical findings? | SEC 11 | [State] | [Evidence] | [Rating] |

Design detail belongs in the Security architecture (`security/security-architecture`) and IAM solution design (`security/iam-solution-design`).

## 6. Reliability

<!-- Guidance: Does the workload do what it should, when it should, and recover within its objectives? Look for quota management, redundant network paths, loosely coupled services, demand-driven scaling, automated change, backups that are restored, fault isolation and tested disaster recovery. Pitfall: claiming multi-AZ resilience without a test that proves it. -->

### 6.1 Design principles

| AWS design principle | What the reviewer looks for |
|---|---|
| Automatically recover from failure | KPIs measured on business value trigger automated recovery when thresholds are breached |
| Test recovery procedures | Failure injection and recovery tests run on a schedule, including scenarios that caused past incidents |
| Scale horizontally to increase aggregate workload availability | Several small resources instead of one large one, with no shared point of failure |
| Stop guessing capacity | Demand and utilisation monitored, capacity adjusted automatically, quotas managed |
| Manage change through automation | Infrastructure changes made by reviewed, tracked automation |

Best practice areas and AWS question identifiers: Foundations (REL 1 and REL 2); Workload architecture (REL 3 to REL 5); Change management (REL 6 to REL 8); Failure management (REL 9 to REL 13).

### 6.2 Review questions

| ID | Question | AWS ref | Current state | Evidence | Rating |
|---|---|---|---|---|---|
| AWR-REL-01 | Are service quotas known for every Region in use, monitored against peak and failover demand, and raised ahead of need? | REL 1 | [State] | [Evidence] | [Rating] |
| AWR-REL-02 | Is network connectivity redundant (multiple AZs, redundant hybrid links) with non-overlapping address space planned for growth? | REL 2 | [State] | [Evidence] | [Rating] |
| AWR-REL-03 | Is the workload split into services with clear contracts so that one failure does not take down unrelated functions? | REL 3 | [State] | [Evidence] | [Rating] |
| AWR-REL-04 | Are interactions designed to prevent failure: idempotent operations, loose coupling and constant work where suitable? | REL 4 | [State] | [Evidence] | [Rating] |
| AWR-REL-05 | Do clients use timeouts, retries with backoff and jitter, circuit breakers and graceful degradation? | REL 5 | [State] | [Evidence] | [Rating] |
| AWR-REL-06 | Are all resources monitored, with alarms that start automated responses for known failure signals? | REL 6 | [State] | [Evidence] | [Rating] |
| AWR-REL-07 | Does capacity scale automatically with demand, and has scaling been load tested at expected peak plus margin? | REL 7 | [State] | [Evidence] | [Rating] |
| AWR-REL-08 | Are changes deployed by automation with runbooks for the deployment and a tested rollback path? | REL 8 | [State] | [Evidence] | [Rating] |
| AWR-REL-09 | Are backups automated, protected from deletion, stored in a separate account or Region, and restored on a schedule? | REL 9 | *Example:* Snapshots exist; no restore test in 14 months | Backup report | High |
| AWR-REL-10 | Is the workload deployed across multiple Availability Zones, with cell or shuffle sharding where the blast radius warrants it? | REL 10 | [State] | [Evidence] | [Rating] |
| AWR-REL-11 | Does the workload detect component failure and fail over automatically, including static stability during an AZ loss? | REL 11 | [State] | [Evidence] | [Rating] |
| AWR-REL-12 | Are reliability tests (game days, fault injection) run on a schedule and in the pipeline, with findings tracked? | REL 12 | [State] | Chaos experiment (`ops/chaos-experiment`) | [Rating] |
| AWR-REL-13 | Is the disaster recovery strategy chosen to meet RTO and RPO, documented and exercised end to end in the past 12 months? | REL 13 | [State] | Disaster recovery plan (`ops/disaster-recovery-plan`) | [Rating] |

Tier and strategy choices belong in the Resilience tiering design (`architecture/resilience-tiering-ha-dr-design`); restore steps in the Backup and restore procedure (`ops/backup-restore-procedure`).

## 7. Performance efficiency

<!-- Guidance: Does the workload meet its performance targets with the least resource, and keep doing so as demand and services change? Look for evidence-based selection, the right compute and data stores for the access patterns, network placement and a habit of benchmarking. Pitfall: choosing services by team familiarity alone. -->

### 7.1 Design principles

| AWS design principle | What the reviewer looks for |
|---|---|
| Democratize advanced technologies | Specialised capabilities consumed as managed services rather than built and run by the team |
| Go global in minutes | Deployment to Regions or edge locations close to users where latency matters |
| Use serverless architectures | Serverless options used where they remove server management and fit the workload |
| Experiment more often | Comparative tests of instance types, storage and configuration before committing |
| Consider mechanical sympathy | Technology chosen to match access patterns and workload behaviour |

Best practice areas and AWS question identifiers: Architecture selection (PERF 1); Compute and hardware (PERF 2); Data management (PERF 3); Networking and content delivery (PERF 4); Process and culture (PERF 5).

### 7.2 Review questions

| ID | Question | AWS ref | Current state | Evidence | Rating |
|---|---|---|---|---|---|
| AWR-PERF-01 | Were the main services selected against written performance requirements, with options compared and the decision recorded? | PERF 1 | [State] | ADR (`architecture/adr-full`) | [Rating] |
| AWR-PERF-02 | Is the compute type and size chosen from load test data, including newer instance families or Graviton where compatible? | PERF 2 | [State] | [Evidence] | [Rating] |
| AWR-PERF-03 | Do the data stores match the access patterns (key-value, relational, search, cache), and are indexes and partitions tuned? | PERF 3 | [State] | [Evidence] | [Rating] |
| AWR-PERF-04 | Is network placement chosen for latency (Region, edge caching, private connectivity), and is cross-AZ and cross-Region traffic understood? | PERF 4 | [State] | [Evidence] | [Rating] |
| AWR-PERF-05 | Does the team set performance KPIs, benchmark before major changes and review new service features on a schedule? | PERF 5 | [State] | [Evidence] | [Rating] |
| AWR-PERF-06 | Are performance regressions caught before production by automated load or latency tests in the pipeline? | PERF 5 | *Example:* Load test run manually twice a year | Test report | Medium |

## 8. Cost optimization

<!-- Guidance: Does spend track value? Look for a cost owner, cost allocation by tags or accounts, budgets and anomaly alerts, decommissioning, right-sizing, commitment coverage, data transfer awareness and a habit of re-evaluating. Pitfall: reporting a monthly total without a unit cost. -->

### 8.1 Design principles

| AWS design principle | What the reviewer looks for |
|---|---|
| Implement Cloud Financial Management | A funded FinOps function or role, with programmes and processes, not ad hoc savings drives |
| Adopt a consumption model | Resources sized and scheduled to actual use, with non-production stopped outside working hours |
| Measure overall efficiency | Business output per unit of cost tracked over time |
| Stop spending money on undifferentiated heavy lifting | Managed services used to remove effort that does not differentiate the product |
| Analyze and attribute expenditure | Costs attributed to owners and products, enabling showback or chargeback |

Best practice areas and AWS question identifiers: Practice Cloud Financial Management (COST 1); Expenditure and usage awareness (COST 2 to COST 4); Cost-effective resources (COST 5 to COST 8); Manage demand and supply resources (COST 9); Optimize over time (COST 10 and COST 11).

### 8.2 Review questions

| ID | Question | AWS ref | Current state | Evidence | Rating |
|---|---|---|---|---|---|
| AWR-COST-01 | Is there a named cost owner who reviews spend with engineering and finance on a fixed cadence? | COST 1 | [State] | [Evidence] | [Rating] |
| AWR-COST-02 | Are budgets, approval rules and guardrails in place to stop unplanned resource types or Regions? | COST 2 | [State] | [Evidence] | [Rating] |
| AWR-COST-03 | Are all resources tagged or account-mapped so cost can be attributed, with anomaly detection alerting an owner? | COST 3 | *Example:* 31% of spend untagged | Cost allocation report | Medium |
| AWR-COST-04 | Is there a routine to find and remove idle or orphaned resources, snapshots and environments? | COST 4 | [State] | [Evidence] | [Rating] |
| AWR-COST-05 | Was cost included in service selection, including licensing and operational effort? | COST 5 | [State] | TCO analysis (`architecture/tco-analysis`) | [Rating] |
| AWR-COST-06 | Are resources right-sized from utilisation data, with a review after each significant release? | COST 6 | [State] | [Evidence] | [Rating] |
| AWR-COST-07 | Is steady-state usage covered by Savings Plans or reservations, and is Spot capacity used for interruptible work? | COST 7 | [State] | [Evidence] | [Rating] |
| AWR-COST-08 | Are data transfer paths (cross-AZ, cross-Region, internet egress, NAT) modelled and minimised? | COST 8 | [State] | [Evidence] | [Rating] |
| AWR-COST-09 | Is supply matched to demand through scaling, scheduling, buffering or throttling? | COST 9 | [State] | [Evidence] | [Rating] |
| AWR-COST-10 | Are new services and pricing options evaluated on a schedule, and is the effort of optimising weighed against the saving? | COST 10, COST 11 | [State] | [Evidence] | [Rating] |
| AWR-COST-11 | Is a unit cost (for example cost per 1,000 transactions) published and trended? | COST 1, COST 3 | [State] | FinOps cost review (`ops/finops-cost-review`) | [Rating] |

## 9. Sustainability

<!-- Guidance: Is the resource and energy footprint as small as the value delivered allows? Many answers overlap with cost; rate them separately because the objective differs. Look for Region choice, demand alignment, efficient software, data lifecycle, efficient hardware and goals with an owner. Pitfall: no baseline, so no improvement can be shown. -->

### 9.1 Design principles

| AWS design principle | What the reviewer looks for |
|---|---|
| Understand your impact | Impact measured per unit of work and modelled for the future, including customer use and retirement |
| Establish sustainability goals | Long-term goals per workload, such as resource per transaction, with owners and investment |
| Maximize utilization | Right-sizing and consolidation so hardware runs efficiently and idle capacity is minimal |
| Anticipate and adopt new, more efficient hardware and software offerings | Flexibility to adopt more efficient instance types and managed offerings quickly |
| Use managed services | Shared managed services and lifecycle automation that raise utilisation |
| Reduce the downstream impact of your cloud workloads | Less energy and fewer device upgrades needed by customers to use the service |

Best practice areas and AWS question identifiers: Region selection (SUS 1); Alignment to demand (SUS 2); Software and architecture (SUS 3); Data (SUS 4); Hardware and services (SUS 5); Process and culture (SUS 6).

### 9.2 Review questions

| ID | Question | AWS ref | Current state | Evidence | Rating |
|---|---|---|---|---|---|
| AWR-SUS-01 | Were Regions chosen with sustainability as one criterion alongside latency, residency and cost? | SUS 1 | [State] | [Evidence] | [Rating] |
| AWR-SUS-02 | Does provisioned capacity follow demand, with non-critical work shifted to off-peak or batched? | SUS 2 | [State] | [Evidence] | [Rating] |
| AWR-SUS-03 | Are inefficient code paths, polling loops and unused features identified and removed? | SUS 3 | [State] | [Evidence] | [Rating] |
| AWR-SUS-04 | Do data stores have lifecycle rules, tiering and deletion based on classification and need? | SUS 4 | [State] | [Evidence] | [Rating] |
| AWR-SUS-05 | Are the most efficient compatible instance types and managed services in use, with a plan to adopt new ones? | SUS 5 | [State] | [Evidence] | [Rating] |
| AWR-SUS-06 | Is there a sustainability KPI with a baseline, an owner and a place in the team's regular reviews? | SUS 6 | *Example:* No baseline measured | None | Medium |

## 10. Lens review

<!-- Guidance: Record the questions added by each lens selected in section 3.2. Keep the lens identifiers from the WA Tool in the "AWS ref" column. Do not duplicate framework questions; add only what the lens changes. Pitfall: answering a lens for a workload type the system is not. -->

### 10.1 Lens questions

| ID | Lens | Question | AWS ref | Current state | Evidence | Rating |
|---|---|---|---|---|---|---|
| AWR-LNS-01 *(Example)* | Serverless Applications | Are function concurrency limits set so that a retry storm in one function cannot starve the authorise path? | [Lens question ID] | Unreserved concurrency shared by all functions | Concurrency metrics | High |
| AWR-LNS-02 *(Example)* | Financial Services Industry | Is there evidence that resilience testing results are reported to the operational risk function as regulators expect? | [Lens question ID] | Tests run, not reported | Test log | Medium |
| AWR-LNS-03 *(Example)* | Financial Services Industry | Is concentration on a single Region or provider service assessed and documented as part of third-party risk? | [Lens question ID] | Not assessed | None | Medium |
| [AWR-LNS-NN] | [Lens] | [Question] | [ID] | [State] | [Evidence] | [Rating] |

## 11. Risk register

<!-- Guidance: List every question rated High or Medium. Each finding states the gap, the impact in business terms, the evidence and the response. Keep the finding IDs stable across review cycles so the milestone comparison is meaningful. Pitfall: findings without evidence, which are disputed and never fixed. -->

### 11.1 Findings

| Finding ID | Question | Pillar or lens | Risk | Finding | Business impact | Response |
|---|---|---|---|---|---|---|
| FND-001 *(Example)* | AWR-OPS-06 | Operational excellence | High | All-at-once deployments with manual rollback | A defective release affects all customers for up to 25 minutes | ACT-001 |
| FND-002 *(Example)* | AWR-SEC-02 | Security | High | Long-lived access keys for two CI users | Key leak gives deploy rights to production | ACT-002 |
| FND-003 *(Example)* | AWR-REL-09 | Reliability | High | No restore test for 14 months | RPO and RTO are unproven | ACT-003 |
| FND-004 *(Example)* | AWR-LNS-01 | Serverless Applications | High | Shared unreserved concurrency | Retry storm can starve authorise | ACT-004 |
| FND-005 *(Example)* | AWR-COST-03 | Cost optimization | Medium | 31% of spend untagged | Cost cannot be attributed; savings unowned | ACT-005 |
| FND-006 *(Example)* | AWR-PERF-06 | Performance efficiency | Medium | No automated load test | Regressions found by customers at peak | ACT-006 |
| FND-007 *(Example)* | AWR-SUS-06 | Sustainability | Medium | No sustainability baseline | Goal cannot be tracked | RA-001 |
| [FND-NNN] | [AWR-ID] | [Pillar or lens] | [High / Medium] | [Finding] | [Impact] | [ACT-NNN / RA-NNN] |

The *Example* rows show a subset; the completed register lists every question rated High or Medium in the sections above.

### 11.2 Summary by pillar

| Pillar or lens | High | Medium | None | Not applicable |
|---|---|---|---|---|
| Operational excellence | [n] | [n] | [n] | [n] |
| Security | [n] | [n] | [n] | [n] |
| Reliability | [n] | [n] | [n] | [n] |
| Performance efficiency | [n] | [n] | [n] | [n] |
| Cost optimization | [n] | [n] | [n] | [n] |
| Sustainability | [n] | [n] | [n] | [n] |
| [Lens] | [n] | [n] | [n] | [n] |
| **Total** | [n] | [n] | [n] | [n] |

### 11.3 Trade-offs between pillars

| Decision | Pillar favoured | Pillar affected | Rationale | Decided by |
|---|---|---|---|---|
| *Example:* Warm standby in eu-central-1 instead of pilot light | Reliability | Cost optimization (about 18% more spend) | RTO of 1 hour cannot be met by pilot light for the Aurora cluster size | [@workload-owner] |
| *Example:* Keep x86 instances for one service | Reliability (vendor library support) | Sustainability, cost | Native library not yet available for Arm | [@tech-lead] |
| [Decision] | [Pillar] | [Pillar] | [Rationale] | [@name] |

Escalate risks that outlive this review to the organisation's Risk register (`compliance/risk-register`).

## 12. Improvement plan

<!-- Guidance: Turn findings into owned, dated actions sized for the team's capacity. Order by risk reduction per effort. In the WA Tool the improvement plan lists the best practices not yet selected; this section adds owners, dates and acceptance criteria. Pitfall: a plan with 40 actions and no capacity reserved. -->

### 12.1 Action backlog

| Action ID | Finding | Action | Owner | Effort | Target date | Acceptance criterion | Status |
|---|---|---|---|---|---|---|---|
| ACT-001 *(Example)* | FND-001 | Introduce canary deployment with automatic rollback on error-rate and latency alarms | [@tech-lead] | M | YYYY-MM-DD | Rollback within 5 minutes shown in a staged failure | [Open] |
| ACT-002 *(Example)* | FND-002 | Replace CI access keys with OIDC federation to IAM roles; delete the keys | [@platform-eng] | S | YYYY-MM-DD | Credential report shows no active keys for the workload | [Open] |
| ACT-003 *(Example)* | FND-003 | Automate a monthly restore into an isolated account and verify row counts | [@dba] | M | YYYY-MM-DD | Two consecutive successful restores within RTO | [Open] |
| ACT-004 *(Example)* | FND-004 | Set reserved concurrency for authorise and cap retry workers | [@dev-lead] | S | YYYY-MM-DD | Load test with injected retry storm keeps authorise p99 within target | [Open] |
| ACT-005 *(Example)* | FND-005 | Enforce tag policy and backfill tags | [@finops] | S | YYYY-MM-DD | Untagged spend below 5% for two months | [Open] |
| ACT-006 *(Example)* | FND-006 | Add a load test stage to the pipeline with a latency budget | [@qa-lead] | M | YYYY-MM-DD | Pipeline blocks a release that exceeds p99 by 10% | [Open] |
| [ACT-NNN] | [FND-NNN] | [Action] | [@owner] | [S / M / L] | YYYY-MM-DD | [Criterion] | [Status] |

### 12.2 Responsibilities

| Activity | Workload owner | Lead reviewer | Engineering team | Security | FinOps |
|---|---|---|---|---|---|
| Approve scope and lenses | A | R | C | C | C |
| Answer questions with evidence | A | C | R | R | R |
| Rate and record findings | C | A/R | C | C | C |
| Prioritise and fund actions | A/R | C | C | C | C |
| Implement actions | A | I | R | R | R |
| Save milestones and report progress | A | R | C | I | I |

R = responsible, A = accountable, C = consulted, I = informed.

### 12.3 Timeline

Schedule High risk actions first and place the re-review milestone after the last of them closes.

```mermaid
gantt
  title Improvement plan (Example)
  dateFormat YYYY-MM-DD
  section High risk
  ACT-002 OIDC for CI          :a2, 2026-11-02, 10d
  ACT-004 Concurrency limits   :a4, 2026-11-02, 7d
  ACT-001 Canary and rollback  :a1, 2026-11-09, 21d
  ACT-003 Restore automation   :a3, 2026-11-16, 21d
  section Medium risk
  ACT-005 Tag policy           :a5, 2026-12-01, 14d
  ACT-006 Load test stage      :a6, 2026-12-07, 21d
  section Milestones
  MS-002 re-review             :milestone, m2, 2027-01-25, 0d
```

## 13. Milestones and re-review

<!-- Guidance: A WA Tool milestone records the state of the workload review at a point in time. Save one after the first complete pass and after each batch of improvements, then compare risk counts between milestones. Pitfall: re-answering questions without saving a milestone first, which loses the baseline. -->

### 13.1 Milestone record

| Milestone ID | WA Tool milestone name | Date | Framework and lens versions | High | Medium | Notes |
|---|---|---|---|---|---|---|
| MS-001 *(Example)* | [2026-10 initial review] | YYYY-MM-DD | [Framework version], Serverless [version], FSI [version] | 5 | 11 | Baseline |
| MS-002 *(Example)* | [2027-01 re-review] | YYYY-MM-DD | Same as MS-001 | 1 | 6 | ACT-001 to ACT-004 closed |
| [MS-NNN] | [Name] | YYYY-MM-DD | [Versions] | [n] | [n] | [Notes] |

### 13.2 Re-review triggers

Run a new review cycle, and save a milestone, when any of the following occurs:

- the scheduled interval is reached ([every 6 months for Tier 1, 12 months for others]);
- a major architecture change, such as a new Region, a new data store or a move from containers to serverless;
- a Severity 1 incident or a failed disaster recovery exercise;
- a new lens version or framework version the team decides to adopt;
- a material change in regulation or contract that affects the workload.

## 14. Risk acceptance and sign-off

<!-- Guidance: A risk that will not be fixed must be accepted by someone with the authority to carry it, for a limited time, with a review date. Pitfall: accepting a High risk without a compensating control. -->

### 14.1 Accepted risks

| Acceptance ID | Finding | Reason | Compensating control | Accepted by | Expiry |
|---|---|---|---|---|---|
| RA-001 *(Example)* | FND-007 | Baseline tooling planned at organisation level next quarter | Cost right-sizing actions also reduce footprint | [@workload-owner] | YYYY-MM-DD |
| [RA-NNN] | [FND-NNN] | [Reason] | [Control] | [@name] | YYYY-MM-DD |

### 14.2 Review conclusion

| Item | Value |
|---|---|
| Overall conclusion | [Ready for production / Ready with conditions / Not ready] |
| Conditions | [List conditions, each linked to an action] |
| Go-live link | [Go-live readiness review, `project/go-live-readiness-review`, if pre-launch] |
| Next review date | YYYY-MM-DD |

## 15. Glossary and references

<!-- Guidance: Define terms the readers may not share, and list the exact versions used. -->

### 15.1 Glossary

| Term | Meaning in this document |
|---|---|
| Pillar | One of the six areas of the AWS Well-Architected Framework against which the workload is reviewed |
| Best practice area | A grouping of questions within a pillar, such as Failure management |
| Lens | A set of questions and best practices for a technology, industry or workload type, applied in the WA Tool |
| Lens Catalog | The collection of official AWS lenses available in the WA Tool without installation |
| HRI, MRI | High risk issue and medium risk issue, the risk levels the WA Tool assigns to answered questions |
| Milestone | A saved snapshot of the review state for a workload at a point in time |
| Profile | Business context attached to a workload that the WA Tool uses to prioritise questions |
| Review template | Pre-filled answers that can be applied to several workloads |
| RTO, RPO | Recovery time objective and recovery point objective |

### 15.2 References

| Reference | Version or date | Use |
|---|---|---|
| AWS Well-Architected Framework, docs.aws.amazon.com/wellarchitected/latest/framework | Latest major update 6 November 2024 (document revisions page) | Pillars, design principles, question identifiers |
| AWS Well-Architected Tool User Guide, Lens Catalog page | Checked 2026-10-23, 16 official lenses | Section 3.2 |
| AWS Well-Architected Tool User Guide, Milestones page | Checked 2026-10-23 | Section 13 |
| AWS Well-Architected Tool User Guide, release notes | AWS Well-Architected Agent preview, 1 October 2026 | Section 3.4 |
| AWS Well-Architected lenses (whitepapers), aws.amazon.com/architecture/well-architected | Checked 2026-10-23 | Section 3.2 |
| Related templates | Current | Cloud architecture review (`architecture/cloud-architecture-review`), GenAI Well-Architected review (`architecture/genai-well-architected-review`), Azure Well-Architected review (`architecture/azure-well-architected-review`), Google Cloud Well-Architected review (`architecture/google-well-architected-review`) |

## Standard and licence note

Structure aligned with the six pillars, design principles, best practice areas and question identifiers of the AWS Well-Architected Framework and with the Lens Catalog, milestone and Well-Architected Agent (preview) features of the AWS Well-Architected Tool, as checked on the AWS documentation on 23 October 2026. Pillar, design principle, best practice area and lens names and question identifiers are used for mapping only. The review questions, ratings, guidance and examples are original text written for this collection and do not reproduce AWS question or best practice wording. Check the current official framework version, lens versions and tool features before each review; AWS updates them frequently. AWS, Amazon Web Services and AWS Well-Architected are trademarks of their owners; this template is not affiliated with or endorsed by them. Template licence: MIT.