AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

正解

A. マネージド対象インスタンスにSSM Agentがインストール済みであることを確認する

正解の 1 つです。インスタンスを Systems Manager のマネージドノードにする大前提が、SSM Agent がインストールされ稼働していることです。
Amazon Linux や Windows Server の AWS 提供 AMI にはプリインストールされていますが、独自に持ち込んだ AMI や古いイメージでは導入・起動状態の確認が必要です。
エージェントが動いていなければ、権限やエンドポイントを整えても管理対象として現れません。

正解

B. Systems Manager用のIAMインスタンスプロファイルを作成し、そのロールをプライベートサブネット内のEC2インスタンスにアタッチする

正解の 1 つです。インスタンスから Systems Manager の API を呼ぶ権限は、IAM ロールをインスタンスプロファイルとしてアタッチして渡します（マネージドポリシー AmazonSSMManagedInstanceCore が定番）。
これにより長期のアクセスキーをインスタンスに置く必要がなくなり、一時的な認証情報が自動配布・自動ローテーションされます。
権限が無いとエージェントは起動していても Systems Manager に登録されません。

正解

C. サービス名がcom.amazonaws.[region].ssm、com.amazonaws.[region].ec2messages、com.amazonaws.[region].ssmmessagesである3つのインターフェイスVPCエンドポイントを作成する

正解の 1 つです。インターネットに出られない環境では、AWS PrivateLink のインターフェース VPC エンドポイントで Systems Manager への到達性を確保します。
必要なのは ssm（API の呼び出し先）、ssmmessages（Session Manager や Run Command の制御チャネル）、ec2messages（SSM Agent から Systems Manager サービスへの呼び出し）の 3 つです。
エンドポイントに関連付けるセキュリティグループでは、マネージドインスタンスからの HTTPS（443 番）の着信を許可します。

D. マネージド対象インスタンスにアウトバウンドのインターネットアクセスを許可し、ssm.[region].amazonaws.com等の外部エンドポイントへHTTPS(443番ポート)で通信できるように構成する

アウトバウンドのインターネットアクセスを開ければ確かに Systems Manager には接続できますが、「インターネットアクセスのないプライベートサブネットに移行する」という要件そのものを壊します。
NAT ゲートウェイ経由であっても通信はいったん AWS ネットワークの外に出るため、閉じた経路を求める本問の設計方針に反します。
技術的に動くかどうかではなく、要件に合致するかで切る選択肢です。

E. サービス名がcom.amazonaws.[region].ssmのみのインターフェイスVPCエンドポイントを1つ作成する

ssm エンドポイントだけでは不十分です。Session Manager や Run Command のセッションは ssmmessages エンドポイントを経由し、SSM Agent から Systems Manager サービスへの呼び出しには ec2messages も使われます。
1 つに減らすとインスタンスがマネージドノードとして登録できない、あるいはセッションを開始できないという症状になります。
「エンドポイントは少ないほど安く済む」という発想に引っ張られてはいけません。

F. 各インターフェイスVPCエンドポイントに関連付けるセキュリティグループのインバウンドルールを、443番ポートではなく22番ポートを許可するように設定する

インターフェース VPC エンドポイントとの通信は HTTPS（443 番）で行われるため、22 番だけを許可したセキュリティグループでは一切通信できません。
そもそも Session Manager を使う最大の利点はSSH（22 番）のインバウンドを開けずに済むことであり、22 番を持ち出す発想自体が設計思想に反します。
踏み台サーバーや SSH 鍵の管理を無くすための構成だと理解しておきましょう。

構成図

IAM インスタンスプロファイル（AmazonSSMManagedInstanceCore）
   │ 権限を付与
   ▼
Amazon EC2（プライベートサブネット・SSM Agent 稼働）
   │ HTTPS 443
   ▼
インターフェース VPC エンドポイント
   ├ com.amazonaws.region.ssm
   ├ com.amazonaws.region.ec2messages
   └ com.amazonaws.region.ssmmessages
   │ AWS ネットワーク内で完結（インターネット経由なし）
   ▼
AWS Systems Manager

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
EC2 を Systems Manager のマネージドノードにする	大前提は SSM Agent の導入と稼働。AWS 提供 AMI はプリインストール済みだが独自 AMI では確認が必要 →選択肢（A）が正解
インスタンスから Systems Manager の API を呼ぶ権限が要る	長期のアクセスキーではなく IAM インスタンスプロファイル（AmazonSSMManagedInstanceCore）で渡す →選択肢（B）が正解
インターネットアクセスなしで AWS のエンドポイントに到達する	ssm / ec2messages / ssmmessages の 3 つのインターフェース VPC エンドポイントが必要。ssm だけでは Session Manager が成立しない →選択肢（C）が正解・選択肢（E）を消す
プライベートサブネットへ移行する（インターネットに出さない）	外部エンドポイントへの HTTPS 通信を許可する案は要件そのものに反する →選択肢（D）を消す
エンドポイントに関連付けるセキュリティグループの設定	インターフェースエンドポイントは HTTPS（443 番）で通信する。22 番の許可では到達できない →選択肢（F）を消す

ひっかけポイント

• 選択肢 E の「ssm だけで十分」は最頻出のひっかけ。Session Manager / Run Command の制御チャネルは ssmmessages で、エンドポイントを減らすとセッションを確立できない
• 選択肢 D はエージェントが確実につながる正攻法だが、「インターネットアクセスのない」という設問の前提を自ら壊す。動くかどうかではなく要件に合うかで判断する
• 選択肢 F の「22 番を許可」は、SSH のインバウンドを開けずに済むという Session Manager の最大の利点を否定している。エンドポイントとの通信はあくまで 443 番
• SSM Agent 3.3.40.0 以降は可能な場合に ssmmessages を優先して使うが、ec2messages も互換性のため作成しておくのが公式手順。「2 つで足りる」と早合点しない

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「Session Manager のセッションログを S3 や CloudWatch Logs に保存したい」	S3 のゲートウェイエンドポイントや logs / kms のインターフェースエンドポイントが追加で必要に。
「オンプレミスのサーバーも同じ仕組みで管理したい」	ハイブリッドアクティベーションによるマネージドノード登録と、そのための IAM サービスロールが正解軸に。
「踏み台サーバー（Bastion）を廃止したい」	Session Manager のシェルアクセスとポート転送が正解に。SSH ポートの開放も鍵管理も不要になる。
「誰がどのインスタンスに接続できるかを細かく制御したい」	IAM ポリシー＋タグ条件（ssm:resourceTag）による制御が正解軸に。
「パッチ適用状況を一元的に可視化・修復したい」	Patch Manager とパッチベースライン（および Systems Manager Inventory）が正解に。

関連サービスの解説

Amazon EC2
Amazon VPC
AWS Systems Manager

リファレンス

この問題を解くために必要な知識を扱う公式ドキュメントです。

知識項目	公式ドキュメント
Systems Manager のためのインターフェース VPC エンドポイント（ssm / ec2messages / ssmmessages）	Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する