aws-well-architected-review
starsforks
How to install aws-well-architected-review?
github/awesome-copilot/aws-well-architected-review
$npx -y skills add github/awesome-copilot --skill aws-well-architected-reviewPerform an AWS Well-Architected Framework review of the current workload IaC and architecture, generating findings and GitHub issues for improvements.
SKILL.md
| 1 | # AWS Well-Architected Review |
| 2 | |
| 3 | This workflow performs a structured AWS Well-Architected Framework (WAF) review against your workload's IaC files and deployed infrastructure. It identifies risks across all 6 WAF pillars and creates GitHub issues to track remediation. |
| 4 | |
| 5 | ## Prerequisites |
| 6 | - AWS CLI configured and authenticated |
| 7 | - IaC files present in the repository (Terraform, CloudFormation, CDK, or SAM) |
| 8 | - GitHub MCP server configured and authenticated |
| 9 | |
| 10 | ## Workflow Steps |
| 11 | |
| 12 | ### Step 1: Load Well-Architected Framework Reference |
| 13 | Fetch current AWS WAF best practices: |
| 14 | - `https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html` |
| 15 | - Pillar-specific lenses relevant to the workload type (Serverless, SaaS, etc.) |
| 16 | |
| 17 | ### Step 2: Discover IaC & Architecture |
| 18 | Scan the repository for IaC files: |
| 19 | - Terraform: `**/*.tf` |
| 20 | - CloudFormation/SAM: `**/*.yaml`, `**/*.json` (CFn templates) |
| 21 | - CDK: `lib/**/*.ts`, `bin/**/*.ts`, `cdk.json` |
| 22 | |
| 23 | Identify key AWS services in use (compute, data, networking, security, observability) and generate a Mermaid architecture diagram. |
| 24 | |
| 25 | ### Step 3: Pillar-by-Pillar Review |
| 26 | |
| 27 | #### Pillar 1: Operational Excellence |
| 28 | - [ ] All infrastructure defined as IaC (no manual console changes) |
| 29 | - [ ] Consistent tagging strategy applied across all resources |
| 30 | - [ ] CloudWatch alarms defined for key metrics |
| 31 | - [ ] Automated deployment pipeline present (no manual deployments) |
| 32 | - [ ] CloudTrail enabled for audit logging |
| 33 | - [ ] Runbooks or operational documentation present |
| 34 | |
| 35 | #### Pillar 2: Security |
| 36 | - [ ] IAM roles use least-privilege policies (no `*` actions without justification) |
| 37 | - [ ] No hardcoded credentials in IaC or code |
| 38 | - [ ] Secrets managed via Secrets Manager or SSM Parameter Store |
| 39 | - [ ] S3 buckets have public access blocked and server-side encryption enabled |
| 40 | - [ ] Sensitive resources placed in private subnets |
| 41 | - [ ] Security groups restrict inbound to minimum required ports/CIDRs |
| 42 | - [ ] KMS encryption enabled for sensitive data stores (RDS, EBS, S3, SQS, DynamoDB) |
| 43 | - [ ] SSL/TLS enforced on all endpoints (`enforceSSL: true`) |
| 44 | - [ ] GuardDuty enabled (`aws guardduty list-detectors`) |
| 45 | - [ ] AWS WAF configured on public-facing APIs and CloudFront distributions |
| 46 | - [ ] MFA delete enabled on critical S3 buckets |
| 47 | |
| 48 | #### Pillar 3: Reliability |
| 49 | - [ ] Multi-AZ deployments for production databases (RDS Multi-AZ, DynamoDB Global Tables) |
| 50 | - [ ] Auto Scaling configured with appropriate policies for EC2/ECS |
| 51 | - [ ] S3 versioning and lifecycle policies configured |
| 52 | - [ ] RDS automated backups enabled with appropriate retention period |
| 53 | - [ ] DynamoDB Point-in-Time Recovery (PITR) enabled |
| 54 | - [ ] Dead Letter Queues (DLQ) configured for Lambda, SQS, SNS |
| 55 | - [ ] Route 53 health checks configured for DNS failover |
| 56 | - [ ] Lambda reserved concurrency set to prevent noisy-neighbor throttling |
| 57 | |
| 58 | #### Pillar 4: Performance Efficiency |
| 59 | - [ ] Right-sized instance types (Lambda memory, EC2 type, RDS class) |
| 60 | - [ ] Graviton/ARM instances used where available (Lambda `arm64`, EC2 Graviton) |
| 61 | - [ ] Caching implemented (ElastiCache, DAX, CloudFront, API Gateway caching) |
| 62 | - [ ] CloudFront used for global static content delivery |
| 63 | - [ ] Aurora Serverless or DynamoDB On-Demand for variable load patterns |
| 64 | - [ ] Lambda Provisioned Concurrency for latency-critical synchronous paths |
| 65 | |
| 66 | #### Pillar 5: Cost Optimization |
| 67 | - [ ] EC2 Reserved Instances or Savings Plans for steady-state workloads |
| 68 | - [ ] S3 lifecycle policies moving data to cheaper storage tiers |
| 69 | - [ ] Lambda `arm64` architecture adopted (20% cost reduction) |
| 70 | - [ ] VPC Endpoints for S3/DynamoDB to avoid NAT Gateway charges |
| 71 | - [ ] gp2 EBS volumes migrated to gp3 (same performance, 20% cheaper) |
| 72 | - [ ] Development/test environments have auto-shutdown schedules |
| 73 | - [ ] AWS Budgets and Cost Anomaly Detection configured |
| 74 | - [ ] Unattached EBS volumes and idle EC2 instances identified |
| 75 | |
| 76 | #### Pillar 6: Sustainability |
| 77 | - [ ] Graviton/ARM instances selected where available |
| 78 | - [ ] Serverless/managed services preferred over always-on EC2 |
| 79 | - [ ] S3 lifecycle policies reduce unnecessary long-term data storage |
| 80 | - [ ] Auto Scaling configured to avoid over-provisioning |
| 81 | - [ ] Region selection considers AWS renewable energy commitments |
| 82 | |
| 83 | ### Step 4: Risk Classification |
| 84 | For each finding, classify: |
| 85 | - **High Risk**: Security vulnerability, single point of failure, no backup/recovery |
| 86 | - **Medium Risk**: Suboptimal reliability, cost inefficiency, performance concern |
| 87 | - **Low Risk**: Best practice deviation, minor optimization opportunity |
| 88 | |
| 89 | ### Step 5: User Confirmation |
| 90 | |
| 91 | ``` |
| 92 | 🏗️ AWS Well-Architected Review Summary |
| 93 | |
| 94 | 📊 Review Results: |
| 95 | • IaC Files Analyzed: X |
| 96 | • AWS Services Identified: Y |
| 97 | • Total Findings: Z |
| 98 | • High Risk: A (immediate action required) |
| 99 | • Medium Risk: B (should address soon) |
| 100 | • Low Risk: C (nice to have) |
| 101 | |
| 102 | 🔴 Top High Risk Findings: |
| 103 | 1. [Pillar]: [Find |
People who liked this also viewed
6 picksType
- microsoft-foundryDeploy, evaluate, fine-tune, and manage Foundry agents end-to-end with azd: hosted agent scaffold/run/deploy, prompt agent create, batch eval, continuous eval, prompt optimizer, Agent Optimizer scaffoSkillsJul 2026
- azure-deployExecute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application SkillsJul 2026
- azure-preparePrepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wSkillsJul 2026
- azure-validate--- name: azure-validate description: "Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity pSkillsJul 2026
- azure-aigatewayConfigure Azure API Management as an AI Gateway for AI models, MCP tools, and agents. WHEN: semantic caching, token limit, content safety, load balancing, AI model governance, MCP rate limiting, jailbSkillsJul 2026
- azure-hosted-copilot-sdkOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026
