アベイラビリティゾーンとマルチリージョン｜クラウドの障害単位を理解した配置設計

EC2やRDSを作るときに「アベイラビリティゾーン」を選ぶ欄があり、よく分からないまま「1a」を選んでいる方は多いのではないでしょうか。あるいは「マルチAZにすると料金が倍になる」と聞いて、意味を理解せずに単一AZのままにしている方もいるかもしれません。

この記事では、リージョン・アベイラビリティゾーン（AZ）・データセンターの関係を整理し、AZ間のレイテンシと転送料の実態、ロードバランサー・アプリ・DBをマルチAZに配置する基本形、マルチリージョンが本当に必要になる条件とその難しさ、そして東京・大阪リージョンの使い分けまで解説します。VPCやサブネットの作り方そのものはAWS VPCのネットワーク設計入門で扱っているので、ここでは「どの障害単位に何を置くか」という配置の判断に絞ります。

リージョン・AZ・データセンターの関係

3階層の「障害の単位」

クラウドの物理的な構造は3階層で理解できます。

• データセンター：建物そのもの。電源、冷却、ネットワーク機器を備えた物理拠点。
• アベイラビリティゾーン（AZ）：1つ以上のデータセンターをまとめた単位。同じリージョン内のAZ同士は、電源・冷却・ネットワークが独立し、互いに数十km程度離れた場所に置かれ、洪水や停電といった局所的な災害を共有しないよう設計されています。それでいて低遅延の専用回線で結ばれています。
• リージョン：複数（通常3つ以上）のAZをまとめた地理的な単位。東京（ap-northeast-1）、大阪（ap-northeast-3）など。リージョン同士は数百km以上離れ、原則として独立して運用されます。

重要なのは、これらが障害の影響範囲の単位だということです。1台のサーバー故障はインスタンス単位、電源設備の障害はAZ単位、広域災害や制御系の大規模障害はリージョン単位で影響します。冗長化とは「同じ障害単位に全部を置かない」ことであり、どの単位まで備えるかがコストを決めます。可用性の計算と単一障害点の考え方は可用性とSPOFをなくす冗長化設計を前提としてください。

AZ名はアカウントごとにずれている

見落とされがちな点として、「ap-northeast-1a」という名前が指す物理AZはAWSアカウントごとに異なります。他社の資料で「1aが落ちた」と書かれていても、自社の1aとは別の場所かもしれません。物理的な位置を一意に表すには、AZ IDを使います。

# AZ名とAZ ID（物理的な識別子）の対応を確認する
aws ec2 describe-availability-zones --region ap-northeast-1 \
  --query "AvailabilityZones[].{Name:ZoneName,Id:ZoneId,State:State}" --output table

AZ間のレイテンシと転送料｜マルチAZの「見えないコスト」

レイテンシは数ミリ秒、しかし積み重なる

同一リージョン内のAZ間の通信遅延は、往復で1〜2ミリ秒程度に収まることが多く、単発では体感できません。しかし、アプリからDBへ1リクエストあたり50回クエリを投げれば、AZをまたぐだけで50〜100ミリ秒が上乗せされます。マルチAZ構成にした途端にレスポンスが遅くなったという場合、原因はこの「クエリ数×AZ間遅延」であることがよくあります。対策はAZを1つに戻すことではなく、N+1クエリの解消やコネクションの使い回しなど、クエリ回数を減らすことです。

AZ間のデータ転送には料金がかかる

もうひとつの見えないコストが転送料です。AWSでは、同一リージョン内でもAZをまたぐデータ転送に対し、送信側・受信側の双方にGBあたりの課金が発生します（同一AZ内でプライベートIPを使った通信は無料）。単価は小さいのですが、アプリとDB、アプリとキャッシュの間で大量のデータをやり取りする構成では、月額で無視できない金額になることがあります。

通信の経路	レイテンシの目安	転送料
同一AZ内（プライベートIP）	1ms未満	無料
同一リージョン・別AZ	1〜2ms程度	双方向に課金（少額）
別リージョン（東京⇔大阪）	10ms前後	リージョン間転送として課金（AZ間より高い）
インターネットへの送信	経路による	最も高い

転送料の全体像はクラウドの通信費（Egress）入門で解説しています。設計上の実務判断としては、「AZ間転送料と遅延は、AZ障害で全停止するリスクに対する保険料」と捉え、それでも払う価値のある部分（本番のDBとアプリ）だけをマルチAZにし、開発環境などは単一AZで安く済ませる、という切り分けが現実的です。

マルチAZ配置の基本形｜LB・アプリ・DBをどう置くか

3層それぞれの置き方

Webシステムの標準的なマルチAZ配置は次のようになります。

1. ロードバランサー（ALB/NLB）：作成時に2つ以上のAZのサブネットを指定する。マネージドLBは指定した各AZにノードを配置し、AZ障害時は生き残ったAZのノードだけで振り分けを続ける。LBを1つのAZにしか置かなければ、その時点でSPOFになる。
2. アプリサーバー：Auto Scalingグループ（またはECSサービス）に複数AZのサブネットを指定し、台数を「AZ数の倍数」にする。各AZに均等に配置されるので、1つのAZが落ちても残りのAZで処理が続く。このとき、残りのAZだけでピーク負荷を処理できる台数が必要。
3. データベース：RDSのマルチAZ配置を有効にすると、別AZに同期レプリケーションされたスタンバイが作られ、障害時に自動でフェイルオーバーする。アプリはエンドポイント（DNS名）に接続しているため、切替後は同じ名前で新しいプライマリにつながる。

