SAA-036
プライベートサブネットのEC2インスタンスに、運用担当者がシェルアクセスする必要があります。踏み台サーバーを運用せず、インスタンスへのインバウンドポートも一切開けず、誰がいつ接続したかを監査できる構成として最も適したものはどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：C. AWS Systems Manager Session Managerを使用し、SSM Agentが必要なエンドポイントへ到達できるようにしてセッションを確立する
解説
Session Managerは、インスタンス上のSSM AgentからSystems Managerへのアウトバウンド接続を使ってセッションを確立します。インバウンドポートを開ける必要も踏み台も不要で、接続はIAMで制御され、操作はCloudTrailとセッションログで監査できます。
選択肢ごとの解説
A. パブリックサブネットに踏み台EC2を配置し、22番ポートを運用担当者の送信元IPだけに許可する
踏み台サーバー自体のパッチ適用・鍵管理・可用性という運用負荷が残り、22番ポートのインバウンドも開いたままです。「踏み台を運用しない」「インバウンドを開けない」という要件を満たしません。
B. 対象インスタンスにElastic IPを付与し、SSHの待ち受けポートを22番から変更したうえでキーペアで接続する
プライベートサブネットのインスタンスをインターネットへ露出させることになり、要件と逆行します。ポート番号を変えても待ち受け自体は残るため、実質的なセキュリティ向上にもなりません。
C. AWS Systems Manager Session Managerを使用し、SSM Agentが必要なエンドポイントへ到達できるようにしてセッションを確立する
正解です。アウトバウンド方向の接続だけでセッションが成立するため、セキュリティグループのインバウンドルールを空にしたまま運用できます。
D. EC2 Instance Connectを有効化し、マネジメントコンソールのブラウザ経由でSSH接続する
EC2 Instance Connectでコンソールから接続する構成は、インスタンスがEC2 Instance Connectサービスのプレフィックスリストからの22番インバウンドを許可し、かつ到達可能である必要があります。インバウンドを一切開けないという要件に反します。
実務での使いどころ
AWS Systems Manager Session Manager は、EC2 インスタンスやオンプレミスサーバーに対してブラウザまたは AWS CLI からシェルセッションを張れる機能である。仕組みの要点は通信の向きにあり、インスタンス上で動く SSM Agent が Systems Manager のエンドポイントへ「アウトバウンドで」接続し、その経路上にセッションを載せる。したがってインスタンス側のセキュリティグループにインバウンドルールを一切書かなくても接続でき、踏み台サーバーもキーペアも不要になる。接続の可否は IAM ポリシー（ssm:StartSession など）で制御され、誰がいつどのインスタンスに接続したかは CloudTrail に残る。 設計上の前提として、インスタンスには AmazonSSMManagedInstanceCore を含む IAM インスタンスプロファイルが必要で、かつ SSM のエンドポイントへ到達できる経路が必要になる。プライベートサブネットの場合、経路の作り方は 2 通りある。1 つは NAT Gateway 経由でインターネットへ出る方法、もう 1 つは ssm / ssmmessages / ec2messages の 3 つの Interface 型 VPC エンドポイントを作り、インターネットに出ずに到達させる方法である。後者は NAT Gateway の固定費を避けられ、通信を AWS ネットワーク内に留められる。セッションの内容は S3 や CloudWatch Logs へ記録でき、KMS でセッションを暗号化することもできる。 SAA-C03 では「踏み台サーバーをなくしたい」「SSH ポートを開けたくない」「キーペアを管理したくない」「接続を監査したい」という要件が出たら Session Manager が正解になる。誤答には踏み台 EC2 の構築、SSH ポート番号の変更、パブリック IP の付与といった従来型の構成が並ぶ。プライベートサブネットで NAT Gateway を使わずに済ませる文脈では、VPC エンドポイント 3 種の話まで踏み込んで問われることがある。