/aws-well-architected-framework-review

Perform a full AWS Well-Architected Framework review of the user's workload by analyzing code, IaC, and configurations to produce evidence-backed findings with prioritized remediation.

Step 1: Define the workload scope

Ask the user to describe the workload:

> What workload would you like me to review? Please share: > - **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 — anything you already know is problematic)

If the user has already provided architecture details or you are in a codebase with IaC, skip the prompt and proceed with discovery.

**IMPORTANT**: When no code or IaC is available to analyze (e.g., the user describes their architecture verbally), proceed with the review based on the information provided. Produce the full report using the architecture description as evidence. Mark findings where you cannot verify implementation details as "Based on description — verify in code." Do NOT ask for code if the user has already given you enough context to perform a meaningful review.

Determine if a specialized WA Lens applies:

• SaaS, Serverless, Data Analytics, Machine Learning, IoT, Containers, Games, Financial Services, Healthcare

If a lens is obvious from the code (e.g., Lambda-heavy → serverless), note it and apply lens-specific questions.

Step 2: Infrastructure Discovery

Analyze all infrastructure-as-code and deployment configurations in the codebase.

You MUST examine:

• CDK code (TypeScript, Python, Java, Go)
• CloudFormation templates (YAML, JSON)
• Terraform configurations (.tf files)
• SAM/Serverless Framework templates
• CI/CD pipeline definitions (CodePipeline, GitHub Actions, etc.)
• Monitoring configurations (CloudWatch alarms, dashboards)
• Deployment configurations (CodeDeploy, ECS deployment settings)

For each infrastructure component, document:

• Resource type, logical name, and configuration
• File path and line numbers where defined
• Security-relevant configs (IAM, encryption, network)
• Resilience configs (multi-AZ, backups, scaling)
• Cost-relevant configs (instance types, capacity mode)

You MUST create an architecture diagram in PlantUML showing:

• All major components and their relationships
• Data flows and external dependencies
• Trust and network boundaries

Step 3: Application Architecture Discovery

Analyze application code for architectural patterns:

• Entry points (API handlers, event processors, scheduled tasks)
• Service communication patterns (sync/async, retries, timeouts, circuit breakers)
• Data access patterns (queries, caching, connection management)
• Error handling and resilience patterns
• Authentication/authorization logic
• Observability instrumentation (logging, tracing, metrics)

Step 4: Evaluate each pillar with code evidence

For each pillar, assess against the WA Framework questions. Every assessment MUST include:

• **Status**: "Implemented", "Partially Implemented", "Not Implemented", "Cannot Determine"
• **Evidence**: specific file paths and line numbers
• **Gaps**: what's missing or could be improved
• **Risk**: what could go wrong due to the gap

Operational Excellence

• **OPS 4 — Observability**: Look for structured logging, distributed tracing, custom metrics. Evidence: log statements, X-Ray/OTEL instrumentation.
• **OPS 5 — Reduce defects**: Look for automated testing, linting, staged deployments. Evidence: test files, CI/CD configs.
• **OPS 6 — Deployment risk**: Look for canary/blue-green, feature flags, rollback automation. Evidence: deployment config, CodeDeploy settings.
• **OPS 8 — Workload health**: Look for health dashboards, composite alarms. Evidence: alarm definitions, health checks.
• **OPS 10 — Event management**: Look for event routing, automated remediation. Evidence: EventBridge rules, Lambda remediations.

Security

• **SEC 3 — Permissions**: Look for least privilege, permission boundaries. Flag any `"Action": "*"` or `"Resource": "*"` on mutating actions.
• **SEC 5 — Network protection**: Look for VPC design, security groups, WAF, VPC endpoints. Flag `0.0.0.0/0` on non-443/80 ports.
• **SEC 8 — Data at rest**: Look for encryption on ALL stores. Flag any storage resource without encryption.
• **SEC 9 — Data in transit**: Look for TLS enforcement. Flag TLS < 1.2.
• **SEC 2/3 — Identity**: Look for IAM roles, trust relationships, credential management. Flag hardcoded secrets.

Reliability

• **REL 2 — Network topology**: Look for multi-AZ deployment, subnet distribution.
• **REL 3 — Demand adaptation**: Look for auto-scaling, capacity modes. Flag compute without scaling.
• **REL 4 — Distributed system interactions**: Look for retries with backoff, timeouts, idempotency.
• **REL 9 — Data backup**: Look for automated backups, PITR. Flag stateful resources without backups.
• **REL 11 — Component failures**: Look for redundancy, failover, health-based routing.
• **REL 13 — Disaster recovery**: Look for cross-region resources, DR automation.

Performance Efficiency

• **PERF 1 — Resource selection**: Look for instance type justification, Graviton usage.
• **PERF 2 — Compute solution**: Look for right-sizing, memory/CPU alignment.
• **PERF 4 — Database solution**: Look for read replicas, connection pooling (RDS Proxy, DAX).
• **PERF 5 — Networking**: Look for CloudFront, VPC endpoints, edge caching.
• **PERF 8 — Tradeoffs**: Look for caching, async patterns, eventual consistency.

Cost Optimization

• **COST 4 — Decommission resources**: Look for lifecycle policies, retention configs. Flag "never expire" logs.
• **COST 5 — Service selection**: Look for pricing model alignment. Flag over-provisioned resources.
• **COST 6 — Right-sizing**: Look for scaling boundaries, capacity allocation.
• **COST 8 — Data transfer**: Look for VPC endpoints vs NAT Gateway, cross-region patterns.

Sustainability

• **SUS 2 — User