SAP-C02 D3 継続的改善｜Well-Architected 5ピラー・Config/GuardDuty・コスト最適化

1. はじめに — D3「継続的改善」とは

本記事は「AWS SAP-C02試験対策」シリーズの Vol3 です。
シリーズ全体の学習ロードマップは Vol0、組織的複雑性は Vol1、新規ソリューション設計は Vol2 で解説しています。

ここから扱うのは第3ドメイン、D3「Continuous Improvement for Existing Solutions（既存ソリューションの継続的改善）」 です。
公式試験ガイド v1.2 に基づく出題比率は 25%（75問中75問換算） であり、4ドメインの中では D2（29%）に次ぐ第2位の配点を誇ります。

D3 が Associate（SAA）と決定的に異なるのは、「既存の本番環境をいかに継続して改善するか」という 運用成熟度の観点 が問われる点です。
単純な「このサービスは何か」という知識問題ではなく、「今の構成にどの改善手段を、どの順序で、なぜ適用するか」というトレードオフ評価と設計判断が問われます。

1-1. D3 の出題範囲を一望する

D3「継続的改善」は、稼働中のシステムを Well-Architected のフレームワークで定期的に診断し、運用・セキュリティ・性能・信頼性・コストの5軸から継続して改善する 能力を問います。
頻出問題の集計では、Config（56問）・GuardDuty（47問） が D3 の代表的なサービスとして上位に出現します。
下表に D3 の主要テーマを整理します。

2. 継続的改善の設計原則 — SAP が求める「改善サイクル」

SAP-C02 D3 で問われる「継続的改善」とは、単発の修正作業ではなく Plan-Do-Check-Act（PDCA）型の継続サイクル を AWS サービスで実装する能力です。

2-1. 改善サイクルの全体像

AWS における継続的改善のサイクルは、大きく4フェーズで構成されます。

① 可観測（Observe）: CloudWatch メトリクス・ログ・トレース、CloudTrail API 監査ログ、Config リソース変更追跡によって、システムの現状を可視化します。

② 評価（Evaluate）: Well-Architected Tool のレビュー、Trusted Advisor のチェック、Compute Optimizer の推奨事項、Security Hub のコンプライアンスチェックによって、現状のギャップを定量評価します。

③ 修正（Remediate）: Config Remediation（自動修復）、Systems Manager Automation Runbook、EventBridge → Lambda の自動化パイプラインによって、発見された問題を修正します。

④ 検証（Verify）: 修正後の状態を再度モニタリングし、改善効果を計測します。SLO（Service Level Objective）の達成状況を確認し、次の改善サイクルへつなげます。

2-2. Professional 差別化の核心：改善優先度の設計判断

SAP の問題が Associate と最も異なるのは、「複数の改善候補の中からどれを優先するか」という 設計判断のトレードオフ が問われる点です。

たとえば、あるシステムで「CPU使用率の慢性的な高止まり」「S3 バケットへの公開アクセス許可」「インスタンスの過剰プロビジョニング」が同時に検出された場合、SAP の試験では「どの問題を最初に対処すべきか、その根拠は何か」を問います。
答えの根拠は Well-Architected のピラー優先順位（セキュリティが最高優先） にあります。

3. AWS Well-Architected Framework — 5ピラー+持続可能性と WAF Tool

Well-Architected Framework（WAF）は、AWS が提供するベストプラクティス集であり、SAP-C02 D3 の根幹をなす概念です。

3-1. 6本のピラー（5ピラー + 持続可能性）

AWS Well-Architected Framework は現在 6本のピラー で構成されています。

SAP の試験では、「セキュリティ」が全ピラーの中で 最高優先度 に置かれていることを覚えておいてください。
コスト削減のためにセキュリティ機能を無効化する選択肢は、たとえ短期コスト効果が高くても「不正解」です。

3-2. AWS Well-Architected Tool（WAF Tool）の活用

AWS Well-Architected Tool は、WAF のベストプラクティスに基づいた自動レビューをワークロード単位で実行できるマネージドサービスです。

主な機能は次の通りです。

