VPCのルートテーブルでVPCローカルより具体的なルートを指定可能になりました


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

初めに

近日AWS VPCルートテーブルの許可により、サブネット間の詳細のルートがコントロールできるようになりました。

Amazon VPC Routing Enhancements Allow You to Inspect Traffic Between Subnets In a VPC | AWS News Blog

今携わっているプロジェクトでもセキュリティチェックのため、サブネット間の通信はアプライアンス(ファイヤーウォール)は通過する要件がありました。

早速ですが、今回のアップデートを試したいと思います。

ルーティングイメージ

Subnet AとSubnet BにあるEC2が通信したい場合、必ずSubnet Cにあるアプライアンスを経由するのは、今回の設定ポイントです。

動作確認

1.サブネット作成

図上のように、下記三つのサブネットを作成する

create_subnet

2.テスト用インスタンスを作成する

下記のように、それぞれのサブネットにテスト用インスタンスを作成する。
※Amazon Linux2を選定しています

本物のアプライアンス機械がないため、いったんAmazon Linuxで代替する。
トラフィックを転送するため、以下のように転送設定をします。

sudo sysctl -w net.ipv4.ip_forward=1

以下のコマンドで、フォーワード設定が1になっているかを確認します。

cat /proc/sys/net/ipv4/ip_forward

それでここで重要なのは、セキュリティのため、デフォルトでは、AWS側がトラフィックの転送が禁止されています。
フォーワード設定を有効するために、以下ように「送信元/送信先チェック」を停止する必要があります。

3.ルートテーブルを作成

Subnet AとSubnet Bは下記ルートテーブルを利用する。
デフォルトのVPC範囲のルート以外に、お互いにサブネット範囲のアプライアンスを経由するルートを追加しています。

route_table

ターゲットのENI情報は、アプライアンスのENI IDとなります。

Subnet CはデフォルトのローカルVPCしかないルートテーブルを利用する。

route_table_default

4.通信テスト

ここまで、設定完了しましたので、通信できるかは確認します。

上記のように、Pingが通れます。また、ルート確認でアプライアンスを経由することも確認できます。

纏め

ローカルルールより具体的なルートをい指定できるようになったことで、サブネット間の通信チェックが楽になりました。
これで、楽の方法でセキュリティ要件を実現できるとプロジェクトに提案したいと思います。

以上です。

Last modified: 2024-02-07

Author