AWS移行 - Gateway Load Balancerを使用したゲートウェイ型IPS移行

１．はじめに

　オンプレミスのシステムをAWSへ移行する際、ゲートウェイ型IPS（IDS/IPS）をどのようにAWSへ移行するかが課題となることがありました。その理由としては、
・AWSではホスト型の事例が多く、ゲートウェイ型の国内事例が少ない
・AWSでゲートウェイ型IPSを構成するには、複雑な制御が必要だった(2021年1月以前)
などが考えられます。

　しかし、2021年2月に東京リージョンにてサポートされたGateway Load Balancer(以下GWLBと略す)を使うことで、以前よりシンプルに構成が組めるようになりました。本資料では、GWLBを使ってAWS上でゲートウェイ型IPSを構成・動作させる方法を解説します。

　本記事は、GWLBの基本が分かっている人を想定して書いています。GWLBについて初めての人は次の参考資料を最初に読まれると良いと思います。本記事がIPSのAWS移行を検討する際に参考になれば幸いです。

＜補足＞
　2021年にAWS Network Firewallが新サービスとしてリリースされました。このサービスの中にIPSが含まれていますが、2021年7月時点ではこのサービスに含まれるIPSについては、ユーザ側でIPSルールを定義・管理する必要があります。常に最新のルールを手動管理するのは現実的な運用ではないと個人的には考えています。将来的に、このサービスに対しサードパーティによるIPSルール提供が自動化されるようになれば、最初からこのサービスへ移行するようになる可能性があります。残念ながら、現時点では採用が難しいと判断しています。

（参考資料１）
　　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ
　　　GWLBの概要からルーティングまで詳しく解説されていて参考になりました。
（参考資料２）
　　AWS Gateway Load Balancerの紹介：サポートされているアーキテクチャパターン
（参考資料３）
　　AWS Gateway LoadBalancerを使用したネットワークトラフィック検査のスケーリング
（参考資料４）
　　Gateway Load BalancerとTransit Gatewayを使用した一元化された検査アーキテクチャ
　　　GWLBの動作の詳細が説明されていて参考になりました。

２．GWLBの概要

　GWLBは以下の特徴を持っており、GWLBを使うことでAWS上のゲートウェイ型IPSがシンプルに構成出来るようになりました。
・ネットワークに透過
・冗長化、スケールが簡単
・リソース共用が可能

　2020年以前は、AWS上でゲートウェイ型IPSを導入するには、複雑な設計・構築が必要だったようです。例えば図2.1のように、IPS(図のfirewall）を冗長化するために死活監視をし、障害時にルートテーブルの書き換えを実装する必要がありました。

（図2.1)

（参考資料１のスライド10より抜粋）
　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ

　他の例では、上記のようなルートテーブルの書き換えを不要にするために、VPNをVPC間で構成し、VPNを冗長構成にしBGPによる動的ルーティングを構成する方法がとられていました。

（図2.2)

（参考資料１のスライド11より抜粋）
　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ

　他にもいろいろと課題があったようですが、次のようなサービスが拡充された結果、状況が改善しました。

• 2018年「AWS Transit Gateway」サービス発表
• 2019年「VPC Ingress Routing」サービス発表
• 2020年「AWS Gateway Load Balancer(GWLB)」サービス発表

それでは、キーとなるGWLBのサービス概要について図2.3を参照下さい。

（図2.3)

（参考資料１のスライド12より抜粋）
　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ

再度掲載しますが、GWLBの特徴は次の3点だと思います。

• ネットワークに透過
• 冗長化、スケールが簡単
• リソース共用が可能

