モジュール 9 · SAA-C03

監視、運用、Infrastructure as Code

CloudWatch、CloudTrail、Config、Systems Manager、CloudFormation：可観測性、操作の記録、運用の自動化。

分野弾力性のあるアーキテクチャ
分野セキュアなアーキテクチャ
図 11
出題パターン 10
サービス 11

5 分で押さえる要点

3 つの問い、3 つのサービス：パフォーマンスはどうか → CloudWatch、誰がどの API を呼んだか → CloudTrail、リソースの設定がどう変わり、ルールに準拠しているか → AWS Config。試験ではこの 3 つがよく混ぜて出題されます。問われているのが数値データか、操作ログか、設定履歴かを注意深く読み取りましょう。
EC2 はデフォルトで 5 分ごとにメトリクスを送信します（basic、無料）。detailed monitoring を有効にすると 1 分間隔になります（有料）。1 分間隔のメトリクスなら Auto Scaling がより速く反応できます。
EC2 はメモリ使用量やディスク使用量のメトリクスを自動では送信しません。CloudWatch agent のインストールが必要です（ログも送信可能）。「RAM が 80% を超えたら通知」→ CloudWatch agent + custom metric + alarm。
Custom metric は high-resolution（1 秒）にでき、このメトリクスに対する alarm は 10 秒または 30 秒ごとに評価できます。AWS の標準メトリクスは 1 分間隔です。より速さが必要なら高解像度メトリクスを自分で送信します。
CloudWatch alarm の状態は OK / ALARM / INSUFFICIENT_DATA の 3 つ。アクション：SNS 通知、scaling policy、EC2 action（stop、terminate、reboot、recover）、Systems Manager。ハードウェア障害時に EC2 を自動復旧：StatusCheckFailed_System に alarm を設定し、アクションを recover にします。
CloudWatch Logs はデフォルトでログを無期限に保持します。コスト削減のため log group ごとに retention を設定します。Metric filter はログ行をメトリクスに変換し（5xx エラーの件数など）、alarm を設定できるようにします。クエリには Logs Insights を使います。
Subscription filter はログをリアルタイムで Kinesis、Firehose、Lambda に送ります（その先は S3、OpenSearch など）。複数アカウントのログを 1 か所に集約したり、ほぼリアルタイムでログを分析したりする場合に使います。
CloudTrail は最初から有効です。Event history は各リージョンで management event を 90 日間保持します。より長く保存するには S3 に書き込む trail を作成します（または CloudTrail Lake）。Organization trail はすべてのアカウントを記録します。log file validation を有効にするとログの改ざんを検出できます。
Data event（S3 GetObject / PutObject、Lambda Invoke など）はデフォルトでは記録されず、追加料金がかかります。「誰がバケット内のオブジェクトを読んだ / 削除したか」と問われたら、そのバケットの data event を有効にする必要があります。
AWS Config は設定履歴を記録し、Config rules で準拠状況を評価します。Systems Manager Automation による自動修復（remediation）も可能です。「ポート 22 を 0.0.0.0/0 に開放した security group を検出して自動修正」→ Config rule + remediation。
X-Ray は 1 つのリクエストを複数のサービスにまたがって追跡します（service map、区間ごとのレイテンシー）。マイクロサービス / サーバーレスで遅い箇所やエラー箇所を探すなら X-Ray であり、CloudTrail ではありません。
Systems Manager：Session Manager（SSH、踏み台、ポート 22 なしでサーバーに接続）、Patch Manager、Run Command、Parameter Store、Automation。EC2 / オンプレミスのサーバーを一括でパッチ適用・管理します。プライベートサブネット内のサーバーには SSM の VPC endpoint または NAT が必要です。
CloudFormation：Infrastructure as Code（template → stack）。StackSets は複数アカウント / リージョンへデプロイし、drift detection は手動変更を検出します。別リージョンにまったく同じ環境を素早く一貫して再構築できます（DR、複数環境）。

構成図

CloudWatch alarm：メトリクスからアクションまで

メトリクスが所定の期間数しきい値を超えると、alarm は ALARM に移行してアクションを実行します：サーバー追加、チームへの通知、ハードウェア障害の instance の自動復旧。

