AWS Well-Architected Framework 完全ガイド 2025: 6つの柱、実戦適用、コスト/セキュリティ/パフォーマンス

TL;DR

• 6つの柱: Operational Excellence、Security、Reliability、Performance Efficiency、Cost Optimization、Sustainability。
• トレードオフ: すべての柱を100%満たすことはできない。ビジネス優先度で判断。
• Well-Architected Tool: AWS コンソール上の無料セルフアセスメント。
• Sustainability (2021年追加): 環境影響を考慮する。効率的なコードは二酸化炭素排出も少ない。
• 他クラウドにも応用可: AWS のフレームワークだが GCP/Azure でも有効。

1. Well-Architected Framework とは

1.1 背景

AWS が数万顧客のアーキテクチャを分析して整理したベストプラクティスガイド。最初は5つの柱だったが、2021年に Sustainability が追加され6つになった。

1.2 6つの柱 (2025)

1.3 一般原則

すべての柱に共通する5原則:

1. 推測ではなく計測 — データ駆動の意思決定。
2. 本番規模でテスト — staging は本番とは別物。
3. 自動化で実験頻度を上げる — 手作業は人為ミスの源。
4. 進化するアーキテクチャを許容 — 一度作ったものが永遠ではない。
5. ゲームデーで改善 — カオスエンジニアリング。

2. 柱 1: Operational Excellence

2.1 コア

「ビジネス価値を届けるためにシステムを効果的に運用・監視し、継続的に改善する能力」

2.2 設計原則

1. 運用をコードに (Operations as Code) — インフラ、ポリシー、手順をコード化。
2. 小さく頻繁な変更 — 大きなデプロイはリスク。
3. 運用手順を継続的に改善 — 振り返りと runbook 更新。
4. 障害を予測 — 起こりうる失敗モードを洗い出す。
5. すべての障害から学ぶ — ポストモーテム。

2.3 実戦チェックリスト

計画:

• ビジネス目標は明確か?
• メトリクスで成功を測れるか?
• 運用上の優先度は定義済みか?

準備:

• インフラは IaC (CloudFormation/Terraform) 管理か?
• CI/CD パイプラインはあるか?
• モニタリングとアラートは設定済みか?

運用:

• runbook は最新か?
• オンコール手順は明確か?
• インシデント対応時間は計測されているか?

進化:

• 定期的な retrospective を行っているか?
• カオスエンジニアリングを実施しているか?
• メトリクスベースで改善しているか?

2.4 AWS ツール

• CloudFormation / CDK — IaC。
• Systems Manager — 自動化 (runbook、パッチ)。
• CloudWatch — モニタリング、アラート。
• X-Ray — 分散トレーシング。
• Config — リソース変更追跡。

3. 柱 2: Security

3.1 コア

「データ、システム、資産を保護しながらクラウドでビジネス価値を提供する能力」

3.2 設計原則

1. 強固な Identity 基盤 — IAM、MFA、最小権限。
2. すべてのレイヤーにセキュリティ — Defense in Depth。
3. 保存中も転送中も暗号化 — Encryption everywhere。
4. 人のデータアクセスを制限 — 自動化優先。
5. セキュリティイベントに備える — IR (Incident Response) 計画。
6. 共有責任モデルを理解 — AWS はクラウドの、顧客はクラウド内のセキュリティ。

3.3 IAM ベストプラクティス

BAD: root アカウントの使用
BAD: コードにアクセスキーを埋め込む
BAD: ワイルドカード (*) 権限
BAD: 共用ユーザー

GOOD: 全ユーザー MFA
GOOD: ロールベース (IAM Roles)
GOOD: 最小権限原則
GOOD: Access Analyzer の活用
GOOD: STS による一時クレデンシャル

3.4 データ保護

保存中 (At Rest):

• S3: デフォルトで SSE-S3、または SSE-KMS。
• EBS: デフォルト暗号化を有効化。
• RDS: KMS キーで暗号化。
• DynamoDB: 常に暗号化 (デフォルト)。

転送中 (In Transit):

• TLS 1.2 以上必須。
• VPC 内部も暗号化 (Service Mesh、mTLS)。
• VPN / Direct Connect。

3.5 ネットワークセキュリティ

[Public Subnet]    <- Internet Gateway
    |
[Private Subnet]   <- NAT Gateway (egress only)
    |
[Isolated Subnet]  <- DB のみ、インターネットなし

Security Group と NACL:

• Security Group: インスタンス単位、stateful。
• NACL: サブネット単位、stateless。

3.6 AWS セキュリティツール

4. 柱 3: Reliability

4.1 コア

「ワークロードが意図通りに正確かつ一貫して機能する能力」

4.2 設計原則

