SSM Agent 3.3.40.0以降ならec2messagesのVPCエンドポイントは要らない

  • AWS
  • Systems Manager
  • VPC
  • PrivateLink

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

プライベートサブネットの EC2 から Session Manager を使うために、VPC エンドポイントとして ssm・ssmmessages・ec2messages の 3 つを作っていた。エンドポイントを棚卸ししていたら、ec2messages は今の SSM Agent では使われていないことが分かった。

何が変わったか

SSM Agent 3.3.40.0 から、Agent がつなぎに行くエンドポイントの優先順位が変わった。ssmmessages（Amazon Message Gateway Service）が使えるときは、ec2messages（Amazon Message Delivery Service）ではなくそちらを使う。Agent の変更履歴にも、ssmmessages に接続できたら ec2messages を使わないようにする、という変更が入っている。

AWS のドキュメント（Systems Manager ユーザーガイドの「Reference: ec2messages, ssmmessages, and other API operations」）には、次の 2 点が書かれている。

  • SSM Agent 3.3.40.0 以降は、使える場合は ssmmessages:* エンドポイントを優先して使う
  • 2024 年より前にローンチしたリージョンでは、ec2messages:* の権限はポリシーから安全に削除できる

「VPC エンドポイントの ec2messages は不要」とそのまま書かれているわけではない。ただ、Agent が ssmmessages しか使わないのであれば、ec2messages のエンドポイントに通信は来ない。

Agent がどちらにつなぐか

flowchart TD
    A[SSM Agent 起動] --> B{Agent バージョン >= 3.3.40.0?}
    B -- No --> E[ec2messages を使う]
    B -- Yes --> C{IAM で ssmmessages:* が許可されている?}
    C -- No --> E
    C -- Yes --> D[ssmmessages を使う]

古いリージョン（2024 年より前にローンチしたもの）では、Agent の起動時に ssmmessages:* の権限がなく ec2messages:* の権限だけがあると、ec2messages につなぎに行く。AmazonSSMManagedInstanceCore を付けていれば ssmmessages:* は入っている。

逆に言うと、ec2messages のエンドポイントを消してよい条件は次の 3 つになる。

  • 対象のインスタンスすべてで SSM Agent が 3.3.40.0 以上
  • インスタンスプロファイルで ssmmessages:* が許可されている
  • ssmmessages のエンドポイントは残っている

Agent のバージョンを確認する

SSM に登録されているインスタンスの Agent のバージョンは、これで一覧できる。

ターミナル
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].[InstanceId,AgentVersion]' \
  --output table

最初に叩いたときは常時起動しているインスタンスしか出てこなかった。キューにジョブが溜まったときだけ起動するワーカーも確認したかったので、ワーカーを起動してからもう一度叩いた。どちらも 3.3 系で、3.3.40.0 以降になっていた。

バージョンは 3 つ目の数字で比べる。たとえば 3.3.131.0 なら 131 > 40 なので条件を満たしている。3.2 系の Agent が残っている場合は、先に更新しておく。

普段止めているインスタンスや、AMI に Agent を焼き込んで自動更新を止めているインスタンスは見落としやすい。古い Agent のまま起動するインスタンスがあると、ec2messages を消したあとにそのインスタンスでは Session Manager や Run Command が使えなくなる。ワーカーは毎回同じ AMI から起動しているので、次に起動したときも同じバージョンのはず。

実際に使われているかを見る

念のため、エンドポイントに通信が来ていないかも見ておくと安心できる。

  • CloudWatch の AWS/PrivateLinkEndpoints 名前空間にある BytesProcessed をエンドポイントごとに見る。ec2messages がほぼゼロなら使われていない
  • CloudTrail のイベントには vpcEndpointId が入るので、どのエンドポイント経由で何の API が呼ばれているかも追える

ec2messages を消したあとは、Session Manager で各インスタンスにつながることを確認しておく。