Skills

Skill 43 of 200

AWS Well Architected Review

Perform an AWS Well-Architected Framework review of the current workload IaC and architecture, generating findings and GitHub issues for improvements.

3 minutes · 750 words · 18 sections

Install

$ npx skills add github/awesome-copilot --skill aws-well-architected-review

$ npx skills add github/awesome-copilot

» /plugin marketplace add github/awesome-copilot

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

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.

Prerequisites

AWS CLI configured and authenticated
IaC files present in the repository (Terraform, CloudFormation, CDK, or SAM)
GitHub MCP server configured and authenticated

Workflow Steps

Step 1: Load Well-Architected Framework Reference

Fetch current AWS WAF best practices:

https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
Pillar-specific lenses relevant to the workload type (Serverless, SaaS, etc.)

Step 2: Discover IaC & Architecture

Scan the repository for IaC files:

Terraform: **/*.tf
CloudFormation/SAM: **/*.yaml, **/*.json (CFn templates)
CDK: lib/**/*.ts, bin/**/*.ts, cdk.json

Identify key AWS services in use (compute, data, networking, security, observability) and generate a Mermaid architecture diagram.

Step 3: Pillar-by-Pillar Review

Pillar 1: Operational Excellence

Not done: All infrastructure defined as IaC (no manual console changes)
Not done: Consistent tagging strategy applied across all resources
Not done: CloudWatch alarms defined for key metrics
Not done: Automated deployment pipeline present (no manual deployments)
Not done: CloudTrail enabled for audit logging
Not done: Runbooks or operational documentation present

Pillar 2: Security

Not done: IAM roles use least-privilege policies (no * actions without justification)
Not done: No hardcoded credentials in IaC or code
Not done: Secrets managed via Secrets Manager or SSM Parameter Store
Not done: S3 buckets have public access blocked and server-side encryption enabled
Not done: Sensitive resources placed in private subnets
Not done: Security groups restrict inbound to minimum required ports/CIDRs
Not done: KMS encryption enabled for sensitive data stores (RDS, EBS, S3, SQS, DynamoDB)
Not done: SSL/TLS enforced on all endpoints (enforceSSL: true)
Not done: GuardDuty enabled (aws guardduty list-detectors)
Not done: AWS WAF configured on public-facing APIs and CloudFront distributions
Not done: MFA delete enabled on critical S3 buckets

Pillar 3: Reliability

Not done: Multi-AZ deployments for production databases (RDS Multi-AZ, DynamoDB Global Tables)
Not done: Auto Scaling configured with appropriate policies for EC2/ECS
Not done: S3 versioning and lifecycle policies configured
Not done: RDS automated backups enabled with appropriate retention period
Not done: DynamoDB Point-in-Time Recovery (PITR) enabled
Not done: Dead Letter Queues (DLQ) configured for Lambda, SQS, SNS
Not done: Route 53 health checks configured for DNS failover
Not done: Lambda reserved concurrency set to prevent noisy-neighbor throttling

Pillar 4: Performance Efficiency

Not done: Right-sized instance types (Lambda memory, EC2 type, RDS class)
Not done: Graviton/ARM instances used where available (Lambda arm64, EC2 Graviton)
Not done: Caching implemented (ElastiCache, DAX, CloudFront, API Gateway caching)
Not done: CloudFront used for global static content delivery
Not done: Aurora Serverless or DynamoDB On-Demand for variable load patterns
Not done: Lambda Provisioned Concurrency for latency-critical synchronous paths

Pillar 5: Cost Optimization

Not done: EC2 Reserved Instances or Savings Plans for steady-state workloads
Not done: S3 lifecycle policies moving data to cheaper storage tiers
Not done: Lambda arm64 architecture adopted (20% cost reduction)
Not done: VPC Endpoints for S3/DynamoDB to avoid NAT Gateway charges
Not done: gp2 EBS volumes migrated to gp3 (same performance, 20% cheaper)
Not done: Development/test environments have auto-shutdown schedules
Not done: AWS Budgets and Cost Anomaly Detection configured
Not done: Unattached EBS volumes and idle EC2 instances identified

Pillar 6: Sustainability

Not done: Graviton/ARM instances selected where available
Not done: Serverless/managed services preferred over always-on EC2
Not done: S3 lifecycle policies reduce unnecessary long-term data storage
Not done: Auto Scaling configured to avoid over-provisioning
Not done: Region selection considers AWS renewable energy commitments

Step 4: Risk Classification

For each finding, classify:

High Risk: Security vulnerability, single point of failure, no backup/recovery
Medium Risk: Suboptimal reliability, cost inefficiency, performance concern
Low Risk: Best practice deviation, minor optimization opportunity

Step 5: User Confirmation

🏗️ AWS Well-Architected Review Summary

📊 Review Results:
• IaC Files Analyzed: X
• AWS Services Identified: Y
• Total Findings: Z
  • High Risk: A (immediate action required)
  • Medium Risk: B (should address soon)
  • Low Risk: C (nice to have)

