踏み台サーバーとは？仕組みから今どきの代替手段まで解説 - エムティーアイエンジニアリングブログ

※この記事は「MTI Blog Summer 2026」の 6/9 分の記事です。

こんにちは！AIオーケストレーションエンジニア部の原です！
最近、業務で踏み台サーバーを経由してEC2インスタンスに接続する機会があったのですが、手順通りに操作はできたものの、「そもそも踏み台サーバーとは何か」「なぜ必要なのか」をちゃんと理解できていなかったので、改めて調べてみました。

本記事では、踏み台サーバーの仕組みを前提知識から整理し、今どきの代替手段であるAWS Systems Manager Session Managerとの比較までをまとめていきます。

前提知識: VPCとサブネット

踏み台サーバーを理解するには、まずAWSのネットワーク構成の基本を知っておく必要があります。「そんなの知ってるよ」という方は踏み台サーバーとはまで読み飛ばしてください。

VPC（Virtual Private Cloud）とは

VPCは、AWS上に作る自分専用のネットワーク空間です。AWSのクラウド上に、自社だけが使える隔離されたネットワークを区画として確保したもの、と考えるとイメージしやすいです。

パブリックサブネットとプライベートサブネット

VPCの中はさらに「サブネット」という小さなエリアに分割できます。サブネットには大きく2種類あります。

パブリックサブネット: インターネットとの通信経路があるエリア
プライベートサブネット: インターネットとの通信経路がないエリア

ここで注意したいのは、パブリックサブネットの「パブリック」は「誰でもアクセスできる」という意味ではないということです。「パブリック」はインターネットとの通信経路があるかどうかを指しているだけであり、実際のアクセス制御はセキュリティグループ（後述）で行います。道路に面した建物だからといって、誰でも中に入れるわけではないのと同じですね。

ルートテーブル

パブリックとプライベートの違いは、実は「ルートテーブル」の設定によって決まります。

ルートテーブルとは、サブネット内の通信の行き先案内表です。「この宛先に通信したいときはここを通れ」というルールが書かれています。

サブネット	ルートテーブルの設定	結果
パブリック	VPC外への通信 → インターネットゲートウェイへ	インターネットと通信できる
プライベート	VPC外への通信 → 行き先なし	インターネットと通信できない

つまり、パブリック/プライベートという「種類」の設定があるわけではなく、ルートテーブルにインターネットゲートウェイへの経路があるかないかで呼び方が変わっているだけです。

なお、パブリック・プライベートに関わらず、同じVPC内のサブネット同士は自由に通信できます。制限されているのはあくまでインターネット（VPCの外）との通信だけです。

なぜプライベートサブネットがあるのか

本番のDBサーバーやアプリケーションサーバーには、外部から直接アクセスされたくないですよね。そこで、これらをプライベートサブネットに配置することで、インターネットからの通信経路を物理的になくしています。

[インターネット]
      ↓ ↑
[インターネットゲートウェイ]
      ↓ ↑
[パブリックサブネット]
      ↓ ↑（VPC内の通信）
[プライベートサブネット] ← DBやアプリサーバーはここに置く
      ✕ インターネットとは直接通信できない

踏み台サーバーとは

なぜ必要か

プライベートサブネットはインターネットからの通信経路がありません。しかし、運用・保守のためにサーバーへ接続する必要はあります。

そこで、パブリックサブネットに1台だけ「入口用のサーバー」を置き、そこを経由してプライベートサブネットのサーバーにアクセスします。この入口用サーバーが踏み台サーバー（Bastion Host）です。

入口を集約するメリット

自分のPC → (SSH) → 踏み台サーバー(パブリック) → (SSH) → 目的のサーバー(プライベート)

入口を1台のサーバーに集約することで、以下のメリットがあります。

守る場所が1箇所で済む: プライベートサブネットのEC2すべてを個別にインターネットへ露出させる必要がない
監視しやすい: 誰がいつアクセスしたかを1箇所で記録・監視できる

ドアが100個ある建物より、入口が1つの建物の方が警備しやすいのと同じ考え方です。

踏み台サーバーのアクセス制御

ここまでで踏み台サーバーの役割はわかりました。では、踏み台サーバー自体はどうやって守っているのでしょうか。主に2つの仕組みで制限しています。

セキュリティグループ（IP制限）

セキュリティグループは、AWSのファイアウォールです。「どのIPアドレスからの、どのポート番号への通信を許可するか」を設定できます。