ステップ

EC2 がメトリクスを送信します（5 分。detailed monitoring を有効にすると 1 分）。
Alarm は連続する複数の期間でしきい値と比較し、1 点のノイズによる誤報を避けます。
ALARM に移行：scaling policy を呼び出し、SNS を送信します。システム status check の alarm は instance を recover できます。

CloudWatch agent：OS 内部のメトリクスとアプリケーションログ

Agent はサーバー（EC2 またはオンプレミス）上のメモリ、ディスク、ログファイルを読み取ります。Metric filter はログ内のエラーを数えて alarm を設定でき、Logs Insights でクエリできます。

ステップ

Agent はメモリ / ディスクのメトリクス（namespace CWAgent）を送信し、ログファイルを log group に送ります。
Metric filter が ERROR 行をメトリクスに変換します。そのメトリクスやメモリに対する alarm が SNS で通知します。

CloudTrail：organization trail から専用ログアカウントへ

1 つの trail ですべてのアカウントとリージョンをカバーします。ログはログアカウントの S3 バケット（Object Lock、validation）と、機密性の高い操作を通知するための CloudWatch Logs に送られます。

ステップ

管理アカウントで作成した trail が、すべてのメンバーアカウントの API を記録します。
ログはログアカウントのバケットに保存され、改ざん / 削除から保護されます。lifecycle で Glacier に移行し、長期間安価に保持します。
同時に CloudWatch Logs にも送信し、metric filter で機密性の高い操作（root ログイン、IAM 変更）を捕捉して通知します。

AWS Config：設定ミスを検出して自動修正

Recorder はすべての設定変更を記録します。Config rule がリソースを評価し、非準拠なら Systems Manager Automation で remediation を実行します。

ステップ

設定変更のたびに configuration item として記録されます。
Config rule は設定が変わった時点で（または定期的に）評価します。
非準拠の場合：remediation がポート 22 を開放するルールを自動で削除し、同時にイベントを送信してチームに通知します。

subscription filter でログを S3 と OpenSearch に集約

Subscription filter はログをほぼリアルタイムで Firehose に送ります。Firehose は S3（長期保存、Athena）と OpenSearch（検索、ダッシュボード）に書き込みます。

ステップ

Lambda、EC2、VPC Flow Logs のログが CloudWatch Logs に集まります（Logs Insights で素早くクエリ）。
Subscription filter がログを Firehose に送り、S3 に安価に保存して OpenSearch で検索できるようにします。

X-Ray：1 つのリクエストを複数のサービスにまたがって追跡

各サービスが trace ID 付きの segment を記録し、X-Ray がそれらを組み合わせて service map を作り、どの区間が遅いか、エラーかを示します。

ステップ

リクエストは API Gateway、Lambda を経て DynamoDB と外部 API に到達します。trace ID は経路全体にわたって付与されます。
X-Ray が segment を組み合わせると、外部 API の呼び出しが所要時間のほとんどを占めていることがすぐにわかります。

Systems Manager でプライベートサブネットの EC2 を管理

サーバー上の SSM agent が VPC endpoint 経由でサービスに接続します（NAT 不要、インバウンドポートの開放不要）。Session Manager は SSH と踏み台を置き換え、Patch Manager はスケジュールに従ってパッチを適用します。

ステップ

エンジニアはコンソール / CLI からセッションを開始します。権限は IAM で制御され、セッションはログに記録されます。
SSM agent が VPC endpoint 経由で自ら外向きに接続します。パブリック IP、踏み台、ポート 22 のインバウンドルールは不要です。

CloudFormation StackSets：1 つの template で複数のアカウントとリージョンへ

Template がインフラを記述し、StackSets が対象のアカウント / リージョンに同一の stack を作成します。Drift detection はどのリソースが手動で変更されたかを示します。

ステップ

Git 上の template がインフラの唯一の信頼できる情報源です。
StackSet が同一の stack を複数のアカウントとリージョン（DR リージョンを含む）にデプロイします。

AWS Health：AWS の障害とメンテナンスに自動で対応

