AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Aws Well Architected Review

skill-github-awesome-copilot-aws-well-architected-review · by github

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

No reviews yet
0 installs
49 views
0.0% view→install

Install

$ agentstack add skill-github-awesome-copilot-aws-well-architected-review

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-github-awesome-copilot-aws-well-architected-review)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Aws Well Architected Review? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

AWS Well-Architected Review

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
  • [ ] All infrastructure defined as IaC (no manual console changes)
  • [ ] Consistent tagging strategy applied across all resources
  • [ ] CloudWatch alarms defined for key metrics
  • [ ] Automated deployment pipeline present (no manual deployments)
  • [ ] CloudTrail enabled for audit logging
  • [ ] Runbooks or operational documentation present
Pillar 2: Security
  • [ ] IAM roles use least-privilege policies (no * actions without justification)
  • [ ] No hardcoded credentials in IaC or code
  • [ ] Secrets managed via Secrets Manager or SSM Parameter Store
  • [ ] S3 buckets have public access blocked and server-side encryption enabled
  • [ ] Sensitive resources placed in private subnets
  • [ ] Security groups restrict inbound to minimum required ports/CIDRs
  • [ ] KMS encryption enabled for sensitive data stores (RDS, EBS, S3, SQS, DynamoDB)
  • [ ] SSL/TLS enforced on all endpoints (enforceSSL: true)
  • [ ] GuardDuty enabled (aws guardduty list-detectors)
  • [ ] AWS WAF configured on public-facing APIs and CloudFront distributions
  • [ ] MFA delete enabled on critical S3 buckets
Pillar 3: Reliability
  • [ ] Multi-AZ deployments for production databases (RDS Multi-AZ, DynamoDB Global Tables)
  • [ ] Auto Scaling configured with appropriate policies for EC2/ECS
  • [ ] S3 versioning and lifecycle policies configured
  • [ ] RDS automated backups enabled with appropriate retention period
  • [ ] DynamoDB Point-in-Time Recovery (PITR) enabled
  • [ ] Dead Letter Queues (DLQ) configured for Lambda, SQS, SNS
  • [ ] Route 53 health checks configured for DNS failover
  • [ ] Lambda reserved concurrency set to prevent noisy-neighbor throttling
Pillar 4: Performance Efficiency
  • [ ] Right-sized instance types (Lambda memory, EC2 type, RDS class)
  • [ ] Graviton/ARM instances used where available (Lambda arm64, EC2 Graviton)
  • [ ] Caching implemented (ElastiCache, DAX, CloudFront, API Gateway caching)
  • [ ] CloudFront used for global static content delivery
  • [ ] Aurora Serverless or DynamoDB On-Demand for variable load patterns
  • [ ] Lambda Provisioned Concurrency for latency-critical synchronous paths
Pillar 5: Cost Optimization
  • [ ] EC2 Reserved Instances or Savings Plans for steady-state workloads
  • [ ] S3 lifecycle policies moving data to cheaper storage tiers
  • [ ] Lambda arm64 architecture adopted (20% cost reduction)
  • [ ] VPC Endpoints for S3/DynamoDB to avoid NAT Gateway charges
  • [ ] gp2 EBS volumes migrated to gp3 (same performance, 20% cheaper)
  • [ ] Development/test environments have auto-shutdown schedules
  • [ ] AWS Budgets and Cost Anomaly Detection configured
  • [ ] Unattached EBS volumes and idle EC2 instances identified
Pillar 6: Sustainability
  • [ ] Graviton/ARM instances selected where available
  • [ ] Serverless/managed services preferred over always-on EC2
  • [ ] S3 lifecycle policies reduce unnecessary long-term data storage
  • [ ] Auto Scaling configured to avoid over-provisioning
  • [ ] 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-] [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:

aws s3api put-bucket-encryption --bucket  \
  --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

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [github](https://github.com/github)
- **Source:** [github/awesome-copilot](https://github.com/github/awesome-copilot)
- **License:** MIT
- **Homepage:** https://awesome-copilot.github.com/

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.