# Terraformでのマルチ AZ 配置の要点（抜粋）
resource "aws_lb" "app" {
  name    = "app-alb"
  subnets = [aws_subnet.public_a.id, aws_subnet.public_c.id]  # 2つ以上のAZ
}

resource "aws_autoscaling_group" "app" {
  vpc_zone_identifier = [aws_subnet.private_a.id, aws_subnet.private_c.id]
  min_size            = 2   # AZ数の倍数にして各AZに均等配置
  max_size            = 6
}

resource "aws_db_instance" "main" {
  identifier = "prod-db"
  multi_az   = true         # 別AZに同期スタンバイを作成
}

RDSのマルチAZは「読み取り分散」のためのものではなく、スタンバイには通常アクセスできません。読み取りを分散したい場合は別途リードレプリカを作ります。この違いはデータベースレプリケーション入門で詳しく説明しています。

トラブル事例：マルチAZのはずが片方のAZ障害で全停止

症状：ALBとアプリ2台をマルチAZに配置していたが、あるAZの障害時にサービス全体が停止した。

原因：アプリがアップロードファイルを保存するEFSではなく、1台のEC2上で動かしていたNFSサーバーに依存しており、そのEC2が障害AZにあった。さらに、NATゲートウェイも1つのAZにしか置いておらず、もう一方のAZのアプリは外部APIへ出られなくなっていた。LB・アプリ・DBは正しく分散していたが、「共有ストレージ」と「外向き通信の経路」がAZに縛られていた。

対処：ファイル保存先をS3（またはEFS）に移行し、NATゲートウェイを各AZに1つずつ配置してルートテーブルをAZごとに分けた。教訓は、「アプリが依存しているものすべて」について、それがどのAZに存在するかを洗い出す必要がある、ということです。

マルチリージョンが必要になる条件と難しさ

まずマルチAZで足りるかを疑う

マルチAZで防げるのはAZ単位の障害までです。リージョン全体に影響する障害（制御系の障害、広域災害など）は頻度こそ低いものの、実際に発生しています。とはいえ、マルチリージョンは複雑さとコストが桁違いに上がるため、次のいずれかに当てはまる場合に限って検討するのが妥当です。

• リージョン障害による数時間の停止が、事業として許容できない（RTOが1時間未満など）。
• 災害対策として、データを地理的に離れた場所に保持することが規程や契約で求められている。
• 海外の利用者に対して、近いリージョンから配信して遅延を下げたい。

それ以外の多くの場合、マルチAZ＋別リージョンへのバックアップ複製で十分です。RPO・RTOに応じた待機系の段階分けは災害復旧（DR）計画の立て方で解説しています。

難しいのはデータ同期とDNS

マルチリージョンでアプリを複数リージョンに置くこと自体は難しくありません。難しいのは次の2点です。

• データ同期：リージョン間のレプリケーションは非同期になるため、フェイルオーバー時に直近の書き込みが失われる可能性がある。両リージョンで同時に書き込みを受ける構成にすると、同じレコードへの更新が衝突し、どちらを正とするかの解決が必要になる。多くの場合は「書き込みは1リージョンに固定し、他リージョンは読み取りと待機のみ」とするのが現実的。
• DNSとクライアントのキャッシュ：切替はDNSで行うが、TTLとクライアント側のキャッシュにより、全利用者が切り替わるまで時間差が生じる。Route 53のヘルスチェック連動フェイルオーバーで自動化しても、TTL分の遅延は残る。

加えて、リージョン固有のリソース（KMSキー、AMI、ACM証明書、パラメータストアの値など）を両方に用意し、インフラ定義をコード化して同じ構成を両リージョンに再現できる状態が前提になります。

東京・大阪リージョンの使い分け

国内2リージョンをどう組み合わせるか

国内で完結させたい場合、東京と大阪の組み合わせが基本になります。実務上の使い分けの目安は次のとおりです。

目的	推奨構成	備考
通常のWebサービス	東京でマルチAZ	サービス・インスタンスタイプの選択肢が最も多い
災害対策（データ保全）	東京本番＋大阪へバックアップ複製	低コストで地理的分散を確保
災害対策（短時間で復旧）	東京本番＋大阪にパイロットライト/ウォームスタンバイ	DBのクロスリージョンレプリカ＋DNS切替
西日本の利用者が多い社内システム	大阪を本番にすることも検討	ただし提供サービスに差がないか事前確認

大阪リージョンは東京より後に一般提供されたため、一部のサービスやインスタンスタイプが利用できない、あるいは提供開始が遅れる場合があります。マルチリージョン構成を組む前に、本番で使うすべてのサービスが大阪でも利用可能かを必ず確認してください。

まとめ

リージョン・AZ・データセンターは障害の影響範囲の単位であり、冗長化とは同じ単位に全部を置かないことです。マルチAZの基本形は、LBに複数AZのサブネットを指定し、アプリをAZ数の倍数で均等配置し、DBはマルチAZでスタンバイを持つ構成で、AZ間の遅延と転送料はその保険料として扱います。ただし共有ストレージやNATゲートウェイのように「AZに縛られた依存先」を見落とすと、マルチAZの意味がなくなります。マルチリージョンはデータ同期とDNSの難しさを伴うため、RTOや規程上の要件がある場合に限り、まずは大阪へのバックアップ複製やパイロットライトから段階的に検討するのが現実的です。

まずは自社の本番環境について、LB・アプリ・DB・ストレージ・NATがそれぞれどのAZにあるかを一覧にしてみてください。AZ障害に耐えられる配置設計やリージョン戦略の検討にお困りの際は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。