はじめに
こんばんは。
めっきり寒くなってきましたね。
秋服の出番がほとんどなくて寂しかったです。
さて、今回はSSMのセッションマネージャーを使ってインターネット接続なし(NAT-gatewaysも利用しない)でEC2に接続してみたいと思います。
結論ファースト
構成に必要なものは先に以下にまとめておきます。
- ssm-agentがプリインストールされたAMI
- VPCエンドポイント用のセキュリティグループ
(VPCcidrからのHTTPSトラフィックを許可するインバウンドルール) - VPCのDNS有効化
- VPCエンドポイント
①com.amazonaws.ap-northeast-1.ssm
②com.amazonaws.ap-northeast-1.ec2messages
③com.amazonaws.ap-northeast-1.ssmmessages - EC2用IAMロール(AmazonSSMManagedInstanceCoreポリシー)
では以下にて実際に進めてまいります。
作業
VPCエンドポイント作成
インターネットにアクセスしない構成にするにはVPCエンドポイントを利用します。
特に、セッションマネージャーで接続するには以下3つのVPCエンドポイントの作成が必要となります。
- com.amazonaws.[region].ssm
- com.amazonaws.[region].ec2messages
- com.amazonaws.[region].ssmmessages
まず、以下でVPCエンドポイントを利用するための前提条件を整えていきます。
事前確認・作業
-
[DNSホスト名]と[DNS解決]がともに有効になっていることを確認します。
※ VPCのナビゲーションペインから[お使いのVPC]のページを開き、利用するVPCを選択して詳細タブから確認できます。
-
VPCエンドポイントに関連付けるセキュリティグループを作成し、インバウンドルールに利用するVPCからのHTTPS通信を許可するルールを追加します(アウトバウンドはデフォルトのままです)。
※その他、NACLを設定している場合や、AWS PrivateLinkのquotaの確認などが必要ですが本記事では触れません。
com.amazonaws.[region].ssm
前提が整ったのでVPCエンドポイントを作成していきます。
-
VPCのナビゲーションペインからエンドポイントのページを開き、[エンドポイントを作成]をクリックします。
-
[AWSのリソース]を選択し、[サービス名]でssmと入力すると候補が表示されますので選択します。
-
VPCを選択します。[DNS名を有効化]にチェックをつけます。利用するAZとサブネットも選択します。
※ 今回はEC2インスタンスがデプロイされるサブネットと同じプライベートサブネットを選択します。
-
先ほど作成したセキュリティグループを選択します。ポリシーについては今回特に設けません。そのまま画面下部の[エンドポイントを作成]をクリックします。
com.amazonaws.[region].ec2messages
上と同様の作業を繰り返します。
com.amazonaws.[region].ssmmessages
上と同様の作業を繰り返します。
※ なお、作成するVPCエンドポイントの配置についてですが、AWS re:post では以下のように言及されています。
注: 同じアベイラビリティーゾーンに複数のサブネットがある場合、追加のサブネット用に VPC エンドポイントを作成する必要はありません。同じアベイラビリティーゾーン内の他のサブネットは、インターフェイスにアクセスして使用することができます。
可用性を考慮してVPCエンドポイントを複数作成する場合に関しては、異なるアベイラビリティゾーンに作成するのがよさそうです。
EC2起動
VPCエンドポイントの作成が完了したので次はEC2の準備です。
SSM用ロールの作成
まずはEC2に関連付けるSSM用のロールを作成します。
-
IAMのナビゲーションペインからロールのページを開き、[ロールを作成]をクリックします。
-
信頼されたエンティティで[AWS のサービス]を選択し、ユースケースのサービスまたはユースケースで[EC2]を選び、表示される選択肢の中から[EC2 Role for AWS Systems Manager]を選択して画面下部(キャプチャには映っていませんが)の[次へ]をクリックします。
-
デフォルトでAmazonSSMManagedInstanceCoreというポリシーがロールに追加されています。
SSMにはこのポリシーが必要ですのでこのまま[次へ]をクリックします。
-
ロール名を入力して画面下部の[ロールを作成]をクリックするとロール作成完了です。
あとでEC2に関連付けるためにロール名はコピーして控えておきます。
EC2用のセキュリティグループの作成
- SSMのセッションマネージャの利点を活かして、今回はインバウンドトラフィックについては、SSH含めてすべてのポートを閉じたいと思います。(アウトバウンドはデフォルトのままです。)
EC2起動
さて、いよいよEC2起動です。
使用するAMIにssm-agentがプリインストールされていなければなりません。
もし、利用したいAMIにssm-agentがプリインストールされていない場合は以下の記事を参考にしてみてください。RHEL9ですが、ssm-agentのインストール、AMIの作成、privateサブネットでのセッションマネージャー接続確認まで行っています。
参考: RHEL9にSSMエージェントをインストールしてセッションマネージャで接続するまで
https://cloud5.jp/ssm-agent-in-rhel9/
もちろん、Amazon Linux 2などのssm-agentがプリインストールされているAMIを利用される場合は特に意識することはありません。
画像は省略しますが、対象のVPC、サブネット、セキュリティグループ、IAMロールを選んでいき、EC2を起動します。
なお、今回SSHはしませんのでキーペアの作成は不要です。
その他インスタンスタイプやストレージ設定はデフォルトのままで構いません。
セッションマネージャで接続確認
起動ができたらセッションマネージャーで接続してみましょう。
接続できました!!
おわりに
いかがだったでしょうか。
今回構成するうえで必要だったものを再掲します。
- VPCエンドポイント用のセキュリティグループ
(VPCcidrからのHTTPSトラフィックを許可するインバウンドルール) - VPCのDNS有効化
- VPCエンドポイント
①com.amazonaws.ap-northeast-1.ssm
②com.amazonaws.ap-northeast-1.ec2messages
③com.amazonaws.ap-northeast-1.ssmmessages - EC2用IAMロール(AmazonSSMManagedInstanceCoreポリシー)
- ssm-agentがプリインストールされたAMI
ではまたどこかでお会いしましょう!
あでゅー!!