SSMでEC2に安全接続！踏み台不要のセッションマネージャー構築

はじめに

AWSの運用において、プライベートサブネット内にあるEC2インスタンスへの接続方法として、従来の「SSHキーと踏み台サーバー（Bastion）」の組み合わせは、管理コストやセキュリティリスク（IP制限の運用、鍵の紛失など）の観点から推奨されなくなっています。

現在、実務で標準となっているのがAWS Systems Manager（SSM）セッションマネージャーを利用した接続方法です。本記事では、踏み台サーバーを完全に廃止し、セキュアにプライベートEC2へシェル接続するための設計と、具体的な構築手順をステップバイステップで解説します。

前提知識/必要な理由

SSMセッションマネージャーを採用する最大の理由は、「インバウンド（受信）ポートを完全に閉じたままEC2にアクセスできる」点にあります。

SSHポート（22番）の開放不要：インターネットから直接アクセスを待ち受ける必要がありません。
踏み台サーバーの維持費がゼロ：管理対象のインスタンスが減り、運用の手間とコストが削減されます。
IAMによる一元的な権限管理：SSH公開鍵の配布・管理が不要になり、誰がいつ接続したかの操作ログを CloudWatch Logs に自動記録できます。

今回は、実務で最も要望が多い「パブリックIPを持たない完全なプライベートサブネット内のEC2」を対象に、VPCエンドポイントを併用したセキュアな接続構成を構築します。

具体的な設定手順・設計方法

ステップ1：EC2用のIAMロール（インスタンスプロファイル）の作成

EC2がSSMサービスと安全に通信するために、IAMロールを作成して付与します。

AWSマネジメントコンソールの「IAM」に移動し、ロールの作成を開始します。
信頼されたエンティティタイプで「AWSサービス」、ユースケースに「EC2」を選択します。
許可ポリシーの検索窓に AmazonSSMManagedInstanceCore と入力し、チェックを入れてアタッチします（このポリシーがSSM通信に必要な最小権限を含んでいます）。
ロール名（例: EC2-SSM-Access-Role）を入力し、ロールを作成します。

ステップ2：VPCエンドポイントの設定（プライベート環境の場合）

インターネットへのルートがないプライベートサブネットの場合、EC2からAWSのSSM APIエンドポイントへアクセスできるようにするため、3つのインターフェイス型VPCエンドポイント（PrivateLink）を作成する必要があります。

※パブリックサブネットやNATゲートウェイ経由でインターネットにルートがある場合はこの手順は不要です。

com.amazonaws.[リージョン名].ssm
com.amazonaws.[リージョン名].ssmmessages
com.amazonaws.[リージョン名].ec2messages

設定のポイント：

VPCエンドポイントにアタッチするセキュリティグループでは、VPCのCIDR内部（またはEC2のセキュリティグループ）からの「HTTPS（443番）」インバウンド通信を許可してください。
VPCの設定で「DNSホスト名（EnableDnsHostnames）」および「DNS解決（EnableDnsSupport）」が両方とも「有効（true）」になっていることを確認してください。

ステップ3：EC2インスタンスの起動とロールのアタッチ

対象となるEC2インスタンス（Amazon Linux 2023 を推奨。SSM Agentがプリインストールされているため追加導入が不要です）を起動します。

インスタンス起動画面の「高度な詳細」にある「IAMインスタンスプロファイル」で、ステップ1で作成した EC2-SSM-Access-Role を指定します。
サブネットはプライベートサブネットを選択します。セキュリティグループのインバウンドルールは空（すべて拒否）で問題ありません。アウトバウンドはVPCエンドポイント宛て（または全開放）に設定します。

ステップ4：ローカルPC環境のセットアップと接続テスト

ローカルPCの端末（ターミナルなど）から直接コマンドで接続するために、必要なツールを導入します。

1. Session Manager Pluginのインストール

AWS CLI単体ではシェル接続が開始できないため、セッションマネージャー専用のプラグインをローカルPCに導入する必要があります。macOS（Homebrewを使用する場合）およびWindows（PowerShell）の導入手順は以下の通りです。

macOSの場合：

# Homebrewを使用してプラグインをインストール
brew install --cask session-manager-plugin

# インストール確認
session-manager-plugin --version

Windows（PowerShell）の場合：

# インストーラーをダウンロードして実行
Start-Process msiexec.exe -ArgumentList '/i https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows_amd64/SessionManagerPlugin.msi /qn' -Wait

# ターミナルを再起動して確認
session-manager-plugin

2. 接続コマンドの実行

AWS CLIの設定（認証情報）が完了している状態で、以下のコマンドを実行してEC2に接続します（i-xxxxxx部分に対象インスタンスのIDを入力します）。

aws ssm start-session --target i-0123456789abcdef0

コマンド実行後、以下のようにプロンプトが表示されれば接続成功です。

Starting session with SessionId: botocore-session-1234567890
sh-5.2$ sudo su - ssm-user
[ssm-user@ip-10-0-1-10 ~]$

実務での注意点

マネジメントコンソールにEC2が表示されない場合：
EC2インスタンス起動後、数分経ってもSSMの「フリートマネージャー」等に表示されない場合は、VPCエンドポイントのセキュリティグループの設定ミス（443番ポートの疎通不足）や、EC2に付与したIAMロールの権限不足（アタッチ忘れ）を疑ってください。
ログの保管と監査：
実務で利用する際は、誰がどのような操作を行ったかを記録するため、SSMの「設定」からセッションログをAmazon S3やCloudWatch Logsに送信する設定を必ず有効にしてください。デフォルトではログがローカルに保存されないため、監査要件を満たせなくなります。
SSM Agentのアップデート：
SSM Agentは古いバージョンのまま放置すると脆弱性の原因や接続不良につながります。SSMの「ステートマネージャー」で AWS-UpdateSSMAgent ドキュメントを定期的（週次など）に自動実行させる設定を入れておくのがベストプラクティスです。

まとめ

AWS Systems Manager セッションマネージャーを導入することで、インフラ全体の「アタックサーフェス（攻撃対象領域）」を劇的に減らすことができます。鍵管理のオーバーヘッドから解放され、IAMによる細かなアクセス制御と監査ログの自動取得が実現可能です。まだ踏み台サーバー運用を行っている環境があれば、ぜひ本手順を参考にモダンでセキュアなインフラへと移行を進めてみてください。