なぜFargateやRDSにSSHできない？ Client VPN・Session Manager・ECS Execを図解

Posted at 2026-09-23

はじめに

AWS を触っていると、次のような疑問が出てくる。

EC2 は Session Manager で入れるのに、なぜ Fargate には SSH できないのか
Fargate には ECS Exec があるが、これは SSH なのか
AWS Client VPN で VPC に入れば、Fargate や RDS に SSH できるのか
RDS は Private Subnet にあるだけなら、Session Manager で入ればよいのではないか
Session Manager のポートフォワーディングで RDS に接続できるなら、結局 RDS に SSH しているのか

このあたりは、ネットワーク到達性とOS へのログイン方法とAWS マネージドサービスの境界を混ぜると分かりにくくなる。

先に結論を書く。

対象	SSH	Session Manager	代わりに使うもの
EC2	できる	できる	Session Manager shell / SSH over Session Manager
Fargate の基盤ホスト	できない	できない	AWS 管理領域
Fargate のコンテナ	通常 SSH しない	SSM の仕組みを ECS Exec が利用	ECS Exec
通常の RDS	できない	できない	MySQL / PostgreSQL 等の DB プロトコル
RDS Custom	構成により可能	可能	RDS Custom の OS アクセス

そして AWS Client VPN は、この表の「できる / できない」を変えるものではない。

Client VPN は、手元 PC から VPC 内部へネットワーク上の道を作るサービスだからである。

1. まず3つを分離する

最初に、Client VPN・Session Manager・SSH の役割を分ける。

見た目はどれも「リモートから接続する」仕組みに見えるが、役割が違う。

AWS Client VPN

PC と VPC の間にネットワーク経路を作る

VPN 接続後は、条件がそろえば手元 PC から VPC 内の Private IP / Private DNS に到達できる。

しかし Client VPN 自体は、

SSH サーバーを起動しない
SSM Agent を入れない
RDS の OS を公開しない

つまり 「道」ができるだけである。

Session Manager

SSM Agent と Systems Manager の間に管理用チャネルを作る

Session Manager の通常セッションでは、対象マシン上の SSM Agent を通してシェルを開始する。

そのため、EC2 の Security Group で SSH の 22 番ポートをインターネットに開ける必要はない。

SSH

対象OSで動いている sshd に接続してログインする

SSH には接続先に少なくとも、

SSH サーバー（通常は sshd）
ログイン対象の OS ユーザー
認証方法

が必要になる。

👉 ネットワーク的に到達できることと、SSH ログインできることは別問題である。

2. Session Manager は SSH そのものではない

ここはかなり重要。

Session Manager には大きく分けて、

Session Manager 自身がシェルを開く
Session Manager を SSH のトンネルとして使う

という2種類の使い方がある。

Session Manager の通常セッション

例えば EC2 に対して、

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

とすると、SSM Agent を介してセッションが開始される。

この場合、SSH は使っていない。

対象ノードには SSM Agent が必要で、Agent が Systems Manager のエンドポイントへ到達できる必要がある。

SSH over Session Manager

一方、Session Manager を SSH のトンネルとして使うこともできる。

この場合は Session Manager が SSH パケットを運んでいるだけなので、接続先には依然として sshd が必要になる。

つまり、

Session Manager shell
    → SSHサーバー不要

SSH over Session Manager
    → SSHサーバー必要

である。

👉 「Session Manager が使える = SSH が使える」ではない。

出典: Step 1: Complete Session Manager prerequisites、Allow SSH connections through Session Manager

3. EC2 ではなぜ Session Manager が使えるのか

EC2 は、自分で管理できる OS を持つ仮想マシンである。

その中に SSM Agent を入れて動かせる。

Session Manager の対象になるには、主に、

SSM Agent がインストールされ、動作している
IAM 権限がある
SSM Agent から Systems Manager のエンドポイントへ通信できる

という条件が必要になる。

Private Subnet の EC2 でも、NAT Gateway や Systems Manager 用 VPC Endpoint などを使って必要なエンドポイントへ到達できれば Session Manager を利用できる。