ここで「ポート番号」とは、サーバー上で動いている各サービスの窓口番号のことです。1つのサーバーではSSHやHTTPなど複数のサービスが動いており、ポート番号でどのサービス宛ての通信かを区別します。マンションで言うところの部屋番号のようなものですね。

ポート番号	サービス
22	SSH（リモート接続）
80	HTTP（Webサイト）
443	HTTPS（暗号化されたWebサイト）
3306	MySQL（データベース）

踏み台サーバーのセキュリティグループでは、例えば「会社のIPアドレスからのポート22（SSH）への通信のみ許可」と設定します。これにより、許可されたIPアドレス以外からの接続は拒否されます。

SSH鍵認証

IPアドレスによる制限に加え、SSH鍵認証で本人確認をします。

SSH鍵認証は、パスワードではなく鍵ファイルを使った認証方式です。

秘密鍵（Private Key）: 自分のPCに持っておく。絶対に他人に渡さない
公開鍵（Public Key）: サーバー側に登録しておく。他人に知られても問題ない

この2つはペアで生成され、公開鍵で暗号化したものは、対応する秘密鍵でしか復号できないという関係があります。

接続する際の流れは以下の通りです。

自分のPCがサーバーに「接続したい」と要求する
サーバーがランダムなデータを公開鍵で暗号化して送る
自分のPCが秘密鍵で復号して返す
サーバーが「正しく復号できた＝正しい秘密鍵を持っている人だ」と判断し、ログインを許可する

ポイントは、秘密鍵そのものはネットワーク上を流れないということです。送っているのは「復号した結果」だけなので、通信を盗み見されても秘密鍵は漏洩しません。

一人のユーザーにつき鍵ペアは1つで、サーバー側にはユーザーごとの公開鍵が登録されます。

踏み台サーバーの中
  登録済み公開鍵リスト
    - 公開鍵A（ユーザーA用）
    - 公開鍵B（ユーザーB用）
    - 公開鍵C（ユーザーC用）

暗号化の仕組み

「公開鍵で暗号化、秘密鍵で復号」と言われてもイメージが湧きにくいですよね。実際にやっていることは数学の計算です。

ここではRSAというアルゴリズムを例に、非常に簡略化して仕組みを示します。

鍵ペアの生成

① 2つの素数を選ぶ 3 と 11
② 掛ける 3 × 11 = 33
③ (3-1) × (11-1) = 20 を求める
④ 20と共通の約数を持たない数を選ぶ → 7（公開鍵）
  （7と20の共通の約数は1だけなのでOK）
⑤ 7 × ? ÷ 20 の余りが1になる数を探す → 3（秘密鍵）
  （7 × 3 = 21、21 ÷ 20 = 1 余り 1）

ここで重要なのは、この手順で公開鍵（7）と秘密鍵（3）が数学的に対になる関係で生成されるという点です。

暗号化（サーバー側）

元のデータ 4
計算 4の7乗 ÷ 33 の余り = 16384 ÷ 33 = 496 余り 16
暗号化されたデータ 16

復号（自分のPC側）

暗号化されたデータ 16
計算 16の3乗 ÷ 33 の余り = 4096 ÷ 33 = 124 余り 4
復号されたデータ 4 ← 元に戻った！

公開鍵（7）で変換したものは、秘密鍵（3）でしか元に戻せません。この関係は、「素数の掛け算は簡単だが、大きな数を素数に分解するのは極めて難しい」という数学的性質に支えられています。

ProxyJump（-Jオプション）

踏み台サーバーから目的のサーバーに接続する際、踏み台にも秘密鍵を置く必要がある...と思うかもしれませんが、それはセキュリティ上好ましくありません。踏み台は外に露出しているサーバーなので、一番攻撃を受けやすい場所です。そこに秘密鍵を置くのは、狙われやすい場所に金庫の鍵を置くようなものです。

SSHの-J（ProxyJump）オプションを使えば、秘密鍵を自分のPCにだけ持たせたまま、踏み台を経由して目的のサーバーに接続できます。

ssh -i ~/.ssh/bastion-key -J ec2-user@<踏み台IP> ec2-user@<目的のEC2のプライベートIP>

オプション	意味
`-i ~/.ssh/bastion-key`	使う秘密鍵ファイルを指定
`-J ec2-user@<踏み台IP>`	この踏み台を経由する
`ec2-user@<目的のEC2のプライベートIP>`	最終的に接続したいサーバー

このとき、踏み台には「接続」はしていますが「ログイン」はしていません。踏み台は通信の通り道として使われているだけで、秘密鍵による認証処理はすべて自分のPC上で行われます。踏み台が仮に乗っ取られたとしても、秘密鍵は安全です。

