AWS 02：リージョンと AZ ― どこに置き、どう分けるか

まず、サーバーは「データセンター」の中にある

クラウドと聞くと、雲の上にある実体のないものを想像するかもしれません。でも実際には、AWS のサーバーは地上の建物の中にあります。この建物をデータセンターと呼びます。

データセンターは、サーバーを何万台も置くために作られた専用の建物です。

第0章の「オンプレミス」で、自分たちでこれを全部用意するのは大変だという話をしました。AWS はこれを世界中に持っていて、あなたはその一部を借ります。

ただし、どれだけ立派なデータセンターでも、建物が1つなら、その建物ごと止まることがあります。広い範囲の停電、火災や浸水、建物につながる回線の切断などです。確率は低くても、ゼロにはできません。

では、建物が1つ止まってもサービスを続けるには、どうすればよいでしょうか。答えは単純で、離れた別の建物にも置いておくことです。AWS はこの考え方を、次の「AZ」という単位で用意しています。

建物をまとめた単位が「アベイラビリティゾーン（AZ）」

アベイラビリティゾーン（Availability Zone、略して AZ）は、1つ以上のデータセンターをまとめた単位です。図では、左の大きな建物が縮んで AZ a の中に入りました。

AZ の大事な性質は、次のとおりです。

「離れているのに 100 km 以内」には理由があります。離すほど災害に強くなりますが、離しすぎると AZ 間の通信に時間がかかります。同時に被災しにくく、それでいて AZ をまたいでもほとんど遅くならない距離に置かれているのです。

そのおかげで、あなたは「サーバーを AZ a と AZ c に1台ずつ置く」という作り方ができます。2台は別の建物群にありながら、同じ場所にあるのとほとんど変わらない速さで連携できます。

なお「アベイラビリティ」は「使える状態であること（可用性）」という意味です。「使える状態を保つための区画」と覚えるとよいでしょう。

AZ を3つ以上まとめた地域が「リージョン」

AZ をさらにまとめた、地理的な地域をリージョンと呼びます。図の灰色の大きな囲みが、東京リージョンです。

どのリージョンにも、AZ が3つ以上あります。東京リージョンには4つの AZ があります。

つまり、データセンター ⊂ AZ ⊂ リージョンという入れ子の関係です。

あなたが AWS で何かを作るとき、選ぶのは「リージョン」と、場合によっては「AZ」です。個々のデータセンターを選ぶことはありません。どの建物のどの棚に置くかは、AWS が決めます。

コンソール右上の「東京」は、このリージョンを選ぶ場所だったのです。東京を選んだ状態でサーバーを作ると、東京リージョンの中のどれかの AZ にサーバーが作られます。どの AZ にするかは、作るときに自分で指定できます（第6章でサブネットを AZ ごとに作るときに出てきます）。

リージョンは世界に39か所ある

2026年時点で、AWS のリージョンは世界に39か所、AZ は合わせて124あります。図はその一部です。数は毎年のように増えています。

日本には2つのリージョンがあります。

リージョンがたくさんあるのは、世界中の利用者の近くにサーバーを置けるようにするためと、国や地域ごとの決まりごと（データをその国に置くこと、など）に応えるためです。

また、少し特殊なリージョンもあります。たとえば米国政府向けの専用リージョンや、中国のリージョンは、ふつうのアカウントからは使えません。この本では扱いません。

もう1つ知っておくとよいのが、2019年3月20日より後にできたリージョンは、アカウントで「有効化」するまで使えないことです（オプトインリージョンと呼びます）。東京や大阪は最初から使えます。新しいリージョンを使いたくなったら、アカウントの設定から有効にします。

最新のリージョンの一覧は、公式の「AWS グローバルインフラストラクチャ」のページで確認できます。

名前の読み方：リージョンコードと AZ

画面では「アジアパシフィック（東京）」と表示されますが、CLI や設定ファイルでは リージョンコードという短い名前を使います。東京は ap-northeast-1 です。

米国東部のバージニア北部は us-east-1、欧州のフランクフルトは eu-central-1 という具合です。

AZ の名前は、リージョンコードの後ろにアルファベットを1文字付けたものです。東京なら ap-northeast-1a、ap-northeast-1c、ap-northeast-1d などです。

ここに1つ注意があります。古いアカウントでは、AZ の名前と実際の場所の対応がアカウントごとに違うことがあります。あなたの 1a と、別のアカウントの 1a が別の建物群を指している、ということが起こりえます（利用者が特定の AZ に集中しないよう、昔はそのように割り当てていました）。2025年11月以降に作ったアカウントは、同じ名前が同じ場所を指します。

