AWS Systems Manager（SSM）入門｜SSH不要でEC2にアクセスするSession Manager設定と活用ガイド

「EC2に接続するために踏み台サーバーを構築している」「セキュリティポリシーでSSHの22番ポートを開けられない」——そんな課題を抱えているオンプレ出身のエンジニアは少なくありません。クラウドに移行してもSSHベースのアクセス管理を引き継いでいると、運用コストが下がらないどころか、セキュリティリスクまで抱え込むことになります。

この記事では、AWS Systems Manager（SSM）のSession Managerを使って踏み台サーバーもSSHポートも不要でEC2に安全に接続する方法を解説します。設定手順から実務で使えるRun Commandの活用法、よくあるトラブルの対処法まで、現場で役立つ情報をまとめました。

なぜSession Managerなのか？従来のSSHアクセスとの違い

オンプレ環境では、サーバーへのアクセスは「SSH（22番ポート）＋踏み台サーバー」が一般的な構成でした。クラウドに移行してもこの構成をそのまま使い続けているケースは多いのですが、AWS環境ではより安全でシンプルな方法があります。それがAWS Systems ManagerのSession Managerです。

Session Managerは、EC2インスタンスにインストールされたSSM AgentがアウトバウンドでAWSのSystems Managerエンドポイントに接続する仕組みです。サーバー側からAWSへ接続を確立するため、インバウンドのポートを一切開ける必要がありません。

セキュリティグループでインバウンドルールをすべて閉じたまま、プライベートサブネットに置いたEC2にブラウザやCLIから接続できる——これがSession Managerの最大の利点です。

SSMを使うための事前準備

Session Managerを使うには、3つの準備が必要です。順番に確認していきましょう。

1. EC2インスタンスプロファイル（IAMロール）の設定

Session Managerを使うには、EC2インスタンスにIAMロールをアタッチし、SSMと通信できる権限を付与する必要があります。

AWSが用意しているマネージドポリシー AmazonSSMManagedInstanceCore をアタッチするのが最も簡単な方法です。手順は次のとおりです。

・IAMコンソールを開く: サービス一覧から「IAM」を選択
・ロールを作成: 「ロールの作成」→「AWSサービス」→「EC2」を選択
・ポリシーを検索: 「AmazonSSMManagedInstanceCore」を検索してアタッチ
・ロール名を設定: わかりやすい名前（例: EC2-SSM-Role）をつけて作成
・EC2にアタッチ: 対象のEC2インスタンスを選択し、「アクション」→「セキュリティ」→「IAMロールを変更」でアタッチ

既存のEC2に後からロールを追加する場合も、インスタンスを停止せずにアタッチできます。IAMロールのアタッチ後、SSMへの登録が反映されるまで数分かかることがあるので、すぐに接続できなくても少し待ってから試してみてください。

2. SSM Agentの確認

Amazon Linux 2、Amazon Linux 2023、Ubuntu Server（16.04以降）、Windows Server（2008 R2以降）など、主要なAMIにはSSM Agentがプリインストールされています。インストール状況はCLIで確認できます。

# Amazon Linux 2 / Amazon Linux 2023 の場合
sudo systemctl status amazon-ssm-agent

# Ubuntuの場合
sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service

「active (running)」と表示されていれば問題ありません。もしインストールされていない場合は、AWSの公式ドキュメントに従ってOSに合わせたパッケージをインストールしてください。

3. VPCエンドポイントの設定（プライベートサブネット利用時）

パブリックサブネットにあるEC2でインターネットへの経路がある場合は、追加設定なしでSession Managerを使えます。しかしプライベートサブネットにEC2を置いている場合は、VPCエンドポイントが必要です。必要なVPCエンドポイントは次の3つです。

・com.amazonaws.ap-northeast-1.ssm: SSMのメインエンドポイント
・com.amazonaws.ap-northeast-1.ssmmessages: Session Managerのメッセージ処理
・com.amazonaws.ap-northeast-1.ec2messages: EC2とSSMのメッセージ交換

VPCコンソールの「エンドポイント」から、これら3つのインターフェースエンドポイントを作成します。セキュリティグループでHTTPS（443）の受信を許可することも忘れずに。

オンプレで言えば、社内サーバーがインターネットへ出るために必要なプロキシサーバーを設定するイメージに近いです。

Session Managerでの接続手順

準備が整ったら、実際に接続してみましょう。

1. AWSコンソールから接続する

コンソールからの接続はとてもシンプルです。

・EC2コンソールを開き、接続したいインスタンスを選択
・「接続」ボタンをクリック
・「Session Manager」タブを選択
・「接続」をクリック

これだけでブラウザ上にターミナルが開きます。SSH鍵を用意する必要もなく、踏み台サーバーを経由する必要もありません。

2. AWS CLIから接続する

