1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【AWS】踏み台不要!完全閉域網のEC2にSSMポートフォワードで接続する

Last updated at Posted at 2026-01-18

目次

  1. はじめに
  2. ポートフォワード機能を利用するメリット
  3. 構成図と通信フロー
  4. 構築手順
  5. まとめ

はじめに

AWS上のプライベートサブネットにあるEC2(WebサーバーやDBサーバーなど)に、ローカルPCから接続したい場面は多々あります。
従来、これを行うには以下のような「踏み台(Bastion)サーバー」構成が一般的でした。

  • 従来の構成 : パブリックサブネットに踏み台EC2を立てる → SSH(22)ポートを開ける → SSHトンネルで接続

しかし、この構成にはセキュリティと運用の課題がつきまといます。

  • 踏み台サーバー自体の管理(OSパッチ適用など)が手間
  • セキュリティグループで22番ポートを開けるリスク
  • SSH鍵の管理・配布・漏洩リスク

「AWS Systems Manager (SSM) Session Manager」 のポートフォワード機能を使えば、これらの課題をすべて解決し、踏み台サーバーなしでセキュアに接続できます。
この記事では、特に「インターネット接続さえない完全な閉域網」での構成を例に、その仕組みと手順を解説します。

ポートフォワード機能を利用するメリット

この構成を採用することで、セキュリティと運用効率が劇的に向上します。

  1. インバウンドポート全閉鎖 (Security Group)

    • EC2のセキュリティグループで SSH(22) や RDP(3389) を許可する必要が一切ありません。インバウンドルールを「空(None)」にしても接続可能です。
  2. 踏み台サーバーの廃止

    • 従来必要だった「踏み台サーバー」自体の構築・OS管理・鍵管理が不要になります。管理対象は接続先のEC2のみとなり、運用コストが下がります。
  3. 完全閉域網で動作

    • VPCエンドポイント(PrivateLink)を使用すれば、インターネットゲートウェイ(IGW)やNATゲートウェイがない環境でも接続可能です。
  4. 操作ログの完全な監査

    • 「誰が・いつ・どのインスタンスに」接続したか、すべてのログをCloudTrailやS3に記録できます。

構成図と通信フロー

なぜポートを開けずに、しかもインターネットに出られない環境で接続できるのでしょうか?
以下に構成図と通信の仕組みをまとめました。
image.png

裏側の仕組み:なぜ繋がるのか?

この通信の最大のポイントは、「外から中へ」ではなく「中から外へ」接続している点です。

1. 通信の方向 (Outbound Only)

管理者(ユーザー)がEC2に接続しに行くように見えますが、技術的には EC2内のSSM Agentが、AWSの管理基盤(Systems Manager)に対して「仕事はないですか?」とポーリング(Outbound通信) を行っています。
そのため、EC2側のファイアウォール(SG)で受信ポートを開ける必要がありません。

2. トンネリングの確立

ユーザーがAWS CLIで接続コマンドを叩くと、Systems Manager経由で指令が飛びます。EC2上のSSM Agentはそれを検知し、WebSocketを使ってSystems Managerとの間にトンネルを確立します。ローカルポートへのアクセスは、このトンネルを通ってEC2へ転送されます。

3. VPCエンドポイントの役割

図にある Endpoint Network Interface は、AWS PrivateLink (VPC Endpoint) です。
SSM Agentは、このVPCエンドポイントを経由してAWSのネットワーク網を通ってAPIへアクセスします。これにより、インターネットへの経路(IGW/NAT)が一切ない環境でも管理操作が可能になります。

構築手順

ここからは具体的な設定手順です。
ポイントは、「サーバー側(EC2)」と「クライアント側(PC)」の両方に適切な権限が必要という点です。

前提条件

  1. AWS環境の準備

    • VPCおよびプライベートサブネット、EC2インスタンスは作成済みであること。
    • EC2にSSM Agentが正常に稼働していること。(Amazon Linux 2023用AMIの場合、エージェント(SSM Agent)がプリインストールされています)
    • 接続に使用する SSH秘密鍵(.pem) が手元にあること。
  2. ネットワーク設定(セキュリティグループ)

    • EC2のセキュリティグループ:
    • インバウンド: ルールなし(None)でOK。
    • アウトバウンド: HTTPS (443) のみ許可(宛先: 0.0.0.0/0 または VPCエンドポイントのPrefix List)。
  3. ローカル環境の準備

    • PCに AWS CLI がインストールされていること。
    • PCに Session Manager Plugin for AWS CLI がインストールされていること(必須)。