アカウントをまたいで「同じ場所」を指したいときは、AZ ID（apne1-az1 のような名前）を使います。AZ ID は、どのアカウントでも同じ場所を指します。図の右の対応は一例で、実際の対応は後で紹介する CLI の命令で確かめられます。

1つの AZ だけに置くと、その AZ と運命を共にする

さて、リージョンと AZ の関係がわかったところで、この章でいちばん大事な考え方です。

図では、東京リージョンの AZ a と AZ d に、サーバーを1台ずつ置いています。

もしサーバーを AZ a に2台置いたら、どうなるでしょうか。台数は同じ2台でも、AZ a が止まったとき、2台とも一緒に止まります。同じ建物群にあるので、停電や回線の障害を一緒に受けるからです。

AWS は、「AZ の障害は起こりうる」という前提に立っています。だから、大事なサービスは最低2つの AZ に分けて置くことを勧めています。これをマルチ AZと呼びます。

真ん中の AZ c は空いています。3つめの AZ は、台数を増やすときや、2つのうち1つが止まったときの置き場所として使えます。

この「壊れる前提で、分けて置く」という考え方は、この本で何度も出てきます。サーバー（第11・12章）、データベース（第13章）、そして災害対策（第29章）でも、形を変えて同じ発想を使います。

AZ a が止まった：それでもサービスは続く

AZ a で大規模な停電が起き、AZ a の中のサーバー A に届かなくなったとします。

このとき、AZ d のサーバー B は、別の電源・冷房・回線で動いているので影響を受けません。利用者からのリクエスト（「このページを見せて」という求め）は、サーバー B が受け続けます。利用者から見れば、何も起きていないのと同じです。

ただし、これを実現するには、まだ足りない部品があります。

サーバーを別々の AZ に置いただけでは、利用者は相変わらずサーバー A の住所にアクセスしてしまいます。「どちらに送るか」を決める入口が要るのです。これは第11章の困りごとにつながります。

また、実際の AZ 障害は、「完全に止まる」だけでなく「一部だけ遅い」「一部の機能だけ動かない」という形で起きることもあります。第17章の監視で、そうした症状に気づく方法を扱います。

リージョンどうしは独立している

AZ が「近くの別の建物群」だったのに対し、リージョンどうしは完全に独立しています。

東京リージョンで作ったサーバーやデータは、東京リージョンの中だけにあります。コンソールの右上をバージニア北部に切り替えると、東京で作ったサーバーは一覧に出てきません。図の右がその状態です。

第1章の落とし穴「作ったものが消えた」の多くは、これです。慌てる前に、右上のリージョンを確かめてください。

リージョンが独立しているのは、障害をそのリージョンの中に閉じ込めるためです。東京リージョンで大きな問題が起きても、他のリージョンは影響を受けないように作られています。

逆に言えば、東京リージョン全体が使えなくなるような大災害に備えたいなら、大阪など別のリージョンにデータを写しておく必要があります。どこまで備えるかは、第29章で詳しく考えます。

リージョンの選び方：4つの問い

では、どのリージョンを選べばよいのでしょうか。次の4つの問いで考えます。

順番が大事です。① と ② を先に決め、③ と ④ で確かめるのがよいでしょう。

① と ② は、後から変えるのがとても大変です。リージョンを引っ越すには、サーバーもデータも全部写し直す必要があるからです。一方、③ の料金差は、多くの場合それほど大きくありません。

④ は見落としがちです。AWS の新しいサービスや機能は、米国のリージョンから始まり、順に広がることがよくあります。使いたい機能があるなら、作る前に公式の「リージョン別の AWS サービス」の一覧で確かめてください。

日本の利用者向けのサービスなら、ほとんどの場合、答えは東京になります。

距離は速さに効く：光でも往復に時間がかかる

「近いほうが速い」について、もう少し詳しく見ておきます。

インターネットの通信は、光ファイバーの中を光（に近い速さの信号）で進みます。光は速いですが、無限に速いわけではありません。しかも、ケーブルは地球をまっすぐ貫いているわけではなく、海底や陸を回り道しています。

0.1秒なら気にならない、と思うかもしれません。でも、1つの画面を表示するのに、ブラウザは HTML・画像・データなどを取りに何十回も往復することがあります。1回0.1秒の遅れが何十回も重なると、利用者ははっきり「遅い」と感じます。

