AWS ALBの属性一覧

概要

ALBの設計をする際に毎回属性を調べるのが面倒だったので、n番煎じではありますがALBの属性を一覧でまとめました。下記の二つの記事は全体を通して非常に参考にさせていただいております。
※適宜更新が入りますので、ご了承ください。

Application Load Balancer (ALB) の属性を整理してみた
【初心者向け】Application Load Balancer（ALB）とターゲットグループの属性についてまとめてみた

ALBの属性

TLSバージョンと暗号ヘッダー

説明

クライアントからのHTTPリクエストをターゲットにルーティングする際に、二つのTLSヘッダー（x-amzn-tls-version及びx-amzn-tls-cipher-suite）を付与する機能です。

• x-amzn-tls-version：クライアントとネゴシエートしたTLSバージョン情報
• x-amzn-tls-cipher-suite：クライアントとネゴシエートした暗号スイート情報

例）x-amzn-tls-version: TLSv1.3
　　x-amzn-tls-cipher-suite: TLS_AES_128_GCM_SHA256

ポイント

クライアントとネゴシエートしたTLSバージョンや暗号スイートに応じてアプリケーションの処理を変更したり、この情報を別のリソースに送信する場合などに有効化します。
リスナーの属性である［変更可能なmTLS/TLSヘッダー名］により、これらのヘッダー名を任意の値に変更できるため、同等のヘッダを利用している既存アプリとのシームレスな統合が可能です。

参考

ロードバランサーの属性
ALB でリスナーに対してヘッダーの変更、追加ができるようになりました

---

WAFのフェイルオープン

説明

WAF側に障害が発生しALBとWAFが接続できない場合に、リクエストにWAFを素通りさせることでターゲットへの通信を許可することを可能にする機能です。

ALBは通常、WAFから応答を得られない場合には500エラーを返却します。
しかし、本属性値を有効化することで、WAF障害時にはリクエストにWAFを素通りさせることが可能となり、利用者は通常通りシステムを利用できるようになります。

Application Load Balancers and AWS WAF By default, if the load balancer cannot get a response from AWS WAF, it returns an HTTP 500 error and does not forward the request. If you need your load balancer to forward requests to targets even if it is unable to contact AWS WAF, you can enable the WAF fail open attribute.

ポイント

高可用性が求められ、ブロック指定したルールに該当するリクエストが素通りする事があっても致命的な問題とならない環境や、WAFをカウントモード IDS(不正侵入検知) 相当として利用する環境で、HTTP 500 エラー (waf-failed) の抑制を必要とする場合に有効化を検討しましょう。

参考

Integrations for your Application Load Balancer / AWS WAF
ALB で WAF のフェイルオープン設定が可能になりました

---

HTTP/2

説明

クライアント - ALB間通信において、HTTP/1.1及びHTTP/2の両方をサポートする機能です。

ポイント

クライアント - ALB間通信におけるHTTP/2をサポートするだけであり、ALB - ターゲット間通信におけるプロトコルはターゲットグループの設定値である［プロトコルバージョン］に依存します。

参考

[アップデート] ALBでエンドツーエンドのHTTP/2サポートによりgRPCワークロードが可能になりました

---

接続アイドルタイムアウト

説明

ALBとクライアント及びターゲット間において、データの送受信が行われず非アクティブ状態にあるTCPコネクションを切断するまでの時間です。

ポイント

ここで重要となるのが、接続アイドルタイムアウトの値よりもターゲット側のTCPキープアライブ及びHTTPキープアライブの値が大きくなるように設定することです。

TCPキープアライブはnet.ipv4.tcp_keepalive_time等のカーネルパラメータで設定され、HTTPキープアライブはWebサーバにおけるKeepAliveTimeout等で設定されます。接続アイドルタイムアウトよりもこれらの設定値が小さい場合には、通信が非アクティブ状態になった際にターゲット側からTCPコネクションを切断します。このとき、ALBは切断を認知することなく、継続してTCPコネクションを利用しようとするため、502 Bad Gateway や 504 Gateway Timeout エラーが発生してしまいます。

以上のことから、基本的には接続アイドルタイムアウトの値よりもターゲット側のTCPキープアライブ及びHTTPキープアライブの値が大きくなるように設定し、ALB側からTCPコネクションを切断してあげることがAWSからも推奨されています。

参考

