Network Firewall (Transit Gateway + NATGW) で Multi-AZ 構成

5 min read読了の目安(約4700字
  • Deployment Model3) North-South: Centralized internet egress (VPC to internet via Transit Gateway) and NAT gatewayNetwork Firewall 部分(Inspection VPC) を Multi-AZ で 組みたい人向けです。

  • 上の構成を既に作れる方向けでもありますので、まずは上記参考に Single-AZ 構成を作ってみてください。
  • 途中の作業で AWS CLI が必須です。ご用意ください。

増やすサブネットの用意

基本的には Deployment Model の通り作れば OK です。
主に Network Firewall が存在する Inspection VPC で多少設計変更が必要です。

Inspection VPC で Transit Gateway 用のサブネットと、Network Firewall が作成するエンドポイント用のサブネットが 1 つずつ増えます。つまり合計で 2 つ増える事に。
※ 勿論、既存のサブネットとは同じアベイラビリティゾーンに作成しないでください。同じアベイラビリティゾーンに作ってしまったら Multi-AZ にならないので。

Network Firewall を作る

これらのサブネットを作成した時点で Network Firewall を作成します。
Network Firewall 作成後、Network Firewall エンドポイントがエンドポイント用サブネットにそれぞれ作成されてます。

ルートテーブルを作る

Transit Gateway ENI 用ルートテーブル(Inspection VPC Route Table)を作る

最初の構成図では Inspection VPC Route Table A になる部分です。Inspection VPC Route Table A を増やす感じになります。
所謂、Transit Gateway 用のサブネットを関連付けるルートテーブルになります。

黒で塗り潰しちゃってるので見辛いとは思いますが、それぞれのアベイラビリティゾーンに配置されたエンドポイント用にルートテーブルを作成してます。
0.0.0.0/0 向けのルートをエンドポイント(vpce-xxxxx)をターゲットに設定して作成する必要があります。
この時、アベイラビリティゾーン毎にルートテーブル分けてますので、ターゲットに設定するエンドポイントは、それぞれのルートテーブル毎に変えてください。

その後、ルートテーブルにサブネットを関連付けます。私の場合は各ルートテーブルに分かりやすいようにアベイラビリティゾーンを含めてます。

Network Firewall エンドポイント用ルートテーブル(Firewall Route Table)を作る

ここは実はルート情報については Single-AZ 構成と変わりません。0.0.0.0/0 を Transit Gateway に向けるだけです。
Network Firewall エンドポイント用ルートテーブル(Firewall Route Table) において、Multi-AZ 構成で必要な作業はサブネットの関連付けだけです。

エンドポイント用サブネットをそれぞれ 2 つ関連付けてます。Single-AZ 構成にもう 1 つサブネットの関連付けが増えた状態ですね。

Transit Gateway アタッチメントを編集して増やしたサブネットを関連付ける

既に Single-AZ 構成がある方向けの記事なので、色々端折ってます。なので、既に Transit Gateway アタッチメントも作成されている前提です。
今回編集が必要なのは Inspection VPC 用の VPC アタッチメントです。

上の図の通り、増やしたサブネットのアベイラビリティゾーンに Transit Gateway 用のサブネットを関連付けます。
しばらくすると、Transit Gateway 用のサブネットに Transit Gateway の ENI が作成され、Modify が完了します。

Transit Gateway アタッチメントを編集してアプライアンスモードを有効にする

Transit Gateway を経由した通信の行きと戻りの通信が非対称となる場合、非対称ルーティングとなってしまうために通信が正常に確立されません。
Network Firewall + Transit Gateway 構成かつ Multi-AZ 構成で一番重要なのはアプライアンスモードと言えるかもしれません。

資料 の通り、Inspection VPC の VPC アタッチメントのアプライアンスモードを有効にする必要があります。
この作業は現時点でマネジメントコンソールから行う事ができないため、AWS CLI を利用してアタッチメントを編集する必要があります。

実施するコマンドは modify-transit-gateway-vpc-attachment になります。詳細な仕様はこちら

まずアプライアンスモードを有効にするための設定を含んだ JSON ファイルを作成する

下記の通り VPC アタッチメントのオプションである AppliandeModeSupport を Enable にする設定を記述した JSON ファイルを用意します。

appliance_mode_enable.json
{
    "Options":{
        "ApplianceModeSupport": "enable"
    }
}

modify-transit-gateway-vpc-attachment コマンドを実行する

上で作った JSON ファイルを使って modify-transit-gateway-vpc-attachment コマンドを実行します。
コマンド内引数の --transit-gateway-attachment-id には Inspection VPC の VPC アタッチメント ID を入力します。

aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-s4mp1e4tt4chm3nt --cli-input-json file://appliance_mode_enable.json

変更が完了すると下記の通り結果が返却されます。

{
    "TransitGatewayVpcAttachment": {
        "TransitGatewayAttachmentId": "tgw-attach-s4mp1e4tt4chm3nt",
        "TransitGatewayId": "tgw-*********",
        "VpcId": "vpc-*********",
        "VpcOwnerId": "*********",
        "State": "modifying",
        "SubnetIds": [
            "subnet-*********",
            "subnet-*********"
        ],
        "CreationTime": "****-**-**T**:**:**+**:**",
        "Options": {
            "DnsSupport": "enable",
            "Ipv6Support": "disable",
            "ApplianceModeSupport": "enable"
        }
    }
}

Modify が完了するまで少しだけ時間がかかりますが、これにて作業は完了になります。
Deployment Model の通り Spoke VPC から通信しても問題無くインターネットへ抜ける事が可能なはずです。

感想

  • Multi-AZ にするだけでこの作業量
  • サブネットが増えれば増えるほど管理が大変
  • パケットの気持ちにならないとトラブルシューティングが難解になる
  • アプライアンスモードをマネジメントコンソールから作業させてほしい