Network Firewall検証環境を作成するためのCloudFormationテンプレート作ってみた

記事タイトルとURLをコピーする

この記事を書いた経緯

案件で、Network Firewall(以降、NFWと表記)が存在する検査用VPCに、Transit Gateway(以降、TGWと表記)で複数の被検査VPCが接続される環境を作成する機会がありました。 同様の環境を再現して色々と検証をしていたのですが、下記の点に課題を抱えていました。

  1. 環境の構成が複雑で作成に時間がかかる
    検査用VPCに被検査VPCの通信をルーティングするためには、
    VPC内部ルートテーブルやTGWルートテーブルを細かく設定する必要があり時間をとられます。

  2. 高額な利用料金が発生するため検証環境を維持できない
    NFWエンドポイントやTGWアタッチメントには高額な固定費が発生します。そのため検証したらすぐ削除し、また検証したいことが発生したら時間をかけて作成…ということをしなければなりませんでした。

上記の課題を解決するためにCloudFormationテンプレートを作成したので、同じような課題を抱えている方向けに役立てたらと思い記事にしました。

作成したCloudFormationテンプレート

長いのでGithub Gistに記載しています。

作成環境

ネットワーク構成図

  • vpc-NwMng …検査用VPCです。被検査VPCが被検査VPC内部以外と通信を行う場合は必ずこのVPCのNFWを通るようにルーティング設定を施しています。
    また、被検査VPCからインターネットへの出口となるNat Gatewayも集約しています。

  • vpc-Spoke1、vpc-Spoke2…被検査VPCです。被検査VPC内部以外との通信(vpc-Spoke1 or vpc-Spoke2へ向かう通信・インターネットへ向かう通信)は必ず検査用VPCのNFWを通ります。各VPCには検証用EC2とセッションマネージャ用VPCエンドポイントを配置しており、セッションマネージャでログインすることが出来ます。

※CloudFormationテンプレートにて、各VPC/サブネットCIDRには10.0.X.0/XXを採番していますが、ご自身のAWSアカウントの既存VPC/サブネットCIDRと重複している場合はパラメータ指定画面にて別のCIDRをご指定下さい。


Network Firewall設定

  • デフォルトでは通信を拒否。特定の通信のみルールで評価し、アラートログを出力した上で許可する方式を取っています。

  • 検査ルールには「被検査VPC同士の通信の許可&アラートログを出力するルール」「被検査VPCからインターネットへの通信の許可&アラートログを出力するルール」と大きく分けて2つ設定しています。(個人的な理由で申し訳ございませんが、私が検証していた時に2つに分かれていた方が都合が良かったため、今回もこのように設定しています。)


上記設定を反映すると下図のようなフローで検査が行われます。


発生する固定費について

2024年6月時点のAWS価格設定では約$1.1/時間の固定費が発生しますので、検証後は速やかにCloudFormationスタックの削除を行うことをお勧めします。

リソース名 単価($) 個数 合計($) 備考
Transit Gateway Attachment 0.07     3(アタッチメント数) 0.21   Transit Gateway AttachmentはENI単位ではなくアタッチメント単位で課金が発生します。
Network Firewall Endpoint 0.395    2(ENI数) 0.79  
VPC Endpoint 0.014    6(ENI数) 0.084 
Nat Gateway 0 2(個) 0 Network Firewall Endpoint1個につき、Nat Gateway1個の料金は相殺されるため$0です。
Nat Gatewayに割当てられるパブリックIP 0.005    2(個) 0.01  
検証用EC2(t4g.nano) 0.0054 2(個) 0.0108
合計 1.1048

補足1_VPCルートテーブルでNFWエンドポイントをターゲットに指定する際の表記方法について

下記のようにVPCルートテーブルでNFWエンドポイントをターゲットに指定する際、何やら複雑な指定方法をしていますがこの理由について補足いたします。

  RtbNwMngPublicARoute1:
    Type: AWS::EC2::Route
    DependsOn: NetworkFirewallNwMng
    Properties:
      RouteTableId: !Ref RtbNwMngPublicA
      DestinationCidrBlock: !Ref VpcSpoke1Cidr
      VpcEndpointId: !Select [ 0, !Split [ ',', !Select [ 1 , !Split [ 'a:', !Join [ ',', !GetAtt NetworkFirewallNwMng.EndpointIds ] ] ] ] ]

2024年6月現在、Fn::GetAttで複数のAZに存在するNFWエンドポイントを指定してもAZ順でソートされたものが返りません。
そのため、例えばap-northeast-1a用のルートテーブルでap-northeast-1cに存在するNFWエンドポイントをターゲットに指定してしまい、上手く検査できなくなってしまうことが起こり得ます。
今回は、上記リンクのGithub Issuesに記載されていたPetri Kallberg氏のブログ記事記載の解決策を流用させていただきました。


補足2_スタック削除時にNFWルールグループが削除できないエラーが発生した場合の対処方法について

CloudFormationスタック削除時、NFWルールグループ「InternetEgressStatefulRuleGroup」と「InternalStatefulRuleGroup」が使用中のため削除できない旨のエラーが発生してスタック削除が失敗することがあります。
その時は、しばらく間を置いてから再びスタック削除操作を行えば削除に成功します。

感想

CloudFormationテンプレートは一回作ってしまえば楽ですが、作るまでが大変でなかなか腰が重くなりがちかなと思います。
同じような悩みを抱えた方々の一助になれば幸いです。

前田 青秀(執筆記事の一覧)

2023年2月入社 技術4課改めCR課

AWS資格12冠

ジムに通い始めましたが、なるべく楽してマッチョになりたい…