踏み台サーバーの運用上の課題

ここまで読むと踏み台サーバーは便利に見えますが、実際の運用にはいくつかの課題があります。

SSH鍵の管理

メンバーが増えるたびに鍵ペアを作成し、公開鍵をサーバーに登録する必要がある
退職者の公開鍵をサーバーから削除する必要がある
秘密鍵を紛失された場合、再発行が必要になる

サーバー自体の保守

踏み台もEC2インスタンスなので、OSのパッチ適用やセキュリティアップデートを継続的に行う必要があります。これを怠ると、既知の脆弱性を突かれて侵入されるリスクがあります。

ポート開放のセキュリティリスク

踏み台サーバーはSSH（ポート22）をインターネットに向けて開けています。これにより、以下のような攻撃を受ける可能性があります。

ブルートフォース（総当たり攻撃）: ユーザー名とパスワードの組み合わせを何万回も自動で試行する攻撃。SSH鍵認証にしていれば防げるが、試行自体がサーバーに負荷をかける
ポートスキャン: 開いているポートを探索し、そこで動いているソフトウェアの種類やバージョンを特定する。古いバージョンだと既知の脆弱性を突かれる恐れがある
脆弱性攻撃: 特定されたソフトウェアの脆弱性を突いて、認証を迂回して侵入する

乗っ取られた場合の影響

踏み台サーバーはプライベートサブネットへの入口であるため、乗っ取られた場合の被害は大きくなります。

横展開: 踏み台からプライベートサブネット内の他のサーバーに次々とアクセスされる
機密情報の窃取: DBの個人情報、APIキー、ソースコードなどが盗まれる
ランサムウェア: データを暗号化され、復元と引き換えに身代金を要求される
二次攻撃の踏み台: 乗っ取ったサーバーから別の企業やサービスを攻撃される。自社が加害者に見えてしまう

Session Managerという選択肢

ここまで見てきた踏み台サーバーの課題、実はこれらをまとめて解決するアプローチがあります。AWS Systems Manager Session Manager（以下、Session Manager）です。

仕組み

Session Managerは、SSHなしでEC2インスタンスに接続できるAWSのマネージドサービスです。

踏み台サーバーの場合
  自分のPC → SSH → 踏み台EC2(パブリック) → SSH → 目的のEC2(プライベート)

Session Managerの場合
  自分のPC → AWS Console/CLI → AWSサービス → 目的のEC2(プライベート)

接続コマンドもシンプルです。

aws ssm start-session --target <インスタンスID>

もしくは、AWSコンソール（ブラウザ）から「接続」ボタンを押すだけでも接続できます。

EC2側に必要なのは以下の2つだけです。

IAMロールの付与（AmazonSSMManagedInstanceCore）: EC2がSession Managerのサービスと通信するための許可
SSMエージェントが動いていること: 最近のAmazon LinuxやUbuntuには最初から入っている

アクセス制御の考え方の違い

踏み台サーバーとSession Managerでは、「誰が入れるか」の管理方法が根本的に異なります。

踏み台サーバー
  サーバー側に公開鍵を登録 → サーバー側が「誰が入れるか」を管理

Session Manager
  ユーザー側にIAMポリシーを設定 → IAMポリシーで「誰がどこに入れるか」を管理

踏み台サーバーでは「サーバー側」でアクセスを制御していましたが、Session Managerでは「ユーザー側」のIAMポリシーで制御する形に変わっています。アクセス制御の主体がサーバーからユーザーに移っているわけです。

IAMポリシーはJSON形式で定義され、「どのユーザーが、どのEC2に接続できるか」を細かく制御できます。

{
  "Effect": "Allow",
  "Action": "ssm:StartSession",
  "Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abc123def456"
}

ここで注意すべきは、IAMポリシーはユーザーに紐づきますが、ユーザー自身が設定するわけではないということです。IAMポリシーを設定するのはAWSアカウントの管理者であり、ユーザーが自分の権限を勝手に変更できません。

また、EC2に付与するIAMロールは「Session Managerと通信してよい」という受け入れ態勢の設定です。「誰が入れるか」の制御ではありません。アクセス制御はあくまでユーザー側のIAMポリシーで行います。

監視・ログ

Session Managerでは、監視の仕組みがサービスに組み込まれています。

記録内容	仕組み	設定
誰がいつどのEC2に接続したか	CloudTrail	自動で記録される
セッション中に打ったコマンド	S3 / CloudWatch Logs	出力先を設定すれば記録される