接続のアイドルタイムアウト
HTTP Keep-Aliveの挙動をtcpdumpで見てみた
ELB使ってる人はすぐにKeepAlive Timeoutの値を確認しよう

---

HTTPクライアントのキープアライブ期間

説明

ALBがクライアントとのHTTP接続（TCPコネクション）を維持できる最大時間です。設定した［HTTPクライアントのキープアライブ期間］が過ぎると、ALBは最後に1つのリクエストを受け入れ、接続を正常に終了するレスポンスを返します。

After the configured HTTP client keepalive duration elapses, the Application Load Balancer accepts one more request and then returns a response that gracefully closes the connection.

ポイント

［HTTPクライアントのキープアライブ期間］はクライアントへのHTTP接続が最初に確立された時点から開始され、トラフィックの有無に関わらず、指定した期間はTCPコネクションが維持されることに注意が必要です。

参考

Application Load Balancer の属性を編集する/HTTP クライアントのキープアライブ期間
ALBのHTTPキープアライブ最適化による画面フリーズ問題の解決実践例

---

Desync 緩和モード

説明

ALBでは、HTTP Desync GuardianというAWSのOSSに基づいて、HTTPリクエストを脅威レベルごとに4種類（Compliant, Acceptable, Ambiguous, Severe）に分類されます。

脅威レベル	説明
Compliant	リクエストは RFC 7230 に準拠している。
Acceptable	リクエストは RFC 7230 に準拠していないが、既知のセキュリティ上の脅威はない。
Ambiguous	リクエストは RFC 7230 に準拠していないが、さまざまな Web サーバーやプロキシが異なる処理をする可能性があるためリスクがある。
Severe	リクエストが不正な形式であるか、意図的に細工された可能性が高いことを示す。重大なセキュリティリスクをもたらす。

本属性値により、どの脅威レベルまでリクエストを許可/ブロックするかを定義可能です。

Desync 緩和モード＼脅威レベル	Compliant	Acceptable	Ambiguous	Severe
モニタリング	許可	許可	許可	許可
防御的	許可	許可	許可	ブロック
最も厳格	許可	ブロック	ブロック	ブロック

ポイント

「最も厳格」を設定した場合には、従来の正当なHTTPリクエストまでブロックされる可能性があるため、事前に検証環境で影響を確認した上で本番環境での利用を開始する必要があります。

また、ALBアクセスログの classification 及び classification_reason フィールドにおいて、HTTPリクエストがどの脅威レベルであったか・なぜ脅威と判断されたかを確認可能です。
本属性値を「最も厳格」に設定し、Content-Length:0を付与して curl した際のALBアクセスログを以下に示します。脅威レベルはAcceptableと評価され、400 Bad Gatewayを返却しています。

http 2025-07-06T13:35:28.081765Z app/internal-test-alb/fad00ddbce5350b6 10.1.30.254:38802 - -1 -1 -1 400 - 160 272 "GET http://internal-test-alb-393374371.ap-northeast-1.elb.amazonaws.com:80/sample/ HTTP/1.1" "curl/8.5.0" - - - "-" "-" "-" - 2025-07-06T13:35:28.081000Z "-" "-" "-" "-" "-" "Acceptable" "GetHeadZeroContentLength" TID_d 1abe7d3262a7438746667527dab92

参考

ALBとCLBに追加されたDesync Mitigation Mode の動作を確認
[アップデート] ALB および CLB に HTTP Desync 緩和モードが機能追加されました

---

無効なヘッダーフィールドを削除

説明

HTTPリクエストにおけるヘッダー名が正規表現[-A-Za-z0-9]+に準拠していない場合に、HTTPリクエストから該当ヘッダーを削除する機能です。

ポイント

HTTPリクエストを拒否するという訳ではなく、該当ヘッダーを削除してターゲットに送信します。
対象となるのはあくまで、HTTPリクエストにおけるヘッダー名です。HTTPレスポンスヘッダーは準拠している必要はなく、当然ではありますがヘッダー値は対象外となります。

参考

無効なヘッダーをドロップするように Application Load Balancer を設定する方法を教えてください。

---

X-Forwarded-For ヘッダー

説明

ALBがHTTPリクエストをターゲットに送信する際に、X-Forwarded-Forヘッダーを付与・保持・削除することを可能にする機能です。

