Terraformで起動したEC2インスタンスがセッションマネージャーに接続できない理由

閲覧いただきありがとうございます！"さいとう"と申します。わたしは異業種・未経験からIT業界に転職し、現在インフラエンジニアとしてクラウド環境の設計や構築・運用の支援を行っています。

Terraformを利用して検証用のEC2インスタンスを起動し、セッションマネージャーで接続しようとした際に、「SSM Agent is not online」というエラーメッセージが表示されました。セッションマネージャーに接続するための要件はすべて満たしていると思っていたのに、何かが間違っていたようです。

この問題の原因を調べていくうちに、Amazon Linux 2023の"minimal AMI"にはSSM Agentがプリインストールされていないことがわかりました。"minimal AMI“を知らなかったために、セッションマネージャーでの接続ができずに困ってしまったのです。

この記事では、セッションマネージャー接続の要件を満たしているはずなのに接続できないと悩んでいる方向けに、私がどのようにこの問題を解決したかを紹介します。具体的な手順を通じて、同じトラブルに直面している方の助けになれば幸いです。

Contents

1. セッションマネージャーに接続できない？
2. まとめ

セッションマネージャーに接続できない？

結論

結論から言いますと、AMIの選択に誤りがあった、です。

TerraformのAMIを指定する記述で[al2023-ami-2023]を指定していると思っていましたが、
正規表現に誤りがあり、[al2023-ami-minimal-2023]を指定していました。

のちほど"minimal“について紹介します。

状況説明

わたしは普段AWSサービスの検証をする際に、Terraformで構築します。接続もローカルからsshアクセスするのですが、セッションマネージャーで接続する要件があったためマネコンから接続を試みると以下のエラーが表示されました。

SSM Agent is not online
The SSM Agent was unable to connect to a Systems Manager endpoint to register itself with the service.

・Verify that the IAM instance profile has the correct permissions. 
・Verify that your instance's security group and VPC allow HTTPS (port 443) outbound traffic to the following Systems Manager endpoints:
    ・ssm.ap-southeast-1.amazonaws.com
    ・ec2messages.ap-southeast-1.amazonaws.com
    ・ssmmessages.ap-southeast-1.amazonaws.com
    If your VPC does not have internet access, you can use VPC endpoints  to allow outbound traffic from your instance.

If you still can't connect to your instance, or if you receive an error, including an error about SSM Agent, see:

・セッションマネージャーでのトラブルシューティング 
・Troubleshooting managed node availability using ssm-cli 
・Troubleshooting with Automation Runbook AWSSupport-TroubleshootSessionManager

↓ためしにTerraformで作成した環境に手動で同じOSのEC2インスタンスを起動してみると、問題なくセッションマネージャーで接続できます。

OSはどちらともAmazon Linux 2023なのでエージェントの有無は関係ないし、同じネットワーク内に作成したEC2インスタンス(手動)にはセッションマネージャーでアクセスできるからネットワークの問題ではないなぁと思ってました。一応二つのEC2インスタンスの詳細を見比べてみると、

[手動]

↓

[Terraform]

Terraformで起動したインスタンスのAMIが[al2023-ami-minimal-2023]となっていますね。

minimal？

AMIのminimalとは

AWSの公式ドキュメントで「minimal」に関して調べてみると、

The standard AL2023 AMI is the default AMI that you create. This version comes installed with all of the most commonly used applications and tools. We recommend the standard AMI if you want to get started quickly and aren’t interested in customizing the AMI.
>
>標準の AL2023 AMI は、ユーザーが作成するデフォルト AMI です。このバージョンには、最も一般的に使用されるアプリケーションとツールがすべてインストールされています。すぐに使い始めたいが AMI のカスタマイズは不要な場合は、標準 AMI をお勧めします。
>
>　
>
>The minimal AL2023 AMI is the basic, streamlined version that contains only the most basic tools and utilities necessary to run the OS. We recommend the minimal AMI if you want to have the smallest OS footprint possible. The minimal AMI offers slightly reduced disk space utilization and better long-term cost efficiency. The minimal AMI is suitable if you want a smaller OS and don’t mind manually installing tools and applications.
>
>最小 AL2023 AMI は、OS の実行に必要な最も基本的なツールとユーティリティのみを含む、基本的で効率的なバージョンです。OS のフットプリントをできるだけ小さくしたい場合は、最小 AMI を使用することをお勧めします。最小 AMI では、ディスク容量の使用率がわずかに低下し、長期的なコスト効率が向上します。OS を小さくしたいが、ツールやアプリケーションを手動でインストールしてもかまわない場合は、最小 AMI が適しています。 (Amazon Linux 2023 標準 (デフォルト) と最小 AMI の比較より)

“Amazon Linux 2023″には[minimal(最小)]という、必要最低限のパッケージのみがプリインストールされているAMIがあるようです。もしかしてssm-agentが入っていないのでは？と思い、プリインストール一覧を見てみると、

やはり[amazon-ssm-agent]はプリインストールされていませんでした。

tfファイル修正

そもそもなぜminimalなAMIが指定されたのか、自分が作成したTerraformの記述を確認してみると、

data "aws_ami" "amazon_linux_2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-kernel-6.1-x86_64"]
  }

}

↓この記述だと、デフォルトの[al2023-ami-2023]ではなく、最小構成の[al2023-ami-minimal-2023]が指定されるんですね。

values = ["al2023-ami-*-kernel-6.1-x86_64"]

↓[al2023-ami-2023]を指定するように、[*]から[2*]に変更しました。

data "aws_ami" "amazon_linux_2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-2*-kernel-6.1-x86_64"]
  }

}

まとめ

普段問題なく利用しているツールでも、少し使い方を変えると意外な問題が発生することがあります。今回のように、Amazon Linux 2023のminimal AMIにはSSM Agentがプリインストールされていないことに気づかず、セッションマネージャーで接続できないというトラブルに直面しました。これをきっかけに、ツールや環境の特性を再確認する重要性を痛感しましたね。

ツールやシステムの利用において、継続的なリファクタリングと定期的な見直しを行うことが重要です。これにより、使いやすさと安全性を常に高い水準で維持することができます。特に新しいバージョンや異なる設定を使用する場合は、その特性や変更点をしっかりと理解することが不可欠です。インフラエンジニアの場合、安易なバージョンアップでクリティカルな問題を引き起こす場合があります。

今回の経験を通じて、知らなかったことを学ぶことができました。これからも、ツールの使い方や設定を見直し、より効率的で安全な運用を目指していきたいと思います。同じような問題に直面した方々にとっても、この情報が役立つことを願っています。

参考リンク:AWS公式ドキュメント

2024年6月8日