【脱・踏み台サーバー】SSM Session ManagerでローカルからプライベートRDSへ安全にポートフォワーディング接続する完全ガイド

開発や保守運用において、プライベートサブネットにあるRDSなどのデータベースにローカルPCから安全に接続したいケースは頻繁に発生します。かつてはパブリックIPを持つ「踏み台サーバー（Bastionホスト）」を構築し、SSHトンネル経由で接続するのが一般的でした。しかし、この方法にはSSHキーの管理や、ポート22をインターネットに開放するセキュリティリスク、踏み台サーバーの維持コストといった課題があります。

本記事では、これらの課題をすべて解決する、AWS Systems Manager (SSM) Session Manager を活用した「踏み台サーバー不要のセキュアなポートフォワーディング接続」の設定手順を分かりやすく解説します。

前提知識/必要な理由

SSM Session Manager ポートフォワーディングとは？

AWS Systems Manager（SSM）のポートフォワーディング機能を使用すると、ローカルPCの特定のポートへのトラフィックを、AWS上のEC2インスタンス（SSMエージェント実行環境）を経由して、同一VPC内にある別ターゲット（RDSやElastiCacheなど）のポートに安全に転送できます。

この構成が推奨される理由（メリット）

セキュリティの最大化： インバウンド（外から内への）SSHポート（22番など）を開放する必要がありません。完全にアウトバウンド接続のみで通信を確立します。
SSH鍵管理からの解放： 個別のSSHキーペアを作成・配布・ローテーションする手間が不要になります。認証・認可はすべてAWSのIAMで一元管理されます。
コストの削減： 踏み台専用のEC2を常時起動しておく必要性が下がります。SSM通信を受け持つ中継用EC2は、t3.nanoなどの極小スペックや、既存の別用途のプライベートEC2を流用することでコストを最小限に抑えられます。
運用の透明性： 誰がいつセッションを開始したかをAWS CloudTrailやSSMの監査ログで簡単に追跡できます。

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

今回は、プライベートサブネット内にある「中継用EC2インスタンス」を介して、同VPC内の「RDS（PostgreSQL）」へローカルPCから接続する環境を構築します。

ステップ1：中継用EC2インスタンスの準備

VPCのプライベートサブネットに、中継役となるEC2インスタンスを1台起動します。

OS： Amazon Linux 2023（SSMエージェントがデフォルトでプリインストールされています）
パブリックIP： アタッチ「無効」で問題ありません。

ステップ2：IAMロール（EC2用）の作成とアタッチ

EC2インスタンスがSSMサービスとセキュアに通信できるように、IAMロールを作成してアタッチします。

IAMコンソールで、信頼されたエンティティとして「EC2」を選択し、ロールを作成します。
許可ポリシーとして、AWS管理ポリシーの AmazonSSMManagedInstanceCore をアタッチします。
作成したIAMロールを、ステップ1で作成した中継用EC2インスタンスに「IAMロールの変更」からアタッチします。

ステップ3：ネットワークとセキュリティグループの設計

以下の通り、ネットワークの疎通とセキュリティグループ（SG）を設定します。

EC2からSSMへのアウトバウンド： 中継用EC2がSSMのAPIエンドポイントにアクセスできる必要があります。NAT Gateway経由、またはVPCエンドポイント（ssm, ssmmessages, ec2messages）をVPC内に設置してください。
RDSのインバウンドルール： RDSに紐づくセキュリティグループのインバウンドルールで、中継用EC2のセキュリティグループ（またはIP）からの通信（PostgreSQLの場合はTCP 5432ポート）のみを許可します。

ステップ4：ローカルPC（作業端末）の事前準備

ローカルPCからSession Managerを実行するため、以下の2つのツールをインストールします。

AWS CLI： インストール後、接続権限を持つIAMユーザーの認証情報を aws configure 等で設定しておきます。
Session Manager プラグイン： お使いのOS（Windows/Mac/Linux）に合わせて、AWS公式ドキュメントに従いインストールしてください。

ステップ5：ポートフォワーディングの実行

すべての準備が整ったら、ローカルPCのターミナル（またはコマンドプロンプト）を開き、以下のAWS CLIコマンドを実行します。

aws ssm start-session \
  --target i-0123456789abcdef0 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["my-rds-database.xxxxxx.ap-northeast-1.rds.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["15432"]}'

上記のパラメータは、環境に合わせて以下のように書き換えてください。

--target: ステップ1で作成した「中継用EC2」のインスタンスID
host: 接続先となるRDSのエンドポイント（ホスト名）
portNumber: RDSのポート番号（PostgreSQLなら5432、MySQLなら3306）
localPortNumber: ローカルPC側で待ち受ける任意の空きポート（例: 15432）

コマンド実行後、ターミナルに「Waiting for connections…」と表示されれば接続成功です。ローカルのデータベースクライアント（DBeaver、pgAdmin、VS Code等）を起動し、ホスト localhost、ポート 15432 で接続を試みてください。安全にRDSへアクセスできます。

実務での注意点

1. セッションのタイムアウトに注意する

AWS Systems Managerのセッションには、デフォルトで「無操作状態が続いた場合のタイムアウト（デフォルト20分）」が設定されています。長時間のデータ移行やデバッグ作業を行う場合は、SSMの「優先設定（Preferences）」からタイムアウト値を適切に引き上げるか、定期的にキープアライブ（クエリ実行）を送る設定をクライアント側で行ってください。

2. IAMによる権限の「最小特権の原則」を徹底する

実務では、すべての開発者がどのEC2を経由してもよいわけではありません。特定の開発者には特定のEC2インスタンス（中継用）経由でのみセッション開始を許可するように、IAMポリシーでリソース制限をかけましょう。以下は制限を適用したIAMポリシーの例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:StartSession"
      ],
      "Resource": [
        "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0123456789abcdef0",
        "arn:aws:ssm:ap-northeast-1::document/AWS-StartPortForwardingSessionToRemoteHost"
      ]
    }
  ]
}

まとめ

AWS Systems Manager Session Managerを使用したリモートホストへのポートフォワーディングは、従来の「SSHキーの紛失リスク」や「踏み台サーバーの維持費」といった運用コストを劇的に改善します。

セキュリティ向上と運用負荷軽減を同時に達成できる、現代のAWSインフラ設計における「必須のベストプラクティス」です。まだ踏み台サーバーの管理に追われている現場があれば、ぜひ本手順を参考にモダンでセキュアなアクセス環境へ移行してみてください。