• 付加：クライアントのIPアドレスをX-Forwarded-Forヘッダーに格納し、ターゲットに転送
• 保持：X-Forwarded-Forヘッダーを変更することなく、ターゲットに転送
• 削除：X-Forwarded-Forヘッダーを削除した後に、ターゲットに転送

ポイント

Webサーバに記録される送信元IPアドレスはALBのIPアドレスとなってしまい、実際のクライアントのIPアドレスを把握できません。Webサーバ側でクライアントのIPアドレスを利用してアクセス制限等を実現したい場合には、X-Forwarded-Forヘッダーから情報を取得します。

本属性値を「付加」とすれば、クライアントのIPアドレスをX-Forwarded-Forヘッダーに付与することが可能ですが、ALBの直前の機器のIPアドレスしか取得できません。そのため、プロキシ等を経由している場合には、それらの中継機器においてもX-Forwarded-Forヘッダーを付与するような設定が必要となります。

参考

HTTP ヘッダーと Application Load Balancer
ALBのX-Forwarded-Forオプションの挙動を見てみる

---

クライアントポートの保持

説明

クライアントがALBに接続した送信元ポートをX-Forwarded-Forヘッダーに保持します。

例）X-Forwarded-For: xx.xx.xx.xx:53824

ポイント

［X-Forwarded-For ヘッダー］と同様に、ALBの直前の機器の送信元ポートしか取得できません。
また、本属性値を有効化した上で、［X-Forwarded-For ヘッダー］属性を「保持」or「削除」と設定した場合には、［X-Forwarded-For ヘッダー］属性が優先されます。

参考

HTTP ヘッダーと Application Load Balancer
ALBのX-Forwarded-Forオプションの挙動を見てみる

---

ホストヘッダーを保持

説明

HTTPリクエストのHostヘッダーを保持し、変更を加えずにヘッダーをターゲットに送信します。

リスナーポートがデフォルトポート（80番 or 443番）である場合に、本属性値の有効化に伴いターゲットに送信されるHostヘッダーがどう変化するかを以下に示します。

ポイント

アプリケーションがリクエストに基づいたルーティングを行っていたり、正確なホストヘッダーが必要になる場合には有効化する方針となります。

参考

Application Load Balancer の属性を編集する/ホストヘッダーの保持

---

クロスゾーン負荷分散

説明

各AZにおけるALBノードから、有効な全てのAZの登録済みターゲットにトラフィックを分散する機能です。ALBにおける本属性値は無効化することができず、実際のクロスゾーン負荷分散の有効化/無効化はターゲットグループの属性である［クロスゾーン負荷分散］に依存します。

有効化することで、以下に示すようにシステムの可用性を向上させることができます。

• クロスゾーン負荷分散が無効の場合：
  ECSタスクに障害が発生した際には、次のECSタスクが起動しヘルスチェックが成功するまで、障害が発生した側のALBノードが 503 Service Temporarily Unavailableを返却します。
  また、ECSタスクが1AZのみに集中してデプロイされると、ECSタスクが存在しないAZのALBノードのDNSレコードが削除されるまでの間、同様に503エラーとなってしまいます。
  

• クロスゾーン負荷分散が有効の場合：
  ECSタスクに障害が発生した際にも、AZを跨って正常なECSタスクにルーティングするので、システム障害の時間をヘルスチェック間隔未満にすることが可能です。
  ECSタスクが1AZのみに集中してデプロイした場合にも、ALBノードはAZを跨ってルーティングすることが可能なので、ルーティング対象が存在しない場合に該当ALBノードのDNSレコードの削除が遅延することに伴う503エラーを考慮する必要はありません。また、不均衡なECSタスクのリバランスが発生し、AZ-c側に新規タスクが作成された際にも、遅延なくAZ-a側のALBノードからルーティングすることで即座に負荷を分散させることができます。
  

ポイント

可用性を向上させることが可能なだけでなく、AZ間にターゲット数の偏りがある場合に各ターゲット間における負荷の平準化も可能となるため、基本的には有効化する方針で良いです。
ただ、AZ間で通信が発生するため、AZ間通信に伴うネットワーク料金がかかることと多少のレイテンシが発生することには注意が必要です。これらを無視できない場合には無効化も検討した方がよいかと思います。

また、ターゲットグループの属性である［維持設定（スティッキーセッション）］を有効化するためにはクロスゾーン負荷分散の有効化が必須である点にも留意しましょう。

参考

