AZをまたいだ冗長化をどこまでやるか

AZをまたいだ冗長化は「やれるだけやる」が正解ではない。Single-AZで十分な構成にMulti-AZのコストと複雑性を持ち込むと、AZ間転送コストと運用負荷が設計を圧迫する。本記事では、Single-AZ／2AZ／3AZそれぞれの適用条件と、RDS・ALB・ECS/EKSごとの設計判断の境界線を整理し、「どこまで冗長化するか」を構造的に判断できるよう解説する。具体的な数値基準・比較表・判断チェックリストを合わせて提示するので、設計の意思決定の根拠として活用してほしい。

Single-AZで十分な構成とMulti-AZが必要な構成の境界

SLAと許容ダウンタイムを判断の起点にする

判断の起点は「月間許容ダウンタイムが何分か」にある。99.9%（月間43.2分）を担保できればよい構成なら、Single-AZで設計を組み始めることも選択肢に入る。AWS単一AZのEC2/EBSはサービス単体で99%台後半のSLAを提供するが、AZ障害時には復旧まで数十分以上かかるケースがある。本番環境のSLAが99.99%以上（月間4.3分以下）を要求するなら、Single-AZのリスクは受け入れられない水準になる。まずSLAを数値で定義し、それを起点に冗長化レベルの判断を始める流れが正確だ。

ステートレス層とステートフル層で判断を分ける

冗長化の必要性はレイヤーによって異なる。ステートレスなWebサーバーやAPIサーバーは、Single-AZでもAMIから数分以内に新規インスタンスを起動できるため、RTO要件が15〜30分程度であればMulti-AZを強制する必要はない。一方、DBやキャッシュなどステートフル層は、フェイルオーバーと整合性確保のコストが高いため、SLAの厳しさに関わらずMulti-AZを前提に設計する判断が現実的だ。ステートレス層とステートフル層を分けて冗長化要件を定義することで、コストと信頼性のバランスを取りやすくなる。

開発・ステージング環境のSingle-AZ活用

本番環境とは別に、開発・ステージング環境をSingle-AZに統一することで、環境あたりのコストを30〜50%程度削減できる想定がある。Multi-AZ構成は本番環境の可用性要件に応じて適用し、それ以外の環境は積極的にSingle-AZを採用する方針が、全体の構築コストを抑える設計判断になる。ステージング環境でフェイルオーバーのテストを行いたい場合は、専用の検証期間を設けてスポット的にMulti-AZを有効化する方法で対応できる。環境ごとに冗長化レベルを明示したアーキテクチャドキュメントを残しておくと、後のレビューや変更判断に役立つ。

ALB/NLBを2AZに絞るか3AZに広げるかの判断

2AZと3AZのコストと可用性のトレードオフ

ALB/NLBは有効化したAZ数に比例して処理容量とコストが変化する。3AZにすることで1AZが落ちた際に残り2AZで負荷を分担できる設計となるが、問題は「1AZが落ちた際の残り2AZへの集中」を設計に織り込む必要がある点だ。2AZで各AZのキャパシティを十分に確保している場合、3AZ目を追加するメリットは障害ドメインの分散にとどまる。3AZが真価を発揮するのは、各AZのトラフィックが常に均等で、1AZ障害時に残り2AZだけでは処理しきれないほど高負荷な環境だ。ピークトラフィックの想定値をAZ単位で算出してから判断することが前提になる。

トラフィック分散の均等性と「AZ affinity」の落とし穴

一般的につまずきやすいのが、ALBのCross-zone load balancingを無効のまま3AZで運用するケースだ。Cross-zone無効の状態では各AZに均等にリクエストが分配されるが、ターゲット数がAZごとに偏っていると、ターゲット数の少ないAZへ1リクエストあたりの負荷が集中する。結果として特定AZのターゲットが過負荷になる事態が起きることがある。Cross-zone load balancingを有効化するか、ターゲットグループのAZ分散を均等に保つ設計を組み込むことでこのリスクを抑えられる。3AZを選択するならCross-zone設定と合わせて判断することが前提だ。

