目次

AWS Well-Architectedチェックリスト

周辺資料: 学習インデックス · AWSサービス一覧（2026） · アーキテクチャパターン集 · セキュリティ設計ハンドブック

Well-Architected Framework 6本柱を設計レビュー・本番リリース前チェックで使えるチェック項目に展開。

使い方

タイミング 確認範囲
設計初期（PoC・設計書レビュー） ★★★ のみ（必須項目）
本番リリース前 ★★☆ 以上（重要項目）
四半期レビュー 全項目（実運用との乖離チェック）

凡例: ★★★ 必須 / ★★☆ 重要 / ★☆☆ 推奨

1. 運用上の優秀性（Operational Excellence）

IaC・変更管理

  • [ ] ★★★ インフラが CloudFormation / CDK / Terraform で管理され、手動変更が最小化されている
  • [ ] ★★★ 本番環境への変更は CI/CD パイプラインを経由し、直接変更は禁止されている
  • [ ] ★★☆ IaC コードがバージョン管理（Git）され、PR レビューを経ている
  • [ ] ★★☆ CloudFormation StackSets または CDK で環境間の差異が管理されている
  • [ ] ★☆☆ AWS Config の Drift Detection でインフラと IaC の乖離を検出している

運用手順・ランブック

  • [ ] ★★★ 障害時の初動対応（Runbook）が文書化され、最新状態に維持されている
  • [ ] ★★☆ オンコールのエスカレーションパスが明確に定義されている
  • [ ] ★★☆ Systems Manager Automation で定型運用タスクが自動化されている
  • [ ] ★☆☆ ゲームデイ（障害訓練）を四半期ごとに実施している
  • [ ] ★☆☆ AWS FIS（Fault Injection Simulator）でカオスエンジニアリングを実施している

変更管理

  • [ ] ★★★ Blue/Green または Canary デプロイで本番影響を段階的に検証している
  • [ ] ★★☆ ロールバック手順が定義・テストされている
  • [ ] ★★☆ 変更前後の CloudWatch ダッシュボードで影響を確認できる

2. セキュリティ（Security）

ID・アクセス管理

  • [ ] ★★★ ルートアカウントに MFA が設定され、日常利用されていない
  • [ ] ★★★ IAM ユーザーにポリシーを直接アタッチせず、ロール経由でアクセスしている
  • [ ] ★★★ 本番環境への IAM アクセスは最小権限で定義されている
  • [ ] ★★☆ IAM Access Analyzer で意図しない外部公開リソースを検出している
  • [ ] ★★☆ SCP（Service Control Policy）でガードレールが Organizations に適用されている
  • [ ] ★☆☆ IAM Identity Center（SSO）で人間のアクセスを一元管理している

暗号化・シークレット管理

  • [ ] ★★★ 保存データ（S3/EBS/RDS/DynamoDB）は KMS で暗号化されている
  • [ ] ★★★ 転送データは TLS 1.2 以上で保護されている
  • [ ] ★★★ DB パスワード・API キー等のシークレットは Secrets Manager または SSM Parameter Store で管理されている（コード・環境変数に直書きしない）
  • [ ] ★★☆ KMS CMK（Customer Managed Key）のローテーションが有効化されている
  • [ ] ★★☆ S3 バケットのパブリックアクセスブロックが有効化されている

脅威検知・監査

  • [ ] ★★★ CloudTrail が全リージョンで有効化され、S3 に90日以上保存されている
  • [ ] ★★★ GuardDuty が全アカウント・全リージョンで有効化されている
  • [ ] ★★☆ Security Hub が有効化され、CIS ベンチマークのスコアを定期確認している
  • [ ] ★★☆ AWS Config ルールで重要な設定変更を検知・記録している
  • [ ] ★☆☆ Detective で GuardDuty 検出結果の根本原因分析ができる体制がある

ネットワーク保護

  • [ ] ★★★ 公開サービスの前に WAF が設置されている
  • [ ] ★★★ セキュリティグループが最小権限で設定されている（0.0.0.0/0 は ALB のHTTPS受信のみ）
  • [ ] ★★☆ RDS / ElastiCache はプライベートサブネットに配置され、インターネットから直接アクセス不可
  • [ ] ★★☆ VPC Flow Logs が有効化されている

3. 信頼性（Reliability）

単一障害点の排除

  • [ ] ★★★ EC2 / ECS / Aurora / ALB がマルチ AZ に配置されている
  • [ ] ★★★ RDS に Multi-AZ が設定されている
  • [ ] ★★★ Auto Scaling グループが最低 2 つの AZ にわたっている
  • [ ] ★★☆ CloudFront + Route 53 フェイルオーバーでリージョン障害に対応している
  • [ ] ★☆☆ Aurora Global Database または DynamoDB Global Tables でマルチリージョン対応している