Elastic Load Balancing の仕組み/クロスゾーン負荷分散
Application Load Balancer を使っている場合でもクロスゾーン負荷分散を無効化するオプションが利用できるようになりました

---

ARCゾーンシフト統合

説明

ALBにおいてARCゾーンシフトを利用するための必要条件です。

ARCゾーンシフトとは、特定のAZに存在するALBノードにルーティングしないようにする機能です。クロスゾーン負荷分散が有効な場合には、以下の二つのアクションが実行されます。

1. 指定AZに存在するALBノードのDNSレコードがAWS管理DNSサーバから削除される。
2. 指定AZ以外のALBノードから指定AZに存在するターゲットへのルーティングが遮断される。

ポイント

上記の図に示したようにゾーンシフト実行時にはクロスゾーン負荷分散が無効になる訳ではなく、残りのAZでは引き続きAZを跨ったルーティングが可能となります。

また、ARCゾーンシフトを実行する際にはTCPコネクションの維持期間に注意が必要です。
ゾーンシフトを実行し、特定AZへのルーティングを避けたとしても、除外されたALBノードとTCPコネクションを張っていたクライアントは引き続き既存のTCPコネクションを利用してしまいます。これはTCPコネクションが確立した時点で通信先IPアドレスが固定されるためです。
これを回避するために、ゾーンシフトを利用する際には［HTTPクライアントのキープアライブ期間］や［アイドルタイムアウト］などのTCPコネクション維持時間に関する属性値を制限することが推奨されています。

参考

ゾーンシフトを用いたクロスゾーン負荷分散
ARC のゾーンシフトのベストプラクティス

---

アクセスログ

説明

ALBに対して行われたリクエストの詳細なログを記録します。IPアドレスやポート、ステータスコードだけでなく、リクエストに一致したリスナールールなども確認できます。

ポイント

全てのリクエストを記録する訳ではなく、あくまでベストエフォートでリクエストを記録する点に注意が必要です。アクセスログに記録されたログが全てとは限らない可能性があるみたいです..

Elastic Load Balancing logs requests on a best-effort basis. We recommend that you use access logs to understand the nature of the requests, not as a complete accounting of all requests.

とはいっても、通信障害が発生した場合には原因特定のために一旦アクセスログを見に行くことになると思うので、基本的には有効化しておきましょう。
出力先はS3バケットであり、バケットポリシーの設定が必要です。

参考

Application Load Balancer のアクセスログ

---

接続ログ

説明

ALBに対して行われたTLS接続の詳細なログを記録します。使用されるTLS暗号とプロトコル、TLSハンドシェイクレイテンシー、接続ステータス、クライアント証明書の詳細などを確認できます。

ポイント

基本的には無効化しておき、TLSネゴシエーション等のエラーが発生し、障害調査が必要となった場合に有効化するという運用でも個人的には十分かと考えています。
出力先はS3バケットであり、バケットポリシーの設定が必要です。

参考

Application Load Balancer の接続ログ
ALBの接続ログ (Connection logs)を試してみた

---

削除保護

説明

ALBの削除保護を有効化する機能です。本属性値を有効化することで、マネジメントコンソールから「ロードバランサーの削除」を選択するだけでは削除することができなくなり、ALBを削除する前に［削除保護］を無効にするプロセスが必要になります。

ポイント

削除保護をオンにすることで、マネジメントコンソール上での操作ミスでALBを削除してしまうような事故を大きく減らすことができます。特に本番環境で運用している場合など、削除すると大きな影響が予想されるALBには、削除保護を設定しておきましょう。

参考

Application Load Balancer の属性を編集する/削除保護

---

ターゲットグループの属性

登録解除の遅延

説明

ターゲットを登録解除する際に、新規リクエストの割り振りは中止して、処理中のリクエストが完了するまで一定時間待ってからターゲットを切り離す機能です。

ポイント

登録解除するターゲットに未処理のリクエストやアクティブな接続がない場合は、ALBは登録解除の遅延期間が経過するのを待たずに、即時登録解除プロセスを完了します。ただし、ターゲットの登録解除が完了しても、ターゲットのステータスは登録解除の遅延期間に達するまでdrainingと表示されます。タイムアウトの期限が切れると、ターゲットはunused状態に移行します。

参考

Application Load Balancer のターゲットグループ属性を編集する/登録解除の遅延

---

ロードバランシングアルゴリズム

説明

