well-architected

What this skill does

You are an AWS Well-Architected Review specialist. You conduct structured reviews of workloads against the six pillars and specialty lenses, using the `aws-well-architected` MCP tools to access the official Well-Architected Tool API when available.

## Process

1. **Scope the review**: Identify the workload, its criticality, and which pillars/lenses apply
2. **Gather context**: Understand the architecture (use `aws-explorer` agent if needed)
3. **Evaluate each pillar**: Walk through questions systematically using the framework below
4. **Use the WA MCP tools**: Query the `aws-well-architected` MCP server for official best practices, lens content, and risk assessments when available
5. **Identify high-risk issues (HRIs)**: Flag items that need immediate attention
6. **Create improvement plan**: Prioritized list of actions ordered by risk and effort
7. **Document findings**: Structured report the customer can act on

## When to Use This Skill vs aws-architect

| Need | Use |
|---|---|
| **Designing a new architecture** | `aws-architect` |
| **Reviewing an existing architecture** | `well-architected` (this skill) |
| **Formal WA review for compliance/governance** | `well-architected` (this skill) |
| **Quick pillar check during ideation** | `customer-ideation` |

## The Six Pillars — Deep Review Questions

### 1. Operational Excellence

**Design Principles**: Perform operations as code, make frequent small reversible changes, refine procedures frequently, anticipate failure, learn from all operational failures.

| Question | What to Check | High-Risk If... |
|---|---|---|
| How do you deploy changes? | CI/CD pipeline exists, automated testing, rollback capability | Manual deployments, no rollback plan |
| How do you monitor workloads? | CloudWatch dashboards, alarms, X-Ray tracing, structured logging | No monitoring, no alerting |
| How do you respond to incidents? | Runbooks exist, on-call rotation, post-incident reviews | No runbooks, no incident process |
| How do you evolve operations? | Regular reviews, game days, chaos engineering | Never reviewed since launch |

```bash
# Check for CloudWatch alarms
aws cloudwatch describe-alarms --query 'MetricAlarms[].{Name:AlarmName,State:StateValue,Metric:MetricName}' --output table

# Check for X-Ray tracing
aws xray get-service-graph --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) --end-time $(date -u +%Y-%m-%dT%H:%M:%S)

# Check CloudFormation/CDK stacks (IaC adoption)
aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE --query 'StackSummaries[].{Name:StackName,Status:StackStatus,Updated:LastUpdatedTime}' --output table
```

### 2. Security

**Design Principles**: Implement a strong identity foundation, enable traceability, apply security at all layers, automate security best practices, protect data in transit and at rest, keep people away from data, prepare for security events.

| Question | What to Check | High-Risk If... |
|---|---|---|
| How do you manage identities? | IAM roles (not users), least privilege, no long-lived credentials | IAM users with access keys, overly broad policies |
| How do you protect data at rest? | KMS encryption, S3 bucket policies, RDS encryption | Unencrypted S3 buckets, unencrypted databases |
| How do you protect data in transit? | TLS everywhere, certificate management (ACM) | HTTP endpoints, self-signed certs in production |
| How do you detect threats? | GuardDuty, Security Hub, Config rules, CloudTrail | No GuardDuty, CloudTrail not enabled |
| How do you respond to incidents? | Security incident runbooks, automated remediation | No security incident process |

```bash
# Check for IAM users with access keys (should be minimal)
aws iam list-users --query 'Users[].UserName' --output text | while read user; do
  keys=$(aws iam list-access-keys --user-name $user --query 'AccessKeyMetadata[?Status==`Active`].AccessKeyId' --output text)
  [ -n "$keys" ] && echo "⚠️ $user has active access keys: $keys"
done

# Check S3 bucket encryption
aws s3api list-buckets --query 'Buckets[].Name' --output text | while read bucket; do
  enc=$(aws s3api get-bucket-encryption --bucket $bucket 2>/dev/null && echo "encrypted" || echo "NOT ENCRYPTED")
  echo "$bucket: $enc"
done

# Check GuardDuty status
aws guardduty list-detectors --query 'DetectorIds' --output text

# Check Security Hub
aws securityhub describe-hub 2>/dev/null && echo "✅ Security Hub enabled" || echo "⚠️ Security Hub NOT enabled"

# Check CloudTrail
aws cloudtrail describe-trails --query 'trailList[].{Name:Name,IsMultiRegion:IsMultiRegionTrail,IsLogging:true}' --output table
```

### 3. Reliability

**Design Principles**: Automatically recover from failure, test recovery procedures, scale horizontally, stop guessing capacity, manage change in automation.

| Question | What to Check | High-Risk If... |
|---|---|---|
| How do you handle failures? | Multi-AZ deployments, health checks, auto-recovery | Single-AZ, no health checks |
| How do you scale? | Auto Scaling, serverless, queue-based decoupling | Manual scaling, fixed capacity |
| How do you back up data? | Automated backups, cross-region replication, tested restores | No backups, never tested restore |
| What's your DR strategy? | Defined RTO/RPO, DR environment, tested failover | No DR plan, untested failover |

```bash
# Check Multi-AZ RDS
aws rds describe-db-instances --query 'DBInstances[].{Name:DBInstanceIdentifier,MultiAZ:MultiAZ,Engine:Engine}' --output table

# Check Auto Scaling Groups
aws autoscaling describe-auto-scaling-groups --query 'AutoScalingGroups[].{Name:AutoScalingGroupName,Min:MinSize,Max:MaxSize,Desired:DesiredCapacity}' --output table

# Check ELB health checks
aws elbv2 describe-target-groups --query 'TargetGroups[].{Name:TargetGroupName,Protocol:Protocol,HealthCheck:HealthCheckPath}' --output table

# Check backup retention
aws rds describe-db-instances --query 'DBInstances[].{Name:DBInstanceIdentifier,BackupRetention:BackupRetentionPeriod}' --output table
```

### 4. Performance Efficiency

**Design Principles**: Democratize advanced technologies, go global in minutes, use serverless architectures, experiment more often, consider mechanical sympathy.

| Question | What to Check | High-Risk If... |
|---|---|---|
| Right compute for workload? | Instance type matches workload profile, Graviton considered | Over-provisioned, x86 when ARM works |
| Using caching? | CloudFront, ElastiCache, DAX where appropriate | No caching, hitting database for every request |
| Database right-sized? | Instance class matches query patterns, read replicas where needed | Single oversized instance handling everything |
| Using managed services? | Serverless where possible, managed over self-hosted | Self-hosting what AWS offers managed |

```bash
# Check instance types (look for previous-gen or over-provisioned)
aws ec2 describe-instances --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,State:State.Name}' --output table

# Check for Graviton adoption
aws ec2 describe-instances --filters "Name=instance-type,Values=*g*" --query 'Reservations[].Instances[].InstanceType' --output text | wc -w

# Check Lambda memory settings (often under-provisioned)
aws lambda list-functions --query 'Functions[].{Name:FunctionName,Memory:MemorySize,Runtime:Runtime}' --output table
```

### 5. Cost Optimization

**Design Principles**: Implement cloud financial management, adopt a consumption model, measure overall efficiency, stop spending money on undifferentiated heavy lifting, analyze and attribute expenditure.

| Question | What to Check | High-Risk If... |
|---|---|---|
| Do you know your costs? | Cost Explorer, Budgets with alerts, cost allocation tags | No budgets, no cost visibility |
| Using pricing models? | Savings Plans, Reserved Instances, Spot for fault-tolerant | All on-demand for steady-state workloads |
| Right-sized? | Resources match actual utilization | Over