バックアップ・復旧

  • [ ] ★★★ AWS Backup で全重要データの自動バックアップが設定されている
  • [ ] ★★★ RDS の自動バックアップ保持期間が7日以上に設定されている
  • [ ] ★★☆ 復旧テスト（リストア手順の動作確認）を四半期ごとに実施している
  • [ ] ★★☆ S3 Object Lock またはバージョニングでデータ保護がされている
  • [ ] ★☆☆ RPO / RTO が定義され、バックアップ設定と整合している

自動復旧

  • [ ] ★★★ ELB ヘルスチェック + Auto Scaling で異常インスタンスが自動置換される
  • [ ] ★★☆ CloudWatch Alarm + Auto Scaling でトラフィックに応じてスケールする
  • [ ] ★☆☆ Route 53 ヘルスチェックで障害時にフェイルオーバーされる

4. パフォーマンス効率（Performance Efficiency）

適切なサービス選定

  • [ ] ★★★ ワークロードの特性（CPU/メモリ/IO）に合ったインスタンスタイプを使用している
  • [ ] ★★☆ Compute Optimizer の推奨を確認し、過剰プロビジョニングを見直している
  • [ ] ★★☆ データアクセスパターンに合ったDBを選定している（DynamoDB/Aurora/Redshift）
  • [ ] ★☆☆ SageMaker Inference / Lambda Snap Start 等の高速化機能を検討している

キャッシュ・非同期化

  • [ ] ★★★ 読み取り頻度の高いデータに ElastiCache または CloudFront キャッシュが設定されている
  • [ ] ★★☆ 重い処理が SQS/SNS を介した非同期処理にオフロードされている
  • [ ] ★★☆ DynamoDB DAX でマイクロ秒レイテンシが必要なアクセスをキャッシュしている
  • [ ] ★☆☆ CloudFront の Cache-Control ヘッダーが適切に設定されている

スケーリング

  • [ ] ★★★ トラフィックのピーク時に自動スケールできる設計になっている
  • [ ] ★★☆ Lambda / Fargate のターゲット追跡スケーリングが設定されている
  • [ ] ★☆☆ ロードテストでスケーリング動作を確認している

5. コスト最適化（Cost Optimization）

可視化・監視

  • [ ] ★★★ AWS Budgets でコスト予算と超過アラートが設定されている
  • [ ] ★★★ コスト配賦タグ（Environment / Team / Service）が全リソースに付与されている
  • [ ] ★★☆ Cost Anomaly Detection でコスト異常検知が有効化されている
  • [ ] ★★☆ Cost Explorer で月次トレンドを定期確認している

リソース最適化

  • [ ] ★★★ 本番で安定稼働しているリソースに Reserved Instances / Savings Plans を適用している
  • [ ] ★★☆ バッチ処理・開発環境に Spot Instances を活用している
  • [ ] ★★☆ 開発・検証環境は夜間・週末に自動停止されている
  • [ ] ★★☆ Compute Optimizer で右サイジング推奨を定期確認している
  • [ ] ★☆☆ 未使用 EBS / EIP / Load Balancer を定期棚卸ししている

ストレージ最適化

  • [ ] ★★☆ S3 Intelligent-Tiering またはライフサイクルポリシーでストレージクラスを最適化している
  • [ ] ★★☆ CloudWatch Logs の保持期間がデフォルト（無期限）でなく、適切に設定されている
  • [ ] ★☆☆ RDS 自動バックアップ保持期間が必要最低限（監査要件に準拠）に設定されている

6. 持続可能性（Sustainability）

  • [ ] ★★☆ 使用率が低い EC2 インスタンスを Graviton（ARM）に移行している
  • [ ] ★★☆ 不要になったリソースの自動削除・スケダウンが設定されている
  • [ ] ★☆☆ AWS リージョン選択時に再生可能エネルギー比率を考慮している
  • [ ] ★☆☆ データ転送量を最小化するためにリージョン内処理を優先している

レビュー記録テンプレート

柱 項目 状態 課題・リスク 対応期限 担当
Security IAM 最小権限 要改善 Admin ロール多用 2週間 インフラ担当
Reliability Multi-AZ 良好 — — —
Cost Savings Plans 未対応 EC2 オンデマンド多い 1ヶ月 FinOps
OpEx Runbook 部分対応 DR 手順が未文書化 3週間 SRE

Well-Architected Tool の活用

AWS マネジメントコンソールから Well-Architected Tool を使うと、各設問への回答に基づくリスクレポートが生成されます。設計レビューの客観的な評価ツールとして活用してください。

Well-Architected Tool の使い方:
  1. ワークロードを定義（システム名・環境・チーム情報）
  2. 6本柱の質問に回答（High Risk / Medium Risk / No Risk）
  3. 改善計画をマイルストーンとして記録
  4. 次回レビューとの比較でリスクの改善を確認