• ワークロード定義: レビュー対象のシステムを「ワークロード」として定義し、環境・チーム・タグと紐付けます
• 質問形式のレビュー: 各ピラーで数十問の質問に回答すると、リスクが「High Risk / Medium Risk / None」で分類されます
• 改善計画の生成: 検出された High Risk 項目に対して、具体的な改善手順とリソースへのリンクが提示されます
• カスタムレンズ: 業界固有要件（金融コンプライアンス・HIPAA 等）やマルチアカウント固有の観点を追加できます
• マイルストーン管理: 改善前後のスコアをスナップショット（マイルストーン）として保存し、改善の軌跡を追跡できます

Trusted Advisor との違いについては、SAP で頻繁に問われます。
WAF Tool は「ピラー視点からのアーキテクチャ評価」であり、定性的な設計判断を支援します。
これに対して Trusted Advisor は「具体的な AWS リソース設定の問題点を自動チェック」するサービスで、定量的な自動診断に特化しています。
両者は 補完関係 であり、どちらかを選ぶ問題ではありません。

3-3. 持続可能性ピラー（Sustainability）の実装

2021 年に追加された Sustainability（持続可能性）ピラー は、SAP-C02 でも出題されます。

主な実装手段は以下の通りです。

• Graviton プロセッサの採用: ARM ベースの Graviton3/Graviton4 は、x86 比で最大 60% の消費電力削減を実現します
• 適切なインスタンスサイズの選択: 過剰プロビジョニングを排除し、使用率を最大化します（Compute Optimizer と連携）
• マネージドサービスへの移行: EC2 から Lambda/Fargate/RDS Serverless 等へ切り替えることで、アイドル時のリソース消費をゼロにします
• S3 Intelligent-Tiering: アクセスパターンに応じた自動ティアリングで、不要なストレージを削減します

4. 可観測性と運用監視 — CloudWatch/CloudTrail/X-Ray

4-1. 可観測性の三本柱（Metrics / Logs / Traces）

現代のクラウド運用では、可観測性（Observability） として「メトリクス・ログ・トレース」の三本柱を整備することが求められます。

SAP の試験では、「マイクロサービス間のレイテンシ問題の原因を特定する最適なサービスは何か」という問いに対して、X-Ray（分散トレーシング） が正解となるパターンが頻出です。

4-2. CloudWatch の深掘り — SAP 頻出機能

CloudWatch Metrics Insights は SQL ライクなクエリ言語で複数メトリクスを横断分析できます。
例えば、全 EC2 インスタンスの平均 CPU 使用率を AutoScaling グループ単位で集計するクエリを書き、ダッシュボードに表示できます。

CloudWatch Anomaly Detection は機械学習を用いてメトリクスの正常範囲を自動学習し、外れ値を検出します。
季節性や時間帯のパターンを自動補正するため、手動でしきい値を設定するアラームより誤検知が少なく、SAP では「しきい値の管理コストを削減したい」という要件に対する正解候補です。

CloudWatch Synthetics は定期的なカナリアスクリプトにより、エンドユーザー視点でのエンドポイント死活・レイテンシを監視します。
ユーザーからの問い合わせが来る前に異常を検知する「外形監視」として、SAP の問題で「アプリ可用性をユーザー視点で継続監視する方法」として登場します。

CloudWatch Contributor Insights は CloudWatch Logs のレコードを分析し、トップ N の「貢献者」を特定します。
「どの IP アドレスから最もリクエストが来ているか」「どのリソース ID がエラーを最も多く生成しているか」という分析に使えます。

4-3. CloudTrail の継続的監視

CloudTrail は AWS API コールの全記録を S3 に保存する監査ログサービスです。
SAP で問われる主なユースケースを整理します。

• 証跡（Trail）の有効化: 全リージョン対象の証跡を組織レベル（Organizations Trail）で有効化し、S3 への一元集約を実現します
• CloudTrail Lake: SQL クエリで CloudTrail イベントを直接分析できる分析エンジンです。Athena と異なり、S3 への出力とデータカタログの管理が不要で、ガバナンス調査のスピードが向上します
• 証跡の改ざん防止: S3 のオブジェクトロック（Compliance モード）と SNS 通知を組み合わせて、証跡の削除・変更を検知・防止します
• EventBridge 連携: 特定の API コール（例: DeleteSecurityGroup、ConsoleLogin の MFA なしアクセス）を EventBridge で捕捉し、Lambda や SNS でアラートを飛ばす自動化パターンが頻出です