踏み台サーバーの場合、ログはサーバー内のファイル（/var/log/auth.log等）に残ります。ただし、ログの保管・監視は自分で設定する必要があります。サーバーが壊れたらログも失われる可能性がありますよね。Session Managerのログはサーバーの外（AWSのサービス側）に保存されるため、EC2が壊れても消えません。

プライベートEC2との通信経路

Session Managerは「SSHポートを開けなくていい」と述べました。ではプライベートサブネットのEC2はどうやってSession Managerのサービスと通信しているのでしょうか。

プライベートサブネット単体では外との通信経路が一切ありません。通信経路を確保する方法は2つあります。

NATゲートウェイ経由

NATゲートウェイは、プライベートサブネットのEC2が外向きの通信（EC2側から始める通信）をするための出口です。パブリックサブネットに配置します。

EC2(プライベート) → NATゲートウェイ(パブリック) → インターネット → Session Managerサービス

ここで「外向き通信」とは、EC2側から始めた通信のことです。EC2がリクエストを送り、そのレスポンスが返ってくるのはOKですが、外部から勝手に始まった通信は通しません。一方通行の出口であり、入口にはなりません。

NATゲートウェイはSession Manager以外の用途（外部API呼び出し、OSアップデートなど）でも使います。そのため、多くのプロジェクトで既に存在しています。

VPCエンドポイント経由

VPCエンドポイントは、AWSのサービスへの接続口をVPCの中に直接作る仕組みです。インターネットを経由しません。

EC2(プライベート) → VPCエンドポイント → Session Managerサービス

Session Manager用には以下の3つのエンドポイントが必要になります。

エンドポイント	役割
`com.amazonaws.ap-northeast-1.ssm`	SSMサービスとの基本通信
`com.amazonaws.ap-northeast-1.ssmmessages`	セッションのデータ通信
`com.amazonaws.ap-northeast-1.ec2messages`	EC2へのコマンド送受信

どちらを使うか

NATゲートウェイが既にあるプロジェクトであれば、それを使えば追加コストはかかりません。NATゲートウェイがない環境なら、VPCエンドポイントの方がセキュリティ面で堅いです（インターネットを経由しないため）。

	NATゲートウェイ	VPCエンドポイント
通信経路	インターネット経由	VPC内で完結
コスト	月$30〜（＋通信量課金）	月$20程度（3エンドポイント分）
他の用途	EC2の外向き通信全般に使える	Session Manager専用

踏み台サーバーとSession Managerの比較

最後に、ここまでの内容を一覧で整理します。

項目	踏み台サーバー	Session Manager
中継するもの	EC2インスタンス（自分で管理）	AWSのマネージドサービス
SSHポートの開放	必要（攻撃対象になり得る）	不要
SSH鍵の管理	必要（ユーザーごとに公開鍵を登録）	不要（IAMで認証）
サーバーの保守	必要（OSパッチ、セキュリティ更新）	不要（AWSが管理）
アクセス制御	サーバー側で公開鍵を管理	ユーザー側のIAMポリシーで管理
監視・ログ	自前で設定が必要	CloudTrailで自動記録
コスト	月$12〜20（EC2 + Elastic IP）	月$0〜20（通信経路による）

踏み台サーバーが今も使われるケース

Session Managerの方が運用負荷・セキュリティの面で優位ですが、踏み台サーバーが今も使われるケースはあります。

SSMエージェントが対応していない古いAMI（OSイメージ）: Session Managerを使うにはEC2上でSSMエージェントが動く必要がある。対応していないOSではSSHで接続するしかない
AWS以外の環境: 踏み台サーバーはSSHの仕組みなので、オンプレミス（自社データセンター）や他のクラウドでも使える。Session ManagerはAWSのサービスなのでAWSでしか使えない
既存の運用が確立されている: Session Managerへの移行にはIAMポリシーの設計、VPCエンドポイントの設定、接続方法の変更などが必要になる。動いている環境をあえて変えない判断もある

おわりに

踏み台サーバーは、プライベートサブネットへのアクセスを実現するために長く使われてきた手法です。入口を1箇所に集約することでセキュリティと監視を実現するという考え方自体は今も有効です。ただし、その実現方法はサーバーを自前で管理する形から、AWSのマネージドサービスに任せる形へと変わりつつあります。

なお、本記事では詳しく触れませんでしたが、EC2 Instance Connect Endpointという選択肢もあります。一時的なSSH鍵を自動生成して接続する仕組みで、踏み台サーバーなしでプライベートサブネットのEC2にSSH接続できます。無料で利用できるため、興味のある方は調べてみてください。

参考