検証環境

ALBの下に、Autoscaling group経由でNginxを動作させているEC2をZone AとZone Cに1台づつぶら下げています。

検証結果と考察

今回の構成ではゾーン縮退自体は可能でした。
但し、以下課題が残ります。

どのゾーン(ゾーンID)が障害になったかオフィシャルには公開されなかった認識ですが、ゾーン縮退するために障害ゾーンの特定が必要
ゾーンの属性がないサービス(WAF等)は、手動によるゾーン縮退ができない

ゾーン障害でもゾーン縮退よりディザスタリカバリ(DR)をするほうが、良いかもしれません。
念の為DRできるように準備するのでは無く2,3年に1回DRが発生する位のつもりで準備しておけば万全だと思います。

以下、ゾーン縮退の検証の詳細です。

1. ALBの特性

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
ロードバランサー用のアベイラビリティーゾーンを有効にすると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。ターゲットをアベイラビリティーゾーンに登録したが、アベイラビリティーゾーンを有効にしていない場合、登録したターゲットはトラフィックを受信しません。

アベイラビリティーゾーンを無効にすると、そのアベイラビリティーゾーン内のターゲットはロードバランサーに登録されたままですが、ロードバランサーはトラフィックをターゲットにルーティングしなくなります。

AWSのドキュメントからの引用です。
障害の発生したALBのゾーンを無効化すればそのゾーンにトラフィックが流れなくなります。一方ALBに最低2ゾーン登録しておく必要があります。
つまり2ゾーン登録されている状態で、ゾーンを無効化するためには、同時に別のゾーンを追加する必要があります。

2. ALBのゾーン縮退の検証

Zone AとZone Cで構成されているシステムで、実際にZone Aを縮退させてみました。

No	およその経過時間	Zone AのEC2へのトラフィック	Zone CのEC2へのトラフィック	ALBのヘルスチェック	ALBのネットワークインターフェースの状態	説明
1	-	Zone AとZone Cから流れる	Zone AとZone Cから流れる	Zone AとZone Cから流れる	Zone AとZone C	ALB変更前
2	0分	流れなくなる	↓	↓	↓	ALBに対しZone A無効化・Zone D追加を手動実行
3	2分半	↓	Zone CとZone Dから流れる	Zone AとZone CとZone Dから流れる	Zone AとZone CとZone D	ALBのZone Dのネットワークインターフェースが利用中になる
4	1時間	↓	↓	Zone CとZone Dから流れる	Zone CとZone D

ALBでZone Aを無効化した直後から、Zone AのNginxへのトラフィックは来なくなりました。
また(ヘルスチェックを除き)ALBのZone Dのネットワークインターフェースが利用中になった位から、ALBのZone AのインターフェースからZone CのNginxへのトラフィックも来なくなりました。