【緊急】AWS Network Firewallの「謎の接続切れ」がついに解消！デフォルト設定が大幅アップデート

AWS Network Firewallにおいて、新規作成されるファイアウォールポリシーのデフォルトステートフルアクションが、「Application drop established (bidirectional)」から、より接続の信頼性を高める「Application drop established (server-directed only)」へと変更されました。これにより、サーバーからクライアントへの正当なTCPパケット（ウィンドウ更新、Keep-alive、Reset等）がサイレントにドロップされる問題が解消されます。本変更は、新規作成されるポリシーにのみ自動適用されます。

🛠️ エンジニアへの衝撃：あの「原因不明の通信エラー」の正体だった！？

今まで、Network Firewallを使っている環境で「なぜか時々、データベースやAPIとの接続がプツプツ切れるんだよね…」という、診断が非常に困難なトラブルに遭遇していませんでしたか？

実は、それ、旧デフォルト設定のせいだった可能性が高いです！

🔍 何が変わったのか？

これまでは「双方向(bidirectional)」でドロップする設定がデフォルトだったため、サーバーからクライアントへ送られる制御パケット（Window UpdateやKeep-aliveなど）まで巻き添えでドロップされてしまっていました。これが、通信の安定性を損なう大きな原因になっていたんです。

🇯🇵 国内リージョンへの影響

最新のリージョン状況を調査したところ、東京リージョン (ap-northeast-1) および 大阪リージョン (ap-northeast-3) の両方で、既にこのアップデートの恩恵を受けられます。 国内のインフラ運用においても、非常に重要な変更です。

🚀 運用上のアドバイスと次の一歩

1. 既存環境のチェック: 既存のポリシーは自動では変わりません。もし現在、接続の不安定さを感じているなら、手動で最新の設定へ移行することを検討しましょう。
2. PQC（ポスト量子暗号）への配慮: ただし、注意！PQCなどの断片化されたTLSハンドシェイクを必要とする特殊な環境では、旧設定が必要なケースもあります。その場合は、TCPドロップルールに to_server フラグを追加するなどの調整が必要です。
3. まずはテスト環境で検証: ルール変更を行う際は、必ず非本番環境で新ポリシーを作成し、**「正当なトラフィックがブロックされていないか」**を徹底的に確認してください。VPC Flow Logs と併せて監視するのが鉄則です。

参照ドキュメント: Managing evaluation order for Suricata compatible rules