AWS Health は自分のリソースに関係するイベントを EventBridge に送信し、ルールが通知を送ったり自動化を実行したりします。

ステップ

AWS Health が自分のアカウント向けにイベント（サービス障害、予定されたメンテナンス）を発行します。
EventBridge ルールが当番チームに通知し、メンテナンス開始前に Lambda で対処を実行します。

CloudWatch alarm の 3 つの状態

新しく作成した alarm は INSUFFICIENT_DATA から始まります。欠落データの扱い（TreatMissingData）：missing（デフォルト）、notBreaching、breaching、ignore（直前の状態を維持）。EC2 の stop / terminate / reboot / recover アクションを持つ alarm は missing のままにし、ALARM のときだけアクションを実行させます。

ステップ

Alarm の作成直後やメトリクスがまだない場合は INSUFFICIENT_DATA となり、データポイントがそろうと OK または ALARM に移行します。
M out of N：例えば直近 5 期間のうち 3 期間がしきい値を超えると ALARM になり、アクション（SNS、Auto Scaling、EC2 action）を実行します。
所定の期間数しきい値内に戻ると OK に戻ります（OK に戻ったときに通知を送ることも可能）。
データ欠落時：TreatMissingData の設定次第です。missing → INSUFFICIENT_DATA、breaching はしきい値超過とみなし、notBreaching は正常とみなし、ignore は現状を維持します。

ログからアラートへ：metric filter と Logs Insights

Metric filter はログ内のパターン（例：「ERROR」）を数えてメトリクスにし、alarm を設定できるようにします。filter 作成後に届いたログにのみ適用され、過去のログは遡って数えません。Logs Insights は調査時にログをアドホックにクエリするために使います。

ステップ

アプリケーション（Lambda は自動で出力、EC2 は CloudWatch agent を使用）が log group にログを送ります。
Metric filter はパターンに一致した各行をメトリクス値に変換し、そのメトリクスの alarm がしきい値超過時に SNS を送信します。
調査時：Logs Insights で、事前にメトリクスを作成しなくてもログをクエリ、フィルタ、グループ化できます。

比較表

CloudWatch、CloudTrail、Config

	CloudWatch	CloudTrail	AWS Config
答える問い	システムがどう動いているか（メトリクス、ログ、alarm）	誰が、何を、いつ、どこから行ったか（API コール）	リソースがどう設定され、どう変わり、準拠しているか
データ	メトリクス、ログ、トレース（X-Ray / Application Signals）	API イベント（management、data、Insights）	時系列の Configuration item
アクション	Alarm → SNS、Auto Scaling、EC2 action	ログを S3 / CloudWatch Logs に送信、EventBridge	Config rule → remediation（SSM Automation）
出題例	CPU が 80% を超えたらサーバーを追加	誰が security group を削除したか？	どのバケットがパブリックか？どのボリュームが未暗号化か？

データの保持期間

種類	保持期間
解像度 60 秒未満のメトリクス	3 時間
1 分メトリクス	15 日
5 分メトリクス	63 日
1 時間メトリクス	455 日（15 か月）
CloudWatch Logs	デフォルトで無期限（retention を自分で設定）
CloudTrail Event history	90 日、management event のみ
CloudTrail trail	任意（ログは自分の S3 に保存）

Systems Manager：機能の選び方

要件	機能
ポート 22 を開けずに EC2 のシェルに入り、セッションログを残す	Session Manager
サーバー群全体の OS にスケジュールでパッチ適用	Patch Manager + Maintenance Window
数百台のサーバーで 1 つのコマンドを実行	Run Command
設定値、接続文字列の保存（KMS で暗号化可能）	Parameter Store
自動化された Runbook（例：Config の remediation）	Automation

よく出る出題パターン

1EC2 のメモリ使用率が 85% を超えたら通知する必要があります。

答えを見る

正解: CloudWatch agent をインストールして mem_used_percent を送信し、CloudWatch alarm → SNS を設定
メモリやディスク使用量は OS 内部のメトリクスであり、agent でしか読み取れません。

不正解: EC2 に標準で用意された MemoryUtilization メトリクスに alarm を設定
EC2 には標準のメモリメトリクスがありません。

