実現したいこと
プライベートサブネットにあるEC2への接続にIP制限をかけたい。
結論
- EC2 Instance Connectエンドポイントを、クライアントのソース IP アドレスを保持する設定で構成する。
- EC2インスタンスのセキュリティグループのインバウンドルールで許可したいIPアドレス範囲のみ許可する。
以下のような構成になります。
EC2 Instance Connectとは？
アマゾン EC2 インスタントコネクト を使用すると、Secure Shell (SSH) 経由で Linux インスタンスに安全に接続できます。EC2 インスタントコネクト では、AWS Identity and Access Management (IAM) ポリシーおよびプリンシパルを使用して、インスタンスへの SSH によるアクセスをコントロールします。SSH キーを共有および管理する必要はありません。EC2 Instance Connect を使用したすべての接続リクエストは、AWS CloudTrail にログとして記録されるため、接続リクエストを監査できます。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/connect-linux-inst-eic.html
EC2インスタンスへのSSH接続を、SSHキー管理不要で実現できる機能です。
EC2 Instance Connect を使用してインスタンスに接続すると、EC2 Instance Connect API から SSH パブリックキーがインスタンスメタデータにプッシュされ、60 秒間保持されます。ユーザーにアタッチされた IAM ポリシーにより、ユーザーはパブリックキーをインスタンスメタデータにプッシュすることを許可されます。SSH デーモンは、インスタンスメタデータから承認用のパブリックキーを検索してユーザーをインスタンスに接続するために、EC2 Instance Connect のインストール時に設定される AuthorizedKeysCommand と AuthorizedKeysCommandUser を使用します。
とのことなので、Instance ConnectがSSHキーをいい感じにしてくれているようです。
そしてEC2 Instance Connectエンドポイントを利用することで、プライベートなEC2（Linuxインスタンス）にSSH接続が可能となります。
[参考]
実装手順
[参考]
こちらにも書かれているように、管理トラフィックのユースケースを想定されているため考慮点はいくつかあります。
細かい制限等はドキュメントを参照してください。
前提
プライベートサブネットにEC2を起動していること
EC2 Instance Connectエンドポイントを作成する
VPCマネジメントコンソールのサイドバーからエンドポイントのページに行き、Create endpointからエンドポイントを作成します。
（VPCエンドポイントを作成するのと同じです。）
ここでエンドポイントタイプを「EC2 Instance Connect」を選択。
EC2があるVPCとサブネットを選びます。セキュリティグループもEC2 Instance Connectエンドポイント用のものを選択。（設定内容は後述）
そしてこの作成時点で、高度な設定の「Preserve Client IP」にチェックを入れます。（エンドポイント作成ごは変更できません）
EC2 Instance Connectエンドポイントのセキュリティグループ
- インバウンドルール：不要（ここでIP制限をしても適用されません）
- アウトバウンドルール：：EC2への接続（SSH等、必要なプロトコル）を許可
EC2側の設定
EC2のセキュリティグループは以下のように設定します。
- インバウンドルール：任意のIPアドレス範囲からのトラフィックを許可（EC2 Instance Connectエンドポイントグループのセキュリティグループの指定は不要）
- アウトバウンドルール：必要なトラフィックを許可
接続してみる
コンソールからインスタンスに接続してみます。
※AWS CLIを利用しての接続も可能です。
許可されたIPアドレスから
接続できました！
許可していないIPアドレスから
セキュリティグループの設定をいじってIPアドレス範囲を別のものにして再度アクセスすると、このように接続に失敗します。
何がうれしいの？
EC2 Instance Connectを利用することでプライベートサブネットにあるリソースへの踏み台サーバーとしてのEC2をパブリックにしなくていいことが大きなメリットです。
（または、プライベートサブネットにあるEC2への接続にパブリックな踏み台サーバーが不要となる）
プライベートなEC2への接続にはSession Managerという選択肢もありますが、VPCエンドポイントを複数構成する必要があるため、シンプルな管理用ユースケースにおいてはコスト面を踏まえてもEC2 Instance Connectが優位なのではと思います。
なおかつクライアントIPの保持を設定することで、IAM認証した上でさらにプライベートなEC2への接続にもIP制限をしたい！を実現できます。
開発者が踏み台サーバーの用途でEC2を置きたい（だからこそ、パブリックには置かずにIP制限だけでも実装しておきたい）といった場面でとても有効です。
EC2への安全な接続の選択肢
re:Invent2024でのAWS Verified AccessアップデートによりEC2へのSSH接続をゼロトラストベースで実現可能になりました。
こちらを検証しているタイミングで、EC2への接続をIP制限したい！ということがあり調べていたところEC2 Instance Connectで良いのでは？ということで本記事の内容を試してみました。
AWS Verified AccessでもIP制限自体は実現できます。こちらはネットワークに限らずID認証も交えたより厳密かつ柔軟なアクセス制御を実現できる一方で、接続クライアントやSSHキーの管理が必要になります。
またEC2 Instance Connectは作成できる数やログ出力等に制限があり、用途によってはSessionManagerが有力となるパターンもあるかと思います。
どんな要件で、どのぐらい厳しく、そして金銭的・工数的なコストはどうか？を考えて、プライベートなEC2への安全な接続の方法を選ぶことができるため、とくに踏み台サーバーのような用途のEC2をパブリックに配置する必要はほとんどなくなりそうです。
Discussion