NLBのCross-zone課金とALBとの違い

NLBはCross-zone load balancingを有効化すると、AZをまたいだトラフィックにデータ転送料が発生する点がALBと異なる。NLBを採用するアーキテクチャでCross-zone設定を入れると予想外のコスト増につながるため、NLBの場合は2AZ構成に留め、AZ単位でのターゲット分散を明示的に管理する設計判断が有効だ。ALBとNLBの使い分け自体も、Layer-7のHTTPSオフロードや高度なルーティングが必要かどうかで決まるため、ロードバランサーの選定とAZ数の判断はセットで行うことが設計の一貫性を保つ。

RDS Multi-AZとRead Replicaをどう使い分けるか

Multi-AZはHA用、Read Replicaはスケール用という役割分離

RDS Multi-AZ（スタンバイレプリカ）は自動フェイルオーバーのためのHA構成であり、スタンバイへの直接クエリは不可能だ。これをRead Replicaと混同し「スタンバイでも読めるはず」と設計に組み込むと、フェイルオーバー前後でアプリケーションの動作が変わってしまう。読み込み負荷分散にはRead Replicaを別途用意し、Multi-AZとは役割を明確に分離するのが基本設計だ。この分離を最初に決めておかないと、後から構成を変更する際の工数が大きくなる。設計の早い段階で「HAのためのMulti-AZ」と「スケールのためのRead Replica」をエンドポイント単位で設計図に記述しておくことを推奨する。

Multi-AZ DBクラスターとMulti-AZ DBインスタンスの選択基準

Aurora Multi-AZ（クラスター構成）とRDS Multi-AZ DBインスタンスでは、フェイルオーバー時間に大きな差がある。RDS Multi-AZ DBインスタンスは切替に1〜2分程度かかるのに対し、AuroraはDNS切替によるフェイルオーバーが30秒以内で完了することが期待できる。RTO要件が60秒以内であればAuroraが現実的な選択になるが、PostgreSQLやMySQLをマネージドで運用しつつコストを抑えたい場合はRDS Multi-AZ DBインスタンスも有効な選択肢だ。アーキテクチャ選定の際はRTO要件を数値で定義してから比較検討する流れが正確な判断につながる。

Read Replicaのクロスリージョン配置とAZまたぎの使い分け

同一リージョン内でのAZ分散Read ReplicaはAZ障害時の読み込み継続に効果がある。クロスリージョン配置はDR対応と読み込み分散を同時に達成できるが、レプリカラグとデータ整合性の保証範囲が変わる点を設計に組み込む必要がある。同一リージョン内での可用性向上が目的なら、AZ分散Read Replicaで十分であり、クロスリージョンレプリカは明示的なDR要件がある場合に限定する判断が現実的だ。2つの目的を混ぜると、障害時の切り替え手順が複雑になり運用負荷が増す。用途ごとにレプリカを分けて管理する設計が長期的な運用性を高める。

ECS/EKSタスクのAZ分散設計

ECSのspread戦略とタスク配置の設計判断

ECSでは、タスク配置戦略に`spread`を使いAZ単位で均等配置を強制できる。デフォルトのbinpack戦略はコスト効率重視で同一インスタンスに詰め込むため、AZ偏りが発生しやすい。本番ECSクラスターでは`placementConstraints`にAZ spreadを組み込む設計を採用し、特定AZのインスタンス障害時にタスクが別AZに自動分散されるよう備える。タスク数が2の場合は2AZ均等配置が可能なため最低2タスクを維持する設計も合わせて決めておく。タスク数が奇数になる場合の偏りも考慮して、デプロイ時の最小タスク数を設計仕様として明記しておくことが安定した運用につながる。

EKS Podの反親和性設定とノードグループのAZ設計

