AWS Well Architected Review

AWSOfficialPublished by AWS

Skill
Review and audit
Cloud and DevOps
Apache-2.0
No issues found

From the author

Performs a full AWS Well-Architected Framework review evaluating every framework question across all pillars discovered from the live AWS documentation by analyzing code, IaC, and configurations to produce evidence-backed findings with Eisenhower-prioritized remediation. Supports full reviews (every framework best practice with BP ID citations), quick reviews (question-level), pillar-scoped reviews, score-mode reviews (a maturity scorecard with per-pillar scores and filtered findings), and lens-specific reviews using lenses discovered from the live AWS documentation. Triggers on mentions of Well-Architected review, WA review, WAR, pillar assessment, architecture review across pillars, workload assessment, cloud readiness evaluation, or a Well-Architected score, grade, or scorecard request. Does not apply to single-pillar deep-dives, learning WA concepts, ADRs, or migration readiness assessments.

— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill conducts a systematic AWS Well-Architected Framework (WA Framework) review by discovering workload architecture from code and IaC, acquiring a live corpus of framework best practices, and evaluating them against the workload. It produces a risk-ranked, Eisenhower-prioritized report, ensuring comprehensive coverage across all pillars. The process is gated to ensure accuracy, using a frozen manifest of questions and best practices to maintain consistency throughout the assessment.

What it does

Discovers infrastructure and application architecture from code, IaC, and deployment configurations.
Fetches and validates the current AWS Well-Architected Framework corpus from live documentation.
Evaluates every framework best practice against the workload with specific evidence citations.
Generates a risk-classified report including a pillar scorecard and remediation plan.
Supports multiple review modes including full, quick, pillar-scoped, and lens-specific assessments.
Provides Eisenhower-prioritized remediation steps for identified risks.

When to use it

When you need a formal, evidence-based assessment of your AWS workload's alignment with the Well-Architected Framework.
When preparing for a cloud architecture review or seeking to improve the maturity of an existing deployment.
When you require a prioritized list of remediation tasks based on architectural risks.
When you need to evaluate specific AWS lenses or pillar-scoped assessments for your infrastructure.

Advantages

Evidence-backed findings linked directly to your codebase or architecture description.
Comprehensive coverage ensures no best practice is overlooked during the review.
Prioritized remediation plan helps focus efforts on the most critical architectural risks.
Uses live documentation to ensure the framework criteria are current and accurate.
Structured, repeatable process reduces subjectivity in architectural assessments.

Usage examples

“Perform a full AWS Well-Architected review for my current project in this repository.”: The agent will analyze the IaC and code, fetch the latest WA framework, evaluate all pillars, and output a comprehensive report with a scorecard and remediation plan.
“Can you run a pillar-scoped assessment on the Security pillar for my infrastructure?”: The agent will focus its discovery and evaluation exclusively on the Security pillar, providing a detailed breakdown of findings and risks for that specific area.
“I need a Well-Architected scorecard for my workload.”: The agent will perform a score-mode review, providing a maturity scorecard with per-pillar scores and a summary of findings.
“Perform a lens-specific review using the Serverless Lens.”: The agent will apply the Serverless Lens criteria to your workload and generate a standalone report focusing on serverless-specific best practices.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/aws/aws-well-architected-review/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip aws-well-architected-review.zip -d .agents/skills

Documentation by AWS

Well-Architected Review

Overview

Guides a systematic AWS Well-Architected Framework (WA Framework) review: discover the workload from code and IaC, acquire the live corpus inventory, evaluate every framework question and best practice against evidence, and deliver a risk-ranked, Eisenhower-prioritized report inline.

Framework content is fetched from the live AWS documentation at review time rather than embedded as a snapshot. The AWS MCP server's documentation reader (aws___read_documentation) is recommended for reliable retrieval; when it is unavailable, fetch the same docs.aws.amazon.com pages over HTTPS with the environment's web-fetch tool, and if no documentation access exists at all, proceed from internal knowledge and disclose that the framework inventory could not be verified live. Do not depend on any non-public or internal best-practice/WA-guidance MCP; those are unavailable in supported runtimes.

Detailed procedures live in reference files — read each one when its step says to:

Review modes — mode selection (full / quick / pillar-scoped / score), trigger phrases, score output format
Discovery procedure — infrastructure and application architecture discovery
Live corpus inventory — the gated ACQUIRE_CORPUS stage: deterministic read-only traversal of the framework, the corpus records, and the validation gate
Evaluation procedure — evaluating every BP against the frozen manifest, per-pillar passes, aggregation rules, coverage audit
Lens guidance — when and how to apply Well-Architected Lenses
Risk assessment — impact × likelihood matrix and cross-pillar trade-offs
Report template — the full report structure for the report step
Security considerations — secure handling of workload data, review tooling, findings, and persisted artifacts