この遅れをレイテンシ（遅延）と呼びます。サーバーの性能をいくら上げても、距離によるレイテンシは縮みません。だから、利用者の近くにサーバーを置くことが大切なのです。

世界中に利用者がいる場合は、画像などを利用者の近くから配る CloudFront（第15章）を組み合わせます。

リージョンを選ばない「グローバル」なサービスもある

ほとんどの AWS のサービスはリージョンごとに分かれていますが、いくつかのサービスはグローバル、つまり全リージョン共通で1つです。

たとえば IAM で作った許可は、東京でもバージニア北部でも同じように効きます。コンソールで IAM を開くと、右上のリージョンが「グローバル」と表示されます。

一方、図の右のように、サーバー（EC2）・ネットワーク（VPC）・データベース（RDS）などはリージョンごとです。ファイル置き場の S3 は少し特殊で、置き場の名前は世界で1つだけしか使えませんが、中身は選んだリージョンに保存されます。

そして、覚えておくべき例外があります。CloudFront で HTTPS を使うための証明書は、必ずバージニア北部（us-east-1）で作る決まりです。CloudFront がグローバルなサービスで、その設定の置き場がバージニア北部にあるためです。第14・15章で「東京で作ったのに選べない」とならないよう、頭の片隅に置いておいてください。

フォトログは東京リージョン、2つの AZ で始める

フォトログの利用者は日本にいます。4つの問いに答えてみます。

結論は東京リージョン（ap-northeast-1）です。大阪より AZ が多く、対応しているサービスも多いことも理由です。

そして最初から、2つの AZ（a と c）を使う前提で設計します。第9章ではサーバー1台から始めますが、ネットワーク（第5・6章）の段階で AZ を2つ用意しておけば、第11章でサーバーを2台に、第13章で DB の予備を置くときに、作り直さずに済みます。

大阪リージョンは、東京全体が使えなくなるような災害への備えの候補として、第29章で検討します。バージニア北部には、第14・15章で CloudFront 用の証明書だけを置く予定です。

それ以外のリージョンには、何も作りません。使わない場所に何かがあれば、それは消し忘れか、乗っ取りの跡です。

確かめ方：画面と CLI でリージョンを見る

どのリージョンを操作しているかは、入口ごとに決まり方が違います。

図の左の上の命令は、東京リージョンの AZ の名前と AZ ID の対応を一覧します。--query は、結果から見たい項目だけを取り出す指定です。自分のアカウントでの 1a がどの AZ ID なのかを、ここで確かめられます。

下の命令は、第1章で作った CLI のプロファイル photolog-admin の既定のリージョンを東京にします。これで、毎回 --region を付けなくても東京が操作されます。

コンソールでも、作業を始める前に右上のリージョンを見る癖を付けてください。特に、IAM などのグローバルなサービスの画面から別のサービスに移ったとき、リージョンが思わぬところになっていることがあります。

お金：場所によって値段も、運ぶ料金も変わる

この章では何も作らないので、料金はかかりません。ただ、場所の選び方は、この後の料金に効いてきます。

AZ をまたぐ通信に料金がかかるなら、1つの AZ にまとめたほうが安いのでは、と思うかもしれません。たしかに少しは安くなります。でもそれは、AZ が止まったときにサービスごと止まることと引き換えです。AZ をまたぐ通信料は、「止まらない」ための保険料と考えるのがよいでしょう。

具体的な単価は、各サービスの料金ページで、リージョンを選んで確かめてください。料金の考え方そのものは、第4章で詳しく扱います。

よくある落とし穴

リージョンと AZ にまつわる、よくある失敗です。

4つ目は、乗っ取りの発見にもつながります。鍵を盗まれた人が、あなたの普段使わないリージョンで大量のサーバーを動かす、という事件はよくあります。使っていないはずのリージョンに料金が出ていたら、真っ先に疑うべきサインです。

片付け：すべてのリージョンに消し忘れが無いか見る

この章で作ったものはありません。代わりに、「どのリージョンに何があるか」を見渡す方法を覚えておきましょう。リージョンが独立しているということは、見ていないリージョンのものは目に入らないということでもあるからです。

おすすめの習慣は、月に一度、請求の画面でリージョン別の料金を見ることです。フォトログなら、東京と、証明書だけのバージニア北部以外に料金が出ていたら、何かがおかしいと判断できます。

第1章で作った予算の知らせ（AWS Budgets）は、全リージョンの料金を合計して見張っています。どこかのリージョンで消し忘れがあれば、知らせが届きます。その知らせを受けて「どこで増えたか」を調べるときに、これらの道具が役立ちます。