はじめる前に
- 必須AWS アカウントを持ち、マネジメントコンソールにサインインできること
- 必須VPC・プライベートサブネットを作成した経験があること
- 必須IAM ロールの基本的な経験があること（信頼されたエンティティ・ポリシーのアタッチなど）
- 必須ローカルに AWS CLI をインストールし、認証情報を設定済みであること（
aws configure済み） - あると良いNAT ゲートウェイまたは VPC エンドポイントのどちらかを扱った経験があること
※ ローカルの PowerShell から、AWS CLI と Session Manager プラグインを使って接続します。SSH クライアントや秘密鍵ファイルは一切使いません。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
SSH でサーバーに入るには、セキュリティグループでポート 22 を開け、秘密鍵ファイルを安全に管理し続ける必要があります。鍵が漏れたり、ポートが開いたままになっていたりすると、それ自体が攻撃の入り口になりかねません。
Systems Manager のSession Managerを使うと、インバウンドのポートを一切開けず、鍵ファイルも使わずに、IAM の権限だけでサーバーの中に入れます。今回はパブリック IP を持たないプライベートサブネットに EC2 を置き、外からの接続経路を完全に閉じたまま管理する構成を作ります。
SSH の代わりに Session Manager を使うと何が変わるの？
セキュリティグループで SSH（22 番ポート）を開ける必要がなくなり、秘密鍵ファイルの管理も不要になります。誰がいつ接続したかという記録も、Systems Manager 側で一元的に残ります。
プライベートサブネットの EC2 は、インターネットに出られないのにどうやって Systems Manager と通信するの？
2 つの方法があります。1 つはNAT ゲートウェイを経由してインターネット越しに Systems Manager のエンドポイントへ到達する方法、もう1つはVPC エンドポイントを使ってインターネットを経由せず AWS のネットワークの中だけで到達する方法です。どちらも今回の構成で選べます。
プライベートサブネット（パブリック IP なし）に EC2 を 1 台作成し、IAM ロールで Systems Manager の権限を持たせる。NAT ゲートウェイまたは VPC エンドポイントのいずれかの方法で Systems Manager への到達経路を用意し、ローカルの PowerShell から Session Manager プラグイン経由で EC2 に接続する。
つくる構成
プライベートサブネットの EC2 から Systems Manager へ到達する経路には、大きく 2 つの方式があります。どちらを選んでも、このあとの手順は同じように進められます。
プライベートサブネットの EC2 が、パブリックサブネットに置いた NAT ゲートウェイとインターネットゲートウェイを経由して、インターネット越しに Systems Manager のエンドポイントへアクセスします。
| 必要なリソース | NAT ゲートウェイ、Elastic IP、インターネットゲートウェイ、パブリックサブネット |
|---|---|
| 向いている場面 | NAT ゲートウェイを他の外向き通信（パッケージ更新など）にも使う予定がある場合 |
| コストの目安 | NAT ゲートウェイの起動時間とデータ処理量に応じた料金が発生 |
プライベートサブネットに置いたインターフェース型の VPC エンドポイントを経由し、インターネットを一切経由せず、AWS のネットワークの中だけで Systems Manager のエンドポイントへ到達します。
| 必要なリソース | 3 つの VPC エンドポイント（systems-manager / ssmmessages / ec2messages） |
|---|---|
| 向いている場面 | インターネットへの経路をそもそも持たせたくない、閉じたネットワークを保ちたい場合 |
| コストの目安 | インターフェース型エンドポイント 1 つあたり起動時間に応じた料金が発生（3 つ分） |
要件
以下の要件を満たす構成を作り、プライベートサブネットの EC2 に Session Manager 経由で接続できることを確認してください。
| No | 要件 |
|---|---|
| 1 | リージョンは「東京（ap-northeast-1）」を使用する。 |
| 2 | VPC 内にプライベートサブネットを 1 つ用意する（既存のものを使ってもよい）。 |
| 3 | EC2 用の IAM ロールを作成する（信頼されたエンティティ：AWS のサービス → EC2、ポリシー：AmazonSSMManagedInstanceCore）。 |
| 4 | NAT ゲートウェイまたはVPC エンドポイント（systems-manager / ssmmessages / ec2messages の 3 つのインターフェース型エンドポイント）のいずれかの方法で、プライベートサブネットから Systems Manager への到達経路を用意する（どちらを選ぶかは自由）。 |
| 5 | プライベートサブネットに EC2 を 1 台起動する（パブリック IP なし、手順 3 の IAM ロールを付与、Amazon Linux 2023）。セキュリティグループのインバウンドルールは 1 つも作らない。 |
| 6 | ローカルに AWS CLI・Session Manager プラグインを導入し、PowerShell から aws ssm start-session コマンドで EC2 に接続する。 |
構築の進め方
「IAM ロールを用意する → 到達経路を用意する → EC2 を起動する → ローカルから接続する」の順に積み上げます。各ステップで「なぜそうするのか」を意識すると理解が定着しやすくなります。
-
マネジメントコンソールにサインインし、リージョンを東京に合わせる
ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。
-
IAM ロールを作成する
IAM コンソールで「ロールを作成」を選び、信頼されたエンティティタイプに「AWS のサービス」、ユースケースに「EC2」を選びます。許可ポリシーで
AmazonSSMManagedInstanceCoreを検索してアタッチします。ロール名は自由に決めます（例：ec2-ssm-role）。このロールがあるから Systems Manager に見えるEC2 自体は Systems Manager に何かを申請するわけではなく、この IAM ロールの権限を使って Systems Manager のエージェントが通信できるようになります。ロールがないと、後の手順でインスタンスが一覧に表示されません。
-
プライベートサブネットを用意する
既存の VPC・プライベートサブネットがあれば、それを利用して構いません。新しく作る場合は、CIDR は VPC の範囲内で重ならなければ自由に決めます（例：
10.0.2.0/24）。 -
Systems Manager への到達経路を用意する
以下のどちらか一方を選んで進めます。両方作る必要はありません。
方式A を選んだ場合パブリックサブネットに NAT ゲートウェイを作成し（接続タイプ「パブリック」、新規 Elastic IP を割り当て）、プライベートサブネットのルートテーブルに
0.0.0.0/0→ NAT ゲートウェイの経路を追加します。方式B を選んだ場合VPC エンドポイントを 3 つ作成します（
com.amazonaws.ap-northeast-1.ssm、ssmmessages、ec2messages）。タイプは「インターフェース」、対象はプライベートサブネットを含むサブネット、セキュリティグループは VPC 内からの HTTPS（443）を許可するものを指定します。どちらも「到達経路」を作るという目的は同じ方式が違っても、最終的に確認することは同じです。「プライベートサブネットの EC2 が Systems Manager のエンドポイントに届くか」という一点に注目しましょう。
-
セキュリティグループを用意する
EC2 用のセキュリティグループを新規作成、または既存のものを選びます。インバウンドルールは 1 つも追加しません。（方式B を選んだ場合は、VPC エンドポイント用に別のセキュリティグループで VPC 内からの HTTPS を許可しますが、これは EC2 用のセキュリティグループとは別のものです。）
-
プライベートサブネットに EC2 を 1 台起動する
EC2 コンソールで「インスタンスを起動」を選び、次のように設定します。
AMI Amazon Linux 2023 ネットワーク 手順 3 のプライベートサブネット、パブリック IP の自動割り当ては無効 セキュリティグループ 手順 5 で用意したもの（インバウンドルールなし） IAM インスタンスプロフィール 手順 2 で作成した IAM ロール パブリック IP がないことを確認する起動設定の確認画面で、パブリック IP の自動割り当てが無効になっているかを必ず見ておきましょう。ここを間違えると、構成の前提（外からの接続経路を閉じる）が崩れてしまいます。
-
マネージドインスタンス一覧への表示を確認する
EC2 の起動から数分待ち、Systems Manager コンソールの「フリートマネージャー」または「マネージドインスタンス」一覧に、起動したインスタンスが表示されることを確認します。
表示されるまで少し時間がかかるインスタンスの起動・エージェントの初期化・到達経路の確立が完了するまで、数分程度かかることがあります。すぐに表示されなくても、少し時間を置いてから再読み込みしてみましょう。
-
ローカルの PowerShell に Session Manager プラグインを導入する
ローカルの PowerShell で AWS CLI が利用できることを確認します（
aws --version）。続けて、公式の msi インストーラーをダウンロードして実行し、Session Manager プラグインをインストールします。# AWS CLI が使えることを確認する aws --version # インストール後、プラグインが認識されているか確認する session-manager-plugin
インストール後はターミナルを開き直すインストール直後の同じ PowerShell ウィンドウでは、パスの変更が反映されず認識されないことがあります。一度ウィンドウを閉じて開き直してから試してみましょう。
-
PowerShell から Session Manager で接続する
EC2 コンソールでインスタンス ID を確認し、PowerShell から接続します。
# インスタンス ID を指定して接続する aws ssm start-session --target <インスタンスID> # 接続できたら、Amazon Linux 2023 であることを確認する hostname cat /etc/os-release # 接続を終了する exit
表示されたシェルの中で
hostnameやcat /etc/os-releaseを実行し、Amazon Linux 2023 のサーバーの中に入れたことを確認します。exitで接続を終了します。鍵もポートも使っていないことを振り返るここまでの接続で、SSH の秘密鍵ファイルや、セキュリティグループのインバウンドルールを一度も使っていません。接続を許可したのは、すべて IAM ロールの権限です。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。
「フリートマネージャーやマネージドインスタンスの一覧に、起動したはずのインスタンスが出てこない」
典型的な原因は 2 つあります。① IAM ロールが正しくアタッチされていない（インスタンスプロフィールの設定や、ポリシーのアタッチ漏れ）か、② NAT ゲートウェイまたは VPC エンドポイントどちらの到達経路も用意されていない（あるいは設定が不完全）かのいずれかであることが多いです。どちらの可能性も順に見直してみましょう。
「SessionManagerPlugin was not found のようなエラーが表示される」
Session Manager プラグインのインストールが完了していない可能性、またはインストール後に PowerShell のウィンドウを再起動していない可能性があります。インストール手順を見直し、新しいウィンドウを開いてから再度試してみましょう。
完了チェック
要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。コンソールと PowerShell の両方で、次を順に確かめましょう。
- Systems Manager コンソールの「マネージドインスタンス」一覧に、起動したプライベートサブネットの EC2 が表示されている。
- EC2 のセキュリティグループの「インバウンドルール」タブを開くと、ルールが 1 つも設定されていない。
- PowerShell から
aws ssm start-session --target <インスタンスID>を実行すると、エラーなくシェルが開く。 - 開いたシェルの中で
cat /etc/os-releaseを実行すると、Amazon Linux 2023 であることが確認できる。 - 選んだ方式（NAT ゲートウェイまたは VPC エンドポイント）のリソースが、コンソール上で想定どおり作成されている（NAT ゲートウェイなら状態が「Available」、VPC エンドポイントなら状態が「Available」で 3 つ揃っている）。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- SSH のセキュリティグループ管理（ポートを開け、鍵を配布・保管する）と比べて、Session Manager はどんな点で安全性を高めているでしょうか。
ヒント
「インバウンドのポートを開けない」「鍵ファイルという物理的な漏えいリスクのある要素を使わない」「接続できる人を IAM の権限だけで管理できる」という 3 つの観点から、それぞれどんなリスクが減るかを考えてみましょう。 - NAT ゲートウェイと VPC エンドポイント、それぞれを採用する場合のコストや運用上の向き・不向きはどう違いそうでしょうか。
ヒント
NAT ゲートウェイは 1 つで複数の用途（パッケージ更新など他の外向き通信）にも使えますが、インターネットを経由します。VPC エンドポイントはインターネットを経由しない代わりに、必要なサービスの数だけエンドポイントを作る必要があります。「他の外向き通信もまとめて必要か」という観点で考えてみましょう。 - Session Manager 経由での操作は、誰がいつ何をしたかをどうやって振り返られそうでしょうか。
ヒント
Session Manager はセッションの開始・終了や、実行されたコマンドの記録を残すことができます。SSH では別途仕組みを用意しないと残らない「操作の記録」が、最初から仕組みに組み込まれている点に注目してみましょう。
後片づけ
選んだ方式によって削除するリソースが異なります。次の順で進めましょう。
- EC2 を削除する：起動したインスタンスを選び「インスタンスの状態」→「インスタンスを終了」。
- （方式A を選んだ場合）NAT ゲートウェイを削除し、関連する Elastic IP を解放する：NAT ゲートウェイを削除したあと、使われなくなった Elastic IP アドレスも忘れずに解放する。
- （方式B を選んだ場合）3 つの VPC エンドポイントを削除する：
systems-manager/ssmmessages/ec2messagesの 3 つをすべて削除する。 - IAM ロールを削除する：手順 2 で作成したロールを IAM コンソールから削除する。
- セキュリティグループを削除する：このハンズオン用に作成したセキュリティグループを削除する。
削除するのは、このハンズオンで自分が作ったものだけ
既存の VPC やデフォルト VPC、他の用途で使っているサブネット・ルートテーブルなどは削除しないようにしましょう。VPC エンドポイントや NAT ゲートウェイの一覧には、他のハンズオンや検証用に作成したものが並んでいることもあるため、名前やタグでこのハンズオン用のものだけを選んで削除してください。
コストに関する注意: NAT ゲートウェイ（方式A）は、起動している時間に対する料金と、処理したデータ量に対する料金が発生します。VPC エンドポイント（インターフェース型、方式B）は 1 つあたり起動時間に応じた料金が発生し、今回は 3 つ作成するため 3 つ分の料金がかかります。Session Manager 自体の利用には追加料金はかかりません。EC2 インスタンス・IAM ロール・セキュリティグループ・VPC・サブネットには、それ自体の料金はかかりません。検証が終わったら、選んだ方式のリソース（NAT ゲートウェイと Elastic IP、または 3 つの VPC エンドポイント）を忘れずに削除しましょう。最新の料金は AWS の公式料金ページで確認してください。