Execution model

Before beginning any step, read and follow security considerations — secrets redaction, HTTPS-only retrieval, least privilege, and confidentiality handling must be loaded before you operate on workload code or review tooling.

A full review runs as a gated sequence. Each step has a transition gate; you MUST NOT advance to the next step, or skip a step, when its gate has not passed. The single user-visible deliverable is one complete inline report — scratch files (a run-local working directory) are execution state only, never the delivered artifact, and their paths MUST NOT appear in the report.

Non-interactive by default. When the user has explicitly requested a review and supplied sufficient scope, execute every step to completion without pausing for confirmation between steps. The discovery and risk-assessment checkpoints are internal validation gates, not user stops: validate them yourself and proceed. Pause for the user only when the user explicitly asked for interactive checkpoints, or when a required scope decision genuinely cannot be inferred (e.g. an ambiguous pillar-scoped request).

Non-negotiable invariants — ALL modes (full / quick / pillar-scoped / score):

Step 4 (ACQUIRE_CORPUS) is mode-independent: every mode acquires and validates the live corpus inventory before any assessment and reads its questions/BPs against that frozen manifest. Assessment MUST NOT begin against an incomplete or unvalidated manifest, and no mode may skip Step 4.
Canonical IDs only — never fabricate a PILLAR##-BP## ID. If corpus acquisition cannot produce an ID, that is a surfaced error, not a gap to invent around.

Non-negotiable invariants — full review only:

Every BP in the frozen manifest receives exactly one status from the five-value vocabulary.
All sections of the report template are present (it is the authoritative list — the numbered items in Step 7 are the recall-critical subset, NOT the complete set: the template also mandates the Executive Summary, Architecture Overview, Cross-Pillar Trade-offs, Next Steps, and others). The report is emitted inline, first line # Well-Architected Review:. No "see file", attachment, or scratch-path deferral.

Step 1: Define the workload scope

Establish the workload from what the user provided:

Workload name and brief description
Code packages/directories to analyze (IaC, application code, CI/CD configs)
Business criticality (critical, high, standard, low)
Current pain points (optional)

If the user has already provided architecture details or you are in a codebase with IaC, proceed with discovery without prompting. When no code or IaC is available (the user describes their architecture verbally), proceed using the description as evidence; mark findings you cannot verify in code as "Based on description — verify in code." Do NOT ask for code when the user has already given enough context for a meaningful review.

Determine the review mode (full / quick / pillar-scoped / score) from the user's phrasing — read review modes. Determine whether the workload matches a live lens — read lens guidance when one does.

Step 2: Infrastructure Discovery

Read and follow the discovery procedure.

Step 3: Application Architecture Discovery

Continue following the discovery procedure, including its internal completeness gate before evaluation.

Step 4: Acquire and freeze the live corpus inventory (ACQUIRE_CORPUS gate)

Read and follow the live corpus inventory procedure. First create the run-local working directory this review uses for scratch state — the corpus/ folder that holds questions.jsonl, best-practices.jsonl, and manifest.json referenced below. Then build the complete live corpus inventory (the question + best-practice manifest) by a bounded, read-only traversal of the canonical framework pages (prefer aws___read_documentation; see the reference for the non-MCP HTTPS fallback), reduce each page to structured records immediately, and validate the manifest.

Gate: you MUST NOT begin Step 5 until corpus/manifest.json reports valid: true. The frozen manifest is the sole authority for the expected question and BP sets used by evaluation, the coverage audit, and the report.

Step 5: Evaluate EVERY BP against the frozen manifest

CRITICAL — DO NOT PRODUCE A SHORT REVIEW. The most common failure is citing a subset of BPs and stopping. A full review MUST evaluate every BP in the frozen manifest, each with a status from the five-value vocabulary (with rationale).

Read and follow the evaluation procedure. It defines per-pillar passes against the frozen manifest, aggregation, per-mode adjustments, and the coverage audit (its sub-steps are labelled 5a–5d). For each BP assess:

Status: exactly one of "Implemented", "Partially Implemented", "Not Implemented", "Not Applicable", "Cannot Determine"
Evidence: specific file paths and line numbers (or "Based on description")
Gaps: what is missing or could be improved
Risk: what could go wrong due to the gap

Evaluate every pillar in the frozen manifest, using its pillar names, prefixes, and question categories.

Step 6: Risk Assessment

Read and follow the risk assessment procedure, including its internal gate.

Step 7: Produce the report