GWLBを使うことで、AWS上のゲートウェイ型IPSがシンプルに構成出来るようになりました。GWLBを使った基本的な構成や処理の流れについては、参考資料１[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズを参照下さい。こちらに詳しく書かれています。

本記事では、前述の資料には記載されていない、複雑な構成について解説します。

３．構成のポイント

　今回の構成を説明する前に、構成のポイントを3点あげさせて頂きます。

• 可用性
  　IPSをAWS上へ導入する際、可用性の確保が大切です。1台のIPSだけで構成した場合、その1台に障害が発生した場合、通信が一切出来なくなりIPSを使っている全システムが停止します。このようなことが起きないよう複数台のIPSにて構成します。さらにAZ障害時にもIPSを稼働させるためには、マルチAZ構成が必要です。　

• 集中ルーティング
  　IPSによる検査には大きく分けると２種類あります。１つはインターネットと内部システム間の通信(南北通信)の検査、もう１つは内部システム間の通信(東西通信)の検査です。この東西、南北、2種類の検査を一元的に対応できる構成にするためにTransit Gatewayを使って集中ルーティングします。

• 拡張性
  　AWS社のリファレンスアーキテクチャの資料を参考にし、インターネットからのインバウンド通信、インターネットへのアウトバウンド通信、検査と各業務毎にVPCを分離しています。このようにすることで業務を拡張する際の構成変更をやり易くしています。

　以上の３つのポイントを満たす構成を次の章から説明します。

４．構成図

　移行前のオンプレミスのサンプル構成を（図4.1）に示します。この構成図では主に３つの処理を表しています。
　（１）ユーザーがインターネットからWebサーバへアクセス時に検査します
　（２）WebサーバがProxyサーバ経由でインターネットへアクセス時に検査します
　（３）イントラネットの運用管理者が内部ネットワークへアクセス時に検査します

（図4.1）

オンプレミスからAWSへ移行する場合、次の表のようにAWSの各サービスへ移行することができます。

NO	移行前（オンプレミス）	移行後（AWSのサービス）
1	外部Firewall兼IPS	Gateway Load BalancerとEC2（IPS）
2	Load Balancer	Application Load Balancer
3	Webサーバ	EC2（Webサーバ）
4	運用管理サーバ	EC2（運用管理サーバ）
5	Proxyサーバ	NAT Gateway
6	内部Firewall兼IPS	Gateway Load BalancerとEC2（IPS）
7	ネットワーク	Transit GatewayとDirect Connect

　（図4.1）のようなオンプレミスの構成をAWS移行し、さらにAZ障害にも対応し、東西・南北2種類の検査に対応したゲートウェイ型IPSの構成例を（図4.2）に示します。

（図4.2）

この構成の特徴は以下です。

• Inbound VPCにGWLBとApplication Load Balancer(ALB)を配置します

  • GWLB Endpointの配置が自由なため、入り口にて検査が可能です
  • 業務システムとVPCを分離することでインターネットからの攻撃が直接業務システムへ届かないようにします

• Inspection VPCは、IPSのEC2とGWLBを配置し，ここのIPSにて全ての検査を実施します

  • IPSを共用することができ、管理コスト、リソースコストの削減が期待できます

• VPC間の通信をTGWに集中させ，TGWからInspection VPCへルーティングします

  • データセンタやイントラネットなどAWS外部からの通信時の検査します
  • VPC間の通信についても検査を可能にします
  • Inbound VPCからWorkload VPC間の通信時は、二重検査をしないように制御します

• Outbound VPCは共用NAT gateway(NATGW)としてVPCを分離します　

  • VPC毎にNATGWを配置した場合、セキュリティの抜け穴になるリスクがある。それを回避します
  • NATGWを共用することができ、コストの削減が期待できます

• Workload VPCは、業務システムを配置します

  • 例えば、情報配信サイト、ショッピングサイト、営業支援システムやそのデータベースなどをこのVPCへ配置します。また必要に応じて、Workload VPCは複数VPCとして構成することも可能です。各VPCをTGWへ接続することで、IPSによる検査を追加することが可能です。

• Operation VPCは、運用管理サーバを配置します

  • AWS内のEC2は、運用管理サーバからのみ接続可能にします
  • オンプレミスからは直接はWorkload VPCなどのEC2へ接続出来ないようにします

　以上のように用途毎にVPCを分離することで、拡張性を維持しながらIPSを導入できるように、今回の構成としました。

　参考までに（図4.2）を詳細化した構成とルートテーブル例を（図4.3）に示します。これらのルートテーブルの参照については次の章にて詳しく見ていきます。
（図4.3）

５．動作の解説

　それでは次の５つの処理パターンにおいて、どのように動作するのかを順番に説明していきます。
（１）インターネットからVPC内へのインバウンド通信を検査
（２）VPC内からインターネット上のパッチダウンロード時に検査
（３）VPC間の通信時に検査
（４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査
（５）マルチAZ構成において、IPSをAZ間で負荷分散・リソース共有

（１）インターネットからVPC内へのインバウンド通信を検査

　（図5.1）を使って①から⑲までの処理の流れを説明します。
（図5.1)