日常的な作業ではCLIからの接続のほうが便利です。事前にAWS CLIとSession Managerプラグインをインストールしておく必要があります。

# AWS CLI経由でSession Managerに接続する
aws ssm start-session --target i-xxxxxxxxxxxxxxxxx

# ポートフォワーディング（例: プライベートサブネットのRDSへのトンネル）
aws ssm start-session \
  --target i-xxxxxxxxxxxxxxxxx \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["your-rds-endpoint.rds.amazonaws.com"],"portNumber":["3306"],"localPortNumber":["13306"]}'

ポートフォワーディングを使えば、プライベートサブネット内のRDSに対してもローカルのMySQLクライアントから接続できます。踏み台サーバー経由のSSHトンネルと同じことが、よりシンプルな設定で実現できます。

Run CommandでEC2を一括管理する

AWS Systems Managerにはセッション接続以外にも、複数のEC2インスタンスに対してコマンドを一括実行できるRun Commandという機能があります。オンプレで言えば、AnsibleやChef、Puppetといった構成管理ツールが担っていた役割の一部を、追加ツールなしでAWSのマネージドサービスとして使えるイメージです。

パッチ適用を例に見てみましょう。

# AWS CLIでRun Commandを実行（複数インスタンスに同時適用）
aws ssm send-command \
  --instance-ids "i-xxxxxxxxxxxxxxxxx" "i-yyyyyyyyyyyyyyyyy" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["sudo yum update -y"]' \
  --output text

# コマンドの実行状態を確認する
aws ssm list-command-invocations \
  --command-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --details

コンソールから使う場合は、「Systems Manager」→「Run Command」から操作します。AWSが用意しているAWS-RunPatchBaselineというドキュメントを使えば、承認済みパッチのみを安全に適用するポリシーを組むことも可能です。

実行結果はS3またはCloudWatch Logsに自動保存できるため、「どのサーバーでいつパッチを当てたか」を証跡として残す運用にも対応できます。コンプライアンス要件がある現場では特に重宝します。

料金の仕組みとコスト計算

Session ManagerやRun Command自体の利用料は無料です。ただし、関連するサービスの利用コストには注意が必要です。

VPCエンドポイントは、プライベートサブネットのEC2からSession Managerを使う場合にのみ必要です。パブリックサブネットのEC2や、NATゲートウェイ経由でインターネットアクセスがある構成では不要なので、その分コストを抑えられます。

踏み台サーバーとして小さめのEC2（例: t3.micro）を24時間稼働させると東京リージョンで月$8前後かかります。VPCエンドポイント3本の固定費と比べると大差ないですが、踏み台サーバーにはOS更新・セキュリティパッチ・稼働監視といった管理コストが伴います。この管理工数まで含めると、Session Managerへの移行はトータルで割に合う選択です。

よくあるトラブルと対処法

【ケース1】「インスタンスが見つかりません」と表示される

Session Managerのコンソールに対象のEC2が表示されない場合、次の点を確認してください。

・IAMロール未設定: AmazonSSMManagedInstanceCoreポリシーがEC2にアタッチされているか確認
・SSM Agent未起動: `sudo systemctl status amazon-ssm-agent` でステータスを確認
・リージョンのミスマッチ: コンソールのリージョンとEC2が起動しているリージョンが一致しているか確認
・反映待ち: IAMロールのアタッチ後は数分待ってからリロードする

【ケース2】プライベートサブネットのEC2に接続できない

VPCエンドポイントの設定漏れが最も多い原因です。次の3点を確認してください。

・前述の3つのエンドポイント（ssm / ssmmessages / ec2messages）がすべて作成されているか
・エンドポイントのセキュリティグループで、EC2からHTTPS（443）インバウンドが許可されているか
・「プライベートDNS名を有効化」がオンになっているか

【ケース3】セッションが途中で切れる

デフォルトでは、操作がない状態が20分続くとセッションが自動的に切断されます。長時間の作業が必要な場合は、Systems Managerコンソールの「セッションマネージャー設定」からアイドルタイムアウトを延長できます（最大60分）。長時間コマンドを実行する場合は `nohup` と組み合わせるのが安全です。

本記事のまとめ

AWS Systems ManagerのSession Managerは、オンプレで当たり前だったSSH＋踏み台サーバーの構成を、よりセキュアでシンプルな方式に置き換えられるサービスです。

まず最初のステップとして、IAMロール（AmazonSSMManagedInstanceCore）をEC2にアタッチするだけで始められます。クラウドへの移行で「とりあえずSSHと踏み台サーバーを使い続けている」という方は、ぜひSession Managerへの切り替えを検討してみてください。

LinuxサーバーのSSH設定やユーザー管理の基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。クラウドとオンプレの両方の視点でLinuxスキルを固めたい方はあわせてご覧ください。