Mode gate: For score mode, emit only the scorecard output from review modes. For quick and pillar-scoped reviews, apply the mode adjustments from review modes. For a lens-only request (the user named a single WA Lens and did not ask for a full framework review), produce a standalone lens report — the core framework tables are omitted and the deliverable is the Lens Findings section plus a lens scorecard, following lens guidance; when a lens is applied on top of a full review, keep the full structure and add the Lens Findings section. Otherwise — a full review — read the report template and produce the report with that exact structure. The report template is the authoritative list of mandatory sections; the following are the recall-critical ones that a weaker model most often drops (do NOT treat them as the complete set):

Coverage audit (from the evaluation procedure, Step 5d) before the executive summary
Pillar scorecard with per-pillar scores (1-5)
Per-question assessment table — every question in the frozen manifest, no truncation
Full BP Ledger — one row per evaluated BP, concatenated verbatim from the pillar passes
Risk-classified findings (Critical/High expanded, Medium condensed, Low tabular)
Eisenhower-prioritized remediation plan (Do First / Plan / Delegate / Defer) with SMART goals

Emit the report inline as the final response, first line # Well-Architected Review:. Do not defer any section to a file.

Step 8: Offer follow-up

After delivering the report, offer:

Would you like me to:
Deep-dive into a specific pillar with expanded analysis?
Generate IaC templates to remediate a specific finding?
Create a migration plan for a specific architectural change?
Compare your workload against a specific WA Lens in detail?
Generate automated checks (Config rules, custom metrics) for ongoing compliance?
Produce a WA Tool import for tracking in the AWS console?

Calibration Guidance

A workload with multi-AZ, encryption, CI/CD with rollback, monitoring, and auto-scaling is MATURE — most findings should be improvements, not Critical
Do NOT manufacture Critical findings for a well-built workload — accuracy over alarm
When business criticality is "low"/"standard", accept simpler architectures (single-region is fine for internal tools)
When business criticality is "critical", apply stricter standards (multi-region DR, chaos testing, sub-minute RTO expected)
Every finding MUST have code evidence — no generic recommendations without backing
If something cannot be determined from code, say "Cannot Determine" and explain what runtime/interview data is needed
Acknowledge strengths prominently — a mature workload should feel validated, not just criticized

Security Considerations

Read and follow security considerations before using review tooling, sharing findings, or persisting artifacts.

Files

ATTRIBUTION.mdAdded by AutoGineer919 B
LICENSELicence file added by AutoGineer9.9 KiB
NOTICELicence file added by AutoGineer67 B
SKILL.md11.7 KiB
assets/report-template.md6.6 KiB
references/discovery-procedure.md3.5 KiB
references/evaluation-procedure.md9.7 KiB
references/lens-guidance.md2.1 KiB
references/phase-live-inventory.md8.3 KiB
references/review-modes.md4.7 KiB
references/risk-assessment.md1.6 KiB
references/security-considerations.md4.3 KiB

assets/report-template.md

Report Template — Full Well-Architected Review

Produce the final report with this exact structure. Do not drop sections. The Coverage audit (defined in the evaluation procedure reference) goes immediately before the Executive Summary.

# Well-Architected Review: {Workload Name}

> **Classification: CONFIDENTIAL** — This report contains sensitive infrastructure details and unremediated security findings. Restrict distribution to authorized personnel. Do not post to broadly visible channels or ticketing systems without explicit approval.

## Coverage Audit
{Coverage audit output from Step 5d — see the evaluation procedure reference}

## Executive Summary
- **Date**: {date}
- **Workload**: {name}
- **Business Criticality**: {level}
- **Lens Applied**: {lens or "General"}
- **Packages Analyzed**: {list}
- **Questions Assessed**: {n}/{n per live documentation}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Maturity**: {1-5} — {one-line justification}

## Architecture Overview
{PlantUML diagram}
{Brief description of architecture, key services, data flows}

## Pillar Scorecard
| Pillar | Score (1-5) | Questions Assessed | Key Strength | Key Gap |
|--------|-------------|-------------------|--------------|---------|
| {pillar from live inventory} | {score} | {n}/{n} | {strength} | {gap} |
| ...one row per discovered pillar... | ... | ... | ... | ... |

{Denominators come from the Step 5a question inventory — use the live counts derived from the appendix pages}

## Per-Question Assessment
| ID | Question | Status | Risk Level | Key Evidence |
|----|----------|--------|------------|--------------|
| {question ID from live inventory} | {question} | {status} | {risk or Not Applicable} | {evidence} |
| ...one row per discovered question... | ... | ... | ... | ... |

