第3章 EC2インスタンスへの接続とIMDSv2
EC2インスタンスに接続する方法として、これまでのSSH鍵認証に加え、AWS特有の安全な接続手段であるSession Managerと、インスタンス自身の情報を取得するインスタンスメタデータサービス（IMDS）の基本を扱います。
SSH鍵ペアでの接続（これまでの延長）
EC2インスタンスを起動する際に指定するキーペアのうち、秘密鍵はダウンロード時の1回しか入手できず、公開鍵はインスタンス内の~/.ssh/authorized_keysに自動的に配置されます。接続にはssh -i keyfile.pem user@IPアドレスのようなコマンドを使い、22番ポートへの通信をセキュリティグループで許可しておく必要があります。
Session Managerでの接続（AWS特有の方法）
AWS Systems Manager Session Managerは、SSMエージェント（多くのAMIに標準搭載）と、適切な権限（AmazonSSMManagedInstanceCoreポリシーなどを含むIAMロール）があれば、22番ポートを開けず、SSH鍵も管理せずに、コンソールやCLIからブラウザ経由でシェルアクセスできる仕組みです。すべてのセッションはIAMの権限に基づいて制御され、CloudTrailに記録されます。
インスタンスメタデータサービス（IMDS）とIMDSv2
EC2インスタンスの内部から、特別なリンクローカルアドレスである169.254.169.254へアクセスすると、そのインスタンス自身の情報（インスタンスIDや、割り当てられたIAMロールの一時的な認証情報など）を取得できます。この仕組みをIMDSと呼びます。従来のIMDSv1は単純なGETリクエストだけで情報を取得できましたが、この性質がSSRF（サーバーサイドリクエストフォージェリ）攻撃で悪用される事例があったため、あらかじめ取得したトークンをヘッダーに付けてアクセスするIMDSv2が、2024年以降に作成される新しいEC2インスタンスの既定になっています。
# IMDSv2でのメタデータ取得手順の例（インスタンス内部で実行）
$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id
i-0abcd1234efgh5678Session Managerでのポートフォワーディング
Session Managerは、対話的なシェルアクセスだけでなく、ローカルのポートをリモートのインスタンス上のポートに転送するポートフォワーディングにも対応しています。データベースなど、通常は外部に公開しないポートへ一時的にアクセスしたい場合、わざわざセキュリティグループでそのポートを開放しなくても、Session Manager経由で安全にトンネルを張れます。SSHのローカルフォワード（ssh -L）と目的が近い機能ですが、22番ポートの開放そのものが不要という点が異なります。
# ローカルの8080番をリモートインスタンスの80番に転送する例
$ aws ssm start-session --target i-0abcd1234efgh5678 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"],"localPortNumber":["8080"]}'接続できないときの切り分け方
EC2への接続がうまくいかない場合、原因の切り分けは基本的にこれまでのネットワークトラブルシューティングと同じ考え方です。まずセキュリティグループで対象のポートが許可されているか、次にインスタンス側のOSが正常に起動しているか（コンソール上のステータスチェックを確認）、そしてSession Managerを使う場合はSSMエージェントが動作し、IAMロールの権限が不足していないか、という順に確認していくと原因を絞り込みやすくなります。
接続方法の使い分け
ここまで見てきたSSH鍵とSession Managerに加えて、ブラウザから直接シェルを開けるEC2 Instance Connectという接続方法も用意されています。それぞれ一長一短があるため、状況に応じて使い分けます。
| 接続方法 | 22番ポートの開放 | 鍵の管理 | 接続ログ |
|---|---|---|---|
| SSH鍵 | 必要 | 利用者が秘密鍵を管理 | OS側のログのみ |
| Session Manager | 不要 | 不要（IAMで制御） | CloudTrailに自動記録 |
| EC2 Instance Connect | 必要（短時間のみ） | 接続の都度、一時鍵を自動発行 | CloudTrailに自動記録 |
踏み台サーバーを維持する手間や、SSH鍵の紛失・漏えいリスクを避けたい場合はSession Managerが第一候補になりますが、ローカルのSSHクライアントに慣れた開発者向けに、鍵を意識させずに済むEC2 Instance Connectを併用する構成もよく見られます。いずれの方法でも、誰がいつ接続したかの記録が残るという点は、オンプレミス環境での「誰が入退室したか分からない」踏み台サーバー運用と比べた大きな利点です。
なお、EC2 Instance ConnectにはEC2 Instance Connect Endpointという機能もあり、これを使うとインターネットからは直接到達できないプライベートサブネット上のインスタンスに対しても、パブリックIPアドレスを割り当てずに接続できます。Session Managerと同様に、踏み台サーバーを別途構築せずに済む選択肢の一つです。
過去の定番だった踏み台サーバー構成との違い
Session Managerが登場する以前は、パブリックサブネットに踏み台サーバー（bastion host）を1台立て、いったんそこにSSHでログインしてから、さらに内部のプライベートサブネット上のサーバーへSSHで接続する、という2段構えの構成が定番でした。この構成では、踏み台サーバー自体のOSパッチ適用やSSH鍵の管理が新たな運用負荷になり、踏み台サーバーが攻撃の踏み台にされるリスクも意識する必要がありました。Session Managerであれば、こうした踏み台サーバー専用のインスタンスを維持する必要がなくなり、運用対象そのものを減らせるという利点があります。
この章のまとめ
SSH鍵認証に加えて、22番ポートを開けずに接続できるSession Managerという選択肢があること、Session Manager経由ではポートフォワーディングも可能なこと、そしてインスタンス自身の情報を取得するIMDSにはv1とv2があり、SSRF対策の観点からIMDSv2が推奨されていることを押さえました。次章では、ネットワークレベルの通信制御であるセキュリティグループを扱います。