2026-09-17（木）CloudWatch, CloudFormation

1. 【この範囲の全体像】

本範囲（第12章12-5、p.284-288）は、AWS上のコンピューティングリソース（EC2）およびオンプレミスのサーバー群を一元的に監視・管理・自動化する重要なガバナンスツールである「 AWS Systems Manager (SSM) 」を扱います [p.284]。

試験においては、踏み台サーバーやSSHキー管理という「セキュリティ上の脆弱性になりやすい運用負荷」を極限まで排除し、安全にリモート接続（Session Manager）や一括遠隔操作（Run Command）、OSパッチ自動更新（Patch Manager）をいかに最小の運用コストで設計・デプロイできるかが問われます [p.284, p.285]。

クラウドにおける「運用の優秀性」と「セキュリティ」を両立させるための、AWS推奨アーキテクチャの必須知識が詰め込まれた最頻出領域です [p.284]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
AWS Systems Manager (SSM) [p.284]	EC2インスタンスやオンプレミスのサーバー群を、管理コンソールやAPIから一元的に管理・自動操作・ガバナンス統制できるフルマネージドな運用管理サービス [p.284]。
SSM Agent (SSM エージェント) [p.284]	管理対象のEC2インスタンス（またはオンプレミス物理・仮想サーバー）のOS内部にインストールしておく必要がある軽量な管理プログラム [p.284]。SSMはこのエージェントとのHTTPSアウトバウンド通信を介して、様々な運用コマンドや内部メタデータの制御を行います [p.284]。
Session Manager (セッションマネージャー) [p.285]	SSHキーの管理や、踏み台サーバーの構築、およびセキュリティグループでのインバウンドポート（SSH用22番やRDP用3389番）の開放を一切行うことなく、AWSマネージドコンソールやCLIからEC2インスタンスにセキュアにログインできるインタラクティブなシェル接続機能 [p.285]。
Run Command (ランコマンド) [p.285]	踏み台サーバーを構築することなく、多数の対象インスタンス群（ターゲットグループ）に対して、一括して任意のコマンド（シェルスクリプトやPowerShell）を安全かつ迅速に遠隔実行させる自動化機能 [p.285]。
Patch Manager (パッチマネージャー) [p.285]	OSのセキュリティアップデートやバグ修正パッチの適用プロセスを、あらかじめ定義したルール（パッチ基準）に従って自動的にスケジュール化し、大量のインスタンス群に対して安全に一括適用・状況監査を行う機能 [p.285]。
Inventory (インベントリ) [p.285]	対象インスタンス群から、インストールされているアプリケーション、パッチの適用状況、OSの設定、ネットワーク構成などの詳細な「システム構成メタデータ情報」を定期的に収集し、一覧化して追跡監査する機能 [p.285]。
Parameter Store (SSM パラメータストア) [p.209]	データベース接続用の文字列、ライセンスキー、パスワードなどのパラメータ構成データを、安全なテキスト、または暗号化されたテキスト（`SecureString`）として階層構造で一元管理できる保管コンポーネント [p.209]。

3. 【試験で問われる比較ポイント】

① リモート接続の境界線：従来のSSH（踏み台含む） vs Systems Manager Session Manager [p.285]

「セキュリティ管理コストの低減」および「詳細な操作ログの証跡保存」という試験のキラー要件から切り分けます [p.245, p.285]。

比較項目	従来の SSH / RDP による直接接続	Systems Manager Session Manager [p.285]
セキュリティグループのインバウンドルール	インターネット（または特定拠点）に向けて、SSH（22番）やRDP（3389番）などのインバウンドポートを開放する設定が必須 [p.36, p.59]。	インバウンドポートの開放は100%「完全不要」。SSMエージェントからAWSのエンドポイントへのアウトバウンドHTTPS（443ポート）のみで通信が成立する [p.284, p.285]。
踏み台サーバー(Bastion)や SSHキーペアの管理	踏み台サーバーのパッチ管理・冗長化や、各開発者へのSSHプライベートキー（`.pem`ファイル）の厳重な配布・ローテーション管理コストが発生する [p.57, p.184]。	踏み台サーバーも、SSHキーペアの管理も一切不要。インフラの管理コストとキー流出による侵入リスクを完全に「ゼロ」に抑えられる [p.285]。
接続ユーザーのアクセス認証	OS内部のユーザー認証（`authorized_keys` ファイルへの公開鍵登録など）に依存する [p.62]。	AWSの IAM ポリシーでアクセス権限を完璧に一元制御可能 [p.181]。特定のIAMに対してのみ、特定の時間や特定のEC2への接続を厳密に制限できる [p.184]。
ユーザー操作履歴の監査性	各OSのヒストリログ（`history`）に依存するため、悪意ある管理者によるログの改ざん・物理消去リスクが残る。	入力された全ての操作・出力ログコマンドを、改ざん不能な形で Amazon S3 や CloudWatch Logs に完全自動転送してリアルタイム保持・証明できる [p.101, p.245]。

② 機密パラメータ管理の使い分け：SSM Parameter Store vs AWS Secrets Manager [p.209]

類似するパラメータ管理機能について、「自動的なローテーション（更新）機能」の有無から最適なシステムをマッピングします [p.209]。

