はじめに

「VPC Ingress Routing」なるものがリリースされましたので、試してみました。

New – VPC Ingress Routing – Simplifying Integration of Third-Party Appliances

従来出来なかったこと

従来、インターネットやVPN経由で、EC2上に構築したファイアウォール(FW)等を挟んでVPC内の他のサーバにアクセスさせたい場合、

FWで宛先IPをNATする
クライアントとFWでトンネルを貼る

のような構成しか取れなかったと思います。したがって、例えば、宛先のサーバのIPアドレスを指定して通信する要件を実現するには上図の右側のトンネルを貼る構成を取るしか無く、複雑な設計と構築をする必要がありました。

これはVPCに必ず存在し最優先で処理される「ローカルルート」がVPCのCIDR宛のパケットを処理してしまうため、VPCのCIDR宛のパケットは必ず宛先のインスタンスに直接届いてしまうことによるものでした（VPCのCIDRより短いCIDRのルートは無効となり、ロンゲストマッチのように優先して処理できなかった）。

ルートテーブル - Amazon Virtual Private Cloud

VPC Ingress Routingで出来るようになること

今回のリリースにより、デフォルトのローカルルートより優先した経路を設定できる「ゲートウェイルートテーブル」というものが設定できるようになりました(※1)。あらかじめローカルルートより（ロンゲストマッチ的に）優先されるルートテーブルを作成しておき（※2）、IGWやVGWに紐付けます。これにより、IGWやVGW経由でVPCに入ってきたパケットが宛先IPのサーバに到達する前にEC2上に構築したFW等を経由させることが出来ます。

ドキュメント的には以下のものが分かりやすいと思います。 Route Tables - Gateway Route Tables

※1 ドキュメントが本記事執筆時点で英語のものしか無いため、正式な日本語名は異なる可能性があります ※2 ローカルルートと全く同じCIDRのルートは設定できません

試してみた

AWSマネジメントコンソールで実際に試してみました。

今回の構成

少し簡易ですが、以下のようにVPCとEC2インスタンスを構築しておきます。IGW経由のトラフィックを特定のインスタンス（図中の「アプライアンス」）を経由するようにします。また「アプライアンス」インスタンスのENIの「送信元先チェック」は無効化しておきます。両インスタンスにPublic IPを付与しておきます。ポイントは上部のルートテーブルをあらかじめ作成しておくことです。通信対象のサブネットのCIDRと通信を経由させたいサーバのENIを指定し、特定のサブネットには紐付けないようにしておきます。

設定

上記の「ゲートウェイルートテーブル」をIGWに紐付けます。マネジメントコンソールのルートテーブルのページを開き、作成しておいた「ゲートウェイルートテーブル」を選択（画像では Ingress ）し、下部タブの「Edge Associations」を選択し、「Edit Edge Associations」を選択します。