SSM セッションマネージャーに必要なVPCエンドポイントが2つになっていた
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、なおにしです。
VPCエンドポイントを整理していた際、Systems Manager Agent のアップデートに伴ってSystems Manager (SSM)で使用するエンドポイントの用途にも変更が入っていることが分かったのでご紹介します。
先に結論
- SSM Agent のバージョンが「3.3.40.0」以降であればセッションマネージャーに限らずSSMの使用においてエンドポイント「ec2messages.
region.amazonaws.com」は必要ありません - VPCエンドポイント「com.amazonaws.
region.ec2messages」を使用しないことでコスト削減にもつながります
はじめに
以下の記事でも紹介されているとおり、プライベートサブネットのEC2インスタンスに対してNATゲートウェイを使用せずにセッションマネージャーで接続するためには以下のVPCエンドポイントが必要でした。
- com.amazonaws.
region.ssm - com.amazonaws.
region.ssmmessages - com.amazonaws.
region.ec2messages
ドキュメントにも執筆時点で以下のとおり同様の記載があります。
エンドポイントへの接続
接続するマネージドノードは、以下のエンドポイントへの HTTPS (ポート 443) アウトバウンド・トラフィックも許可する必要があります:
- ec2messages.region.amazonaws.com
- ssm.region.amazonaws.com
- ssmmessages.region.amazonaws.com
ところが、ドキュメントを確認すると以下の記載が追記されていることに気付きました。
com.amazonaws.region.ec2messages — Systems Manager は、このエンドポイントを使用して SSM Agent から Systems Manager サービスへの呼び出しを行います。SSM Agent のバージョン 3.3.40.0 以降、Systems Manager は、使用可能な場合には ec2messages:* エンドポイント (Amazon Message Delivery Service) の代わりに ssmmessages:* エンドポイント (Amazon Message Gateway Service) を使用するようになりました。
ドキュメント履歴を確認すると、上記の変更は「2024 年 5 月 3 日」に反映されているようです。しかも内容を見ると今後はec2messages:* エンドポイントは使用せずにssmmessages:* エンドポイントのみを使用することが推奨されるようです。
ec2messages:* エンドポイントサポートの変更
2024 年以降にローンチされた AWS リージョン では、
ec2messages:*エンドポイントのステータスと実行情報を Systems Manager サービスに送り返す機能が SSM Agent でサポートされません。これらのリージョンのアカウントはssmmessages:*を使用する必要があります。2024 年より前にローンチされたリージョンでは、ssmmessages:*とec2messages:*の両方が引き続きサポートされていますが、現在はssmmessages:*エンドポイント (Amazon Message Gateway Service) のみを使用することをお勧めします。現時点では、ec2messages:*アクセス許可はポリシーから安全に削除できます。
SSM Agent のリリースノートを見てみると、「2024 年 2 月 7 日」時点で確かに修正が加えられているようです。
Update Messaging module to switch off ec2messages when ssmmessages connected successfully
（ssmmessages が正常に接続されたときに ec2messages をオフにするようにメッセージング モジュールを更新します）
というわけで、実際にセッションマネージャーを利用する際にVPCエンドポイント「com.amazonaws.region.ec2messages」が不要なのかどうかを確認してみます。
やってみた
EC2インスタンス(Amazon Linux 2023)にインストールされているSSM Agentをダウングレードして挙動を比較するという方針で試してみます。使用したAMI自体は以下のとおり執筆時点で最新のものを使用しました。
- AMI ID：ami-0c6359fd9eb30edcf
- Amazon Linux 2023 AMI 2023.5.20240903.0 x86_64 HVM kernel-6.1
- 発行日: 2024-09-03
以下のVPCエンドポイントを作成した状態でEC2インスタンスにセッションマネージャーで接続してみます。「com.amazonaws.ap-northeast-1.ec2messages」は作成していません。
EC2 Instance Connect Endpoint については、後ほどSSM Agent をダウングレードする際にセッションマネージャーで接続できなくなる想定のため、こちらからも接続できるように作成しています。
S3のVPCエンドポイント(ゲートウェイ型)は、プライベートサブネットからSSM Agentの旧バージョンのパッケージをdnfでインストールするために使用します。
セッションマネージャーで接続を試みると、エラー表示もなく問題なく接続できそうです。
接続できたので、SSM Agent のバージョンとセッション状況を確認してみました。
SSM Agent のバージョンは「3.3.380.0」でした。
セッションは「172.31.11.211」と張られています。こちらは以下のとおりVPCエンドポイント「com.amazonaws.ap-northeast-1.ssmmessages」のIPアドレスと一致しています。
セッション自体は張られていませんが、VPCエンドポイント「com.amazonaws.ap-northeast-1.ssm」についても以下のとおり通信は発生していたようです。
それでは、SSM Agent をダウングレードするためにEC2 Instance Connect Endpoint 経由で再接続して、SSM Agent をダウングレードします。リポジトリから取得できる旧バージョンのパッケージは以下のとおりでした。
一旦はセッションマネージャーが接続できなくなることを確認したかったため、最も古い「amazon-ssm-agent-3.1.1927.0-1.amzn2023.x86_64」にダウングレードしました。
念のためサービスを再起動した上でバージョンを確認してみます。
問題なくダウングレードできていますのでセッションマネージャーでの接続を試みます。
？？ 接続自体は問題なくできてしまいました。。
特定の条件に合致しないとec2messages:* エンドポイントは必要でないのでしょうか、、？ とりあえず「com.amazonaws.ap-northeast-1.ec2messages」を追加してみます。IPアドレスは以下のとおりです。
再度セッションマネージャーで接続してみます。
「com.amazonaws.ap-northeast-1.ec2messages」とのセッションが追加されています。しばらくモニタリングしてみましたが、「com.amazonaws.ap-northeast-1.ec2messages」が存在する場合はセッションを張り続けるようです。
それではこの状態(ec2messages、ssm、ssmmessagesのエンドポイントが存在する)で再度SSM Agentを最新化してみます。EC2 Instance Connect Endpoint 経由で再接続します。
念のためSSM Agentを再起動してバージョンを確認します。問題なくアップデートされています。
セッションマネージャーで再接続してセッション状況を確認します。
「com.amazonaws.ap-northeast-1.ec2messages」が存在していてもセッションが張られなくなりました。
まとめ
「com.amazonaws.region.ec2messages」が存在していなくても旧バージョンのSSM Agent でセッションマネージャーを使用できたことは予想と異なっていましたが、存在していれば実際にセッションを張ることやドキュメント上でも必要となっていることから、旧バージョンのSSM Agent では「com.amazonaws.region.ec2messages」は作成すべきです。
一方で新バージョンのSSM Agent であればドキュメント上でも「com.amazonaws.region.ec2messages」の使用は推奨されておらず、あくまでセッションマネージャーの挙動という観点のみですが「com.amazonaws.region.ec2messages」が実際に使われなくなっていることも確認できました。
本記事がどなたかのお役に立てれば幸いです。