1. 障害から自動復旧 — Auto-healing。
2. 復旧手順をテスト — カオスエンジニアリング。
3. 水平スケールで可用性を高める — 巨大単一インスタンスは避ける。
4. 容量を推測しない — Auto Scaling。
5. 変更管理を自動化 — IaC。

4.3 AWS 可用性モデル

• Region: 地理的領域 (us-east-1, ap-northeast-1)。
• Availability Zone (AZ): Region 内の独立したデータセンター (通常3〜6)。
• Edge Location: CloudFront の PoP。

Multi-AZ: 複数 AZ に分散し単一 AZ 障害を吸収。 Multi-Region: 複数リージョンに分散し、広域障害や自然災害に備える。

4.4 可用性目標

現実:

• 99.9% は単一インスタンスでは難しい。
• 99.99% は Multi-AZ + Auto Scaling。
• 99.999% は Multi-Region と精緻な failover が必要。

4.5 実戦パターン

ELB + Auto Scaling Group + Multi-AZ:

        [Route 53]
            |
       [ALB (multi-AZ)]
       /        |        \
   [EC2 az-a] [EC2 az-b] [EC2 az-c]
       |        |        |
       [RDS Multi-AZ Standby]

• EC2 が死ぬ: ASG が新しいインスタンスを起動。
• AZ が死ぬ: ALB が他 AZ にトラフィックを振り分け。
• Primary RDS が死ぬ: Standby に自動 failover。

4.6 RTO と RPO

• RTO (Recovery Time Objective): 復旧までに許される時間。
• RPO (Recovery Point Objective): 許容できるデータ損失。

ビジネスが許容できる RTO/RPO を決めてから戦略を選ぶ。

5. 柱 4: Performance Efficiency

5.1 コア

「要件を満たすためにコンピューティング資源を効率的に使い、需要と技術の変化に合わせてその効率を保つ能力」

5.2 設計原則

1. 先端技術の民主化 — AI/ML やビッグデータを誰もが使える。
2. グローバル展開 — ユーザーの近くへ。
3. サーバーレス優先 — 運用負荷を下げる。
4. より頻繁に実験 — 比較テスト。
5. 技術特性を理解 — ワークロードに合う道具を選ぶ。

5.3 コンピュートの選択

5.4 ストレージの選択

5.5 データベースの選択

5.6 キャッシング

階層的キャッシュ:

1. CloudFront (CDN) — 世界中のエッジ。
2. API Gateway キャッシュ — API 応答。
3. ElastiCache (Redis) — アプリキャッシュ。
4. DynamoDB DAX — DynamoDB キャッシュ。
5. RDS Read Replica — 読み込み負荷分散。

効果: 応答時間 90% 以上削減、DB 負荷激減。

6. 柱 5: Cost Optimization

6.1 コア

「最小コストでビジネス価値を届けるシステムを運用する能力」

6.2 設計原則

1. クラウド財務管理の導入 — FinOps。
2. 消費モデルを採用 — 使った分だけ。
3. 全体効率を計測 — ビジネスメトリクスあたりのコスト。
4. 差別化されない重労働をやめる — マネージドサービスへ。
5. 支出を分析・帰属 — タグと配賦。

6.3 価格モデル

コンピュート (EC2):

• On-Demand: 最も高いが柔軟。
• Reserved Instance (1〜3年): 最大 75% 割引。
• Savings Plans: より柔軟な約款。
• Spot: 最大 90% 割引、中断あり。

ストレージ (S3):

• Standard: 頻繁アクセス。
• Standard-IA: 低頻度、約 30% 安い。
• Glacier: 長期保管、約 95% 安い。
• Glacier Deep Archive: 最安、95% 以上安い。

6.4 コスト削減戦略

1. Right-sizing:

aws compute-optimizer get-ec2-instance-recommendations

使用率 50% の EC2 をよりサイズの小さいインスタンスに落とす。

2. Auto Scaling: トラフィックに応じてスケール。コストは利用量に比例。

3. Spot Instances: バッチや CI/CD に最適、最大 90% 削減、中断設計が前提。

4. Reserved Instances / Savings Plans: 安定ワークロード向け。1年で約 30%、3年で約 60% 削減。

5. S3 Lifecycle Policies:

{
  "Rules": [{
    "Id": "MoveToIA",
    "Status": "Enabled",
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 90, "StorageClass": "GLACIER" },
      { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
    ]
  }]
}

6. データ転送コストの削減: 同一リージョン内転送は無料/安価、S3 直接より CloudFront、NAT Gateway 回避のために VPC Endpoints を使う。

6.5 コストモニタリング

6.6 タグ戦略

Environment: production
Project: ecommerce
Owner: team-checkout
CostCenter: 1234

Cost Explorer でタグ別に分析できる。