不正解: detailed monitoring を有効化
間隔が 1 分になるだけで、メモリのメトリクスは得られません。

2ある security group が変更され、ポート 3389 がインターネットに開放されました。誰がいつ変更したかを知る必要があります。

答えを見る

正解: CloudTrail（Event history または trail の AuthorizeSecurityGroupIngress）
CloudTrail はすべての API コールの呼び出し元、時刻、送信元 IP を記録します。

不正解: EC2 の CloudWatch メトリクス
API 操作を記録しません。

不正解: VPC Flow Logs
ネットワークフローを記録するもので、誰が設定を変更したかは記録しません。

3すべての security group がポート 22 を 0.0.0.0/0 に開放していないかを継続的にチェックし、違反があれば自動修正する必要があります。

答えを見る

正解: AWS Config managed rule（restricted-ssh）+ Systems Manager Automation による自動 remediation
Config は設定が変わるたびに評価し、非準拠のリソースに対して remediation を実行します。

不正解: CloudTrail + 毎週手作業でログを確認
継続的でなく、自動修正もできません。

4監査要件により、organization 内の全アカウントの API ログを 7 年間、誰にも改ざんできない形で保存する必要があります。

答えを見る

正解: 専用ログアカウントの S3 バケットに書き込む Organization trail。log file validation、S3 Object Lock を有効にし、lifecycle で Glacier へ移行
1 つの trail で全アカウントをカバー。validation で改ざんを検出し、Object Lock で削除を防ぎます。

不正解: CloudTrail の Event history に頼る
90 日間のみで、アカウントごとです。

5S3 バケット内の機密ファイルを誰がダウンロードしたかを知る必要があります。

答えを見る

正解: そのバケットの CloudTrail data event を有効化（または S3 server access logging）
Data event はオブジェクトの読み取り / 書き込みを 1 回ずつ記録します。イベント数に応じて課金されます。

不正解: CloudTrail の Event history
management event しかありません。GetObject は data event です。

6Web アプリケーションが CloudWatch Logs にログを出力しています。5 分間で HTTP 500 エラーが 50 件を超えたら alarm を出す必要があります。

答えを見る

正解: log group に「500」を含む行を数える Metric filter を作成し、そのメトリクスに alarm を設定
Metric filter はログをメトリクスに変換し、alarm を設定できるようにします。

不正解: CloudTrail
アプリケーションログは読みません。

7サーバーレスアプリケーション（API Gateway → Lambda → DynamoDB）がときどき遅くなります。どの区間が遅延の原因かを突き止める必要があります。

答えを見る

正解: API Gateway と Lambda で AWS X-Ray トレースを有効化
トレースで区間ごとの所要時間と service map がわかります。

不正解: CloudTrail
管理系の API コールを記録するもので、リクエストのレイテンシーは測定しません。

8運用チームがプライベートサブネット内の EC2 のシェルに入る必要がありますが、会社はポート 22 の開放を禁止しており、踏み台も置きたくありません。

答えを見る

正解: Systems Manager Session Manager（SSM agent + IAM role、VPC endpoint：ssm、ssmmessages、ec2messages）
セッションは SSM のチャネルを通り、権限は IAM で管理し、セッションログは S3 / CloudWatch Logs に保存されます。

不正解: パブリックサブネットの Bastion host
問題文で踏み台は禁止されており、しかもポート 22 を開ける必要があります。

9DR のために 2 つ目のリージョンにまったく同じ環境を構築し、50 アカウントに同じセキュリティ設定をデプロイする必要があります。

答えを見る

正解: CloudFormation template。複数アカウント / リージョンへの展開には StackSets
Infrastructure as Code なので同一の環境を繰り返し構築でき、drift detection で手動変更を検出できます。

不正解: ドキュメントに従って手作業で構築
遅く、差異が生じやすいです。

10自社の EC2 に影響する AWS のハードウェアメンテナンスが予定されたら、チームに自動で通知する必要があります。

答えを見る

正解: AWS Health イベント → EventBridge ルール → SNS / Lambda
AWS Health は自分のリソースに関係する障害やメンテナンスのイベントを送信します。