• ①一般ユーザは、Application Load Balancer (ALB)のDNS名に対してアクセスします。Internet gateway(IGW)からInbound VPCへ通信パケット（パケット）が入ります。
• ②Inbound VPCのIngress ルートテーブルを参照します。この時点でパケットの宛先IPアドレスは、ALBのDNS名から返されたプライベートIPアドレスに変換されています。宛先IPアドレスに該当するTargetのGWLB Endpoint(GWLBE)#1へルーティングします。
• ③GWLBE#1は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。
• ④GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。
• ⑤IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査後、GWLBへ返します。
• ⑥GWLBは元のGWLBE#1へパケットを返します。
• ⑦GWLBE#1は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるALBへパケットを転送します。
• ⑧ALBは登録されているバックエンドのIPアドレスまたはEC2インスタンスへ負荷分散させ、データを送信します。バックエンドのIPアドレスへパケットを転送する際、このサブネットのルートテーブルを参照します。
• ⑨バックエンドのIPアドレスに該当するルーティング先としてTransit Gateway(TGW)を入手します。
• ⑩TGWへパケットを転送します。この際のパケットの送信元IPアドレスはALBのプライベートIPアドレスです。
• ⑪Inbound VPCにアタッチしたTGWのルートテーブルには、Workload VPC宛のCIDRについては、Workload VPCのアタッチメントへルーティングするように記載しておきます。これにより、Workload VPCへパケットがルーティングされます。図に記載していないが、実際にはWorkload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、Webサーバへパケットが転送されます。
• ⑫Webサーバにて処理後、送信元のALBへデータを返します。Workload VPC内のルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。
• ⑬Workload VPCにアタッチしたTGWのルートテーブルには、Inbound VPC宛のCIDRについては、Inbound VPCのアタッチメントへルーティングするように記載しておきます。Inbound VPC内で検査を行うため、Inspection VPCにルーティングはさせません。これにより、Inbound VPCへパケットがルーティングされます。図には記載していませんが、Inbound VPCのTGW ENIが接続されたサブネットのルートテーブルによって、ALBへパケットが転送されます。
• ⑭ALBは戻ってきたパケットから、元々の送信元のパブリックIPアドレスへ宛先を戻します。ALBを配置したサブネットのルートテーブルを参照します。
• ⑮ルートテーブルの宛先0.0.0.0/0に対するルーティング先はGWLBE#1を記載しておきます。
• ⑯ALBはGWLBE#1へパケットを転送します。
• ⑰GWLBE#1は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。
• ⑱GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。
• ⑲IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査後、GWLBへ返します。
• ⑳GWLBは元のGWLBE#1へパケットを返します。
• ㉑GWLBE#1は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるパブリックIPアドレスへパケットを転送します。このサブネットのルートテーブルを参照します。
• ㉒ルートテーブルの**宛先0.0.0.0/0に対するルーティング先はInternet gateway(IGW)**を記載しておきます。これによりIGWへパケットが転送されます。
• ㉓IGWから依頼元にパケットが戻ります。

以上で”（１）インターネットからVPC内へのインバウンド通信を検査”についての説明を終わります。特徴は、行きのパケットと帰りのパケットの２回検査する点です。

（２）VPC内からインターネット上のパッチダウンロード時に検査

（図5.2）の①から⑲までは、サーバからインターネットに出るまでの処理の流れです。インターネットからサーバに戻るまでの処理は次の（図5.3）にて説明します。

（図5.2）

• ①Webサーバからインターネット上のサイトへアクセスします。Workload VPC内のルートテーブルを参照します。
• ②ルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。
• ③WebサーバからTGWへパケットが送信されます。
• ④Workload VPCにアタッチしたTGWのルートテーブルには、Inbound VPC以外のCIDR宛先については、Inspection VPCのアタッチメントへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。
• ⑤Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。
• ⑥ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。
• ⑦GWLBE#3へパケットを転送します。
• ⑧GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。
• ⑨IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。
• ⑩GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。
• ⑪ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。
• ⑫TGWへパケットが転送されます。
• ⑬Inspction VPCにアタッチされたTGWのルートテーブルにて、インターネット宛先の通信はOutbound VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがOutbound VPCへ転送されます。
• ⑭Outbound VPCのTGW ENIのサブネットのルートテーブルを参照します。
• ⑮ルートテーブルには、インターネット宛先の通信はNATGWへルーティングするように記載しておきます。
• ⑯NATGWへパケットが転送されます。
• ⑰NATGWのサブネットのルートテーブルを参照します。
• ⑱ルートテーブルには、インターネット宛先の通信はInternet gateway(IGW)へルーティングするように記載しておきます。
• ⑲インターネットへパケットが転送されます。