👉 Session Manager は基本的に Agent 側から AWS サービスへ接続するため、EC2 の inbound 22 番を開けなくてもよい。

出典: Troubleshooting managed node availability

4. Fargate に SSH できない理由

Fargate では、自分が管理しているものと AWS が管理しているものを分ける必要がある。

ユーザーはコンテナを実行しているが、その下のホスト OS は AWS 管理領域である。

AWS の Fargate ドキュメントでも、ユーザーは基盤ホストへアクセスできないと明記されている。

そのため、

ssh ec2-user@Fargateのホスト

のような操作はできない。

そもそもユーザーに、

ホストの EC2 Instance ID
ホストのログインユーザー
ホスト用の SSH 鍵
ホスト OS の管理権限

が提供されていない。

ではコンテナの中に SSH サーバーを入れればよい？

技術的にはコンテナイメージ内に sshd を入れる設計自体は考えられるが、Fargate の運用でコンテナへ入るために SSH を用意する必要は通常ない。

AWS が提供している仕組みは ECS Exec である。

出典: Fargate security considerations

5. Fargate の「入る」は ECS Exec

ECS Exec を有効にすると、実行中のコンテナでコマンドを実行できる。

例えば、

aws ecs execute-command \
  --cluster my-cluster \
  --task <TASK_ID> \
  --container app \
  --interactive \
  --command '/bin/sh'

という形でコンテナのシェルを開ける。

これは SSH ではない。

AWS の内部構成としては、ECS Exec が Systems Manager Session Manager の仕組みを利用している。

AWS のドキュメントでは、必要な SSM Agent バイナリがコンテナへ bind mount され、ECS / Fargate agent がコンテナ内で SSM core agent を起動すると説明されている。

また、ECS Exec で必要なのは Task 側から Session Manager の ssmmessages エンドポイントへ到達できることであり、Task の inbound 22 番を開けることではない。Private Subnet でインターネット向け経路を持たせない場合は、ssmmessages 用の Interface VPC Endpoint を使える。

つまり、

Fargate のホストへ SSH
    ❌ できない

Fargate のコンテナで shell を実行
    ⭕ ECS Exec

という整理になる。

👉 ECS Exec が SSM を内部利用しているからといって、Fargate の基盤ホストが自分の Session Manager 管理ノードになるわけではない。

出典: Monitor Amazon ECS containers with ECS Exec

6. AWS Client VPN を使えば SSH できるようになる？

接続先が SSH を受けられるならできる。受けられないものは VPN を張ってもできない。

Client VPN は、手元 PC を VPC 内ネットワークへ接続する。

逆に言えば、Session Manager や ECS Exec を使うために Client VPN が必須なわけではない。対象側から Systems Manager / ssmmessages へ到達でき、IAM などの前提を満たせば、管理チャネルは VPN とは別に成立する。

ここで注意したいのは、Client VPN Endpoint 自身にも Route Table があること。これは VPC Subnet に関連付く Route Table とは別物である。

Client VPN Route Table
  → VPNクライアントの通信をどのネットワークへ送るか

VPC Subnet Route Table
  → Subnetから出る通信をどこへ送るか

Client VPN に最初の target network（VPC Subnet）を関連付けると、その VPC の local route が Client VPN 側の Route Table に自動追加される。追加ネットワークへ行かせる場合は Client VPN 側にもルートが必要になる。

Client VPN から VPC のリソースに到達するには、少なくとも、

Client VPN Endpoint を VPC の Subnet に関連付ける
Client VPN の Route Table に宛先へのルートがある
Authorization Rule でそのネットワークへのアクセスが許可されている
接続先 Security Group が Client VPN 側からの通信を許可している

必要がある。

VPC の Subnet / Route Table 自体の考え方は、前の記事でも整理した。

AWSのRoute Tableを「宛先→次の転送先」で理解する

EC2 の場合

EC2 の Private IP にネットワーク的に到達できて、