手順1: VPCエンドポイントの作成

完全閉域網(インターネットに出られない環境)からSSMに接続するために、以下の3つのインターフェイス型VPCエンドポイントを作成し、EC2があるプライベートサブネットに紐付けます。

エンドポイントサービス名 役割
com.amazonaws.[region].ssm SSMコア機能用
com.amazonaws.[region].ec2messages メッセージ配信サービス用
com.amazonaws.[region].ssmmessages 重要: ポートフォワード等のデータチャネル用

注意:
VPCエンドポイント自体にアタッチするセキュリティグループでは、「EC2からのHTTPS(443)アクセス」を許可 してください(インバウンドルール)。

手順2: サーバー側 (EC2) のIAMロール設定

接続される側のEC2には、SSMと通信するための権限が必要です。
IAMロールを新規作成し、対象のEC2にアタッチします。

  • ロールにアタッチするポリシー:
  • AmazonSSMManagedInstanceCore (AWS管理ポリシー)

手順3: クライアント側 (PC) のIAMユーザー設定

コマンドを実行する「あなた(IAMユーザー)」用のIAMユーザーを作成し、アクセスキーを発行します。
権限は AdministratorAccess でも動きますが、「ポートフォワードだけを許可したい」 場合は以下のカスタムポリシーをアタッチします。

▼ ポートフォワードのみを許可する最小権限ポリシー (JSON例)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowStartPortForwardingSession",
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ec2:*:*:instance/*",
                "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession" 
            ]
        },
        {
            "Sid": "AllowTerminateSession",
            "Effect": "Allow",
            "Action": [
                "ssm:TerminateSession",
                "ssm:ResumeSession"
            ],
            "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
        }
    ]
}

手順4: AWS Configure設定

手順3で作成したIAMユーザーの認証情報を、ローカルPCのAWS CLIに登録します。

aws configure

# 以下、対話形式で入力
# AWS Access Key ID [None]: (手順3で取得したアクセスキー)
# AWS Secret Access Key [None]: (手順3で取得したシークレットキー)
# Default region name [None]: ap-northeast-1  (利用しているリージョンを入力)
# Default output format [None]: json

手順5: ポートフォワードの開始

準備ができたら、ローカルPCのターミナルから以下のコマンドを実行します。
ここでは、ローカルの「10022番ポート」を、EC2の「22番ポート(SSH)」に転送します。

aws ssm start-session \
    --target "i-0123456789abcdef0" \
    --document-name AWS-StartPortForwardingSession \
    --parameters '{"portNumber":["22"],"localPortNumber":["10022"]}'

  • --target: 接続したいEC2インスタンスID
  • portNumber: EC2側のポート(SSHなので22)
  • localPortNumber: 自分のPCで受け付けるポート(ここでは10022とします)

コマンド実行後、以下のように表示されればトンネル開通です。
Starting session with SessionId: xxxxxxx...

手順6: 接続確認 (SSH接続)

手順5のターミナルはそのままで、新しいターミナルを開き、以下のSSHコマンドを実行します。
IPアドレスではなく localhost10022 ポートに対して接続するのがポイントです。

# -p でローカル側のポートを指定
ssh -i /path/to/my-key.pem -p 10022 ec2-user@localhost

  • -i: EC2に設定されている秘密鍵を指定
  • -p: 手順5で設定した localPortNumber (10022) を指定
  • @localhost: 自分自身のポートに向けて接続

これで、インバウンドポートが閉じられたプライベートEC2に対して、SSHログインが成功します。

まとめ

SSM Session Managerのポートフォワード機能を使うことで、セキュリティ向上運用負荷軽減を同時に実現できます。

  • 踏み台サーバー不要
  • ポート開放不要 (Inbound All Close)
  • インターネット接続不要 (No IGW/NAT)

特に「VPCエンドポイント」と組み合わせた閉域網構成は、エンタープライズ環境やセキュリティ要件の厳しいプロジェクトで非常に強力な武器になります。ぜひ試してみてください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?