はじめに
対象読者
- インフラ構成図に bastion が出てきて、なぜ要るのか腹落ちしていない人
レガシーなAWS構成を最適化するプロジェクトでbastionという踏み台サーバーの存在にぶち当たったので詳細をまとめます。「直接DBに繋げればいいのに、なんでわざわざ一段挟むんだ？」と内心思っていました。
その認識がひっくり返ったのは、attack surface（攻撃対象面）という言葉で踏み台を捉え直したときでした。この記事では、そのときの腹落ちをそのまま順に整理していきます。
そもそも、なぜ人がDBに直接触る必要があるのか
「アプリ経由でしかDBに触らない設計が理想」というのは正論です。でも運用していると、どうしても人間が直接リソースに触る場面が出てきます。
- 本番で起きた障害の調査（アプリのログだけでは原因が追えない）
- データの中身を直接確認したい（マイグレーション後の整合性チェックなど）
- 検証作業や、緊急のデータ修正
理想論だけでは現場は回りません。そして触りたい相手は1種類とは限りません。たとえば、よくあるサービス構成だとこんな顔ぶれになります。
- リレーショナルDB（RDS のようなマネージドDB）
- キャッシュ（ElastiCache / Redis）
- プライベートサブネットで動くコンテナ（ECS など）
- VPC Peering 越しにつながる外部マネージドDB（MongoDB Atlas のような外部サービス）
これら全部に、開発者が必要なときだけ安全に入れるようにしたい。さて、どうするか。
開発者をDBに入れる方法は、突き詰めると3つしかない
ここがこの記事の核心です。いろいろやり方があるように見えて、本質的には選択肢は3つに収束します。
①は論外に見えますが、急いでいるときに「とりあえずパブリックにして繋ぐ」をやってしまった経験、ありませんか？ 私はあります。そして消し忘れます。これが一番こわい。
②は一見まともです。IP制限してるんだから安全じゃないか、と。でも在宅勤務でIPは変わるし、出先のカフェから繋ぎたくなるし、結局「DBがインターネットに顔を出している」状態は変わりません。穴を開けたり閉じたりの運用も地味に事故ります。
③が踏み台です。なぜこれが「正解」と言われるのか。鍵になるのが次の概念です。
攻撃対象面（attack surface）という考え方
attack surface とは、ざっくり言えば「攻撃者が攻撃を仕掛けられる入口の総量」です。入口が多いほど、守るべき面が広がり、どこか1つでも穴があれば抜かれます。
ここで①②③を入口の数で並べてみると、違いが一目でわかります。
【踏み台なし（①②）】 【踏み台あり（③）】
Internet Internet
╱ │ │ ╲ ← N個の入口 │ ← 入口は1個だけ
RDS Redis 外部DB ECS bastion（公開・要塞化・監視）
全部が標的 │（VPC内部のSSH/トンネル）
↓
RDS Redis 外部DB ECS（外から到達不能）
①②では、RDSもRedisも外部DBもコンテナも、それぞれがインターネットに面した「入口」になります。攻撃者から見れば標的がN個。1個でも設定をミスれば終わりです。
③では、外から到達できるのは bastion ただ1台。その奥のリソースは、そもそもインターネットからは到達不能なネットワーク（VPC内部）に閉じ込めます。守るべき面が N個から1個に減る。これが踏み台の効きどころです。
図でも整理しておきます。
要点は「踏み台はトラフィックを速くするための中継ではない」ということ。セキュリティ上の関所として、晒す面を1点に絞るために存在しているんです。私が昔つまずいていたのはまさにここでした。
踏み台が「やってはいけない設計」になる瞬間
ただし、踏み台は置けば安全という魔法の箱ではありません。1台に入口を集約するということは、その1台が抜かれたら奥まで通じてしまうということでもあります。踏み台が、文字どおり攻撃者の「踏み台」にされるわけです。
なので公開する1台は徹底的に固めます。最低限このあたりは押さえます。
- SSHは鍵認証のみ。パスワード認証は無効化する
- 22番ポートを世界に開かない（後述のSSMなら、そもそも開けずに済む）
- OS・パッケージを継続的にパッチ適用する（晒している以上、放置は致命的）
- ログインと操作を監視・記録する（誰がいつ入ったか追えるように）
- 不要なソフトを入れない。踏み台は「踏むためだけ」の最小構成に保つ
ここで一つ、当時の私のような人が引っかかりやすい罠があります。「踏み台があるから安心」と思って、踏み台自体の運用を疎かにすること。入口を1個に絞ったということは、その1個の守りに全リソースを集中できるという意味であって、守らなくていいという意味ではありません。
踏み台に公開IPを付けて22番ポートを 0.0.0.0/0 に開けっ放し、というのは典型的な事故構成です。攻撃者は常時SSHポートをスキャンしています。「1台だけだから」と油断すると、その1台が最短の侵入経路になります。
で、2026年の今ならどう作るか（SSM Session Manager）
ここまでが踏み台の「考え方」です。どうやら、現在のAWSでの実装は下記でやるのが良いみたいです。
実は2025年あたりから、「公開IPを付けたSSH踏み台」自体がレガシーな構成と見なされるようになってきました。代わりに推奨されるのが、AWS Systems Manager の Session Manager を使うやり方です1。
何が変わるかというと、踏み台の置き方がこうなります。
- 踏み台EC2に 公開IPを付けない（パブリックサブネットに置かない）
- セキュリティグループの インバウンドを1つも開けない（22番すら開けない）
- 接続はSSMエージェント経由で、IAM認証だけで成立する
- ローカルから
AWS-StartPortForwardingSessionToRemoteHostでポートフォワードすれば、private subnet の RDS にそのまま繋がる2
つまり「踏み台＝入口を1台に絞る」という発想はそのままに、その1台すらインターネットに口を開けないところまで持っていける、ということです。attack surface を1個に絞るどころか、限りなくゼロに近づけられる。最初にこれを知ったときは、正直ちょっと感動しました。
従来のSSH踏み台と並べると違いがはっきりします。
| 観点 | 従来のSSH踏み台 | SSM Session Manager 経由 |
|---|---|---|
| 公開IP | 必要 | 不要 |
| インバウンドのポート開放 | 22番を開ける | 開けない（ゼロ） |
| 認証 | SSH鍵 | IAM（鍵管理が不要） |
| 操作ログ | 自前で仕込む | CloudTrail / S3 / CloudWatch に記録可 |
| IP制限の運用 | 必要（変動して煩雑） | 不要 |
SSMエージェントはアウトバウンド通信が必要なので、踏み台はプライベートサブネットに置きつつ、NATゲートウェイ経由か、NATを使えない場合はVPCエンドポイント経由で外向き通信を確保します。DBサブネットはデフォルトルートを持たせず、外部との通信を完全に遮断するのが定石です2。
なお、本記事の構成・サービス名・推奨事項は2026年6月時点の情報です。AWSの機能は更新が早いので、実装前に公式ドキュメントで最新を確認してください。
まとめ
長くなったので、要点を3つに絞ります。
- 開発者をDBに入れる方法は、突き詰めると「全部公開」「SGで穴あけ」「踏み台1台」の3つしかない
- 踏み台の本質は中継ではなく、晒す面（attack surface）を1点に絞り、奥を外から到達不能にすること
- 2026年の今なら、SSM Session Manager で「公開IPなし・ポート開放ゼロ」の踏み台にできる。従来のSSH踏み台より一段安全
昔の私のように「踏み台＝ただの中継サーバ」だと思っていた人に、この記事の「入口を1個に絞る」という見方が届いたら嬉しいです。
もし自分の構成を「公開IPなし踏み台」へ作り替えてみたら、つまずいたポイントなどぜひ教えてください。次はSSMポートフォワーディングの具体的な手順を書こうと思います。