Security Group で TCP/22 が許可されている
EC2 で sshd が動いている
SSH 認証情報がある

なら Client VPN 越しに直接 SSH できる。

Laptop
  ↓ Client VPN
VPC
  ↓ TCP/22
EC2 sshd

Fargate の場合

VPN を張って Fargate Task の Private IP に到達できても、基盤ホストへの SSH 権限が生えるわけではない。

コンテナの中へ運用目的で入るなら ECS Exec を使う。

RDS の場合

VPN を張れば Private RDS の DB Endpoint には到達できる。

しかし接続するのは SSH ではなく、

MySQL     → TCP/3306
PostgreSQL → TCP/5432
SQL Server → TCP/1433

などの DB プロトコルである。

出典: Get started with AWS Client VPN、AWS Client VPN routes

7. 通常の RDS に Session Manager で SSH できない理由

ここまで来ると理由はかなり明確になる。

通常の Amazon RDS は、ユーザーが OS を管理するサービスではない。

AWS が、

OS
ホスト
パッチ
ハードウェア
一部の DB 管理作業

を管理する代わりに、ユーザーには DB Endpoint を公開する。

通常の RDS にはユーザーが管理できるホスト OS が公開されていない。

そのため、

SSH 用のホストアクセスがない
自分で sshd を管理できない
自分で SSM Agent をインストール・管理する対象でもない
EC2 のような Instance ID を指定して Session Manager shell に入る構造ではない

ということになる。

👉 RDS が Private Subnet にあるから Session Manager が必要なのではない。

Private / Public は「ネットワーク上どこから到達できるか」の話。

SSH / Session Manager は「その先の OS にログインできるか」の話。

通常 RDS では後者そのものが提供されていない。

AWS 公式ドキュメントも、通常 RDS は直接のホストアクセスや SSH を許可しないと明記している。

出典: Amazon RDS DB instances、MySQL feature support on Amazon RDS

8. 例外：RDS Custom

通常の RDS と混同しやすい例外が RDS Custom である。

RDS Custom は、通常 RDS よりもユーザー側に OS / DB 環境へのアクセスを許可するサービスである。

AWS のドキュメントでは RDS Custom DB Instance に Systems Manager Session Manager で接続する方法も提供されている。対応エンジンやサポート状況は通常 RDS より限定されるため、採用時は最新の RDS Custom ドキュメントを確認する必要がある。

通常 RDS
  → ホストアクセスなし

RDS Custom
  → underlying OS への管理アクセスあり

👉 「RDS は絶対に Session Manager が使えない」ではなく、通常の RDS では使えないというのが正確。

出典: Amazon RDS Custom、Connecting to RDS Custom using Session Manager

9. Private RDS に手元PCから接続する方法①：Client VPN

RDS の OS に入る必要はなく、単純にローカルの DB クライアントから接続したい場合を考える。

Client VPN を使うと構成は分かりやすい。

例えば MySQL なら、VPN 接続後に、

mysql \
  -h <RDS_ENDPOINT> \
  -P 3306 \
  -u app_user \
  -p

のように普通の DB 接続を行う。

このとき必要なのは RDS への SSH ではない。

必要なのは、

Client VPN のルート
Authorization Rule
DNS 名前解決
RDS Security Group
DB のユーザー認証

である。

👉 VPN は「PC を VPC に近づける」仕組みと考えると分かりやすい。

10. Private RDS に手元PCから接続する方法②：Session Manager のポートフォワーディング

Client VPN を使わず、Session Manager を経由して Private RDS に接続する方法もある。

ただし、この場合も RDS 自体を Session Manager のターゲットにするわけではない。

間に Session Manager 管理ノードを置く。

この機能のポイントは、remote host 側は Systems Manager の管理対象でなくてよいこと。SSM Agent が必要なのは中継する managed node 側で、remote host へのポートフォワーディングには SSM Agent 3.1.1374.0 以降が必要になる。