🔴 Top High Risk Findings:
1. [Pillar]: [Finding] — [Why it matters]
2. [Pillar]: [Finding] — [Why it matters]

💡 This will create Z individual GitHub issues + 1 EPIC issue.

❓ Proceed with creating GitHub issues? (y/n)

Step 6: Create Individual Finding Issues

Label with “well-architected” and the pillar name (e.g., “security”, “reliability”).

Title: [WAF-<PILLAR>] [Brief Finding] — [Risk Level]

Body:

## 🏗️ Well-Architected Finding: [Brief Title]

**Pillar**: [Name] | **Risk Level**: [High/Medium/Low] | **Effort**: [Low/Medium/High]

### 📋 Description
[Clear explanation of the finding and why it matters]

### 🔧 Remediation

**IaC Fix** (preferred):
```hcl
# Terraform example
resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}
```

**AWS CLI fallback**:
```bash
aws s3api put-bucket-encryption --bucket <name> \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'
```

### 📚 AWS Reference
- [WAF Best Practice Link]
- [AWS Documentation Link]

### ✅ Validation
- [ ] Change implemented in IaC and deployed
- [ ] AWS Config rule passes (if applicable)
- [ ] Security Hub finding resolved (if applicable)

**Well-Architected Question**: [WAF question this maps to]

Step 7: Create EPIC Tracking Issue

Label with “well-architected” and “epic”.

Title: [EPIC] AWS Well-Architected Review — X findings across 6 pillars

Body: Executive summary with pillar breakdown table (finding counts by pillar and risk level), Mermaid architecture diagram, prioritized checklist linking all individual issues (High → Medium → Low), and success criteria:

All High-risk findings resolved
Medium findings have accepted mitigation plans
No regression in existing CloudWatch alarms or Config rules

Error Handling

No IaC Files Found: Limit review to live resource discovery via AWS CLI and note the gap
Insufficient AWS Permissions: List required read-only permissions for the review
GitHub Creation Failure: Output all findings as formatted markdown to console

Success Criteria

✅ All 6 WAF pillars reviewed against IaC and live infrastructure
✅ All findings classified by risk level and pillar
✅ Actionable remediation steps with IaC examples for each finding
✅ GitHub issues created for team tracking
✅ Architecture diagram generated for EPIC context
✅ AWS documentation references included

Colophon for this issue

Colophon

How this issue was made

Source

github.com/github/awesome-copilot, branch main, last pushed 24 September 2026.

Licence

MIT — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

200 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 2 distinct layouts observed: .github/skills/*/SKILL.md, skills/*/SKILL.md.

Authorship

3 of 200 skills are installed into the repository rather than published from it. They are shelved in the closing “Credited skills” part and remain the work of their own authors. A skill counts as credited when its only copy lives under one agent’s dot directory; visible directories, per-agent mirror sets, and skills installable from this repository on skills.sh all count as published.

Issue colours

Resolved from a curated brand profile — hue 295°, chroma 0.190. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Removed “AWS Well-Architected Review”, a leading h1 that duplicated the skill title.

Spec compliance

Every skill satisfies the Agent Skills specification’s frontmatter rules.

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Marketplace

A plugin manifest is published at .github/plugin/marketplace.json by GitHub, declaring 162 plugins. It is read for editorial metadata only — never as the skill index, which is always the repository tree.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /github/awesome-copilot.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

Prerequisites

AWS CLI configured and authenticated
IaC files present in the repository (Terraform, CloudFormation, CDK, or SAM)
GitHub MCP server configured and authenticated

Workflow Steps

Step 1: Load Well-Architected Framework Reference

Fetch current AWS WAF best practices:

https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
Pillar-specific lenses relevant to the workload type (Serverless, SaaS, etc.)

Step 2: Discover IaC & Architecture

Scan the repository for IaC files:

Terraform: **/*.tf
CloudFormation/SAM: **/*.yaml, **/*.json (CFn templates)
CDK: lib/**/*.ts, bin/**/*.ts, cdk.json

Identify key AWS services in use (compute, data, networking, security, observability) and generate a Mermaid architecture diagram.

Step 3: Pillar-by-Pillar Review

Pillar 1: Operational Excellence

Not done: All infrastructure defined as IaC (no manual console changes)
Not done: Consistent tagging strategy applied across all resources
Not done: CloudWatch alarms defined for key metrics
Not done: Automated deployment pipeline present (no manual deployments)
Not done: CloudTrail enabled for audit logging
Not done: Runbooks or operational documentation present

Pillar 2: Security

Not done: IAM roles use least-privilege policies (no * actions without justification)
Not done: No hardcoded credentials in IaC or code
Not done: Secrets managed via Secrets Manager or SSM Parameter Store
Not done: S3 buckets have public access blocked and server-side encryption enabled
Not done: Sensitive resources placed in private subnets
Not done: Security groups restrict inbound to minimum required ports/CIDRs
Not done: KMS encryption enabled for sensitive data stores (RDS, EBS, S3, SQS, DynamoDB)
Not done: SSL/TLS enforced on all endpoints (enforceSSL: true)
Not done: GuardDuty enabled (aws guardduty list-detectors)
Not done: AWS WAF configured on public-facing APIs and CloudFront distributions
Not done: MFA delete enabled on critical S3 buckets