EKSでは、PodAntiAffinityを使いAZ単位での分散を強制できる。`topologyKey: topology.kubernetes.io/zone`を設定することで、同一ワークロードのPodが複数AZにまたがるよう制御する。よくあるつまずきとして、ノードグループがAZ偏りを持ちながらPodの反親和性だけを設定するケースがある。この場合、反親和性ルールが守られずに同一AZへの集中が起きる可能性があり、ノードグループのAZ設計とセットで考える必要がある。Cluster Autoscalerを使う場合はAZ rebalancingの設定も確認し、スケールアウト後のノード分布が偏らないよう設計する。

FargateでのAZ分散とタスク数の設計基準

FargateはAWSが自動でAZ分散を考慮する仕組みを持つが、タスク数が少ない場合（目安として4タスク以下）は均等分散が保証されない。最低6タスク以上の稼働を前提とした設計にするか、デプロイ完了後のAZ分散状況をパイプラインで確認する運用設計が必要だ。Blue/Greenデプロイ時は一時的にタスク数が倍増するため、スパイク時のAZ分散の確認タイミングを切り替え前後で明確にしておく。タスク数を絞りたい場合は代わりにAZ障害時の自動スケールアウト速度を担保する設計で補う方向で判断する。

AZ間データ転送コストをどこで吸収するか

AZ間転送コストが発生するアーキテクチャパターン

AZ間をまたぐ通信には1GBあたりの転送コストが発生する。ECSタスクとRDSが異なるAZにある場合、ALBのCross-zone balancingでAZをまたいでルーティングされる場合、ElastiCacheノードがAZをまたぐ場合などが代表的なコスト発生ポイントだ。アーキテクチャ設計段階で通信パスを明示し、どこでAZまたぎが起きるかを可視化しておくことで、コスト試算の精度と設計意思決定の根拠が明確になる。設計図にAZをまたぐ通信を矢印で明示する習慣が、後のコスト最適化の検討を楽にする。

AZ locality設計で転送コストを吸収する判断

AZ間転送コストを抑えるアプローチとして、同一AZ内でリクエストが完結するAZ locality設計がある。ALBのターゲットグループをAZ単位に分けるか、ECSのサービスメッシュ（App Mesh等）でAZ affinityを制御する方法だ。ただしAZ locality設計は、AZ障害時に残存AZへの切り替えを自動または手動で行う設計と組み合わせないと、単なる単一障害点になる。AZ localityを採用するかどうかは、信頼性設計とのトレードオフを明示した上で判断する必要がある。コスト削減効果の試算と可用性の低下リスクを並列で評価した上で設計選定する流れが正確だ。

VPCエンドポイントとPrivateLinkのAZ配置判断

S3やDynamoDBへのGateway型VPCエンドポイントはAZ間転送コストが発生しないが、Interface型（PrivateLink）はAZ単位にENIを作成し、AZ外からの利用には転送コストが発生する。PrivateLinkを使うサービス（SQS、SSM、ECRなど）では、利用するAZにENIを配置することで転送コストを最小化できる。サービスが多い環境ではENI数が増えるため、どのサービスにPrivateLinkを使うかの取捨選択も設計判断に含める。ENI数が増えると管理複雑度が上がるため、コスト削減効果と管理コストのバランスを取る設計方針を先に決めておくことが効率的だ。

自動フェイルオーバーと手動切替の使い分け設計

自動フェイルオーバーが適切なケースと前提条件

RDS Multi-AZやRoute 53ヘルスチェックによる自動フェイルオーバーは、障害検知から切替まで人手を介さずに動作する。自動切替が有効なのは、SLAが厳しく人的対応に数分以上かけられないケースや、24時間365日の自動運用を前提にしている構成だ。ただし自動フェイルオーバーが誤検知で起動した場合の影響範囲を設計に組み込まないと、正常稼働中に無用な切替が走るリスクがある。ヘルスチェックの閾値と間隔を適切に設定し、誤検知リスクを低減する設計を合わせて行うことが自動フェイルオーバーの安全な運用に欠かせない。