次は、パケットがインターネットから戻ってきてからの動作を（図5.3）にて説明します。
（図5.3）

• ①インターネットから戻ってきたパケットがNATGWに届きます。
• ②NATGWのサブネットのルートテーブルを参照します。
• ③ルートテーブルには、送信元（Webサーバ）宛先の通信はTGWへルーティングするように記載しておきます。
• ④パケットをTGWへ転送します。
• ⑤TGWのOutbound VPCにアタッチされたルートテーブルには、全ての通信はInspction VPCへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。
• ⑥Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。
• ⑦ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。
• ⑧GWLBE#3へパケットを転送します。
• ⑨GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。
• ⑩IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。
• ⑪GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。
• ⑫ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。
• ⑬TGWへパケットが転送されます。
• ⑭Inspction VPCにアタッチされたTGWのルートテーブルにて、Workload VPC宛先の通信はWorkload VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがWorkload VPCへ転送されます。図には記載していませんが、Workload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、パケットが送信元（Webサーバ）へ転送されます。

以上で”（２）VPC内からインターネット上のパッチダウンロード時に検査”についての説明を終わります。特徴は、行きのパケットと帰りのパケットの２回検査する点です。

（３）VPC間の通信時に検査

　（図5.4）の①から⑬までは、送信元サーバから宛先サーバまでの処理の流れです。戻りの流れは（図5.5）にて説明します。
（図5.4）

• ①運用管理サーバからWebサーバへアクセスします。Operation VPC内のルートテーブルを参照します。
• ②ルートテーブルには、Operation VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。
• ③運用管理サーバからTGWへパケットが送信されます。
• ④Operation VPCにアタッチしたTGWのルートテーブルには、全ての宛先については、Inspection VPCのアタッチメントへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。
• ⑤Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。
• ⑥ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。
• ⑦GWLBE#3へパケットを転送します。
• ⑧GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。
• ⑨IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。
• ⑩GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。
• ⑪ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。
• ⑫TGWへパケットが転送されます。
• ⑬Inspction VPCにアタッチされたTGWのルートテーブルにて、Workload VPC宛先の通信はWorkload VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがWorkload VPCへ転送されます。図には記載していませんが、Workload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、パケットが宛先（Webサーバ）へ転送されます。

次は、パケットが宛先（Webサーバ）から送信元（運用管理サーバ）へ戻ってくるまでの動作を（図5.5）にて説明します。
（図5.5）

• ①Webサーバから送信元（運用管理サーバ）へパケットが戻ります。Workload VPC内のルートテーブルを参照します。
• ②ルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。
• ③WebサーバからTGWへパケットが送信されます。
• ④Workload VPCにアタッチしたTGWのルートテーブルには、Outbound VPC以外のCIDR宛先については、Inspection VPCのアタッチメントへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。
• ⑤Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。
• ⑥ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。
• ⑦GWLBE#3へパケットを転送します。
• ⑧GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。
• ⑨IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。
• ⑩GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。
• ⑪ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。
• ⑫TGWへパケットが転送されます。
• ⑬Inspction VPCにアタッチされたTGWのルートテーブルにて、Operation VPC宛先の通信はOperation VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがOperation VPCへ転送されます。図には記載していませんが、Operation VPCのTGW ENIが接続されたサブネットのルートテーブルによって、パケットが送信元（運用管理サーバ）へ転送されます。

　以上で”（３）VPC間の通信時に検査”についての説明を終わります。特徴は、行きのパケットと帰りのパケットの２回検査する点です。

（４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査

　（図5.6）の①から㉓までを使って説明します。
（図5.6）