Pillar 3: Reliability

Not done: Multi-AZ deployments for production databases (RDS Multi-AZ, DynamoDB Global Tables)
Not done: Auto Scaling configured with appropriate policies for EC2/ECS
Not done: S3 versioning and lifecycle policies configured
Not done: RDS automated backups enabled with appropriate retention period
Not done: DynamoDB Point-in-Time Recovery (PITR) enabled
Not done: Dead Letter Queues (DLQ) configured for Lambda, SQS, SNS
Not done: Route 53 health checks configured for DNS failover
Not done: Lambda reserved concurrency set to prevent noisy-neighbor throttling

Pillar 4: Performance Efficiency

Not done: Right-sized instance types (Lambda memory, EC2 type, RDS class)
Not done: Graviton/ARM instances used where available (Lambda arm64, EC2 Graviton)
Not done: Caching implemented (ElastiCache, DAX, CloudFront, API Gateway caching)
Not done: CloudFront used for global static content delivery
Not done: Aurora Serverless or DynamoDB On-Demand for variable load patterns
Not done: Lambda Provisioned Concurrency for latency-critical synchronous paths

Pillar 5: Cost Optimization

Not done: EC2 Reserved Instances or Savings Plans for steady-state workloads
Not done: S3 lifecycle policies moving data to cheaper storage tiers
Not done: Lambda arm64 architecture adopted (20% cost reduction)
Not done: VPC Endpoints for S3/DynamoDB to avoid NAT Gateway charges
Not done: gp2 EBS volumes migrated to gp3 (same performance, 20% cheaper)
Not done: Development/test environments have auto-shutdown schedules
Not done: AWS Budgets and Cost Anomaly Detection configured
Not done: Unattached EBS volumes and idle EC2 instances identified

Pillar 6: Sustainability

Not done: Graviton/ARM instances selected where available
Not done: Serverless/managed services preferred over always-on EC2
Not done: S3 lifecycle policies reduce unnecessary long-term data storage
Not done: Auto Scaling configured to avoid over-provisioning
Not done: Region selection considers AWS renewable energy commitments

Step 4: Risk Classification

For each finding, classify:

High Risk: Security vulnerability, single point of failure, no backup/recovery
Medium Risk: Suboptimal reliability, cost inefficiency, performance concern
Low Risk: Best practice deviation, minor optimization opportunity

Step 5: User Confirmation

🏗️ AWS Well-Architected Review Summary

📊 Review Results:
• IaC Files Analyzed: X
• AWS Services Identified: Y
• Total Findings: Z
  • High Risk: A (immediate action required)
  • Medium Risk: B (should address soon)
  • Low Risk: C (nice to have)

🔴 Top High Risk Findings:
1. [Pillar]: [Finding] — [Why it matters]
2. [Pillar]: [Finding] — [Why it matters]

💡 This will create Z individual GitHub issues + 1 EPIC issue.

❓ Proceed with creating GitHub issues? (y/n)

Step 6: Create Individual Finding Issues

Label with “well-architected” and the pillar name (e.g., “security”, “reliability”).

Title: [WAF-<PILLAR>] [Brief Finding] — [Risk Level]

Body:

## 🏗️ Well-Architected Finding: [Brief Title]

**Pillar**: [Name] | **Risk Level**: [High/Medium/Low] | **Effort**: [Low/Medium/High]

### 📋 Description
[Clear explanation of the finding and why it matters]

### 🔧 Remediation

**IaC Fix** (preferred):
```hcl
# Terraform example
resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}
```

**AWS CLI fallback**:
```bash
aws s3api put-bucket-encryption --bucket <name> \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'
```

### 📚 AWS Reference
- [WAF Best Practice Link]
- [AWS Documentation Link]

### ✅ Validation
- [ ] Change implemented in IaC and deployed
- [ ] AWS Config rule passes (if applicable)
- [ ] Security Hub finding resolved (if applicable)

**Well-Architected Question**: [WAF question this maps to]

Step 7: Create EPIC Tracking Issue

Label with “well-architected” and “epic”.

Title: [EPIC] AWS Well-Architected Review — X findings across 6 pillars

All High-risk findings resolved
Medium findings have accepted mitigation plans
No regression in existing CloudWatch alarms or Config rules

Error Handling

No IaC Files Found: Limit review to live resource discovery via AWS CLI and note the gap
Insufficient AWS Permissions: List required read-only permissions for the review
GitHub Creation Failure: Output all findings as formatted markdown to console

Success Criteria

✅ All 6 WAF pillars reviewed against IaC and live infrastructure
✅ All findings classified by risk level and pillar
✅ Actionable remediation steps with IaC examples for each finding
✅ GitHub issues created for team tracking
✅ Architecture diagram generated for EPIC context
✅ AWS documentation references included