5. セキュリティの継続的改善 — Config/GuardDuty/Security Hub

セキュリティは Well-Architected で 最高優先度のピラー です。
D3 の試験問題では、セキュリティ設定の継続的な評価と自動修復のパターンが多く出題されます。

5-1. AWS Config — リソース設定の継続的評価

AWS Config は AWS リソースの設定変更を継続的に記録し、ルールに照らして評価するサービスです。
「コンプライアンス違反の自動検出と修復」という D3 のコアユースケースにおいて最重要サービスの一つです。

Config ルールの種類:

Config Remediations（自動修復）:

Config ルール違反を検出した際、Systems Manager Automation Runbook を自動実行して修復できます。
例えば、s3-bucket-public-read-prohibited ルールが違反を検出したとき、自動修復アクションとして AWS-DisableS3BucketPublicReadWrite Runbook を実行し、バケットのパブリックアクセスブロックを有効化します。

Aggregator（組織全体集約）:

Organizations と統合した Config Aggregator を使うと、全アカウント・全リージョンの Config データをマスターアカウントに集約できます。
SAP では「マルチアカウント環境で全リソースのコンプライアンス状況を一元把握したい」という要件に対して、Config Aggregator が正解候補となります。

5-2. Amazon GuardDuty — 脅威検出の継続的改善

Amazon GuardDuty は機械学習と脅威インテリジェンスフィードを使い、悪意ある活動や異常な動作を継続的に検出するマネージドサービスです。

GuardDuty が分析するデータソースは次の通りです。

• VPC フローログ: 通信の異常（C2サーバーへの接続、ポートスキャン等）
• DNS クエリログ: マルウェアが使う DGA（Domain Generation Algorithm）ドメインへのクエリ
• CloudTrail イベント: 異常な API アクセスパターン（不審な IAM アクティビティ等）
• S3 アクセスログ: 大量データへの不審なアクセス
• EKS 監査ログ: Kubernetes コントロールプレーンへの不審な操作
• Lambda ネットワークアクティビティ: Lambda 関数からの不審な外部通信
• EC2 ランタイム監視: ホストレベルの実行時脅威検出（2023 追加）
• S3 Malware Protection: アップロードファイルのマルウェアスキャン（2024 GA）

GuardDuty Findings の対応自動化:

GuardDuty が検出した Findings は EventBridge へ自動送信されます。
SAP で問われる典型的な自動応答パターンは次の通りです。

1. 高重大度の Finding 検出 → EventBridge → SNS で SOC への通知
2. UnauthorizedAccess:EC2/MaliciousIPCaller 検出 → Lambda → 対象 EC2 のセキュリティグループを変更し、送受信をすべてブロック
3. Policy:IAMUser/RootCredentialUsage 検出 → EventBridge → Lambda → 管理者へ即時通知 + CloudTrail で詳細調査

5-3. AWS Security Hub — 統合セキュリティスコアリング

AWS Security Hub は GuardDuty・Config・Inspector・Macie 等、複数のセキュリティサービスの検出結果を 統合ダッシュボード で管理し、セキュリティスコアを継続的に計測します。

主な機能は以下です。

• ASFF（Amazon Security Finding Format）: 全サービスの検出結果を共通フォーマットで統一
• セキュリティスコア: 標準（CIS AWS Foundations / AWS Foundational Security Best Practices 等）への準拠率を 0〜100% でスコア化
• 自動チェック: 200 以上のコントロールを自動実行し、コンプライアンス状況をリアルタイム更新
• インシデント調査ワークフロー: Findings をチームにアサインし、対応状況を追跡

マルチアカウント展開: Organizations と統合すると、Security Hub 管理者アカウントに全メンバーアカウントの Findings が集約されます。
SAP の問題では「数十のアカウントのセキュリティ状況を一元管理する方法」として Security Hub + Organizations の組み合わせが頻出です。

5-4. Amazon Inspector — 脆弱性スキャンの継続的改善

Amazon Inspector V2 は EC2・Lambda・ECR コンテナイメージを継続的にスキャンし、CVE（脆弱性）を自動検出します。

V1 との主な違いは次の通りです。

