はじめに
この文書は、AWS環境でよく使う「ポートフォワード」の主な方法を比べ、状況に応じた選び方を分かりやすく説明します。ポートフォワードとは、離れた場所にあるサーバー上の特定のサービス（例：データベースやWeb管理画面）に、自分のパソコンから安全にアクセスするための仕組みです。たとえば、自宅のパソコンを通じて社内サーバーの管理画面をブラウザーで開くといった場面で使います。
本書では代表的な2つの手段、SSHによるポートフォワーディングと、AWS Systems ManagerのSession Manager（以下SSM）を使ったポートフォワーディングを取り上げます。どちらも遠隔のサービスにアクセスできますが、接続の仕組みや準備、使い勝手、安全性に違いがあります。読み進めることで、具体的な手順と利点・注意点が分かり、実際の運用に合わせた選択がしやすくなります。
対象は、AWSでサーバーやサービスを運用しているエンジニアや、これからリモート接続を設定したい方です。基礎的な操作（AWSのコンソールにアクセスできることや、最低限の権限があること）を前提に説明します。
次の章で、両者のやり方を整理してから、それぞれの詳細へ進みます。
主なやり方の整理
概要
AWS内のサービスにローカルから安全に接続するには、大きく分けて2つの方法があります。1つはSSHポートフォワーディング（踏み台EC2経由）、もう1つはSSM（Session Manager）によるポートフォワーディングです。どちらもローカルの任意ポートをAWS内の特定ホスト・ポートにトンネルでつなぎます。
1) SSHポートフォワーディング（踏み台EC2経由）
仕組み：ローカル→踏み台EC2（SSH）→内部サービス（例：RDSの3306）という経路でトンネルを張ります。
例：ssh -L 3306:内部ホスト:3306 -i 鍵ファイル ec2-user@bastion
前提：踏み台EC2とSSH鍵が必要です。ネットワークの経路が直接通ることを確認します。
長所：導入が分かりやすく、既存の踏み台をそのまま使えます。短所：鍵管理や踏み台の運用が必要になります。
2) SSMポートフォワーディング（Session Manager）
仕組み：SSMエージェントが入ったインスタンス経由で、AWSが提供するセッションを使ってトンネリングします。SSH鍵や公開踏み台が不要です。インスタンスがRDSへアクセスできれば、同じようにローカルからRDSへ接続できます。
前提：対象のEC2にSSMエージェントと適切なIAM権限が設定されていること。
長所：鍵不要で操作が監査されます。IAMで細かい制御が可能です。短所：事前設定（Agent/Permissions）が必要で、慣れるまで手順が増えます。
使い分けの目安
- 既に踏み台運用が整っている場合はSSHを使うと導入が早い。
- 鍵管理を減らしたい、操作履歴を残したい場合はSSMが便利です。
SSH ポートフォワーディング
概要
SSHポートフォワーディングは、ローカルのポートを踏み台（bastion）経由で社内のサービスに安全に接続する方法です。たとえば、自分のPCのポート13306を踏み台経由でRDSの3306に繋げば、ローカルのMySQLクライアントでRDSに接続できます。
コマンド例
以下は典型的なコマンド例です。
ssh -L 13306:mydb.abcdef.region.rds.amazonaws.com:3306 ec2-user@bastion.example.com -i ~/.ssh/id_rsa -N
-L は「ローカルポート:リモートホスト:リモートポート」を指定します。-N はコマンド実行をせずポート転送だけ行うオプションです。
使い方の流れ
- 上記コマンドでトンネルを張る。
- ローカルで127.0.0.1:13306を指定して接続する（例：mysql -h 127.0.0.1 -P 13306）。
注意点
- 可能なら127.0.0.1にバインドして外部からのアクセスを防いでください（例：-L 127.0.0.1:13306:…）。
- 鍵認証を使い、踏み台のセキュリティグループを最小限にしてください。
- バックグラウンド実行は -f を併用します（例：-f -N）。
トラブルシューティング
- ポートが既に使われている場合は別ポートを指定するか、使用プロセスを確認してください（lsofやnetstat）。
- 接続できない場合は ssh -v で詳細ログを確認します。
補足として、複数のホストを経由したり動的なプロキシが必要な場合は -J（ProxyJump）や -D（SOCKSプロキシ）も使えますが、まずは上の手順で安全に接続することをおすすめします。
SSM (Session Manager) ポートフォワーディング
概要
SSMポートフォワーディングは、SSHキーや踏み台サーバーを用いずにAWS CLI経由でHTTPSトンネルを張る方法です。EC2にSSM Agentと適切なIAMロールがあれば、ローカル端末から安全にサーバー内やその先のサービスへ接続できます。設定がシンプルでログ管理もしやすい点が利点です。
前提条件
- EC2にSSM Agentがインストール・起動していること
- EC2に割り当てたIAMロールにSession Managerの権限があること
- ローカルのAWS CLI（Session Manager plugin含む）が設定済みであること
- EC2から接続先へ届くネットワーク経路（セキュリティグループ等）があること
基本的なコマンド例
1) EC2自身のポートにフォワード（例: EC2上のPostgres 5432をローカル5433へ）
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["5432"],"localPortNumber":["5433"]}'
このコマンドでローカルの5433に接続すると、EC2上の5432へ透過的に届きます。
2) EC2を踏み台にしてリモートホストへフォワード（例: RDS）
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["rds.example.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["5433"]}'
この場合、EC2がRDSへ到達できればローカルからRDSへ直接接続できます。
注意点とポイント
- セッションは切断するとトンネルが閉じます。長時間利用時は接続の管理に注意してください。
- EC2のIAMやネットワーク設定が正しくないと接続できません。事前に確認してください。
- ログや録画はCloudWatchやS3へ送れるため、監査に便利です。
以上の手順で、SSH鍵無しで安全にポートフォワーディングができます。
どちらを選ぶと良いか
前提と必要なもの
- SSHポートフォワード: サーバー側でSSH接続を受けられること、公開鍵やパスワード管理、必要に応じて踏み台（bastion）を用意することが必要です。例: ローカルからリモートのDBポートを直接トンネルする。
- SSMポートフォワード: AWS環境でSSMエージェントが動作し、適切なIAM権限が設定されていることが前提です。インバウンドのポート開放や公開鍵配布は不要です。
メリット比較（要点）
- SSHのメリット: 柔軟なトンネル設計が可能で、既存のSSHワークフローに馴染みやすいです。ローカル→リモート、リモート→ローカルなど多様な使い方ができます。
- SSMのメリット: インバウンドポートを開けずに済むためセキュリティ面で有利です。踏み台サーバーが不要になり、鍵管理の手間も減ります。
主な用途と選び方ガイド
- 日常の開発や既存のSSH運用がある場合: SSHを選ぶと効率的です。柔軟な設定やスクリプト自動化がしやすいため、開発者がすぐ使えます。
- セキュリティ重視や管理負荷を下げたい場合: SSMが適しています。特に踏み台を減らしたい、または公開鍵管理を簡素化したい場面で有効です。
最終判断のポイント（実用チェックリスト）
- ネットワークでポートを開けられるか？開けるならSSHが使える。開けられないならSSMを優先。
- 既存の運用負担（鍵管理や踏み台運用）はどれほどか？負担が大きければSSMで簡素化できます。
- AWS環境とIAMの整備があるか？整備済みならSSMを有効に活用できます。
選択は目的と環境次第です。どちらも長所があるため、必要に応じて併用することも検討してください。」}}](MESSAGE)