手動切替を残すべきケースの設計判断

スキーマ変更・大規模バッチ処理・ステートフルなセッションが多い状態での自動フェイルオーバーは、整合性問題や接続断による再試行ストームを引き起こすことがある。このようなメンテナンスウィンドウ中は自動フェイルオーバーを一時停止し、切替の可否を人が判断する手順を設計に組み込む必要がある。自動化と手動判断の境界を運用手順書に明文化しておくことが、本番障害時の混乱を防ぐ設計上の重要ポイントだ。「平常時は自動、特定作業中は手動」という切り替えルールを事前に合意しておくことが運用の安定性につながる。

フェイルオーバー後の自動復旧とフェイルバック設計

フェイルオーバー後に元のAZへ戻す「フェイルバック」の設計も判断が必要だ。RDS Multi-AZは障害が解消されると自動的に元のAZに戻るが、アプリケーション側でコネクションを再確立するまでのタイムラグが発生する。本番環境では、フェイルオーバーとフェイルバックの両タイミングでアプリケーションへの影響を計測し、許容範囲内に収まるかを事前に検証する設計検討が欠かせない。フェイルバック無効化の選択肢も含めて、運用設計の段階で明示的に決定し、チームで合意を取っておくことが後の混乱を防ぐ。

AZ冗長パターン比較表（Single/2AZ/3AZ別コスト・可用性）

下記は主要コンポーネントにおけるAZ冗長パターンの比較表（想定例）だ。コスト倍率はSingle-AZを基準にした相対値であり、実際の費用は構成規模によって異なる。

コンポーネント	Single-AZ	2AZ	3AZ
RDS DBインスタンス	基準コスト。自動フェイルオーバーなし。AZ障害でサービス停止	約2倍コスト。自動フェイルオーバー（1〜2分）。SLA 99.9〜99.99%向け	Auroraクラスター相当。フェイルオーバー30秒以内。RTO 60秒以内が要件の場合
ALB	非推奨（ALBはマルチAZ前提の設計）	標準構成。Cross-zone不要なら転送コスト抑制可能	最高可用性。1AZ障害時も2AZで継続。Cross-zone設定と合わせて判断
NLB	非推奨	推奨構成。Cross-zone無効でAZ間転送コスト不要	Cross-zone有効化で転送コスト発生。高トラフィック環境向け
ECS/Fargate	コスト最小。AZ障害でサービス停止	最小冗長構成。タスク2以上が前提	タスク6以上推奨。AZ分散が安定。高可用性構成向け
ElastiCache（Redis）	基準コスト。障害時データ消失リスクあり	Multi-AZ有効でスタンバイ自動切替。読み込み分散なし	クラスターモードで3AZシャード分散。読み込みスケール対応
推奨適用場面	開発・検証・SLA非要求の内部バッチ	SLA 99.9〜99.99%の本番。コスト効率重視	SLA 99.99%超・高トラフィック・金融・医療系など

AZ冗長化の設計前に確認する判断チェックリスト

AZ冗長化の設計に入る前に、以下の項目を確認しておくと判断の精度が上がる。

• SLA（月間許容ダウンタイム）を数値で定義しているか
• ステートレス層とステートフル層を分けて冗長化要件を定義しているか
• 本番／ステージング／開発で異なるAZ構成を使い分けているか
• RDSのMulti-AZとRead Replicaの役割（HA用／スケール用）を明確に分離しているか
• ECS/EKSのタスク配置戦略でAZ spreadを明示しているか
• AZ間転送コストが発生する通信パスを設計図に可視化しているか
• NLBを採用する場合、Cross-zone有効化による転送コストを把握しているか
• 自動フェイルオーバーの誤検知リスクと手動切替の境界を定義しているか
• フェイルバック（元AZへの復旧）の設計とアプリへの影響を事前検証しているか
• PrivateLinkのENIを利用AZに配置し、AZ間転送コストを最小化しているか