AWSグローバルアクセラレータのUDPフローのアイドルタイムアウトは、TCPフローの場合よりも大幅に短くなっています。具体的には、UDP接続のアイドルタイムアウトは30秒ですが、TCP接続では340秒(約5分40秒)ではるかに長くなります[4]。
この違いは、プロトコルの性質と、グローバルアクセラレータが接続を管理する方法に由来しています。
-TCPフロー：AWSグローバルアクセラレータは、エッジでTCP接続を終了し、バックエンドエンドポイントへの新しいTCP接続を確立します。 340秒のアイドルタイムアウトはこれらの接続に適用されます。つまり、この期間内にデータが送信または受信されない場合、グローバルアクセラレータは接続を閉じます。このタイムアウトは固定されており、カスタマイズできません。 TCP Keep-Aliveパケットを使用して接続を維持することはできません。代わりに、実際のデータパケットをタイムアウトウィンドウ内で送信して、接続を生かし続ける必要があります[4]。
-UDPフロー：UDPはコネクションレスであり、TCPのような正式な接続の確立や分解はありません。 UDPの場合、Global Acceleratorは30秒の短いアイドルタイムアウトを使用します。このウィンドウ内でUDPパケットが送信または受信されない場合、フローはアイドル状態と見なされ、閉じられます。この短いタイムアウトは、UDPのステートレスの性質と、UDPフローが短命または頻繁にリフレッシュされると予想される典型的なユースケースを反映しています[4]。
要約すると、重要な違いは、TCPフローがTCPの接続指向性と接続管理のオーバーヘッドにより、はるかに長いアイドルタイムアウト(340秒)を持っていることです。これにより、グローバルアクセラレータにおける効率的なリソースの使用とタイムリーなクリーンアップが保証されます。
これらのアイドルタイムアウトのカスタマイズは現在、AWSグローバルアクセラレータによってサポートされていません[4]。
引用：
[1] https://aws.amazon.com/global-accelerator/features/
[2] https://aws.amazon.com/global-accelerator/faqs/
[3] https://cloudonaut.io/review-aws-global-accelerator-latency-multi-region-disaster-recovery/
[4] https://docs.aws.amazon.com/pdfs/global-accelerator/latest/dg/global-accelerator-guide.pdf
[5] https://hands-on.cloud/aws-services/global-accelerator/
[6] https://learn.microsoft.com/en-us/answers/questions/1139028/how-big-is-azure-balancer-udp-idletimeout
[7] https://repost.aws/questions/quuniuckyuskkscntmg8mmea/timeout-aws-global-アクセラター
[8] https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-flow-session-for-srx-series-devices.html
[9] https://www.arubanetworks.com/techdocs/sdwan/docs/orch/monitoring/bandwidth/flows-active-recent/