1. はじめに

こんにちは、MSPセクションの毛利です。

踏み台サーバー経由でEC2に接続しているお客様に対して、リプレースのタイミングで踏み台サーバーに代わる接続方法を提案する機会がありました。

今回は、提案の際に調べた内容を自身の頭の整理を兼ねてブログにまとめたいと思います。

2. どんな接続方法があるの

そもそも、どんな接続方法があるのでしょうか？

困った時のAWS公式ドキュメント！

EC2の接続方法についても、ユーザーガイドに充実した内容のページがあります。さすがのAWS公式ドキュメントです、いつもお世話になっております。

AWS公式ドキュメントでは接続オプションとして、いくつかの接続方法が選択肢として記載されています。

参考：EC2 インスタンスに接続する

たくさんありますね。しかし、どれを選べばいいのでしょうか。

そのヒントとして、AWS公式ドキュメントに以下の記載があります。

インスタンスへの接続方法は、インスタンスのオペレーティングシステムと、インスタンスへの接続に使用するコンピュータのオペレーティングシステムによって異なります。

つまり、接続先OS（インスタンスのオペレーティングシステム）と接続元OS（インスタンスへの接続に使用するコンピュータのオペレーティングシステム）によって接続方法が異なるということのようです。

それでは、もう少し詳しく見ていきましょう。

3. 各接続方法は何が違うの

各接続方法の違いを比較しやすいように、AWS公式ドキュメントで確認できる情報を一覧で整理してみましょう。

接続先OS / 接続元OS一覧

まずは、接続先OSと接続元OSについて整理してみます。

接続方法 接続先OS 接続元OS ポート 接続ツール
SSH クライアントを使用して Linux インスタンスに接続する Linux – SSH
  • SSHクライアント
PuTTY を使用して Linux インスタンスに接続する Linux Windows SSH
  • PuTTY（SSHクライアント）
RDP クライアントを使用して Windows インスタンスに接続する Windows – RDP
  • RDPクライアント
Fleet Manager を使用して Windows インスタンスに接続する Windows – RDP
  • Fleet Manager（AWSコンソール）
Session Manager による接続 Linux

Windows

 – –

※１
  • AWSコンソール
  • SSHクライアント（AWS CLIコマンドを使用）
  • RDPクライアント（AWS CLIコマンドを使用）
EC2 Instance Connect を使用して接続 Linux – SSH
  • AWSコンソール
  • SSHクライアント（AWS CLIコマンドを使用）
EC2 Instance Connect エンドポイント を使用した接続 Linux

Windows

 – SSH

RDP
  • AWSコンソール
  • SSHクライアント（AWS CLIコマンドを使用）
  • RDPクライアント（AWS CLIコマンドを使用）

※１：Session Manager による接続 では、セキュリティグループにSSHやRDPを許可するインバウンドルールは不要ですが、HTTPSを許可するアウトバウンドルールが必要になります。（参考：ステップ 1: Session Manager の前提条件を満たす）

各接続方法について接続先OSと接続元OSの情報を一覧で整理してみましたが、接続したいOSがLinuxなのかWindowsなのかで、大きく分かれることがわかります。

前提条件

各接続方法には前提条件がいくつかありますので、こちらも一覧で整理してみます。

接続方法 前提条件
SSH クライアントを使用して Linux インスタンスに接続する –
PuTTY を使用して Linux インスタンスに接続する
  • プライベートキーをPPK形式に変換する
RDP クライアントを使用して Windows インスタンスに接続する –
Fleet Manager を使用して Windows インスタンスに接続する
  • Amazon EC2 インスタンスが Systems Manager のマネージドノードとして設定されていること
  • SSM Agent がインストールされていること　など

（詳細は環境のセットアップ参照）
Session Manager による接続
  • SSM Agent がインストールされていること
  • エンドポイントへの HTTPS (ポート 443) アウトバウンド・トラフィックが許可されていること
  • ローカルマシンに AWS CLI がインストールされていること　など

（詳細はステップ 1: Session Manager の前提条件を満たす参照）
EC2 Instance Connect を使用して接続
  • EC2 Instance Connect がインストールされていること
  • インターネット経由でインスタンスに接続できること　など

（詳細はEC2 Instance Connect の前提条件参照）
EC2 Instance Connect エンドポイント を使用した接続
  • EC2 Instance Connect エンドポイントが作成されていること
  • インスタンスには IPv4 アドレスが必要（IPv6 アドレスはサポート対象外）
  • EC2 Instance Connect がインストールされていること　など

（詳細は考慮事項参照）

※：SSH 接続の前提条件やRDP接続の前提条件のような各接続方法に共通するような条件は一覧には記載していません。

エージェントのインストールなど事前の準備が必要なものもありますが、特に問題となる条件はなさそうです。

メリット

