Your team is asked to run a Well-Architected Review of a production workload using the AWS Well-Architected Tool. What does the review actually consist of, what is a milestone, and what do you have at the end?

## Defining the workload Everything in the AWS Well-Architected Tool hangs off a *workload* record. You create one with a name and description, an environment flag of production or pre-production, the AWS Regions it runs in, and the account IDs involved; you can attach a link to an architecture diagram and name the review owner. Workload records live in the Region you create them in, which surprises people who later look in the wrong Region for last year's review. Getting the scope right matters more than it sounds. "The whole platform" is not a workload — the answers become mush because different components have genuinely different requirements. One deployable system with one set of business objectives is the right granularity. ## Applying lenses A *lens* is a set of design questions. The AWS Well-Architected Framework lens — the pillar questions — is applied by default. From the lens catalog you can add technology- or industry-specific lenses, such as the Serverless, SaaS, Data Analytics, Machine Learning or Financial Services Industry lenses, each adding questions the general framework does not ask. You can also upload a **custom lens** as a JSON document: your own questions, your own best practices, your own risk rules. Custom lenses are versioned and can be shared with other accounts, which is how an organisation encodes "our standards" — a required tagging scheme, a mandated deployment pattern — into the same review instrument as the AWS guidance. ## Answering the questions This is the review. For each design question the tool lists best practices as checkboxes. You select the ones the workload actually follows. Three things are worth knowing: - **Unselected is not neutral.** Every best practice you leave unticked contributes to a risk on that question. There is no "we'll come back to it" state that is invisible in the output. - **Not applicable is a first-class answer.** You can mark a whole question or an individual best practice as not applicable and record the reason. Doing this honestly is what stops a serverless workload from carrying phantom risks about patching instances. - **Notes are where the value hides.** A year later the checkbox tells you nothing, and the note explaining *why* you accepted single-Region tells you everything. The tool rates the resulting gaps as **High Risk Issues (HRIs)** and **Medium Risk Issues (MRIs)**, summarises them per pillar, and builds an improvement plan linking each to the relevant guidance. Where your AWS Support plan exposes them, relevant Trusted Advisor checks are surfaced alongside the questions so account-level evidence sits next to the design answer. ## Milestones A **milestone** is an immutable, read-only snapshot of the entire review — every answer, every note, every risk count — taken at a point in time. You cannot edit a milestone after saving it; you keep working on the live workload, and the milestone stands as the record of where you were. The practice worth adopting is saving a milestone at meaningful moments: at the end of each review session, before a major release, after a remediation push. That gives you a comparison. "We closed eleven high risk issues between the launch milestone and today" is a sentence you can only say if someone saved the first one. ## What you have at the end Four things. A recorded set of answers with reasoning. A prioritised improvement plan of HRIs and MRIs. A downloadable report to circulate to people who will not log into the console. And a milestone to measure the next review against. What you do **not** have is a certificate, a score AWS publishes, or any remediation — the tool does not change a single resource in your account. It is a structured questionnaire with good guidance attached. ## Sharing and reuse Workloads can be shared with other AWS accounts, with IAM principals, or with an organisation or organisational unit, granting read-only or contribute access — which is how a central architecture group participates in a team's review without owning the account. Review templates let you pre-fill answers that are identical across many workloads, such as organisation-wide guardrails, and profiles let you record business context so the tool orders the questions and risks by what matters to this workload right now. ## The common failure The review is answered by one architect alone, in an afternoon, optimistically. Every checkbox goes green, the risk count is zero, and the exercise has produced nothing. A review is worth doing when the people who operate the workload are in the room and are allowed to say "no, we don't actually do that".