{Complete this table for every question in the Step 5a inventory — use the live count from the appendix; do not truncate}

## Full BP Ledger (MANDATORY)

**This section MUST list every BP citation produced by every pillar pass.** Concatenate every pillar table here, sorted by pillar then BP ID. Do NOT filter, cluster, or paraphrase. Every row surfaced by each pass must appear in the ledger. Target row count: one row per BP evaluated across all pillars — matching the summed per-pillar documentation counts from Step 5b.

This section is where recall reaches the user: skipping or truncating it collapses a full-inventory review down to whatever the assembler compresses to. **Do not skip this section.**

| BP ID | Pillar | Status | Risk Level | Evidence | Recommendation |
|-------|--------|--------|----------|----------|-----------------|
| {BP ID from live inventory} | {pillar} | {status} | {risk level or blank} | {evidence} | {recommendation} |
| ...one row per discovered BP... | ... | ... | ... | ... | ... |

{After writing this table, count the rows and confirm the count matches the sum of the pillar-pass rows. If not, you dropped citations — go back and add them.}

## Lens Findings (only if a lens was applied)
{Lens-specific best-practice evaluation, separate from the core findings above. Omit this section entirely for a General review.}

## Critical and High Risk Findings
{For each: ID, pillar, title, description, evidence (file:line), impact assessment, recommendation, effort, AWS services. This section EXPANDS on rows in the Full BP Ledger — it does NOT replace them.}

## Medium Risk Findings
{Same format, condensed. Also references ledger rows.}

## Low Risk Findings
{Summary table: ID | Pillar | Title | Recommendation. Also references ledger rows.}

## Cross-Pillar Trade-offs
{Conflicts between pillars and recommended resolution}

## Prioritize Improvements — Eisenhower Matrix

Not all findings should be addressed at once. Focus on a selected number of issues that make the most business impact and are easiest to implement. Then iterate.

Classify each finding by **importance** (business value) and **effort** (time, complexity, headcount):

        HIGH IMPORTANCE
             │
   ┌─────────┼─────────┐
   │  DO     │  PLAN   │
   │  FIRST  │         │
   │         │         │
───┼─────────┼─────────┼───
   │         │         │
   │DELEGATE │  DEFER  │
   │         │         │
   └─────────┼─────────┘
             │
        LOW IMPORTANCE
   LOW EFFORT    HIGH EFFORT

| Quadrant | Action | Findings |
|----------|--------|----------|
| **Do First** (High Importance, Low Effort) | Implement immediately | {finding IDs} |
| **Plan** (High Importance, High Effort) | Schedule in roadmap, break into phases | {finding IDs} |
| **Delegate** (Low Importance, Low Effort) | Batch together, assign to available team member | {finding IDs} |
| **Defer** (Low Importance, High Effort) | Revisit in next iteration | {finding IDs} |

### Solution Characteristics

For each solution in "Do First" and "Plan":
- **SMART goal**: Specific, Measurable, Achievable, Relevant, Time-bound
- **Owner**: Identify who is responsible
- **Simple over complex**: Choose the simplest solution unless complexity is a non-negotiable requirement
- **Two-way door decisions**: Solutions should be extensible and evolve over time — avoid static solutions that cannot adapt
- **Pattern-based**: Target solutions that can be codified, reused, and re-shared (reference AWS Architecture Center)

## Prioritized Remediation Plan

### Quick Wins (< 1 week) — "Do First" quadrant
| Finding | Action | SMART Goal | Owner Suggestion | Effort |
|---------|--------|-----------|-----------------|--------|
{Config changes, enabling features, adding tags/alarms — simple, high-impact}

### Foundation (1-4 weeks) — "Plan" quadrant
| Finding | Action | Phases | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Multi-AZ, CI/CD improvements, monitoring, caching — phased approach}

### Strategic (1-3 months) — "Plan" quadrant (complex)
| Finding | Action | Phases | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{DR, re-architecture, compliance programs — two-way door design}

### Delegate (batch & assign) — "Delegate" quadrant
| Finding | Action | Owner Suggestion | Effort |
|---------|--------|-----------------|--------|
{Low-importance, low-effort fixes — batch together and assign to an available team member}

### Deferred — Revisit Next Iteration
{Findings in the "Defer" quadrant with brief justification for deferral}

## Next Steps
{Top 5 concrete actions from the "Do First" quadrant — the team should start this week}

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

AWS

Publisher

AWS (Official)

Source

aws/agent-toolkit-for-aws · skills/core-skills/aws-well-architected-review · commit 0a218f8

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
NOTICE (added by AutoGineer from NOTICE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

Also distributed in

aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-well-architected-review.zip