ECR 連携: Docker イメージが ECR へプッシュされると、Inspector V2 が自動スキャンを実行します。
重大な CVE を含むイメージが ECS/EKS へデプロイされる前に Security Hub へ通知が届き、デプロイパイプライン内でブロックできます。

6. コスト分析と最適化 — Compute Optimizer/Savings Plans/Trusted Advisor

コスト最適化は Well-Architected の 1 ピラーであり、SAP D3 では「継続的な改善サイクルとしてのコスト管理」が問われます。

6-1. AWS Cost Explorer — コストの可視化と傾向分析

AWS Cost Explorer は過去 13 ヶ月分のコストデータを可視化し、サービス別・アカウント別・タグ別等の多軸でドリルダウン分析できるツールです。

SAP 頻出機能：

• コスト異常検知（Anomaly Detection）: 機械学習で通常パターンを学習し、コスト急増を自動検知。SNS や Slack 通知に連携可能です
• RI/Savings Plans の利用率レポート: 購入済み Reserved Instances や Savings Plans の使用率・カバレッジをモニタリングし、未使用コストを把握します
• コスト予測: 将来 12 ヶ月の支出予測を過去データから自動算出します

6-2. AWS Budgets — 予算超過の自動アラート

AWS Budgets は予算しきい値に対してコスト・使用量・RI 利用率・Savings Plans カバレッジのアラートを設定できます。

Budgets Actions は SAP で特に重要です。
予算超過が発生したとき、手動対応を待たずに IAM ポリシーの自動アタッチ や EC2/RDS インスタンスの自動停止 を実行できます。
「コスト超過時にプロジェクトチームの新規リソース作成を自動でブロックする方法」という問いに対して、Budgets Actions が正解候補です。

6-3. AWS Compute Optimizer — ML によるリソース適正化

AWS Compute Optimizer は EC2・Lambda・EBS・ECS on Fargate・Auto Scaling グループのメトリクス（最低 14 日間）を機械学習で分析し、最適なリソースサイズ・タイプへの変更推奨 を提供します。

推奨例：

• EC2: m5.4xlarge（過剰）→ m5.2xlarge（推奨）・予測コスト削減 48%
• Lambda: メモリ 1024 MB（過剰）→ 512 MB（推奨）・パフォーマンス維持・コスト 50% 削減
• EBS: gp2 → gp3（同等性能・20% 低コスト）

Savings Opportunity: Compute Optimizer は推奨変更によって節約できる見込みコストを「Savings Opportunity」として金額で表示します。
SAP の問題では「改善優先度の根拠を定量的に示す方法」として Compute Optimizer のレポートが登場します。

Enhanced Infrastructure Metrics: 追加料金で CloudWatch の過去 93 日間のメトリクスを使った精度の高い推奨が得られます。

6-4. Savings Plans と Reserved Instances の戦略的組み合わせ

Savings Plans（SP） はコンピューティング利用量（$/時間）をコミットすることで、オンデマンド比 最大 72% の割引を受けられる購入プランです。

Reserved Instances（RI） との選び方:

• サービス変更・リージョン変更が予想されない EC2 ワークロード: EC2 RI または EC2 Instance Savings Plans が最大割引
• サーバーレスへの移行を検討中: Compute Savings Plans が EC2・Lambda・Fargate 全てをカバー
• ベースライン保証 + スパイク対応: Savings Plans でベースラインをカバー、スパイクは Spot Instance で吸収

SAP での出題パターン: 「コンピュートリソースが EC2 から Lambda + Fargate に段階移行する予定のワークロードに最適なコスト削減方法は何か」→ Compute Savings Plans が正解です。

6-5. AWS Trusted Advisor — 継続的ベストプラクティスチェック

AWS Trusted Advisor は AWS アカウントの設定を定期的にスキャンし、コスト最適化・セキュリティ・フォールトトレランス・パフォーマンス・サービス制限の 5 カテゴリでアドバイスを提供します。

Free Tier で利用可能なチェック（抜粋）:
– 使用されていない EC2 インスタンス・EBS ボリューム・ELB
– S3 バケットのパブリックアクセス設定
– MFA が無効な IAM ルートアカウント
– セキュリティグループのすべてのポート開放

Business/Enterprise サポートプランで追加されるチェック:
– RI/Savings Plans の購入推奨
– High Utilization EC2（CPU 90%超のインスタンス）の特定
– CloudFront の最適化チェック
– EBS プロビジョニングの適正化

