本稿に記載した内容は、個人的な見解を示したものであり、筆者の所属する企業・団体の公式見解ではありません。
概要
PaloAlto社のVM-SeriesをAWS上に構成する際、従来ではApplication Load BalancerでVM-Seriesを挟み込む構成を取ることが通常でした。しかし、2020年11月11日に発表されたGWLB（Gateway Load Balancer）を用いることでセキュリティアプライアンスを透過的に構成することができるようになりました。本記事ではGWLBを用いた構成を検証し、従来構成の問題解決を試みた結果を記述します。
従来構成の問題
公開サーバーをAZ冗長する構成においてVM-Seriesを用いて通信の保護をする場合、以下の構成で対応することがありました。しかし、WEBサーバーのデフォルトルートは自身が所属するAZと同一のAZに配置されたVM-Seriesへ向くような設計となっているため、VM-Seriesの障害が起きたとしてもアウトバウンド通信が切り替わらないという課題がありました（lambdaなどを使えば障害を検知してデフォルトルートを変更することも可能ですが、スクリプトのメンテナンスが大変になるため、できるだけネイティブサービスを使いたいという思いがありました。）。
GWLB（Gateway Load Balancer）とは
AWS GWLB（Gateway Load Balancer）は、ファイアウォールや侵入検知システムなどの仮想アプライアンスをスケーラブルに管理するサービスです。ネットワーク層でトラフィックを分散し、効率的なセキュリティと接続を提供します。GENEVEによるカプセリングにより、透過的で独立したセキュリティ検査システムを実現することを可能にします。前項で示した課題については、この機能を用いることで解決が可能です。
GWLBを利用した冗長構成
前項で提示したGWLBをVM-Seriesに適用した冗長構成は下図のようになります。サービスを提供するVPC（下図ではService VPC）とは別の、独立したVPC（Appliance VPC）を構成し、GWLBを配置します。サービスを提供するVPCにはGWLBEP（Gateway Load Balancer Endpoint）を配置し、ルーティングをGWLBEP経由にすることでVM-Seriesによるセキュリティ検査をすることができます。
GWLB構成を組んだ場合の通信経路
インターネットからサーバーへのアクセス
インターネットからのアクセスは①インターネットゲートウェイ→②GWLBEP→③GWLB→④VM-Series→⑤GWLBEP→⑥ALB→⑦WEBサーバーの順に経路をたどります。戻りの通信もVM-Seriesを含む同じ経路をたどってインターネットへ返送されます。GWLBEPからGWLBまでの経路はGENEVEというプロトコルでカプセリングされ、伝送されます。
サーバーからインターネットへのアクセス
インターネットからのアクセスは①WEBサーバー→②GWLBEP→③GWLB→④VM-Series→⑤GWLBEP→⑥NATゲートウェイ→⑦インターネットゲートウェイの順に経路をたどります。戻りの通信もVM-Seriesを含む同じ経路をたどってインターネットへ返送されます。GWLBEPからGWLBまでの経路はGENEVEというプロトコルでカプセリングされ、伝送されます。
GWLBを利用した冗長構成における注意点
- GWLBは比較的高額なリソースです。
- 検証の軽微な利用で月平均$20の利用実績となっていました。
- シングル構成が2台の構成となるため、通信が2台に分散されます。
- 各機器ごとにレポート等を作成する必要があります。
- Transit Gatewayを利用した構成は未検証です。
- Transit Gatewayを利用する場合はルーティングが大きく変わります。
- アプライアンスモードを有効にする必要があります。
- 検証はHTTPで実施しています。
まとめ
本記事では、従来の「ALBでVM-Seriesを挟み込む」構成で抱えていた"AZのデフォルトルート固定により障害時に自動切替しづらい"という問題に対し、AWS Gateway Load Balancer（GWLB）を用いた透過型アーキテクチャで解決できることを検証しました。GWLB は GENEVE カプセル化によりアプライアンスを意識させずに全トラフィックを集約でき、アプライアンス VPC とサービス VPC を分離することで、冗長性・拡張性・保守性を同時に高められます。