杉村です。 AWS Network Firewall の登場により、ネットワーク経路上（インライン）でのパケット検査や URL フィルタリングが フルマネージドサービスのみで行えるようになりました。
本投稿では AWS Network Firewall と AWS Transit Gateway を活用してフルマネージドサービスだけで構成する、セキュアなマルチ VPC 環境のリファレンスアーキテクチャをご紹介したいと思います。
AWS Transit Gateway や AWS Network Firewall の基本をおさらいしたい方は、私の過去のブログ投稿をご参照ください。
はじめに
以下の図をご覧になったことがあるでしょうか。 AWS 公式の AWS サービス別資料 にて公開されている資料 [AWS Black Belt Online Seminar] Amazon VPC からの抜粋です。
AWS Network Firewall の登場により、上記のようなハブ＆スポーク型アーキテクチャがフルマネージドサービスのみで構成しやすくなったといえるでしょう。
関連して 2020 年 11 月に AWS から以下のブログ投稿が公開されました。前述のアーキテクチャを AWS Network Firewall で構成する際のモデルを紹介したものです。
2021 年 5 月現在は日本語訳されていませんが、内容が詳細で参考になります。
今回の私の投稿では上記のブログ投稿を参考にしつつ、以下をテーマにしたいと思います。
- AWS 公式ブログ投稿
Deployment models for AWS Network Firewall - 生じた疑問とその回答
- 各構成パターンの整理と比較
- 構築時のハマりどころ
AWS 公式ブログ投稿 Deployment models for AWS Network Firewall
3 種類のモデルアーキテクチャ
AWS 公式のブログ投稿 Deployment models for AWS Network Firewall を簡単に解説してみたいと思います。
当該ブログでは AWS Transit Gateway + AWS Network Firewall を利用する際のネットワーク構成を大きく 3 種類に分けています。
- Distributed AWS Network Firewall deployment model
- 和訳するならば
AWS Network Firewall 分散デプロイモデルでしょうか。ワークロード (EC2 など) のある VPC ごとに個別に Internet Gateway や AWS Network Firewall を設けます
- 和訳するならば
- Centralized AWS Network Firewall deployment model
AWS Network Firewall 集中デプロイモデル。 AWS Network Firewall を一つの VPC に作成し全てのパケットがそこを通るようにします。 Internet Gateway も 1 つの VPC に作成し、全てのアウトバウンド (Egress) 通信がそこを通るようにします
- Combined AWS Network Firewall deployment model
- 前述 1 と 2 の組み合わせです
North-South トラフィックと East-West トラフィックとは
当該ブログ投稿では 「 VPC と インターネット/オンプレミスの通信」を North-South トラフィック 、「 VPC から他の VPC への通信」を East-West トラフィック と呼んでいます。これはネットワークの世界ではしばしば見られる表現です。
ネットワーク構成図において、上側にインターネットを、下側に社内ネットワークを、そして L2/L3 スイッチをノードにして各ホストがツリー上に描かれている絵をイメージしてください。
同一サイト内のホスト間通信を線で描くと、構成図上では横向きに山なりの線（つまり地図で言うと東西）になり、インターネット等への通信は縦の通信（南北）になることから、このような表現が生まれたものと思われます。
Distributed AWS Network Firewall deployment model とは
1 の Distributed AWS Network Firewall deployment model は特に難しいものではありません。 VPC ごとに個別に Internet Gateway や AWS Network Firewall を作成します。以下に構成例を示します。
EC2 からインターネットへの経路を赤線で示すと以下のようになります。途中で AWS Network Firewall を通ってパケットが検査されます。
同様にインターネットから ALB 経由で EC2 へ到達する通信も途中で AWS Network Firewall を通って検査されます。
このように North-South トラフィックは AWS Network Firewall により検査されますが、一方で Transit Gateway を通る East-West トラフィックは検査されません。
Centralized AWS Network Firewall deployment model とは
2 の Centralized AWS Network Firewall deployment model では複数の構成が示されています。以下に構成例を示します。
特徴的なのは以下のように Inspection VPC (図左上)を中間に設けて、全てのパケットがそこを通るようにしています。この Inspection VPC に AWS Network Firewall を配置するのです。
EC2 からインターネットへの経路を赤線で示すと以下のようになります。
パケットは一度、図左上の Inspection VPC を経由してから図中央上の Egress VPC に到達し NAT Gateway, Internet Gateway を経由してインターネットへ出ていきます。戻りのパケットも同様です。
インターネットから VPC に入ってくる通信についても図右上の Ingress VPC の ALB から入り Inspection VPC を経由して検査されてから System A や System B の EC2 にたどり着きます。なお ALB のターゲット (EC2) が ALB と別の VPC にあるため、ターゲットグループにはインスタンス ID ではなく IP アドレスを使用します。
また System A's VPC と System B's VPC の間の East-West トラフィックも同様に、一度 Inspection VPC を経由して通信されます。
なお AWS ブログでは IP リソースを節約するため Inspection VPC の IP レンジとしてキャリアグレード NAT の IP レンジ (100.64.0.0/16) が使われています。特殊な IP 帯だと AWS サービスやアプライアンス製品によっては宛先や接続元として指定できないことがありますが、 Inspection VPC は通信に対して透過的なので宛先や接続元として指定されることはなく、 Inspection VPC に余計なリソースを配置しなければ問題になることはありません (当ブログでは普通の Private IP 帯を使っています) 。
Combined AWS Network Firewall deployment model とは
3 の Combined AWS Network Firewall deployment model は 1 と 2 のミックスです。
個別要件のある VPC に個別に Internet Gateway と AWS Network Firewall を配置しそれを利用します。それ以外の VPC は共通の Inspection VPC を利用します。以下に一例を図で示します。
図左下の System A's VPC は 図左上の Inspection VPC を通って Egress VPC/Ingress VPC でインターネットと通信します。
図中央下の System B's VPC は 自分の VPC にある Internet Gateway でインターネットと通信します。
生じた疑問とその回答
生じた疑問
ここで、以下の疑問が出てきました。
疑問1. Centralized AWS Network Firewall deployment model では Inspection 専用の VPC を設けてトラフィックが全てそこを通るようにしている。この構成だと AWS Transit Gateway の通信料金は増大する (同じパケットが Transit Gateway を 2 回通るため) 。 Egress VPC/Ingress VPC に Firewall を置くのではいけないのだろうか
疑問2. AWS Network Firewall の URL フィルタリング機能を使う際、通信要件の異なる接続元 VPC に対して異なる URL フィルタリングルールを適用する方法はあるだろうか
疑問3. 実際にアーキテクチャ設計を行う際は AWS 利用料も重要なファクターとなる。紹介されている各モデルにはどのくらい料金差があるだろうか
疑問4. 実際にこれらのアーキテクチャを採用し構築する際に「ハマりどころ」はあるだろうか
Inspection VPC はなぜ必要なのか
疑問1. Centralized AWS Network Firewall deployment model では Inspection 専用の VPC を設けてトラフィックが全てそこを通るようにしている。この構成だと AWS Transit Gateway の通信料金は増大する (同じパケットが Transit Gateway を 2 回通るため) 。 Egress VPC/Ingress VPC に Firewall を置くのではいけないのだろうか
この疑問に対しては、ブログを読み進めるとすぐ答えが出ました。
Inspection VPC を通信経路の途中に置くことの利点は、 East-West トラフィックも検査できることです。
Egress VPC や Ingress VPC だけに AWS Network Firewall を配置すると、インターネットへの North-South 通信は検査できますが、 VPC 間の East-West 通信は検査できません。
なお East-West 通信を検査できる代償として一度 Inspection VPC を通ったトラフィックが再度 Transit Gateway に戻るため Transit Gateway の通信料金は 2 倍発生します。
もし設計において「 East-West トラフィックの通信は検査しなくてよい (Security Group 設定を厳密にすることでカバーする) 。 North-South 通信だけを検査するようにしよう」と割り切るならば、以下のような構成も可能と考えます (以下の構成は本投稿のオリジナルであり AWS のブログでは紹介されていません) 。
本投稿では Centralized Inspection at Egress/Ingress VPC パターンと呼称します。
この構成であれば EC2 から Egress VPC へパケットが一直線に向かうため、 Transit Gateway の通信料金を抑えることができます。
VPC 間通信の安全を確保するためには各 VPC では Security Group を適切に管理する必要があります。
また当構成図では Ingress VPC と Egress VPC を 1 個の VPC として統合しています。別々の VPC に分けることも可能で、分けることで Subnet Route Table や Subnet Network ACL などを個別に設定することが可能です。
VPC ごとに個別の URL フィルタリングルールを適用するには
疑問2. AWS Network Firewall の URL フィルタリング機能を使う際、通信要件の異なる接続元 VPC に対して異なる URL フィルタリングルールを適用する方法はあるだろうか
AWS Network Firewall のステートフルルールグループの URL フィルタリング機能は ステートフルルールグループ という種類のルールグループによって実現します。
ステートフルルールグループは HOME_NET 変数というパラメータを持っています。
この HOME_NET 変数は、そのステートフルルールグループがどの接続元 CIDR からのパケットを検査対象とするかを示しており、一つまたは複数の CIDR を設定可能です。
この HOME_NET 変数によりドメイン名リスト(ステートフルルールグループ)をどの VPC に適用するかを決めることができます。
先ほどの Inspection VPC を置くタイプの構成において、適用したい VPC の CIDR をドメイン名リスト(ステートフルルールグループ)の HOME_NET 変数に設定すれば、適用対象 VPC を選ぶことができます。
HOME_NET 変数はマネジメントコンソールからは設定できず AWS CLI などを用いて設定する必要があります。設定方法は公式マニュアルをご参照ください。
注意点として、先ほど紹介した Centralized Inspection at Egress/Ingress VPC パターン (Egress VPC に AWS Network Firewall を置くタイプの構成) ですと、 AWS Network Firewall を通るパケットの接続元 IP アドレスは NAT Gateway になります。
よって HOME_NET 変数が効かず、すべての接続元 VPC に同じルールを適用するしかなくなってしまいます。
これに対する他の提案として、 VPC ごとに専用の Egress/Ingress 用 VPC を構築して利用するのも一つの手です。
この専用 Egress/Ingress VPC は同じ通信要件を持つ VPC からは再利用できます (以下の構成は本投稿のオリジナルであり AWS のブログでは紹介されていません) 。
本投稿では Centralized Inspection at Multiple Egress/Ingress VPC パターンと呼称します。
なお以下のように、各 VPC の根元に AWS Network Firewall を配置する構成も考えつくかもしれませんが、これは VPC の仕様上 NG です (以下の構成は本投稿のオリジナルであり AWS のブログでは紹介されていません) 。
理由は Transit Gateway ENI に対して Ingress Routing を適用できないから です。この構成だと VPC から出ていくパケットは AWS Network Firewall で検査されるのですが、戻りのパケットが AWS Network Firewall を通りません。戻りのパケットは Transit Gateway から VPC に戻るときに Transit Gateway ENI のあるサブネットのルートテーブルに従いますが、このとき local のルートに従って直接 EC2 に戻ってしまうからです (AWS Network Firewall を通らない)。
なお実際に構築して試してみたところ、ステートレスルールグループは適用されてルールに合致するパケットを Drop などしてくれましたが、ステートフルルールグループは適用されず Deny にしたはずのドメイン名への HTTP リクエストが成功してしまいました。
サポートされない挙動ですので、この構成を採ってはいけません。
疑問 3 と 疑問 4
以下の疑問に対する回答は、後述します。
疑問3. 実際にアーキテクチャ設計を行う際は AWS 利用料も重要なファクターとなる。紹介されている各モデルにはどのくらい料金差があるだろうか
疑問4. 実際にこれらのアーキテクチャを採用し構築する際に「ハマりどころ」はあるだろうか
各構成パターンの整理と比較
構成パターン一覧
AWS のブログで紹介されたパターンと新しく本投稿で提案した新しいパターンの両方を一覧にして並べます。
（命名を分かりやすくするため本投稿オリジナルの名前になっています）
1. Distributed Inspection
2. Centralized Inspection at Inspection VPC
3. Centralized Inspection at Egress/Ingress VPC
4. Centralized Inspection at Multiple Egress/Ingress VPC
5. Combined Pattern
構成パターンの比較
比較表
各パターンの比較表を作成しました。
| No | パターン名 | East-West トラフィック検査 | North-Southトラフィック検査 (Internet) | North-Southトラフィック検査 (オンプレミス) | きめ細かい設定 | 設定ミス時の影響範囲の小ささ | 料金(一定条件における値。後述) |
|---|---|---|---|---|---|---|---|
| 1 | Distributed Inspection | 不可 | 可 | 不可 | 可 | 小さい | $ 14,625.8 |
| 2 | Centralized Inspection at Inspection VPC | 可 | 可 | 可 | 可 | 大きい | $ 8,186.976 |
| 3 | Centralized Inspection at Egress/Ingress VPC | 不可 | 可 | 不可 | 不可 | 大きい | $ 3,882.44 |
| 4 | Centralized Inspection at Multiple Egress/Ingress VPC | 不可 | 可 | 不可 | 可 | 中程度 | $ 5,801.96 |
| 5 | Combined Pattern | 可 | 可 | 可 | 可 | 中程度 | $ 10,158.576 |
AWS 利用料金の詳細
前述の表では利用料金を一定条件下における値で計算しました。
実際には構成に合わせて値を変動させ、試算してください。
以下に、厳密な計算結果を記載します。
まず、計算の前提条件は以下の通りです。
- VPC 数は 20 個
- 使う AZ は 2 つとして NAT Gateway や AWS Network Firewall Endpoint は各 AZ にデプロイする
- North-South トラフィック量は VPC あたり 30 GB/日
- 計算の単純化のため ALB の計算はせず全て NAT Gateway の通信として計算
- East-West トラフィック量は VPC あたり 50 GB/日
3. Centralized Inspection at Egress/Ingress VPCと4. Centralized Inspection at Multiple Egress/Ingress VPCにおいては Ingress VPC と Egress VPC は同一 VPC に同居4. Centralized Inspection at Multiple Egress/Ingress VPCパターンにおいて Egress/Ingress VPC の数は 4 個5. Combined Patternにおいて個別の Internet Gateway/AWS Network Firewall を持つ VPC の数は 4 個- 1カ月は 31 日 (744h) で計算
- 2021/5/24 現在の東京リージョンの料金で計算
この条件ですと、課金要素の Quantity の数は以下の通りです。
| No | パターン名称 | NAT Gateway時間 | NAT Gatewayデータ | Firewall Endpoint時間 | Firewall Endpointデータ | TGW Attachment時間 | TGW Traffic |
|---|---|---|---|---|---|---|---|
| 1 | Distributed Inspection | 0 | 0 | 40個 * 744h | 18,600 GB | 20 個 * 744h | 31,000 GB |
| 2 | Centralized Inspection at Inspection VPC | 2 個 * 744h | 18,600 GB | 2 個 * 744h | 49,600 GB | 22 個 * 744h | 99,200 GB |
| 3 | Centralized Inspection at Egress/Ingress VPC | 0 | 0 | 2 個 * 744h | 18,600 GB | 21 個 * 744h | 49,600 GB |
| 4 | Centralized Inspection at Multiple Egress/Ingress VPC | 0 | 0 | 8 個 * 744h | 18,600 GB | 24 個 * 744h | 49,600 GB |
| 5 | Combined Pattern | 2 個 * 744h | 14,880 GB | 10 個 * 744h | 49,600 GB | 22 個 * 744h | 91,760 GB |
AWS Network Firewall Endpoint 1 つにつき NAT Gateway 1 つの時間料金・データ処理料金が無料になることに注意します。
上記の Quantity で料金を計算すると、以下の通りです。
| No | パターン名称 | NAT Gateway時間料金 | NAT Gatewayデータ料金 | Firewall Endpoint時間料金 | Firewall Endpointデータ料金 | TGW Attachment時間料金 | TGW Traffic料金 | 計 |
|---|---|---|---|---|---|---|---|---|
| 1 | Distributed Inspection | 0 | 0 | $ 11,755.2 | $ 1,209 | $ 1,041.6 | $ 620 | $ 14,625.8 |
| 2 | Centralized Inspection at Inspection VPC | $ 92.256 | $ 1,153.2 | $ 587.76 | $ 3,224 | $ 1,145.76 | $ 1,984 | $ 8,186.976 |
| 3 | Centralized Inspection at Egress/Ingress VPC | 0 | 0 | $ 587.76 | $ 1,209 | $ 1,093.68 | $ 992 | $ 3,882.44 |
| 4 | Centralized Inspection at Multiple Egress/Ingress VPC | 0 | 0 | $ 2,351.04 | $ 1,209 | $ 1,249.92 | $ 992 | $ 5,801.96 |
| 5 | Combined Pattern | $ 92.256 | $ 922.56 | $ 2,938.8 | $ 3,224 | $ 1,145.76 | $ 1,835.2 | $ 10,158.576 |
構築時のハマりどころ
ここからは実際に構築する際、特に気を付けるべきポイントを記載します。
ステートフルルールグループの HOME_NET 変数
ステートフルルールグループ(URL フィルタリングなど)は HOME_NET 変数というパラメータを持っています。
この変数は前述の通り、そのステートフルルールグループがどの接続元 CIDR からのパケットを検査対象とするかを示しており、複数の CIDR を設定可能です。HOME_NET 変数に無い CIDR から来たパケットにはルールグループが適用されず、パススルー (Allow) されてしまいます。明示的に設定されていない場合は AWS Network Firewall がデプロイされた VPC の CIDR が適用されます。つまり AWS Network Firewall と同じ VPC 内の EC2 等から出たパケットしか検査対象になりません。
つまり HOME_NET 変数の存在を知らずに未設定としてしまうと、せっかく Inspection VPC を作ってもステートフルルールグループが適用されずにパケットが通ってしまいます。 Inspection VPC に AWS Network Firewall を置くと、全ての検査対象パケットは VPC 外から来ることになるからです。
2. Centralized Egress & Centralized Inspection at Inspection VPC や 5. Combined pattern を採用する場合は十分ご注意ください。
逆にいうと、使いこなせば接続元 VPC ごとに適用するルールを変えることができます。なお 3. Centralized Inspection at Egress/Ingress VPC や 4. Centralized Inspection at Multiple Egress/Ingress VPC はインターネットへ出ていくパケットの接続元 IP アドレスが NAT Gateway のものとなるので、接続元 VPC ごと個別にルールを適用することはできません。
HOME_NET 変数は "10.100.50.0/24", "10.100.60.0/24".... のように複数設定してもいいですし、 "10.100.0.0/16" のように範囲設定することもできます。
複数ルールで HOME_NET 変数に設定した CIDR が重複している場合など、挙動にクセがあるため、これはまた別途ブログ投稿でまとめたいと思います。
なおHOME_NET 変数はマネジメントコンソールからは設定できず AWS CLI などを用いて設定する必要があります。 設定方法は公式マニュアルをご参照ください。
AWS マネージドルールグループを使用する場合は HOME_NET 変数 の変更ができません (2022/3/16 山本追記)
AWS マネージドルールグループを使用する場合は HOME_NET 変数 には AWS Network Firewall を配置した VPC の CIDR が入ります
変更不可となります
Inspection VPC の構成を取る場合には事前にこのことを考慮しておきましょう
以下の記事に詳細を記載しています
AWS Network Firewall のルールグループと評価の流れを詳細に理解する ※ハマりポイントも解説しています - サーバーワークスエンジニアブログ
You can't override the Suricata HOME_NET variable in AWS Managed Rules.
和訳：AWSマネージドルールでSuricata のHOME_NET変数を変更することはできません。
Limitations for AWS Managed Rules in AWS Network Firewall - AWS Network Firewall
Transit Gateway のアプライアンスモードの有効化
こちらも 2. Centralized Egress & Centralized Inspection at Inspection VPC や 5. Combined pattern の 2 つ、すなわち Inspection VPC を使って East-West トラフィックを検査する構成のときに注意が必要です。
ある VPC の AZ-1a にある EC2 インスタンスが、別の VPC の AZ-1c など別の AZ のインスタンス等に接続する場合、 Transit Gateway の アプライアンスモード を有効化する必要があります。有効化しないと行きのパケットと返りのパケットで通信経路が変わってしまい通過する AWS Network Firewall が変わってしまうことから、パケットが破棄されてしまいます。
アプライアンスモードについて詳しくは当社のブログをご参照ください。
まとめ
AWS Transit Gateway + AWS Network Firewall を利用した複数の構成パターンとその注意点をご紹介しました。
いずれのパターンを採るかを以下に着目して十分検討し、セキュアで低運用コストな環境を構築してください。
- VPC 数の今後の増加見込み
- セキュリティ要件
- AWS利用料金比較
- AWS Network Firewall で出来ること
杉村 勇馬 (記事一覧)
サーバーワークス → 株式会社G-gen 執行役員CTO
2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers
マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。
2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。