7. 柱 6: Sustainability (2021年追加)

7.1 コア

「環境影響、特にエネルギー消費と効率に関する能力」

7.2 設計原則

1. 影響を理解 — どこで二酸化炭素を出しているか?
2. サステナビリティ目標を設定 — 測定可能な目標。
3. 利用率を最大化 — 遊休資源を最小化。
4. 効率的な新技術を採用 — Graviton、ARM。
5. マネージドサービスを使う — AWS 側の効率を活用。
6. 下流への影響を減らす — クライアント側も軽く。

7.3 サステナビリティ指標

• カーボンフットプリント。
• ユーザーあたりのエネルギー消費。
• 遊休資源比率。
• データ転送の最適化。

7.4 実戦ポイント

• 効率の良いインスタンスタイプ: Graviton (ARM) は Intel/AMD 比で約 60% 高効率。
• Auto Scaling: 使わないときは停止、開発環境は夜間停止。
• オブジェクトライフサイクル: 古いデータを cold storage に、不要なデータは削除。
• CDN: ユーザーの近くで配信してネットワークを減らす。
• リージョン選択: 再生可能エネルギー比率の高いリージョンを選ぶ。AWS Customer Carbon Footprint Tool が役立つ。

7.5 AWS のコミット

• 2025年までに再生可能エネルギー 100%。
• 2040年までにネットゼロ。
• 効率的なデータセンター設計。

8. トレードオフの扱い方

8.1 柱同士の対立

• Security vs. Performance: 強い暗号化は CPU コストを伴う。データの機微性で判断。
• Cost vs. Reliability: Multi-Region はコスト倍増。SLA で判断。
• Performance vs. Cost: 大きいインスタンスほど速くて高い。レイテンシ要件で判断。
• Operational Excellence vs. Cost: 自動化は初期コスト増。長期 ROI で判断。

8.2 意思決定フレームワーク

各意思決定で:

1. ビジネス目標 — 何が最重要か?
2. 各柱への影響 — どの柱に影響するか?
3. トレードオフ — 何を犠牲にするか?
4. リスク — 間違えたらどうなるか?
5. 可逆性 — 変更コストは?

8.3 例

シナリオ: e-commerce サイト、日次100万ユーザー。

9. Well-Architected Tool の使い方

9.1 無料セルフアセスメント

AWS コンソールから:

1. ワークロードを定義 (名前、環境、リージョン)。
2. 6つの柱について約50問に回答。
3. 改善領域を特定。
4. 優先度を決定。
5. 改善後に再評価。

9.2 Lens

Lens は特定のワークロードや技術向けの追加ガイド。

9.3 Well-Architected Review

AWS Solutions Architect との共同レビュー (無料またはパートナー経由):

1. アーキテクチャレビュー。
2. 6つの柱の評価。
3. 優先度付き推奨。
4. 改善ロードマップ。

10. アンチパターンカタログ

10.1 運用

• BAD: 手動デプロイ。GOOD: CI/CD パイプライン。
• BAD: ローカルだけでテスト。GOOD: 本番相当環境でテスト。
• BAD: 障害後に振り返らない。GOOD: blameless postmortem。

10.2 セキュリティ

• BAD: root アカウント使用。GOOD: IAM ユーザー + ロール。
• BAD: ワイルドカード権限。GOOD: 最小権限。
• BAD: ハードコードされたクレデンシャル。GOOD: Secrets Manager / Parameter Store。
• BAD: HTTP のみ。GOOD: HTTPS 強制、HSTS。

10.3 信頼性

• BAD: 単一 AZ デプロイ。GOOD: 最低限 Multi-AZ。
• BAD: バックアップなし、復元テストなし。GOOD: 定期バックアップ + 復元訓練。
• BAD: 単一障害点。GOOD: 全コンポーネントの冗長化。

10.4 パフォーマンス

• BAD: 何でも大型インスタンス。GOOD: ワークロード適正サイズ。
• BAD: キャッシュなし。GOOD: CloudFront + ElastiCache。
• BAD: すべて同期。GOOD: 適切な非同期化。

10.5 コスト

• BAD: すべて On-Demand。GOOD: Reserved / Savings / Spot の混合。
• BAD: タグなし。GOOD: 一貫したタグ戦略。
• BAD: 使っていない資源を放置。GOOD: 定期的なクリーンアップ、Trusted Advisor。

クイズ

参考資料

• AWS Well-Architected Framework
• Well-Architected Tool
• AWS Architecture Center
• AWS Solutions Library
• AWS Customer Carbon Footprint Tool
• Cloud Adoption Framework
• The Twelve-Factor App
• Site Reliability Engineering Book
• AWS This is My Architecture
• AWS Trusted Advisor