EventBridge 連携: Trusted Advisor の推奨事項が変化したとき（新しい問題の発見・問題の解決）、EventBridge でイベントを受け取り、SNS や Slack でアラートを飛ばせます。
SAP では「Trusted Advisor の新規推奨を自動でチームに通知するアーキテクチャ」として問われます。

7. DevOps 改善サイクル — CI/CD と CloudFormation Drift

7-1. CI/CD パイプラインの継続的改善

D3「継続的改善」では、アプリケーションのデリバリーパイプライン自体を改善することも含まれます。

AWS CodePipeline によるパイプライン品質指標の継続的モニタリング:

• パイプラインの実行失敗率・成功率を CloudWatch メトリクスで追跡
• 失敗ステージを EventBridge で検出し、Slack/メールへ自動通知
• CodeStar Notifications でプルリクエスト・コードレビューの状況を通知

CodeBuild のコスト最適化:

• ビルドキャッシュ（S3 または ローカルキャッシュ）の有効化でビルド時間を短縮
• 環境タイプを最適なインスタンスサイズに right-sizing（Compute Optimizer の対象外なので手動分析が必要）
• VPC 内のビルドが必要ない場合は VPC 接続を外す（ネットワーク料金の削減）

7-2. CloudFormation Drift Detection — IaC と実態の乖離検出

CloudFormation Drift Detection は、CloudFormation スタックで管理しているリソースが、テンプレートから手動変更などで逸脱（ドリフト）していないかを検出する機能です。

継続的改善の観点では、定期的な Drift Detection の自動実行 が重要です。

SAP で問われる典型パターン:

EventBridge Scheduler（定期実行）
→ Lambda（Drift Detection を開始）
→ CloudFormation（Drift Detection を実行・完了を待機）
→ Lambda（結果を確認）
→ 逸脱あり: SNS でセキュリティチームへ通知 + Jira チケット自動作成
→ 逸脱なし: CloudWatch にスコアを記録

この自動化により、手動変更によるコンプライアンス違反を週次・月次ではなく 継続的に 検出できます。

7-3. AWS Config + CloudFormation の連携

CloudFormation 変更セット（Change Set）を実行する前に Config ルールを評価し、コンプライアンス違反の変更を事前にブロックするパターンがあります。

CloudFormation Guard を CI/CD パイプラインの CodeBuild ステップに組み込むことで、IaC テンプレート自体がセキュリティポリシーを満たしているかを push 時に自動検証できます。

8. インシデント対応 — Systems Manager/OpsCenter/Incident Manager

インシデント対応の自動化と効率化は、「運用上の優秀性」ピラーの核心テーマです。
SAP-C02 D3 では、インシデントの検知から修復・事後分析までのライフサイクル を AWS サービスでどう自動化するかが問われます。

8-1. AWS Systems Manager — 運用自動化の基盤

AWS Systems Manager（SSM） は EC2 インスタンス（および オンプレミスサーバー）の運用管理を自動化するサービス群です。
D3「継続的改善」において最も広い範囲をカバーします。

主要機能と D3 での活用:

State Manager は特に SAP で重要です。
「インスタンスが常に最新の設定（CloudWatch エージェントのインストール、特定のポート設定等）を維持する仕組みを自動化する方法」という問いに対して、State Manager Association が正解です。

8-2. Systems Manager OpsCenter — インシデント集約管理

OpsCenter は運用上の問題（OpsItem）を中央で管理するサービスです。
CloudWatch アラーム・EventBridge ルール・Config コンプライアンス違反・GuardDuty Findings を OpsItem として自動作成 し、担当者のアサインと対応状況の追跡ができます。

OpsItem には以下の情報が含まれます:
– 問題の説明・重大度・優先度
– 関連リソース（EC2 インスタンス ARN 等）
– 推奨 Runbook（自動修復のリンク）
– 対応ログ（誰がいつ何をしたか）

Jira との統合: OpsCenter は Jira Service Management と双方向連携でき、AWS 上の問題を Jira チケットとして管理できます。
SAP では「既存の ITSM ワークフローに AWS の運用アラートを統合する方法」として出題されます。

