Session ManagerでのEC2接続を後から追加した別のサブネットで使おうとしたときの話
はじめに
安全な環境でEC2を使うために、プライベートサブネットにEC2を構築してSession Managerで接続することがあります。
新しく追加したプライベートサブネットに構築したEC2に接続しようとしたときの話を記載していきたいと思います。
システム構成
Private subnet 1上のInstance 1にSession Managerで接続できている状況で、
後からPrivate subnet 2を追加し、Instance 2もSession Managerで接続を試みました。
使ってみた
いつも通りにVPCエンドポイントを作ろうとしたら、次のようなエラーに遭遇。
VPC内は共通でエンドポイントを使うのか…。と思ったものの、Instance 1と同じセキュリティグループを設定しても接続できず、システム構成を変えたくないなぁ…、と思い調べてみました。
VPCエンドポイント
Session ManagerでのEC2接続は、インターフェイス型のVPCエンドポイントを作成し、AWS PrivateLinkで接続することになります。
公式ドキュメントの抜粋ですが、VPCエンドポイントを作成すると、サブネットに作成されたElastic Network Interfaceがエントリポイントとなるという説明があります。
AWS PrivateLink を使用するには、サービスの名前とサブネットを指定して、VPC で VPC エンドポイントを作成します。これによって Elastic Network Interface がサブネットに作成され、これがサービスへのトラフィックのエントリポイントとなります。
どうすればよいか
既存の構成では、セキュリティグループを次の通り設定していました。
- VPCエンドポイントのセキュリティグループ
| ルール | プロトコル | ポート | ソース |
|---|---|---|---|
| インバウンド | HTTPS | 443 | Private subnet 1のCIDR |
- EC2のセキュリティグループ
| ルール | プロトコル | ポート | ソース |
|---|---|---|---|
| アウトバウンド | HTTPS | 443 | VPCエンドポイントのセキュリティグループ |
Private subnet 2からPrivate subnet 1のElastic Network Interfaceと通信できるようにセキュリティグループでルールを追加すればよいはず…、ということで、セキュリティグループのインバウンドルールを追加して接続してみました。
- VPCエンドポイントのセキュリティグループ
| ルール | プロトコル | ポート | ソース |
|---|---|---|---|
| インバウンド | HTTPS | 443 | Private subnet 1のCIDR |
| インバウンド | HTTPS | 443 | Private subnet 2のCIDR |
下図の通り、無事に接続できました！
おわりに
普段からSession Managerを使ってEC2に接続することが多いのですが、
使い慣れているサービスでも、いつもと条件が異なり、意外と躓きました。
今回のような小さなナレッジも蓄積していきたいと思います。
Discussion