AWSでプライベートサブネットのEC2に接続する際、以前はBastion HostやJump Serverを配置する構成が一般的でした。管理者はまずパブリックサブネットのBastion EC2にSSH/RDPで接続し、その後プライベートサブネットのサーバーに再度接続していました。しかし、最近のAWS環境では、単純な管理接続のためにBastion Hostを別途運用するよりも、AWS Systems Manager Session ManagerやEC2 Instance Connect Endpointを使用する方式がより推奨されています。AWS公式ドキュメントでも、Session Managerはインバウンドポートの開放、Bastion Hostの維持、SSHキーの管理なしにEC2のような管理対象ノードにアクセスできると説明しています。 (AWS Documentation)
なぜBastion Hostを減らそうとするのか？
Bastion Hostはプライベートサブネット内のサーバーに入るためのゲートウェイの役割を果たします。構造自体は単純で馴染み深いものですが、結局はインターネットからアクセス可能なEC2を1台追加で運用する方式です。このサーバーは、セキュリティパッチ、アクセス制御、SSHキー管理、ログ収集、障害対応、コスト管理の対象となります。
従来の構造は以下の通りです。
관리자 PC
-> Public Subnet Bastion Host
-> Private Subnet EC2問題は、Bastion Hostが突破されると内部サーバーへの経路が開かれる可能性がある点です。そのため、セキュリティグループで会社のIPのみを許可したり、MFA、アクセス承認、セッション記録などを付加しますが、運用負担は残り続けます。
AWSブログでも、Bastion HostをSystems Managerに置き換えることで、攻撃対象領域を減らし、ホストで実行されたコマンドの可視性を高めることができると説明しています。 (Amazon Web Services, Inc.) 2024年のAWSブログでも、Bastion Host方式はデプロイ、ハードニング、維持管理、モニタリングの負担とEC2実行コストがあり、Session Managerを使用する方式はセキュリティ・監査体制の改善と管理負担の軽減に役立つと説明しています。 (Amazon Web Services, Inc.)
主要な代替案1: AWS Systems Manager Session Manager
Session ManagerはAWS Systems Managerの機能の一つで、EC2に直接SSHポートを開放することなく、コンソールやAWS CLIを通じてサーバーシェルに接続できるようにします。AWSドキュメントによると、Session ManagerはブラウザベースのシェルとAWS CLI接続をサポートしており、IAMポリシーを通じてどのユーザーがどのインスタンスに接続できるかを制御できます。 (AWS Documentation)
構造は以下の通りです。
관리자 PC
-> AWS Systems Manager Session Manager
-> SSM Agent
-> Private EC2この方式の核心は、EC2へのインバウンドSSHを開放するのではなく、EC2内部のSSM AgentがAWS Systems Managerサービスと通信するという点です。したがって、セキュリティグループで22番SSHや3389番RDPをインターネットに開放する必要はありません。
Session Managerを使用するには、通常以下の条件が必要です。
WRIMO-MD-TABLE-0
EC2インスタンスには通常、AmazonSSMManagedInstanceCoreポリシーを含むIAMロールをアタッチします。AWSドキュメントでも、個々のインスタンスプロファイルを構成する際にこのポリシーを選択する手順を案内しています。 (AWS Documentation)
aws ssm start-session
--target i-xxxxxxxxxxxxxxxxx
--region us-east-1
--profile my-ssoプライベートサブネットでNAT Gatewayなしに完全に閉鎖的な構造を構築したい場合は、VPC Endpointを使用します。Systems Manager用のVPC Endpointを構成すると、管理対象インスタンスはインターネットゲートウェイ、NATデバイスなしでもAWS PrivateLinkを通じてSystems Managerと通信できます。AWSドキュメントでも、PrivateLink使用時、管理インスタンスとSystems Manager、EC2間のトラフィックはAmazonネットワーク内で処理され、インターネットアクセスは不要であると説明しています。 (AWS Documentation)
代表的に必要なエンドポイントは以下の通りです。
com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messagesAWSドキュメントによると、管理対象ノードはssm、ssmmessages、ec2messagesエンドポイントへのHTTPS 443アウトバウンド通信が可能である必要があり、VPC Endpointを使用する場合、ssmmessagesエンドポイントはSession Managerのセキュアデータチャネル通信に必要です。 (AWS Documentation) (AWS Documentation)
主要な代替案2: EC2 Instance Connect Endpoint
Session Managerが「SSHなしで接続する方式」に近いとすれば、EC2 Instance Connect Endpointは「BastionなしでSSH/RDPの使いやすさを維持する方式」に近いと言えます。
EC2 Instance Connect Endpointは、インターネットからプライベートIPインスタンスに安全に接続できるようにし、Bastion HostやVPCの直接的なインターネット接続がなくても使用できます。AWSドキュメントでは、この機能を「identity-aware TCP proxy」と説明しており、IAM認証情報を使用してユーザーPCからエンドポイントまでプライベートトンネルを作成し、トラフィックがVPCに到達する前に認証・認可されると説明しています。 (AWS Documentation)
構造は以下の通りです。
관리자 PC
-> EC2 Instance Connect Endpoint
-> Private EC2この方式は、既存のSSHクライアント、SSHキー、運用ツールを維持する必要がある組織に適しています。ただし、EC2 Instance Connect Endpointは管理トラフィック用途であり、大容量データ転送用ではありません。AWSドキュメントでも、高容量データ転送は制限される可能性があり、エンドポイントあたりの同時接続数と接続持続時間に制限があると案内しています。 (AWS Documentation)
Bastion Host、Session Manager、EC2 Instance Connect Endpointの比較
| 項目 | Bastion Host | Session Manager | EC2 Instance Connect Endpoint |
|---|---|---|---|
| Public IPの必要性 | Bastionに必要 | 不要 | 対象EC2には不要 |
| SSH 22番ポートの開放 | Bastionに必要 | 不要 | 対象セキュリティグループでエンドポイント経路を許可 |
| SSHキー管理 | 必要 | 基本接続は不要 | 使用方式により必要 |
| アクセス制御 | OSアカウント、SSHキー、SG中心 | IAM中心 | IAM + ネットワーク制御 |
| 運用負担 | 高 | 低 | 中 |
| 使いやすさ | 慣れている | コンソール/CLIベース | 既存のSSH方式と類似 |
| 推奨状況 | レガシー、特殊環境 | 一般的な運用接続 | SSHの使いやすさ維持が必要 |
実務基準の推奨
一般的なEC2運用接続であれば、Session Managerを優先的に検討するのが良いでしょう。セキュリティグループからSSH/RDPのインバウンドを削除でき、IAMベースでアクセス制御を統合できるためです。AWSドキュメントもSession Managerの利点として、一元化されたIAMアクセス制御、インバウンドポートの排除、Bastion HostとSSHキー管理の不要、コンソール/CLIからのワンクリックアクセス、セッション活動のロギングなどを説明しています。 (AWS Documentation)
ただし、すべての状況でSession Managerが正解というわけではありません。既存の運用自動化がSSHベースで強く結びついている場合や、scp、SSHトンネル、既存の管理ツールとの互換性が重要であれば、EC2 Instance Connect Endpointの方がより自然かもしれません。AWSドキュメントでも、Session Managerを介したSSH接続とSCPの使用は可能ですが、SSHやポートフォワーディング方式のセッションはSSHがデータを暗号化するため、Session Managerがセッション内容をロギングできないという制限があると案内しています。 (AWS Documentation)
結論
AWSでBastion Hostは依然として使用できます。しかし、単にプライベートEC2に接続するための用途であれば、今後はBastion Hostを新規に作成するよりも、Session ManagerやEC2 Instance Connect Endpointをまず検討する方がより現代的な設計です。
特に運用接続、セキュリティ監査、キー管理の最小化、プライベートサブネット中心の設計を考慮するなら、Session Managerが最もクリーンです。逆に、既存のSSHの使いやすさを維持しつつBastion EC2だけを排除したい場合は、EC2 Instance Connect Endpointが良い代替案となります。
一文でまとめると以下の通りです。
과거에는 Private EC2 접속을 위해 Bastion Host를 두는 구성이 일반적이었지만,
최근 AWS 환경에서는 Session Manager나 EC2 Instance Connect Endpoint를 사용해
Bastion Host 없이 접근하는 방식이 더 선호된다.
コメントを残す