8-3. AWS Systems Manager Incident Manager — 重大インシデントの対応自動化

Incident Manager は重大インシデントの検知・エスカレーション・対応・事後分析を自動化するサービスです。

インシデント対応ライフサイクル:

1. 検知（Detect）: CloudWatch アラームが基準を超える → EventBridge → Incident Manager でインシデント自動作成
2. エスカレーション（Escalate）: オンコールスケジュール（PagerDuty/OpsGenie/Incident Manager ネイティブ）に従い、担当者へ自動呼び出し
3. 調査・対応（Respond）: インシデント画面に関連 CloudWatch メトリクス・ログ・X-Ray トレースが集約表示。Automation Runbook を直接実行可能
4. 解決（Resolve）: インシデントをクローズし、対応タイムラインを記録
5. 事後分析（Post-incident Analysis）: インシデントのタイムラインから自動生成された事後分析ドキュメントでレトロスペクティブを実施

Contact と Escalation Plan:
– Contact: インシデント通知先（SMS・メール・PagerDuty 等）
– Escalation Plan: 段階的エスカレーション設定（N 分以内に応答がなければ次の担当者へ昇格）

SAP の出題パターン: 「夜間の本番障害でオンコール担当者へ自動連絡し、標準対応手順書を即座に実行できる自動化アーキテクチャ」→ Incident Manager + Automation Runbook + Escalation Plan の組み合わせが正解です。

8-4. Runbook 設計のベストプラクティス

Systems Manager Automation Runbook は JSON/YAML で定義された自動化ドキュメントです。
継続的改善の観点では、インシデント対応の 標準手順の Runbook 化 が重要です。

Runbook 設計のポイント:

• べき等性（Idempotency）: 同じ Runbook を何度実行しても結果が変わらない設計とします（StopEC2Instance を実行済みのインスタンスへ再実行しても安全なように）
• 承認ステップ（Approval）: 本番環境への自動変更の前に人手の承認を挟む aws:approve アクション
• ロールバック: Runbook の各ステップでエラーが発生した場合、安全な状態へ戻す onFailure ハンドラの設計
• バージョン管理: Runbook ドキュメント自体を $VERSION で管理し、変更履歴を追跡

9. 性能と信頼性の継続的改善

Well-Architected の「パフォーマンス効率」と「信頼性」ピラーに対応する継続的改善の手法を整理します。

9-1. Auto Scaling の継続的チューニング

Auto Scaling は継続的改善の対象の一つです。
スケーリングポリシーは一度設定すれば終わりではなく、トラフィックパターンの変化に合わせて定期的に見直します。

SAP では「週末に毎回コールドスタートが発生し、ユーザー体験が悪化している EC2 Auto Scaling グループを改善する方法」→ スケジュールスケーリング + 予測スケーリング の組み合わせが正解パターンです。

9-2. Aurora の継続的改善 — パフォーマンスインサイト

Performance Insights は RDS/Aurora のデータベース負荷をリアルタイム・時系列で可視化し、ボトルネックとなっている SQL クエリ・待機イベントを特定します。

D3 での典型的な改善サイクル:
1. Performance Insights で上位 SQL を特定
2. クエリプランを EXPLAIN で分析
3. インデックス追加 or クエリ書き換えを実施
4. Performance Insights で改善効果を確認

Aurora Serverless v2 は DB 負荷に応じて 0.5 ACU 単位で秒単位スケールします。
一定のトラフィックの本番環境には Aurora Provisioned が効率的ですが、開発・テスト環境や不規則な負荷パターンには Aurora Serverless v2 が適しています。

9-3. ElastiCache による継続的なキャッシュ改善

ElastiCache のキャッシュヒット率を CloudWatch で継続監視し、ヒット率が低い場合はキャッシュ戦略（TTL・エビクションポリシー）を見直します。

10. CertTrend LMS D3 演習（300問）

本記事の内容は SAP-C02 D3「継続的改善」の75問を完全カバーしています。
試験対策では、概念の理解と実際の問題演習を組み合わせることが合格への近道です。

11. 実務で深掘り — 継続的改善 本番運用記事

SAP-C02 D3 の試験対策を終えたら、実際の本番環境での実装方法を本番運用記事で学びましょう。

12. シリーズ全体ナビ — SAP-C02 試験対策