また、公式ドキュメントにはAWSの機能を利用して接続するメリットについても記載があります。併せて、確認してみましょう。

Fleet Manager を使用して Windows インスタンスに接続する

  • リモートデスクトップを使用するためにインバウンドポートを開く必要はない　など

Session Manager による接続

  • IAM ポリシーを使用してマネージドノードのアクセス制御を一元化
  • インバウンドポートを開く必要ない
  • 踏み台ホストや SSH キーを管理したりする必要はない
  • ログ記録と監査のセッションアクティビティ　など

EC2 Instance Connect を使用して接続

  • IAMを使用して、インスタンスへの SSH によるアクセスをコントロールできる
  • SSH キーを共有および管理する必要はない
  • すべての接続リクエストは、AWS CloudTrail にログとして記録されるため、接続リクエストを監査できる　など

EC2 Instance Connect エンドポイント を使用した接続

  • 踏み台ホストを使用したり、仮想プライベートクラウド (VPC) がインターネットに直接接続したりする必要がなく、インターネットからインスタンスに安全に接続できる
  • インスタンスにパブリック IPv4 アドレスの設定が不要
  • IAMを使用して、インスタンスに接続する EC2 Instance Connect エンドポイント の作成と使用へのアクセスを制御できる
  • インスタンスへの接続を試みると、成功または失敗を問わず、すべて CloudTrail にログが作成　など

制限事項

最後に、主な制限事項についても確認しておきましょう。

Fleet Manager を使用して Windows インスタンスに接続する

  • 現在、Windows Server 2012 RTM 以降を実行しているインスタンスのみで使用できる
  • コンソール専用サービスで、マネージドインスタンスへのコマンドライン接続はサポートしていない（シェルを介して Windows Server マネージドインスタンスに接続するには、 Session Manager を使用できる）

Session Manager による接続

  • System Manager がサポートしているオペレーティングシステムであること
  • AWS CLI を使用してセッションコマンドを実行するには、CLI のバージョン 1.16.12 (またはそれ以降) を使用していて、ローカルマシンに Session Manager プラグインがインストールされている必要がある
  • ログ記録は、ポート転送または SSH を介して接続する Session Manager セッションでは使用できない

EC2 Instance Connect を使用して接続

  • Linux インスタンスに接続するためのオプションの 1 つであり、Windows インスタンスには接続できない
  • インターネット経由でインスタンスに接続できること、または AWS Direct Connect、AWS Site-to-Site VPN、 VPC ピアリングを使用しプライベートIPアドレスで接続できること

EC2 Instance Connect エンドポイント を使用した接続

  • 特に管理トラフィックのユースケースを対象としており、大量のデータ転送を想定していません。大量のデータ転送はスロットリングされる
  • EC2 Instance Connect エンドポイント は VPC およびサブネットごとに 1 つだけ作成できる
  • 確立された TCP 接続の最大持続時間: 1 時間 (3,600 秒)。IAM ポリシーでは最大許容時間を最大 3,600 秒　など

4. どの接続方法を選べばいいの

少し長くなってしまいましたが、EC2の接続方法についてAWS公式ドキュメントで確認してきました。

それでは、どの接続方法を選べばいいのでしょうか。

今回は、1. はじめに で書いたように下図のような踏み台サーバーに代わる接続方法を選んでみましょう。

踏み台サーバーの目的

一般的に踏み台サーバーを使用する目的に、以下のようなセキュリティの側面があると思います。

  • 踏み台サーバー経由のアクセスに制限
  • アクセスログの集中管理
  • 内部ネットワークの保護

踏み台サーバーに代わる接続方法

上記踏み台サーバーの目的を考えると、メリットに記載の内容から自然と以下2つの接続方法に絞られます。

どちらも、IAMによる接続制御、CloudTrailでのログ記録、インバウンドポートを開ける必要がないなど、踏み台サーバーの目的と合う接続方法です。

また、EC2 Instance Connect エンドポイントは制限に記載したとおり管理トラフィックのユースケースを対象としており、大量のデータ転送を想定していませんとのことなので、インスタンスに接続しインスタンスの使用状況を確認するなどのケースではEC2 Instance Connect エンドポイント、ローカルから大量データを転送するような使い方をするケースではSession Managerのような使い分けもできそうです。

5. まとめ

いかがでしたでしょうか？

踏み台サーバー経由でEC2に接続している場合、踏み台サーバーを維持するためのコストやパッチ適用などメンテナンス作業なども発生しますが、EC2 Instance Connect エンドポイントやSession Managerは追加コストなしで利用できサーバーのメンテナンスも不要です。

みなさまの環境でも一度検討してみてはいかがでしょうか。

実際利用する際に必要な詳細情報はAWS公式ドキュメント内に記載がありますので、参考にしていただければと思います。

本記事がみなさまの参考になれば幸いです。