【AWS_48_02】セッションマネージャーを利用してプライベートサブネットのEC2インスタンスへSSH接続する（NATゲートウェイがある場合）
セッションマネージャーについて一度記事を書いたのですが、あらためて検証をしてみるといろいろと疑問が出てきて、あらためて整理しないとと感じました。
それは以下３点の場合にそれぞれ設定は異なるがどうすればいいのだろうということでした。
・EC2インスタンスがパブリックサブネットにある場合
・EC2インスタンスがプライベートサブネットにあり、インターネットへのアウトバウンド通信経路がある場合
・EC2インスタンスがプライベートサブネットにあり、インターネットへのアウトバウンド通信経路がない場合
また、使用するユーザーが管理者レベル、一般ユーザーレベルで必要な設定も変わるのかなというところも疑問に思いました。
このあたりを検証して整理したいと思います。
今回は、「EC2インスタンスがプライベートサブネットにあり、インターネットへのアウトバウンド通信経路がある場合」を検証します。
アウトバウンド通信経路は、NATゲートウェイを利用します。
検証のポイントは、以下となります。
・プライベートサブネット内からVPC外部（AWS内部ネットワーク）へ接続する経路としてNATゲートウェイを作成する
・EC2インスタンスには、セッションマネージャー接続のためのIAMロール（AmazonSSMManagedInstanceCore）を割り当てる
・EC2インスタンス用のセキュリティグループを設定する（インバウンド：443ポート許可、アウトバウンド：デフォルト[すべてのトラフィック]）
※アウトバウンドはデフォルトですべてのトラフィックを許可しているのでそれを利用する
・管理者ユーザー（admin）へ、AdministratorAccessポリシーをアタッチする
・一般ユーザー（user01）へ、カスタマーポリシー、AmazonEC2FullAccessポリシーをアタッチする
目次
- 1 前提
- 2 VPCの作成
- 3 パブリックサブネットの作成
- 4 インターネットゲートウェイ、ルートテーブルの作成
- 5 プライベートサブネットの作成
- 6 プライベートサブネットへEC2インスタンスを作成
- 7 IAMロールを作成し、EC2インスタンスへアタッチ
- 8 EC2インスタンスのセキュリティグループの確認
- 9 NATゲートウェイの作成、プライベートサブネット用ルートテーブル更新
- 10 EC2インスタンスの再起動
- 11 セッションマネージャーからEC2インスタンスへ接続（admin：管理者）
- 12 一般ユーザー（user01）で接続するための設定
- 13 セッションマネージャーからEC2インスタンスへ接続（user01：一般ユーザー）
- 14 検証後のリソースの削除
- 15 まとめ
前提
設定は、admin（管理者）で作業しています。admin（管理者）には、AdministratorAccessポリシーを適用しています。
user01（一般ユーザー）は、作成済みとして進めます。
VPCの作成
VPCを作成します。作成方法がわからない方は、以下記事を参考にしてください。
パブリックサブネットの作成
パブリックサブネットを作成します。作成方法がわからない方は、以下記事を参考にしてください。
※VPC IDは、事前に作成したVPCのIDを選択します
※アベイラビリティーゾーンは、「指定なし」を選択します
※IPv4 サブネット CIDR ブロックは、10.0.1.0/24 で作成しています
インターネットゲートウェイ、ルートテーブルの作成
VPCの中に作成したパブリックサブネット（10.0.1.0/24）がインターネットと通信できるようインターネットゲートウェイ、ルートテーブルを作成します。
作成方法がわからない方は、以下記事を参考にしてください。
プライベートサブネットの作成
プライベートサブネットを作成します。作成方法がわからない方は、以下記事を参考にしてください。
※IPv4 サブネット CIDR ブロックは、10.0.2.0/24 で作成しています
プライベートサブネットへEC2インスタンスを作成
プライベートサブネットへEC2インスタンスを作成します。作成方法がわからない方は、以下記事を参考にしてください。
※サーバ名は、pri-sv にしました
※キーペアは、「キーペアなしで続行」を選択します
※パブリック IP の自動割り当ては、無効化にします
※セキュリティグループ名は、pri-sv-sg にしました
※セキュリティグループは、以下のとおり設定します。
・インバウンドルール
タイプ： SSH ⇒ HTTPS へ変更
ソース： 0.0.0.0/0
・アウトバウンドルール：デフォルトのまま（すべてのトラフィックを許可）
IAMロールを作成し、EC2インスタンスへアタッチ
IAMロールの作成
AWSマネジメントコンソールで「iam」を検索します。
左ペインのロールをクリック、画面右上の「ロールを作成」をクリックします。
「信頼されたエンティティタイプ」で「AWSのサービス」を選択します。
「ユースケース」で「EC2」を選択し、「次へ」をクリックします。
「許可ポリシー」で「AmazonSSMManagedInstanceCore」を検索し、左側にチェックを入れて「次へ」をクリックします。
「ロールの詳細」へロール名を入力します。
その他はデフォルトのままで「ロールを作成」をクリックします。
IAMロールが作成されました。
IAMロールをEC2インスタンスへアタッチ
AWSマネジメントコンソールで「ec2」を検索します。
左ペインのインスタンスをクリック、作成したEC2インスタンスにチェックを入れます。
アクション > セキュリティ > IAMロールを変更 をクリックします。
プルダウンから作成したIAMロールを選択し、「IAMロールの更新」をクリックします。
EC2インスタンスの「セキュリティ」タブでIAMロールがアタッチされていることを確認します。
EC2インスタンスのセキュリティグループの確認
AWSマネジメントコンソールで「ec2」を検索します。
左ペインのセキュリティグループをクリック、EC2インスタンス用のセキュリティグループ（pri-sv-sg）にチェックを入れます。
「インバウンドルール」タブは「HTTPS 許可」、「アウトバウンドルール」タブは、「すべてのトラフィックが許可」となっていることを確認しておきます。
NATゲートウェイの作成、プライベートサブネット用ルートテーブル更新
プライベート用サブネットに作成した新規インスタンスは、インターネットから接続できないため安全ですが逆にインターネットへ接続できないためアップデートやソフトウェアの新規インストールができません。
今回は、NATを構成するために「NATゲートウェイ」を作成、設定します。
プライベートサブネット用ルートテーブルは、VPCを作成した時に作成されたdefaultルートテーブルを利用します。
作成方法がわからない方は、以下記事を参考にしてください。
EC2インスタンスの再起動
参考サイトに「EC2インスタンスからシステムマネージャーへの接続は、インスタンス起動時に行われ、SSMエージェントがシステムマネージャーへ登録を行っている」とありましたのでEC2インスタンスを再起動します。
実際、再起動せずに接続しようとしたら失敗しました。
セッションマネージャーからEC2インスタンスへ接続（admin：管理者）
AWSマネジメントコンソールで「ec2」を検索します。
左ペインのインスタンスをクリック、作成したEC2インスタンスにチェックを入れ、「接続」をクリックします。
「接続」をクリックします。
※ここで「接続」ボタンがグレーアウトしていたら設定が反映されてないか、設定に不備があります
接続できました。「終了ボタン」やブラウザのタブを閉じるなどして切断することができます。
一般ユーザー（user01）で接続するための設定
一般ユーザー（user01）がEC2インスタンスへ接続するためには、EC2インスタンスを扱えるポリシーとセッションマネージャーに関するポリシーが必要になります。
今回、EC2インスタンスを扱えるポリシーは「AmazonEC2FullAccess」をアタッチし、
セッションマネージャーに関するポリシーは、カスタムポリシーをJSONで作成してアタッチします。
EC2インスタンスのインスタンスARNを確認
AWSマネジメントコンソールで「ec2」を検索します。
左ペインのインスタンスをクリック、該当のEC2インスタンスにチェックを入れます。
画面下の「詳細」タブを選択し、「インスタンスARN」の値を控えます。今回は「arn:aws:ec2:ap-northeast-1:750067409009:instance/i-0d25434800b788950」となります。
ポリシー作成の際に必要となります。
セッションマネージャーに関するポリシーの作成
AWSマネジメントコンソールで「iam」を検索します。
左ペインのポリシーをクリック、「ポリシーの作成」をクリックします。
「ポリシーエディタ」で「JSON」を選択します。
「ポリシーエディタ」にあるコードを一度削除し、上書きする形で新しいコードを貼り付けます。
■コード
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:ap-northeast-1:750067409009:instance/i-0d25434800b788950",
"arn:aws:ssm:ap-northeast-1:750067409009:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceInformation"
],
"Resource": [
"*"
]
}
]
}
任意のポリシー名を入力します。今回は「20250826-user01-policy」としました。
その他はデフォルトのままで「ポリシーの作成」をクリックします。
ポリシーが作成されました。
一般ユーザー（user01）へポリシーの適用
今回は、ユーザーへ直接アタッチします。
AWSマネジメントコンソールで「iam」を検索します。
左ペインのユーザーをクリック、ポリシーを適用したいユーザー選択します。今回は「user01」を選択します。
「許可」タブを選択し、「許可を追加」を選択します。
「許可のオプション」で「ポリシーを直接アタッチする」を選択します。
検索ウィンドウへ「AmazonEC2FullAccess」と入力し、表示された「AmazonEC2FullAccess」にチェックを入れます。
フィルタを一度解除（×印）し、次に作成したポリシー「20250826-user01-policy」にチェックを入れて、「次へ」をクリックします。
確認画面で「AmazonEC2FullAccess」と「20250826-user01-policy」が選択されていることを確認し、「許可を追加」をクリックします。
2つのポリシーが追加されたことを確認します。
セッションマネージャーからEC2インスタンスへ接続（user01：一般ユーザー）
admin（管理者）からサインアウトして、user01（一般ユーザー）でサインインします。
AWSマネジメントコンソールで「ec2」を検索します。
左ペインのインスタンスをクリック、作成したEC2インスタンスにチェックを入れ、「接続」をクリックします。
「接続」をクリックします。
※ここで「接続」ボタンがグレーアウトしていたら設定が反映されてないか、設定に不備があります
接続できました。「終了ボタン」やブラウザのタブを閉じるなどして切断することができます。
検証後のリソースの削除
簡単にですが、作成したリソースの削除について記載します。
・EC2インスタンス
削除
・NATゲートウェイ
削除
・defaultルートテーブルのNATゲートウェイ情報
削除
・Elastic IP
解放
・IAMロール
削除
・IAMポリシー
削除
・VPC
削除
まとめ
本検証にて、セッションマネージャーを利用してプライベートサブネットのEC2インスタンスへSSH接続（NATゲートウェイがある場合）することができました。
次は、セッションマネージャーを利用してプライベートサブネットのEC2インスタンスへSSH接続する（VPCエンドポイントがある場合）を検証したいと思います。
下、他の記事をまとめた一覧です。AWSもまとめています。