比較項目	SSM Parameter Store [p.209]	AWS Secrets Manager [p.209]
主な用途	システムの設定値、ライセンスキー、各種環境変数、暗号化したパスワードの統合管理 [p.209]。	本番データベースやサードパーティ製APIの機微な認証キー、各種パスワード情報 [p.209]。
自動ローテーション（鍵・パスワードの自動更新）	非サポート（値の更新が必要な場合は、ユーザーが新しい値を手動で登録し直す必要がある） [p.209]。	フルサポート。KMSやAWS Lambda関数等と自動連動し、データベース（RDSなど）の接続パスワードを「30日ごと」などのスケジュールで自動的に自動更新（ローテーション）可能 [p.209]。
利用料金の特性	標準パラメータ（最大10,000個、パラメータサイズ4KB）の使用は、クエリ料金を含めて「完全無料」 [p.209]。	有料。保存されているシークレット数およびAPIコール数に応じて、定常の管理費用が発生する [p.209]。
決定的な選定シグナル	「ライセンスキーや暗号パラメータを、追加の課金コストを完全に抑えて一元管理・参照したい」 [p.209]。	「本番のデータベースパスワードが漏洩するリスクを防ぐため、セキュリティ監査基準に従って接続資格情報を自動的かつ定期的に再生成（更新）させたい」 [p.209]。

4. 【ひっかけ注意ポイント】

ひっかけ①：「社内ネットワーク上のセキュリティガバナンスを極限まで高めるため、VPC内のEC2インスタンス群を『インターネットゲートウェイを持たない、かつルートテーブルにもNATゲートウェイへの接続経路がない完全なプライベートサブネット』に配置した。この最高セキュリティ環境のEC2に対し、踏み台サーバーなしで安全にSession Managerを使ってログインさせるため、EC2にSSMエージェントがインストールされていることを確認して接続を試みた。」
- 真実: システムは無応答となり、Session Managerによるリモート接続（ログイン）は100%接続エラーとなります [p.39, p.284]。
- 理由: SSMエージェントは、AWSが提供する「Systems ManagerのグローバルパブリックAPIエンドポイント」に対して、OS内部からアウトバウンド（発信）のHTTPS（ポート443）通信を行って認証を確立する仕様だからです [p.284]。インターネットゲートウェイもNATゲートウェイも存在しないプライベート空間では、エージェントがSSMエンドポイントと通信できず迷子になります [p.37, p.284]。
- 対策: インターネットに一切パケットを出さない極小プライベート環境においてSSM接続を成功させるには、VPC内部に「 インターフェース型VPCエンドポイント（AWS PrivateLink） 」（具体的には ssm、ssmmessages、ec2messages の3つのプライベートエンドポイント）を構築・デプロイし、プライベートIPアドレスを介してVPC内部のみでSSMシステムと閉域疎通させる設計が不可欠です [p.39, p.284]。
ひっかけ②：「セキュリティ監査への適合性向上を目指し、アプリケーションからデータベースへの接続パスワードをSSM Parameter Storeへ『SecureString（暗号化タイプ）』として登録した。EC2にアタッチしたIAMロールのポリシーにおいて、Parameter Storeからの値の取得権限である『ssm:GetParameters』をフル許可（Allow）に設定したため、アプリケーションの起動時プログラムはParameter Storeからデータを引き出すだけで、即座に自動復号されたプレーンテキストのパスワードを読み取って処理を完了できる。」
- 真実: 暗号化された値の読み取り時にAPIアクセス拒否エラー（Access Denied）となり、アプリケーションはデータベースに一切接続できません [p.184, p.200]。
- 理由: Parameter Storeの暗号化パラメータタイプ（SecureString）は、内部的に AWS KMS (Key Management Service) の暗号キーと強力に統合されているためです [p.200]。値を読み取ってプログラムでプレーンテキスト（復号データ）として扱わせるためには、SSMへのAPI呼び出し権限だけでなく、暗号を解くためのKMSキーに対する『kms:Decrypt（復号）』アクションを実行するための実効権限が、EC2インスタンスアソシエイトのIAMロール側にアタッチされていないと、システム的に復号が遮断される仕様によるものです [p.184, p.200]。
ひっかけ③：「オンプレミス環境にある数十台の重要な物理監査サーバー群に対して、AWS上のEC2と同一の設定基準・ポリシーを一元適用し、セキュリティパッチの適用プロセスを自動化したいと考えた。これを実現するため、オンプレサーバーの中に『SSM Agent』をダウンロードしてインストールしたが、AWS上のSystems Managerコンソールの『マネージドインスタンス』一覧にオンプレサーバーが1台も登録されず、管理制御できない状態になった。」
- 真実: エージェントをインストールしただけでは、オンプレのサーバーはAWSのSSMから物理的に管理することはできません [p.284]。
- 理由: AWSで自動構築されるEC2インスタンスとは異なり、オンプレミスの物理的なサーバーは「AWSによるIAMの認証境界の外側」にあるリソースであるため、SSMシステムがオンプレ側からのHTTPS要求を「安全で正規なアクセスである」と自律認証できないためです [p.284]。
- 対策: オンプレサーバーをAWSのSystems Managerに正常登録・安全に同期通信させるには、事前にAWSのSystems Managerコンソールから「 ハイブリッドアクティベーション（Hybrid Activation） 」を作成し、それによって発行される一意の「アクティベーションコード」と「アクティベーションID」を、オンプレ側のSSM Agentの初期セットアップ設定に焼き込んで認証マウントさせる手順が必要です [p.284]。これにより、オンプレサーバーに対して安全なIAMサービスロールがアタッチされ、EC2と同様に一元管理が確立されます [p.184, p.284]。