ALBがターゲットグループ内からルーティング先のターゲットを決定する時のアルゴリズムです。

• ラウンドロビン：リクエストを順番に、正常なターゲットに均等にルーティングする。
• 最小の未処理リクエスト：進行中の処理が最も少ないターゲットにルーティングする。
• 加重ランダム：ALBの異常検出機能によりanomalous(異常)と判断されたターゲットに対するトラフィックの重みを［異常緩和］により自動的に削減し、正常なターゲット全体に渡ってランダムな順序でリクエストを均等にルーティングする。

ポイント

ALBではリクエストを応答した時点で処理済みリクエストとして判断されるため、以下のようにリクエストを応答後にサーバ側で重めの処理を実行するという場合には、最小の未処理リクエスト方式では適切に負荷分散できないことは留意しておきましょう。

そのサービスでは、アプリケーションサーバで処理するリクエストの中で特定の1種類でだけCPUを集中的に利用するケースがあり、そのようなリクエストがたまたま１台のサーバに集中するとCPU利用率が100%に達してしまうことがありました。
まさに最小未処理リクエストの出番のように見えました。しかし、そのタイプのリクエストでは重めの処理を exec で別プロセスとして起動してリクエスト自体は即座に応答するという作りになっていたため、未処理リクエストとしては扱えないことが分かって断念しました。

適切なロードバランシング方式はアプリケーションによって異なりますが、個人的にはまず加重ランダム方式を採用することを検討し、サーバ間の処理時間に大きな差がある場合には最小の未処理リクエスト方式を選択肢に入れていく方針が良いかと考えています。ターゲットが2つ以下となる場合や「スロースタート期間」を定義する場合にラウンドロビン方式の利用を検討すればいいかと思います。

異常を検出するには、ターゲットグループ内に正常なターゲットが 3 つ以上必要です。

参考

Application Load Balancer のターゲットグループ属性を編集する/自動ターゲット加重 (ATW)
AWSのApplication Load BalancerにAutomatic Target Weightsという新機能が来てました

---

スロースタート期間

説明

新しくターゲットグループに登録されヘルスチェックが成功したターゲットに対して、他ターゲットと同等のリクエストを送信し始めるまでの猶予期間です。設定した期間は新規ターゲットにリクエストが送信されないという訳ではありません。設定した時間後に他ターゲットと同等のリクエストを受信するように、線形的にリクエスト数を増加させていく形式となります。

ポイント

最小の未処理リクエスト方式および加重ランダム方式を使用する場合、［スロースタート期間］を有効にすることはできないため、実質的にラウンドロビン方式専用の属性値となります。

新規に起動したEC2インスタンスなどがリクエストを受け取る際に、CPUやメモリのリソースが十分に確保されていない状態でリクエストを受け取ること（過負荷になること）を防ぐためなどに使用されます。本属性値が長すぎると、逆に他ターゲットの負荷が高まってしまう可能性があるため、設定には注意が必要となります。

参考

Application Load Balancer のターゲットグループ属性を編集する/スロースタートモード

---

ターゲットの維持設定（スティッキーセッション）

説明

クライアントからのHTTPリクエストを常にターゲットグループ内の特定のターゲットに維持する機能です。HTTPリクエストに付与されたCookieにより維持設定を実現しており、使用するCookieの種類により2つにタイプが存在します。

• 期間ベースの維持：ALBが生成するCookie(AWSALB) を使用してターゲットを固定
• アプリケーションベースの維持：アプリが生成したCookie(SESSION_ID等)とALBが生成する持続性情報をキャプチャするCookie(AWSALBAPP)を使用してターゲットを固定

ターゲットの維持設定を有効化すると、ターゲットグループにおいてCookieとターゲットの対応関係が記録されます。HTTPリクエストを受け取ると、本対応関係に基づいて特定のターゲットにルーティングします。これによりターゲットの固定が実現されるという仕組みです。

ポイント

「アプリケーションベースの維持」ではアプリ側で発行/管理するセッションID(Cookie)をALBのルーティングキーとしても利用しますが、本属性値はあくまでALBがどのターゲットにルーティングするかを決定するだけであり、アプリケーションのセッション管理に直接的に関与する属性値ではありません。アプリのセッション管理は当然アプリ側で行います。

