インスタンスコネクトとSSMによるEC2インスタンスへの接続について
y_romuEC2インスタンスコネクトとSSM Session Managerでの接続について、個人的なメモをまとめてみます。
SSMエンドポイントを作成し、EC2とセキュアな通信を行うところまで実施します。
参考にしたサイト
前提：
- VPCを作成している。
- インターネットからEC2へ通信できるパブリックサブネットを作成している。
EC2の作成
- AMIはAmazon Linux 2023 kernel-6.1
- インスタンスタイプはt3.nano
- キーペアなし
- セキュリティグループを新しく作成し、インスタンスコネクトのために22番ポートを開放する
- インスタンスを起動後、Elastic IPを作成しEC2にアタッチする
EC2 Instance Connect
必要なもの：
- パブリックなIPアドレス
- インターネットゲートウェイと、外部と通信するためのルートテーブルやサブネットなど一式
- セキュリティグループで22番ポートを開放する
22番ポートを開放していても、キーペアを作成していないため他人はSSH接続できない。
しかしインターネットに22番ポートを開放する事はセキュリティリスクになるため、インスタンスコネクトは推奨されない。
テストで気軽に作成したり接続できる点はメリット。
しかし設計上EC2インスタンスにパブリックなIPアドレスが設定されていなかったり、プライベートサブネットに配置されていたら接続ができない。
Systems Manager Session Managerによる接続
まずはEC2インスタンスにアタッチするロールの作成から。
ロールを作成し、自分でポリシーをアタッチしてみる。
先ほど作成したロールをEC2インスタンスにアタッチする。
後からEC2インスタンスにロールをアタッチした場合は、インスタンスを一度再起動すると接続ボタンが有効化される。
EC2でSession Managerを使うためには、SSM AgentがAWSのエンドポイントへHTTPS通信する必要がある。
そのために必要な経路は下記の2つ。
方法1：インターネット経由
- IGW + パブリックIP（またはEIP）
- NAT Gateway経由（プライベートサブネット）
方法2：VPCエンドポイント（Interface型）
- SSM / EC2 Messaging / Logs 用エンドポイントを作成
こちらは完全に閉じた環境でも動作可能で、EC2とSSMまでの通信がパブリックなインターネットを経由せずAWS内部の通信で行われる点がセキュア
今回は方法2で、VPCエンドポイントを作成してみる。
VPCエンドポイント用のセキュリティグループの作成
SSMエンドポイントにアタッチするためのセキュリティグループを作成する。
重要なのは、インバウンドルールでHTTPS通信を許可すること。
ソースはVPCのアドレスを指定する。
・なぜSSMエンドポイントにアタッチするセキュリティグループでは、インバウンドでHTTPSを許可する必要があるのか？
これは、EC2にインストールされているSSM AgentがVPCエンドポイントを経由し、HTTPS通信でSystems Managerにアクセスするため。
SSM Agentからの通信は、VPCエンドポイントにとってはインバウンドの通信となる。
セキュリティグループはステートフル。インバウンドルールで許可した通信に対しての戻りの通信は自動で許可されるため、今回アウトバウンドルールを定める必要は無い。
VPCエンドポイントの作成
作成する必要のあるエンドポイントは下記の3つ
com.amazonaws.region.ssm
com.amazonaws.region.ec2messages
com.amazonaws.region.ssmmessages
それぞれについてメモ。
-
com.amazonaws.region.ssm
管理用APIエンドポイント。Session Manager全体のコントロールを行うために使われる。マネジメントコンソールやCLIからの「セッション開始」などの管理コマンドを受け付ける。 -
com.amazonaws.region.ec2messages
EC2とのコマンド配送経路。AWSからEC2のSSM Agentへ命令を届けるための経路であり、EC2インスタンス側もこのエンドポイントを使って「指令を受け取った」などの返信する。 -
com.amazonaws.region.ssmmessages
Session Managerの実際のやり取りを仲介する。例えば「ls」と入力して結果が返ってくるのはこの経路を経由しているため。これが無いとセッション開始はできても、中で操作できない状態になる。
なぜエンドポイントが3つに分かれているのか？
- APIリクエストとセッション中の通信を分離することで、セキュリティや信頼性を高めるため。
- 各エンドポイントに対して個別のセキュリティ設定・アクセス制御を可能にするため。
エンドポイントの名前タグは適当なものを入力する。
AWSが提供するサービスにエンドポイント経由で通信する場合は、タイプで「AWSのサービス」を選択する。
エンドポイントを選択する。
・DNS名を有効化とは？
VPC内から通常のパブリックなFQDNに対してアクセスした際に、VPCエンドポイントのプライベートIPに名前解決できるようにするための設定。
例えばEC2から「ssm.ap-northeast-1.amazonaws.com」に対してDNS問い合わせをした際に、VPC内のInterface型VPCエンドポイントのIPを返すようになる。
これにより、NATやIGWが無くてもSSMエンドポイントに到達できるようになる。
反対にこの設定を有効にしないと、インターネットへの出口（IGW/NAT)が無い場合は通信できなくなる。
VPCエンドポイント（実体はENI？）を指定したサブネットに配置する。
この画面では1つのサブネットしか無いが、複数サブネットを選択しエンドポイントをマルチAZとして高可用性を保つこともできる。
先ほど作成したVPCエンドポイント用のセキュリティグループを選択する。
・エンドポイントポリシーとは？
VPCから、エンドポイントを経由してAWS上のサービスやリソースに対してアクセスする際に、何のサービス/リソースにアクセスしていいか、どんな操作をしていいかなど制御するためのもの。
今回は検証用途のためフルアクセスとする。
本番環境では最小権限の原則にのっとって細かく制限する方が望ましい。
事前にVPC側で設定するもの
Interface型のVPCエンドポイントを使うには、VPCのDNS設定で「DNS解決」「DNSホスト名」を事前に有効化しておく必要がある。
・DNS解決を有効化とは？
VPCで内部的なDNSを有効化することで、VPC内における名前解決をできるようにするための設定。
これを有効にすると、VPC内にプライベートなホストゾーンが自動で作成されて、AWS側でよしなにVPC内部で名前解決してくれる。
これが無効だとFQDNからIPアドレスの変換ができず、エンドポイントにアクセスできない。
・DNSホスト名を有効化とは？
VPC内のリソース（ENIやEC2など）にDNS名を割り当てるかどうかを決める。
Interface型VPCエンドポイントのENIもこれに依存しており、有効化する事でDNS名でアクセスできるようになる。
おそらく...
Interface型VPCエンドポイントにはENIが割り当てられており、このENIにはホスト名が割り当てられている。
ENIに対して割り当てられたホスト名を、プライベートなIPアドレスとして名前解決している。
通信の流れとしては、恐らく下記のように
- VPCにDNS解決とVPCホスト名が有効になっている。
- Interface型VPCエンドポイントを作成すると、自動的にENIがサブネットごとに作られる。
- そのENIに内部的なホスト名が割り当てられる。
- 通常のFQDN（ssm.ap-northeast-1.amazonaws.comなど）でアクセスしても、VPC内部のプライベートなホストゾーンによって、ENIのプライベートIPへ名前解決される。
SSM Session Managerによって通信できるところまで確認できました。