• ①アベイラビリティゾーンC（AZ-C)が障害で利用出来なくなったと仮定します。AZ-Cが障害の場合、ALBのヘルスチェックにて利用可能なAZ-D側のパブリックIPアドレスがDNSより返されると想定されます。そのため、一般ユーザがALBのDNS名に対してアクセスすると、IGWを通過した際にAZ-D側のサブネットのALBのプライベートアドレスへ変換されると想定されます。
• ②Inbound VPCのIngress ルートテーブルを参照します。この時点でパケットの宛先IPアドレスは、ALBのDNS名から返されたAZ-D側のプライベートIPアドレスに変換されています。宛先IPアドレスに該当するTargetのGWLBE#2へルーティングします。
• ③GWLBE#2は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。
• ④GWLBは、AZ-C側が障害のため利用出来ない場合、ヘルスチェックにて健全なIPS#2へパケットを転送します。
• ⑤IPS#2は、パケットを検査後、GWLBへ返します。
• ⑥GWLBは元のGWLBE#2へパケットを返します。
• ⑦GWLBE#2は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるALBへパケットを転送します。
• ⑧ALBは登録されているバックエンドのIPアドレスまたはEC2インスタンスへ負荷分散させ、データを送信します。バックエンドのIPアドレスへパケットを転送する際、このサブネットのルートテーブルを参照します。
• ⑨バックエンドのIPアドレスに該当するルーティング先としてTGWを入手します。
• ⑩TGWへパケットを転送します。この際のパケットの送信元IPアドレスはALBのAZ-D側のプライベートIPアドレスです。
• ⑪Inbound VPCにアタッチしたTGWのルートテーブルには、Workload VPC宛のCIDRについては、Workload VPCのアタッチメントへルーティングするように記載しておきます。これにより、Workload VPCへパケットがルーティングされます。図に記載していないが、実際にはWorkload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、Webサーバへパケットが転送されます。
• ⑫Webサーバにて処理後、送信元のALBへデータを返します。Workload VPC内のルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。
• ⑬Workload VPCにアタッチしたTGWのルートテーブルには、Inbound VPC宛のCIDRについては、Inbound VPCのアタッチメントへルーティングするように記載しておきます。これにより、Inbound VPCへデータがルーティングされます。図には記載していませんが、Inbound VPCのTGW ENIが接続されたサブネットのルートテーブルによって、AZ-D側のALBへデータが転送されます。
• ⑭ALBは戻ってきたパケットから、元々の送信元のパブリックIPアドレスへ宛先を戻します。ALBを配置したAZ-D側のサブネットのルートテーブルを参照します。
• ⑮ルートテーブルの宛先0.0.0.0/0に対するルーティング先はGWLBE#2を記載しておきます。
• ⑯ALBはGWLBE#2へパケットを転送します。
• ⑰GWLBE#2は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。
• ⑱GWLBは、AZ-C側が障害のため利用出来ない場合、ヘルスチェックにて健全なIPS#2へパケットを転送します。
• ⑲IPS#2は、パケットを検査後、GWLBへ返します。
• ⑳GWLBは元のGWLBE#2へパケットを返します。
• ㉑GWLBE#2は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるパブリックIPアドレスへパケットを転送します。このサブネットのルートテーブルを参照します。
• ㉒ルートテーブルの宛先0.0.0.0/0に対するルーティング先はIGWを記載しておきます。これによりIGWへパケットが転送されます。
• ㉓IGWから依頼元にパケットが戻ります。

以上で”（４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査”についての説明を終わります。特徴は、正常なAZにパケットが転送される点と、行きのパケットと帰りのパケットの２回検査する点です。

（５）マルチAZ構成において、IPSをAZ間で負荷分散・リソース共有

　これは、今まで説明してきた（１）（４）の処理が、正常な複数AZにて同時に実施されることです。

（１）インターネットからVPC内へのインバウンド通信を検査
（４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査

処理内容は（１）（４）と同じのため、省略します。

６．まとめ

　今回は、ゲートウェイ型IPSをAWSへ移行した場合のアーキテクチャと処理の流れについて解説しました。実際のネットワーク設計については業務要件によって変わるとは思いますが、今回説明したGateway Load BalancerとTransit Gatewayによる通信制御を応用することで設計が出来ると考えます。

　もしかすると今回例示したルートテーブルの設定内容に誤りがある可能性があります。その場合はご了承下さい。最後まで読んで下さりありがとうございました。