はじめに
本書の目的
本ドキュメントは、AWS（Amazon Web Services）におけるアベイラビリティゾーン（AZ）について、基礎から実践まで分かりやすく説明することを目的としています。専門用語は最小限に抑え、具体例を交えて理解しやすくまとめます。
本書で学べること
- AZの基本的な考え方と役割
- AWSインフラの階層構造とAZの位置づけ
- AZの物理的特性と冗長化の考え方
- マルチAZ構成の利点と実装のヒント
各章で実例や図的イメージを交え、実務で使える知識を提供します。
想定読者
クラウド導入を検討中のエンジニア、運用担当者、または初めてAWSを学ぶ方を主な対象とします。ITに詳しくない方でも、例を通して理解できるよう配慮しています。
読み方のポイント
まずは全体像を把握してください。次に、実装や運用に関する章に進むと実務に役立ちます。疑問点が出た場合は、具体例と照らし合わせて読み返すと理解が深まります。
AWS アベイラビリティゾーン（AZ）とは？わかりやすく解説
概要
アベイラビリティゾーン（AZ）は、複数のデータセンターが集まった“1つのまとまり”です。リージョンの中に複数のAZがあり、それぞれ物理的に分かれています。障害や停電が起きても別のAZに影響が及びにくいように設計されています。
仕組み（簡単に）
同じAZ内のデータセンターは高速ネットワークで結ばれ、あたかも1つの場所のように使えます。一方で、別のAZとは独立した電源や建物、ネットワーク経路を持ちます。これにより、単一障害点を避けられます。
具体例（イメージ）
例えばウェブサーバーをAZ-AとAZ-Bに分けて配置すると、AZ-Aが止まってもAZ-Bが処理を続けられます。データベースのレプリカを別AZに置く運用も多いです。
利用上のポイント
- 可用性を高めるには複数AZを使う
- レイテンシーは同一AZ内が最も低い
- コストや運用の複雑さも考慮する必要があります
この章では、まずAZの基本的な考え方を押さえました。次章でAZの階層構造を詳しく見ていきます。
AWSインフラストラクチャにおけるAZの階層構造
リージョン（地理的エリア）
リージョンは大きな地理的な区切りです。たとえば「東京リージョン」は日本に近い拠点を指します。リージョン内ではデータの配置先や法的要件を決めやすくなります。
アベイラビリティゾーン（AZ）
AZはリージョンの中にある、独立性の高い論理単位です。物理的には複数のデータセンターで構成され、電源や通信経路が分離されています。これにより、あるAZで障害が起きても他のAZに影響を与えにくくなります。
データセンター（物理施設）
データセンターはサーバーやネットワーク機器が置かれた実際の建物です。AZは通常、複数のデータセンターをまとめた単位で、運用や設備の冗長化を図ります。
階層のイメージ例
リージョン（東京）
├─ AZ-A（データセンター群）
└─ AZ-B（別のデータセンター群）
設計時のポイント
・可用性を高めたい場合は複数のAZに分散します。
・レイテンシーを抑えたい場合は同じリージョン内でAZを選びます。
・コストや運用性も考えて最適な構成を決めます。
図を思い浮かべると、リージョン→AZ→データセンターの順で小さくなっていく階層構造が分かりやすいです。
アベイラビリティゾーンの物理的特性
概要
アベイラビリティゾーン（AZ）は、地理的に分離されたデータセンター群として設計されます。自然災害や電力・通信の障害が一つのゾーンに波及しにくい点が特徴です。
地理的分離と災害対策
AZ同士は独立した場所にあり、最大で約100kmまで離れていることがあります。この距離をとることで、地震や洪水などの被害が同時に発生する可能性を下げます。一方で、ゾーン間は高速な専用回線で結ばれ、遅延は通常2ms以下になるよう設計されています。
電源と空調の独立性
各AZは別々の電力供給経路を持ち、無停電電源装置（UPS）や非常用発電機を備えます。空調設備もゾーンごとに分かれており、片方で設備故障が起きても他方に影響しにくい構成です。たとえば一つのゾーンが停電しても、別のゾーンは通常通り稼働できます。
ネットワークの冗長化
ネットワークは複数経路で冗長化され、光ファイバーなど高速回線で接続されます。この冗長化により通信の安定性が高まり、データベースのレプリケーションやロードバランサの動作がスムーズになります。遅延が小さいため、同期レプリケーションも現実的です。
運用上の注意点
アプリケーションを設計するときは、AZごとの独立性を前提に冗長化を組み込むと可用性が向上します。特に遅延に敏感な処理は、同一リージョン内の近いAZを利用する方が有利です。定期的なフェイルオーバー試験で実際の障害時挙動を確認することも大切です。
Transit Centerの役割
Transit Centerとは
Transit Centerは、アベイラビリティゾーン（AZ）と外部ネットワークをつなぐ中継点です。データセンター同士の大きな道路のように働き、トラフィックを集約して振り分けます。
主要な役割
- 接続の集約：各AZからの通信を一元的に受け取り、他のリージョンやインターネットへ送ります。具体例として、Webサーバーの応答が別リージョンのデータベースへ向かうとき、Transit Centerが経路管理を行います。
- ルーティングとフィルタリング：適切な経路へ誘導し、不要なトラフィックを遮断します。これにより遅延や混雑を減らせます。
- 冗長経路の提供：各AZは最低2つのTransit Centerに接続します。片方が障害でも他方が機能し続けるため、サービスの継続性が高まります。
冗長化と接続性
Transit Center自体も冗長化されています。複数の物理設備と光ファイバー経路でつながり、障害時は自動的に代替経路へ切り替わります。これにより、リージョン間通信やインターネット接続が安定します。
運用上の注意点
- 帯域設計：想定するトラフィック量に合わせて冗長帯域を確保してください。負荷が集中すると切替時に遅延が増すことがあります。
- セキュリティ：Transit Centerでのルール設定は重要です。不要な公開経路は遮断し、監視ログを有効にしてください。
以上がTransit Centerの主な役割です。適切に設計・運用することで、AZ間や外部との通信の信頼性が大きく向上します。
アベイラビリティゾーンの数と配置
概要
1つのリージョンは複数のアベイラビリティゾーン（AZ）で構成されます。日本では東京リージョンや大阪リージョンがあり、それぞれ複数のAZを備えています。AZの具体的なデータセンター位置はセキュリティ上公開されていません。
AZの数の目安
一般にリージョンごとのAZ数は2〜6個程度で、サービスや成長に応じて増減します。設計上は複数AZを使うことを前提にすることが多く、冗長性を確保するために少なくとも2つ、より高可用性を求める場合は3つ以上を推奨します。
配置の考え方
AZ同士は地理的に分散されますが、同一リージョン内で低遅延で接続されるよう設計されています。これにより、単一の設備障害や停電が発生しても他のAZでサービスを継続できます。同時に、AZ名（例: ap-northeast-1a）はアカウントごとに割り当てが異なるため、名前だけで物理場所を判断しないでください。
実務上の注意点
- データ転送やレプリケーションの遅延とコストを考慮してAZ間設計を行ってください。
- 地理的な災害対策が必要な場合は、同一国内の別リージョン（例: 東京と大阪）も検討します。
- 具体的な設置場所は公開されないため、運用は公開情報とサービスのSLAを基準に行ってください。
アベイラビリティゾーンのメリット
複数のアベイラビリティゾーン（AZ）を使うと、システムの耐障害性や可用性を簡単に高められます。ここでは主なメリットを具体例を交えて分かりやすく説明します。
1. 障害影響の限定（フォールトトレランス）
- AZごとに物理的に独立した設備があるため、あるAZで電源やネットワーク障害が起きても、他のAZでサービスを継続できます。
- 例：Webサーバーを3つのAZに分散していれば、1つが落ちても残りで応答できます。
2. 高可用性の実現
- 負荷分散（例：ロードバランサ）と組み合わせると、障害発生時に自動でトラフィックを健全なAZに振り分けます。
- 例：Eコマースサイトで注文処理を継続でき、ユーザー体験を保てます。
3. メンテナンス時のダウンタイム削減
- ロールアウトやパッチ適用をAZ単位で順次行えば、全体停止を避けられます。
- 例：1つのAZだけを順に更新していく運用が可能です。
4. スケーラビリティと負荷分散
- トラフィック増加時に別のAZへインスタンスを追加して負荷を分散できます。
- 例：キャンペーン時に一部のAZで台数を増やして対応します。
5. データ保護とバックアップ運用
- AZ間レプリケーションでデータを複製し、単一障害点を回避します。
- 例：データベースの同期コピーを別AZに置く運用。
6. 運用の柔軟性とコスト管理
- 必要に応じてAZ数を増減し、可用性とコストのバランスを取れます。小規模環境では2AZ、大規模では3AZ以上を検討します。
これらのメリットにより、AZを活用すると短期間で信頼性の高いシステムを作りやすくなります。
マルチAZ構成の実装例
概要
3層（プレゼンテーション、アプリケーション、データベース）を複数のAZに分散して配置します。外部からはロードバランサーを経由し、各AZのインスタンスへ振り分けます。可用性を高めつつ、運用負荷を抑えます。
配置例（具体例）
- プレゼンテーション層: ALB（Application Load Balancer）を専用AZに配置し、各AZのEC2 Auto Scalingグループへトラフィックを振る
- アプリケーション層: 複数AZにEC2またはコンテナ（ECS/EKS）を配置し、ステートレスに設計
- データベース層: RDS（マルチAZ有効）のプライマリとスタンバイを別AZに配置
フェイルオーバーと同期
RDSは自動フェイルオーバーを行います。アプリ層はセッション情報をElastiCacheやDynamoDBに置き、どのAZでも同じ処理が可能にします。
運用のポイント
- ヘルスチェックをALBと各アプリで適切に設定
- デプロイはローリングやブルー/グリーンでAZ間の影響を小さくする
- 期限付きのバックアップや監視アラートを確実に設定
注意点
ネットワーク遅延やクロスAZ通信コストを考慮し、同期やデータ設計を最適化してください。
シングルAZとマルチAZの違い
概要
同一リージョン内のAZ（アベイラビリティゾーン）はサービス仕様や基本料金が同じです。ただし、物理的に離れて配置されています。単一のAZに資源を置く「シングルAZ」と、複数のAZに分散する「マルチAZ」では、耐障害性や可用性に違いが出ます。
技術的な違い（わかりやすく）
- シングルAZ：すべてのリソースが同じデータセンター群内にあります。構成は単純で運用が楽です。開発環境やコスト重視の用途に向きます。
- マルチAZ：同じリージョン内の別AZに冗長構成を置きます。データの自動レプリケーションやフェイルオーバー機能を使い、障害時に別AZへ切り替えます。サービス停止時間を短くできます。
メリット・デメリット（簡潔に）
- マルチAZの利点：可用性が高く、単一障害点を避けられます。メンテナンス時も影響を抑えやすいです。短時間の障害に強い構成を作れます。
- マルチAZの留意点：設計と運用が複雑になります。クロスAZ通信でデータ転送費用が発生する場合があります。
いつどちらを選ぶか
- シングルAZが適する場合：開発検証環境、短期間のプロトタイプ、厳密な可用性が不要なケース。
- マルチAZが必要な場合：本番サービス、ダウンタイムの影響が大きい業務、SLAを満たす必要がある場面。
実例
- RDSのマルチAZ：自動的に同期的な待機インスタンスを別AZに配置し、障害時に自動フェイルオーバーします。
- EC2＋ALBでの分散：複数AZにEC2を配置し、負荷分散でトラフィックを分けることで可用性を高めます。
注意点
マルチAZは万能ではありません。設計を誤ると運用コストや遅延が増えます。要件（可用性、コスト、性能）を明確にして選択してください。
冗長性・信頼性・可用性の確保
概要
AWSのアベイラビリティゾーン（AZ）は、複数のデータセンターで構成され、電力やネットワークを冗長化して相互に接続されています。これにより単一障害点を避け、サービスの停止リスクを下げます。
冗長性の仕組み
具体例で説明します。Webサーバーを2つのAZに配置し、ロードバランサーで振り分けると、片方のAZが停止してももう片方で処理を続けられます。データベースは自動レプリケーション（例：RDSのマルチAZ）で同期し、フェイルオーバーを素早く行います。
可用性を高める設計例
- 複数AZに資源を分散する（サーバー、ストレージ、キャッシュ）
- 負荷分散とヘルスチェックを組み合わせる
- 定期的なバックアップとスナップショットを取得する
運用と確認
障害時の挙動を定期的に想定してテストします。フェイルオーバー手順や復旧時間（RTO）、データ損失許容度（RPO）を明確にしておくと実運用で安心です。
注意点
AZ間の通信は通常低遅延ですが、設計次第でコストや応答性に影響します。どの部分を冗長化するか、コストと効果を見比べて決めてください。
