バスティオンは「古いから悪い」というより、要件が増えた今の運用に対して負債になりやすいのが問題です。踏み台EC2を置くと、SSH鍵の配布やローテーション、入退社時の棚卸し、踏み台自体のパッチ適用、経路の固定化、監査ログの整備など、やることが一気に増えます。
一方で AWS Systems Manager Session Manager は、マネージドノードに対するシェル接続を、踏み台や受信ポート開放なしで実現し、さらにセッションログの記録など運用に必要な要素まで一緒に設計できます。Session ManagerはSystems Managerの機能のひとつとして提供され、セッションのログ記録や暗号化、セッションの制御などのオプションが用意されています。
この記事はSAA-C03学習者向けに、暗記ではなく「なぜそう設計するのか」を軸に、バスティオンとSession Managerを要件から選べる状態にすることを目標にします。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
バスティオン設計の本質と限界
バスティオンは、プライベートサブネットのEC2に入るための「中継点」を1か所に集約する考え方です。ネットワーク的にはシンプルで、昔からよく使われてきました。ただ、運用設計に落とすと次の負担が出ます。
鍵と認証情報の管理が運用コストになる
- SSH鍵の発行、配布、失効、棚卸し
- 共有鍵運用になった瞬間に、監査性が落ちやすい
- 踏み台自体に多人数がログインするため、端末管理まで含めた統制が必要
踏み台そのものが「守るべきサーバ」になる
- 踏み台OSやミドルウェアの脆弱性対応
- 監視、バックアップ、障害対応
- 踏み台に到達できる経路が攻撃面になる
監査ログが後付けになりやすい
- SSHの実行コマンド履歴をどこまで残すか
- いつ誰が入ったかは残っても、何をしたかが残らないことが多い
- ログの保全や改ざん耐性をどう担保するか
ここで重要なのは、「バスティオンがダメ」ではなく、要件が増えるほど設計の手数が増える点です。逆に言えば、要件が限定的なら、バスティオンが今でも妥当なこともあります。
バスティオンが今でも合理的になり得るケース
- すでに強固な端末統制があり、鍵管理と監査が仕組み化されている
- 一時的な移行期間で、既存運用を崩せない
- Systems Managerが使いにくい特殊な事情がある（極端に制限されたOS、エージェント導入制約など）
ただし、多くの環境では「踏み台を守る」より「踏み台を置かない」方向が設計として楽になります。そこでSession Managerです。
Session Managerの仕組みを設計目線で理解する
Session Managerを理解するコツは、「SSHの代替ツール」ではなく、接続をAWS管理プレーンに寄せて統制する仕組みと捉えることです。Session ManagerはSystems Managerの機能として、マネージドノードへのセッション接続や、セッションで許可する操作の制御、ポート転送などを提供します。
登場人物は4つだけで良い
- 接続される側：EC2などのマネージドノード
- エージェント：SSM Agent
- 権限：IAM（誰が、どのノードに、何をしに入れるか）
- 受け皿：Systems Manager（セッション確立や制御、ログ連携）
どこを通ってつながるのか
Session Managerは、ノードに対して受信ポートを開ける必要がありません。ノード側はSSM AgentがSystems Managerと通信できればよく、インターネットに出さない設計も可能です。その場合はVPCエンドポイントを使って閉域で通信させます。
ポイントとして、SSM Agentの新しめの挙動では、ssmmessages 側を優先する旨がAWSドキュメントに明記されています（エンドポイント設計の前提が変わりやすいので、ここは公式を基準にするのが安全です）。
SSHやポート転送もできるが、設計が必要
Session Managerは、単なるシェル接続だけでなく、セッションタイプのSSMドキュメントを使ってトンネルのようにポート転送することもできます。
ただし、これは「何でもトンネルできて便利」というより、許可してよい用途だけを設計で縛るのが本筋です。最小権限の観点でも、SAA-C03の観点でも、ここが理解の分かれ道になります。
Session Manager設計の基本チェックリスト
ここからは「設計の型」です。環境が違っても、次の順で考えると迷いにくくなります。
認証と認可を最初に固める
Session Managerは「ログインできること」より、誰がどのノードに入れるかが重要です。
- ノード側の権限
EC2をSystems Managerで管理するには、インスタンスプロファイルなどで必要な権限を与えます。AWSはインスタンス権限の設定方法として、デフォルトのホスト管理設定やIAMインスタンスプロファイルを案内しています。
学習段階では、まず「ノードがマネージドノードとして認識される」状態を作るのが第一歩です。 - 人側の権限
「運用担当は本番に入れるが開発者は入れない」や「参照専用のセッションにしたい」など、要件をIAMに落とします。ここは暗記よりも、要件を文章で書いてからIAMに落とす練習が効きます。
ネットワークを閉じるならVPCエンドポイントを前提にする
プライベートサブネット運用で「インターネットに出さない」をやりたい場合、VPCエンドポイント設計がセットになります。Session Managerのセットアップ手順にも、VPCエンドポイントを使うステップが用意されています。
考え方はシンプルで、
- ノードがSystems Managerに到達できる経路を用意する
- その経路をインターネットに出さずに完結させたいなら、VPCエンドポイントで閉じる
というだけです。
監査とログを最初から要件に入れる
Session Managerの強みは「ログが取りやすい」ことです。逆に、ここを設計しないと強みが半減します。
- CloudWatch Logsへ送る
Session Managerはセッション終了時にログをCloudWatch Logsへ送る設定ができ、KMSで暗号化して送る設定も案内されています。 - S3へ送って長期保管する
S3へログ保存する設定も手順として提供され、暗号化やカスタマー管理キー利用時の注意点も公式にまとまっています。 - 設計の勘所
- 「誰がいつ入ったか」だけでなく「何をしたか」を残すか
- ログの保管期間とアクセス権
- KMSキーの権限設計（運用担当が復号できるのか、監査担当だけが見られるのか）
SAA-C03でも、暗号化やログ保管の設計は前提として扱われやすいので、Session Managerを題材にすると整理が進みます。
セッション設定は運用ルールとセットで決める
Session Managerにはプリファレンスやシェルプロファイルの設定など、運用を整えるための設定が用意されています。
「本番は開始ディレクトリを固定する」「環境変数を最小限にする」など、運用ルールに合わせて寄せられます。
よくあるつまずきとトラブルシュート
Session Managerが「つながらない」とき、闇雲に触ると時間が溶けます。確認は次の順が安定です。
マネージドノードとして見えているか
- そもそもSystems Managerがノードを管理対象として認識できているか
- ノード側の権限設定が満たせているか（インスタンス権限の公式手順に戻る）
ネットワーク経路が成立しているか
- インターネット経由で出すならNATなどの経路
- 閉域にするならVPCエンドポイントが必要で、Systems Manager向けのVPCエンドポイントの案内が公式にあります
ログが残らない 暗号化で詰まる
- CloudWatch Logs送信の設定手順と、KMS暗号化の前提を確認する
- S3保管でカスタマー管理キーを使う場合、キー利用権限が必要になる点は公式の注意に従う
ssm-userをどう扱うかで迷う
Session Managerでは、OS側ユーザーの扱いも設計論点になります。結論としては、チームの統制方針次第です。
- 「本番は個別ユーザーで入りたい」なら、OSユーザー管理と紐付け設計が要る
- 「運用作業はロールで統制する」なら、Session Manager側の制御とログで担保する
ここは会社や案件で正解が変わりやすいので、試験対策としては「要件で決める」思考を優先するとブレにくいです。
SAA-C03向けの理解の固め方とUdemy活用
SAA-C03では、サービス名を丸暗記するより「要件から設計を選ぶ」力が効きます。Session Managerはその練習題材としてちょうど良いです。
思考の型はこの3行で足りる
- 受信ポートを開けずに管理したい
- 監査ログを残し、最小権限で入退室を制御したい
- インターネットに出さずに管理したいならVPCエンドポイントを使う
この型で問題文を読むと、「踏み台を立てる」「SSHを開ける」以外の選択肢が自然に見えるようになります。
ありがちな混乱ポイント
- 「プライベートだから踏み台が必要」と決め打ちしてしまう
- 「SSMが便利」だけで終わって、ログと暗号化設計まで考えない
- VPCエンドポイントの前提を曖昧にして、どこを通る通信か説明できない
このあたりは、理解していないと混乱しやすいポイントです。
体系的に学べる教材の一例としてUdemy
独学だと、IAM・ネットワーク・ログ設計をバラバラに学んでしまい、最後に繋がらないことが多いです。
Udemyには、ハンズオンで「Session Managerで接続できる状態を作る → 閉域化する → ログを残す」までを一連で学べる講座が複数あります。講座選びでは、次を満たすものが学習効率が高いです。
- Session Managerの前提条件と権限設計を丁寧に説明している
- VPCエンドポイントでインターネットなし構成を扱う
- CloudWatch LogsやS3へのログ記録、KMS暗号化まで触れる
教材はあくまで一例ですが、点ではなく線で理解したいときに役立ちます。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
バスティオンは今でも使われますが、運用要件が増えるほど「踏み台を守るコスト」が効いてきます。Session Managerは、踏み台や受信ポート開放に頼らず、IAMで入退室を制御し、ログ記録や暗号化まで含めて統制しやすいのが強みです。
設計のポイントは、ツールの暗記ではなく、要件から逆算することです。
- 誰がどのノードに入れるべきか
- インターネットに出さないならVPCエンドポイントをどう置くか
- 監査ログをCloudWatch LogsやS3へどう残し、KMSでどう守るか
この3点を筋道立てて説明できるようになると、SAA-C03の設計問題でも選択肢の見え方が変わってきます。