つまり通常 RDS は Session Manager の managed node にはなれないが、Session Manager トンネルの先にある remote host にはなれる。

例えば EC2 を使う場合は、

CLI では AWS-StartPortForwardingSessionToRemoteHost を使える。

aws ssm start-session \
  --target i-0123456789abcdef0 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{
    "host":["<RDS_ENDPOINT>"],
    "portNumber":["3306"],
    "localPortNumber":["13306"]
  }'

別ターミナルから、

mysql \
  -h 127.0.0.1 \
  -P 13306 \
  -u app_user \
  -p

と接続する。

通信経路は、

localhost:13306
    ↓
Session Manager
    ↓
EC2
    ↓
RDS Endpoint:3306

となる。

重要なのは、

❌ RDS に Session Manager でログインしている

⭕ Session Manager 管理ノードを TCP トンネルとして使い、
   そのノードから RDS へ接続している

という点。

Session Manager が DB 認証まで肩代わりするわけでもない。

RDS 側のユーザー名・パスワード・IAM DB Authentication・TLS など、DB 自体の認証は別途必要になる。

また、管理ノードから RDS Endpoint へ名前解決・ネットワーク到達でき、RDS Security Group がその通信を許可している必要がある。

出典: Start a Session Manager port forwarding session to a remote host

11. `ssh -L` のSSHトンネルとは何が違う？

RDS へのトンネルという話をすると、従来の Bastion Host を使った SSH Port Forwarding と似て見える。

例えば SSH なら、

ssh -L 13306:<RDS_ENDPOINT>:3306 ec2-user@<BASTION>

という形で、

Laptop
  ↓ SSH
Bastion EC2 の sshd
  ↓ TCP/3306
RDS

というトンネルを作る。

一方、Session Manager の remote-host port forwarding は、

Laptop
  ↓ Session Manager
EC2 の SSM Agent
  ↓ TCP/3306
RDS

である。

	`ssh -L`	SSM Port Forwarding
中継EC2の sshd	必要	不要
SSH鍵	通常必要	不要
EC2 inbound 22	ネットワーク経路上で必要	不要
中継側	SSH server	SSM Agent
AWS IAM	補助的	セッション開始権限に使用
RDS自体へのSSH	しない	しない

👉 SSM Port Forwarding の利点は「RDS に SSH できること」ではなく、RDS へ到達できる managed node までの管理トンネルを、SSH ポートを公開せずに作れることである。

12. Fargate Task をポートフォワーディングの中継にすることもできる

少し意外だが、AWS の Session Manager は、ECS Exec を有効にした ECS Task をターゲットにして remote host へのポートフォワーディングを開始することもサポートしている。

概念的には、

となる。

ここでも、

Fargate ホストへ SSH しているわけではない
RDS へ Session Manager shell で入っているわけでもない
Task を TCP 通信の中継地点にしている

だけである。

ただしアプリケーション Task は再デプロイやスケールで入れ替わるため、日常的な管理接続の踏み台として使う場合は Task のライフサイクルや IAM 権限を考慮する必要がある。

出典: Starting a session with an Amazon ECS task

13. Client VPN と Session Manager Port Forwarding は何が違う？

どちらも Private RDS へローカル PC から接続する用途に使えるが、レイヤーが違う。

	Client VPN	SSM Port Forwarding
何を作るか	PC と VPC のネットワーク接続	特定ポートへのトンネル
RDS への接続	RDS Endpoint へ直接	Managed Node 経由
Client 側の見え方	VPC 内ネットワークへ到達可能	`localhost:<port>` へ接続
中継ノード	不要	EC2 / ECS Task 等が必要
IAM	VPN認証方式＋AWS側設定	`ssm:StartSession` 等
DB認証	必要	必要
SSH を使うか	RDS 接続では使わない	RDS 接続では使わない

Client VPN

ネットワーク全体へのアクセスを作る

SSM Port Forwarding

特定の接続先ポートまで細いトンネルを作る

と考えると違いが分かりやすい。

14. 「SSHできるか？」を判断する順番

