aws-well-architected-review

AWS Well-Architected レビュー

このワークフローでは、ワークロードの IaC ファイルとデプロイ済みインフラストラクチャを対象に、AWS Well-Architected Framework（WAF）に基づく体系的なレビューを実施します。WAF の 6 つの柱すべてにわたってリスクを特定し、是正措置を追跡するための GitHub issue を作成します。

前提条件

• AWS CLI が設定され、認証済みであること
• リポジトリに IaC ファイルがあること（Terraform、CloudFormation、CDK、または SAM）
• GitHub MCP サーバーが設定され、認証済みであること

ワークフローの手順

ステップ 1：Well-Architected Framework のリファレンスを読み込む

最新の AWS WAF のベストプラクティスを取得します。

• https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
• ワークロードの種類に関連する柱固有のレンズ（Serverless、SaaS など）

ステップ 2：IaC とアーキテクチャを検出する

リポジトリをスキャンして IaC ファイルを探します。

• Terraform：**/*.tf
• CloudFormation/SAM：**/*.yaml、**/*.json（CFn テンプレート）
• CDK：lib/**/*.ts、bin/**/*.ts、cdk.json

使用中の主要な AWS サービス（コンピューティング、データ、ネットワーク、セキュリティ、可観測性）を特定し、Mermaid のアーキテクチャ図を生成します。

ステップ 3：柱ごとのレビュー

柱 1：オペレーショナルエクセレンス

• すべてのインフラストラクチャが IaC で定義されている（コンソールからの手動変更がない）
• すべてのリソースに一貫したタグ付け戦略が適用されている
• 主要なメトリクスに対する CloudWatch アラームが定義されている
• 自動デプロイパイプラインがある（手動デプロイがない）
• 監査ログ用に CloudTrail が有効になっている
• ランブックまたは運用ドキュメントがある

柱 2：セキュリティ

• IAM ロールに最小権限のポリシーが使用されている（正当な理由なく * アクションを使用していない）
• IaC またはコードにハードコードされた認証情報がない
• Secrets Manager または SSM Parameter Store でシークレットを管理している
• S3 バケットでパブリックアクセスがブロックされ、サーバー側の暗号化が有効になっている
• 機密性の高いリソースがプライベートサブネットに配置されている
• セキュリティグループでインバウンド通信を必要最小限のポート／CIDR に制限している
• 機密データストア（RDS、EBS、S3、SQS、DynamoDB）で KMS 暗号化が有効になっている
• すべてのエンドポイントで SSL/TLS が強制されている（enforceSSL: true）
• GuardDuty が有効になっている（aws guardduty list-detectors）
• インターネットに公開される API と CloudFront ディストリビューションで AWS WAF が設定されている
• 重要な S3 バケットで MFA Delete が有効になっている

柱 3：信頼性

• 本番データベースがマルチ AZ でデプロイされている（RDS Multi-AZ、DynamoDB Global Tables）
• EC2/ECS に適切なポリシーで Auto Scaling が設定されている
• S3 のバージョニングとライフサイクルポリシーが設定されている
• 適切な保持期間で RDS の自動バックアップが有効になっている
• DynamoDB の Point-in-Time Recovery（PITR）が有効になっている
• Lambda、SQS、SNS に Dead Letter Queue（DLQ）が設定されている
• DNS フェイルオーバー用に Route 53 ヘルスチェックが設定されている
• ノイジーネイバーによるスロットリングを防ぐため、Lambda の予約済み同時実行数が設定されている

柱 4：パフォーマンス効率

• インスタンスタイプのサイズが適切である（Lambda メモリ、EC2 タイプ、RDS クラス）
• 利用可能な場合に Graviton/ARM インスタンスを使用している（Lambda の arm64、EC2 Graviton）
• キャッシュを実装している（ElastiCache、DAX、CloudFront、API Gateway キャッシュ）
• グローバルな静的コンテンツ配信に CloudFront を使用している
• 負荷変動がある場合に Aurora Serverless または DynamoDB On-Demand を使用している
• レイテンシが重要な同期パスで Lambda Provisioned Concurrency を使用している

柱 5：コスト最適化

• 定常的なワークロードで EC2 Reserved Instances または Savings Plans を利用している
• S3 のライフサイクルポリシーでデータをより安価なストレージ階層に移行している
• Lambda の arm64 アーキテクチャを採用している（コストを 20% 削減）
• NAT Gateway の料金を避けるため、S3/DynamoDB 用の VPC Endpoints を使用している
• gp2 EBS ボリュームを gp3 に移行している（同等のパフォーマンスで 20% 安価）
• 開発／テスト環境に自動停止スケジュールが設定されている
• AWS Budgets と Cost Anomaly Detection が設定されている
• 未接続の EBS ボリュームとアイドル状態の EC2 インスタンスを特定している

Pillar 6：持続可能性

• 利用可能な場合は Graviton／ARM インスタンスを選択する
• 常時稼働の EC2 より、サーバーレス／マネージドサービスを優先する
• S3 ライフサイクルポリシーにより、不要な長期データ保存を削減する
• 過剰なプロビジョニングを避けるように Auto Scaling を設定する
• リージョンの選択時に、AWS の再生可能エネルギーへの取り組みを考慮する

Step 4：リスク分類

各検出事項を次のように分類します。

• 高リスク：セキュリティの脆弱性、単一障害点、バックアップ／復旧手段がない
• 中リスク：信頼性が最適でない、コスト効率が悪い、パフォーマンスに懸念がある
• 低リスク：ベストプラクティスからの逸脱、軽微な最適化の機会

Step 5：ユーザー確認

🏗️ 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：個別の検出事項イシューを作成

「well-architected」と Pillar 名（例：「security」、「reliability」）のラベルを付けます。

タイトル：[WAF-<PILLAR>] [Brief Finding] — [Risk Level]

本文：

## 🏗️ 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：EPIC トラッキングイシューを作成

「well-architected」と「epic」のラベルを付けます。

タイトル：[EPIC] AWS Well-Architected Review — X findings across 6 pillars

本文：Pillar ごとの内訳表（Pillar とリスクレベル別の検出件数）、Mermaid アーキテクチャ図、個別の全イシューにリンクした優先順位付きチェックリスト（高 → 中 → 低）、および成功基準を含むエグゼクティブサマリー：

• 高リスクの検出事項がすべて解決されている
• 中リスクの検出事項に、承認済みの緩和計画がある
• 既存の CloudWatch アラームや Config ルールに回帰がない

エラー処理

• IaC ファイルが見つからない：AWS CLI による稼働中リソースの検出にレビューを限定し、その制約を明記する
• AWS の権限が不足している：レビューに必要な読み取り専用権限を列挙する
• GitHub イシューの作成に失敗：すべての検出事項を整形済み Markdown としてコンソールに出力する

成功基準

• ✅ IaC と稼働中のインフラストラクチャを対象に、6 つすべての WAF Pillar をレビューしている
• ✅ すべての検出事項がリスクレベルと Pillar ごとに分類されている
• ✅ 各検出事項に IaC の例を含む実行可能な修正手順がある
• ✅ チームでの追跡用に GitHub イシューが作成されている
• ✅ EPIC の文脈を示すアーキテクチャ図が生成されている
• ✅ AWS ドキュメントへの参照が含まれている