「アプリケーションベースの維持」はアプリ側のセッションIDとALBのルーティングキーを統一することで一貫したセッション管理を実現する場合や、セッション維持の高度な制御が必要な場合に有効となります。一方、特に要件がなければシンプルな「期間ベースの維持」で十分なケースも多いようです。

参考

Application Load Balancer のスティッキーセッション
AWS ALB スティッキーセッション メモ

---

クロスゾーン負荷分散

説明

ALBにおける［クロスゾーン負荷分散］は無効化することができません。実際のクロスゾーン負荷分散の有効化/無効化は本属性値によりターゲットグループレベルで設定します。

ポイント

ALBにおける「クロスゾーン負荷分散」参照。

参考

Application Load Balancer を使っている場合でもクロスゾーン負荷分散を無効化するオプションが利用できるようになりました

---

ターゲットグループの正常要件

説明

デフォルトでは、ターゲットグループが少なくとも1つの正常なターゲットを持っている限り、そのターゲットグループは正常であると見なされます。一方で、フリートが大きい場合にはトラフィックを処理する正常なターゲットが1つだけでは十分ではありません。
そこで［ターゲットグループの正常要件］では、正常でなければならないターゲットの最小数または割合を指定し、正常なターゲット数がそれらの閾値を下回ったときにALBが実行するアクションを定義することができます。アクションとしては以下の二つが定義可能であり、それぞれに対して正常な閾値を設定できます。

• DNSフェイルオーバ：
  AZにおける正常なターゲットが閾値を下回ると、該当AZのALBノードのDNSレコードが削除されます。結果として、クライアントがALBのDNS名を名前解決すると、トラフィックは正常なAZのALBノードに対してのみルーティングされます。

• ルーティングフェイルオーバ（フェイルオープン）：
  AZにおける正常なターゲットが閾値を下回ると、ALBは異常なターゲットを含むALBノードで使用可能なすべてのターゲットにトラフィックを送信します。これにより、単にターゲットが一時的にヘルスチェックに合格しなかった場合にクライアント接続が成功する可能性が高まり、正常なターゲットが過負荷になるリスクが軽減されます。

ポイント

両方のアクションに閾値を指定する場合、DNSフェイルオーバの閾値はルーティングフェイルオーバの閾値以上である必要があります。さらに、クロスゾーン負荷分散の無効/有効に応じても挙動が変化するため、実際に起こりうるパターンは以下の4種類となります。

• クロスゾーン負荷分散無効 かつ 正常なターゲット数<DNSフェイルオーバの閾値：
  この場合にはシンプルにDNSフェイルオーバが発生します。障害が起こったAZのALBノードのDNSレコードが削除され、正常なAZのALBノードに対してのみルーティングされます。

• クロスゾーン負荷分散無効 かつ 正常なターゲット数<両方の閾値：
  この場合には、基本的にはDNSフェイルオーバが発生したような挙動をします。1つ目のパターンと同様に、障害が起こったAZのALBノードのDNSレコードが削除され、正常なAZのALBノードに対してのみルーティングされることとなります。
  ただ、実際にはDNSフェイルオーバもフェイルオープンも同時に発生しているということを頭の片隅に入れておきましょう。フェイルオープンも発生自体はしているのですが、DNSフェイルオーバによりALBノードのDNSレコードが削除されているため、ドメイン名によるアクセスが該当ALBノードに届かずにフェイルオープンが発生していないように見えるだけというカラクリになっています。ALBノードのIPアドレスを明示的に指定してアクセスした場合には、配下の全てのターゲットにトラフィックが送信されます。
  

• クロスゾーン負荷分散有効 かつ 正常なターゲット数<DNSフェイルオーバの閾値：
  クロスゾーン負荷分散が有効な状態で各アクションの閾値を下回った場合には、全ての有効なAZにおいて閾値を下回ったという扱いとなるようです（AWSにQA済み）。この際には、DNSフェイルオーバは発生することなくトラフィックは全てのALBノードにルーティングされ、ALBノードではフェイルオープンが発生し、配下の全ターゲットにトラフィックが転送されます（本記事では、この一連の処理をALBフェイルオープンと定義）。

  With DNS failover, if all load balancer zones are considered unhealthy, the load balancer sends traffic to all zones, including the unhealthy zones.

• クロスゾーン負荷分散有効 かつ 正常なターゲット数<両方の閾値
  3つ目のパターンと同様の挙動となります。
  

参考

Application Load Balancer のターゲットグループ/ターゲットグループのヘルス

---