対象リソースを見たときは、次の順で考える。

実際には、

EC2

OSを管理できる
→ SSH / Session Manager

Fargate

基盤OSは管理できない
→ Containerには ECS Exec

RDS

基盤OSは管理できない
→ DB EndpointへDBプロトコルで接続

という違いになる。

15. よくある勘違い

❌ Private Subnet にあるから Session Manager が必要

Private Subnet はネットワーク経路の話。

Session Manager が使えるかは SSM Agent を実行できる管理対象ノードかどうかの話。

❌ Client VPN で VPC に入れば RDS に SSH できる

VPN はネットワーク経路を作るだけ。

通常 RDS は SSH ホストアクセス自体を提供していない。

❌ ECS Exec は Fargate への SSH

ECS Exec は SSH ではない。

SSM の仕組みを使ってコンテナ内でコマンドを実行する ECS の機能。

❌ Session Manager 経由なら接続先に sshd は不要

通常の Session Manager shell なら不要。

しかし SSH over Session Manager を使うなら接続先で sshd が必要。

❌ SSM Port Forwarding なら RDS の OS に入れる

Port Forwarding は TCP 通信を転送しているだけ。

RDS には通常どおり MySQL / PostgreSQL 等で接続する。

16. まとめ

今回の話は、次の3層に分けると整理できる。

① Network
   Client VPN / Route Table / Security Group
        ↓
② Management channel
   Session Manager / ECS Exec
        ↓
③ Target
   OS shell / Container shell / DB Endpoint

Client VPN は VPC へのネットワーク経路を作る
SSH は OS 上の sshd へログインする
Session Manager shell は SSM Agent を使うため SSH とは別物
SSH over Session Manager は Session Manager を SSH のトンネルとして使うため sshd が必要
Fargate は基盤ホストへ SSH できない。コンテナへ入るなら ECS Exec
ECS Exec は内部で SSM Session Manager の仕組みを利用するが SSH ではない
通常 RDS はホスト OS をユーザーに公開しないため SSH / Session Manager shell はできない
RDS Custom は例外で、OS への管理アクセスを提供する
Private RDS へ手元 PC から接続するなら Client VPN または Session Manager Port Forwarding が使える
Port Forwarding で RDS に接続しても、RDS に SSH しているわけではない

一番重要なのは、

「そのサービスまでネットワーク的に届くか」と「そのサービスのOSにログインできるか」は別問題

ということ。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

なぜFargateやRDSにSSHできない？ Client VPN・Session Manager・ECS Execを図解

はじめに

1. まず3つを分離する

AWS Client VPN

Session Manager

SSH

2. Session Manager は SSH そのものではない

Session Manager の通常セッション

SSH over Session Manager

3. EC2 ではなぜ Session Manager が使えるのか

4. Fargate に SSH できない理由

ではコンテナの中に SSH サーバーを入れればよい？

5. Fargate の「入る」は ECS Exec

6. AWS Client VPN を使えば SSH できるようになる？

EC2 の場合

Fargate の場合

RDS の場合

7. 通常の RDS に Session Manager で SSH できない理由

8. 例外：RDS Custom

9. Private RDS に手元PCから接続する方法①：Client VPN

10. Private RDS に手元PCから接続する方法②：Session Manager のポートフォワーディング

11. ssh -L のSSHトンネルとは何が違う？

12. Fargate Task をポートフォワーディングの中継にすることもできる

13. Client VPN と Session Manager Port Forwarding は何が違う？

Client VPN

SSM Port Forwarding

14. 「SSHできるか？」を判断する順番

EC2

Fargate

RDS

15. よくある勘違い

❌ Private Subnet にあるから Session Manager が必要

❌ Client VPN で VPC に入れば RDS に SSH できる

❌ ECS Exec は Fargate への SSH

❌ Session Manager 経由なら接続先に sshd は不要

❌ SSM Port Forwarding なら RDS の OS に入れる

16. まとめ

11. `ssh -L` のSSHトンネルとは何が違う？