不正解: CloudWatch の CPU メトリクス
メンテナンスの予定はわかりません。

早見表

何を監視 / 管理したいか？

やりたいこと	使うもの
メトリクスに基づく通知と自動アクション（scale、recover、SNS）	CloudWatch alarm · 図を見る
EC2 / オンプレミスのメモリ、ディスクのメトリクス、アプリケーションログ	CloudWatch agent · 図を見る
ログ内のエラーを数えて通知	Metric filter + alarm · 図を見る
誰がどの API を呼んだか	CloudTrail（trail / organization trail） · 図を見る
誰が S3 オブジェクトを読んだ / 書き込んだか	CloudTrail data event · 図を見る
設定履歴、準拠チェック、自動修正	AWS Config rules + remediation · 図を見る
ログをほぼリアルタイムで S3 / OpenSearch に送る	Subscription filter → Firehose · 図を見る
マイクロサービスの遅い区間を探す	AWS X-Ray · 図を見る
SSH なしでの接続、パッチ適用、コマンドの一括実行	Systems Manager · 図を見る
Infrastructure as Code、複数アカウント / リージョン	CloudFormation StackSets · 図を見る
自分に影響する AWS の障害 / メンテナンスを把握	AWS Health + EventBridge · 図を見る
コスト削減、セキュリティ、サービスクォータに関する推奨事項	Trusted Advisor

落とし穴

EC2 に標準のメモリメトリクスを探してしまう：CloudWatch agent のインストールが必要です。
detailed monitoring でメトリクスが増えると思い込む：5 分間隔が 1 分間隔になるだけです。
「誰がやったか」に CloudWatch を使う：それは CloudTrail です。
設定がルールに準拠しているかのチェックに CloudTrail を使う：それは AWS Config です。
Event history が無期限に保持されると思い込む：90 日間のみ、management event のみです。
data event を有効にし忘れ、誰が S3 オブジェクトを読んだかわからない。
log group を無期限保持のままにして、ログ保存料金の請求に驚く。
ポート 22 を開けて踏み台を構築する：Session Manager ならどちらも不要です。
プライベートサブネット内のサーバーに SSM の VPC endpoint（または NAT）がなく、Systems Manager に表示されない。
設定変更の監査に X-Ray を使う、またはレイテンシーの測定に CloudTrail を使う。
CloudFormation で作成したリソースを手作業で変更し、stack にずれ（drift）が生じる。

このモジュールのサービス

変わりやすい数値 (AWS ドキュメントで確認済み)

CloudWatch メトリクス：60 秒未満は 3 時間保持、1 分は 15 日、5 分は 63 日、1 時間は 455 日保持。Custom metric は high-resolution で 1 秒、high-resolution alarm の期間は 10 秒または 30 秒。 2026-10-16 確認 ↗
EC2 basic monitoring：5 分メトリクス（status check は 1 分）、無料。detailed monitoring：1 分、メトリクス単位で課金。 2026-10-16 確認 ↗
メモリ（mem_used_percent）、ディスク（disk_used_percent）のメトリクスは CloudWatch agent が収集し、EC2 のデフォルトメトリクスに追加されます。 2026-10-16 確認 ↗
CloudWatch Logs はデフォルトでログを無期限に保存します。retention は log group ごとに設定します。 2026-10-16 確認 ↗
CloudTrail Event history：各リージョンで management event を 90 日間、無料。data event は含みません。 2026-10-16 確認 ↗
Trail と event data store はデフォルトでは data event を記録しません。data event の記録には追加料金がかかります。 2026-10-16 確認 ↗
Alarm の状態は OK、ALARM、INSUFFICIENT_DATA の 3 つ。INSUFFICIENT_DATA には alarm を作成した直後も含まれます。 2026-10-19 確認 ↗
TreatMissingData：notBreaching、breaching、ignore、missing（デフォルト）。stop / terminate / reboot / recover のアクションを持つ EC2 の alarm は missing のままにします。 2026-10-19 確認 ↗
Metric filter は過去のログを遡って処理しません。filter 作成後に届いたログに対してのみデータポイントを作成します。 2026-10-19 確認 ↗

このモジュールの問題を解く →