こんにちは、サーバーワークスの山本です。
先日、CloudFront Connection Functions を利用した IP 制限の実装を検討していた際に、「AWS WAF との実行順序」とそれに伴う「課金」について疑問が生じました。 AWS サポートに問い合わせて明確な回答をいただきましたので、その内容を共有します。
疑問：WAF の料金はかかってしまうのか？
CloudFront でアクセス制御を行う際、一般的には AWS WAF や CloudFront Functions を利用することが多いかと思います。 これまでのドキュメントや構成図（例：CloudFrontとCloudFront FunctionsによるECサイトのVisitor Prioritization）を見ると、リクエストの処理フローは通常以下のようになっています。
- AWS WAF （リクエスト検査）
- CloudFront Functions
この順序だと、仮に後段の CloudFront Functions で 403 Forbidden を返してブロックしたとしても、その前段階で WAF がリクエストを検査しているため、WAF のリクエスト検査料金（$0.60/100万回）は発生してしまうことになります。
今回検討していた CloudFront Connection Functions についても同様に、「結局 WAF が先に動いてしまい、ブロックしたとしても WAF のコストは掛かってしまうのではないか？」という点が懸念点でした。
結論：Connection Functions でブロックすれば、WAF 料金は発生しない
AWS サポートからの回答は「No（WAF料金は発生しない）」でした。 理由は、両者が動作するネットワークレイヤの違いにあります。
HTTPS で接続する場合、通信は以下の順序で行われます。
- TCP 3-way handshake
- TLS handshake
- HTTP request
ここでの重要なポイントは以下の2点です。
- CloudFront Connection Functions は 「2. TLS handshake」 中に動作する
- AWS WAF や CloudFront Functions は 「3. HTTP request」 を評価する
つまり、Connection Functions で IP アドレス制限などに抵触して接続が拒否された場合、通信は TLS handshake 中に失敗します。その結果、後続の HTTP リクエスト自体が発生しません。
HTTP リクエストが発生しないということは、それを検査する WAF も動作しないため、当然 WAF の料金も発生しない ということになります。
まとめ
- CloudFront Connection Functions は TLS ハンドシェイク中に実行される。
- AWS WAF は HTTP リクエストに対して実行される。
- したがって、Connection Functions で接続を拒否した場合、WAF は動作せず、WAF のリクエスト料金も発生しない。
Connection Functions は、通常の CloudFront Functions とは異なり、より低いレイヤで不要な通信をカットできるため、WAF のコスト削減という観点でも非常に有効な手段と言えそうです。
同じ疑問を持たれた方の参考になれば幸いです。
（参考リンク）
