この記事は freee Developers Advent Calendar 2025 12/24 (24日目) の記事です。
こんにちは。今日はクリスマスイブですね 🎄
SRE の min です
今年は 10 月に AWS で大きめの障害がありました
普段当たり前に使える AWS リソースがいきなり使えなくなる体験をして私は思いました
「災害とか起きたらどうなるんだろう？」
今まで Route53 は Route53 としてみていたし、Aurora は Aurora としてみていましたが、
今回はより解像度を上げて物理的にはどうなるの？と思いを馳せてみたくなったので筆を取りました
AWS の実リソースがどこにあるのか忘れがち
実務で Terraform やマネジメントコンソールを触ることがありますが、
実リソースの物理的な場所まで考えることは、（私は）あまりないです
改めて図示してみようという記事です
※ 具体的な場所は公開されてないので、大体こんな感じなんだーと雰囲気を感じていただければと思います
「東京からちょっとズレてる」とか、「設定によっては別の配置もできる」などあるかもしれませんが、
ファミチキとか食べながらぼーっと眺めたり思い出していただくくらいの想定で書いております
図示のために決め打ちする部分もありながら作図していますのでそこはご容赦ください🙏
ネットワークまわり
Route 53 , CloudFront + S3 , ALB について図示します
Route 53
- DNS の応答は世界中にあるエッジロケーション（権威 DNS サーバー）から返ってくる
- レコードの追加・変更などの管理操作は us-east-1 に集約されていて、操作を受けてエッジロケーションに伝達される。
- 2025年10月の DynamoDB の障害では、us-east-1 の DNS 管理側の問題でレコードが空になっていた。
Route53 の物理配置イメージ
CloudFront + S3
- CloudFront のエッジロケーションは世界中に 700 箇所以上あり、ユーザーに近い場所からキャッシュを配信する
- まずエッジにアクセスし、キャッシュがなければリージョナルエッジを見にいき、そこにもキャッシュがなければ S3 を見に行く
- オリジンの S3 は東京リージョンなら 3AZ 以上に自動複製されている
ちなみに CloudFront の管理操作や、S3 のバケット作成・削除は us-east-1 に依存しています
ACM 証明書を CloudFront に紐づけるとき us-east-1 で作る必要があるのもこの辺の事情が関係しています
（ CloudFront で SSL/TLS 証明書を使用するための要件 , ハマりポイントですよね）
ALB
- ALB は論理的には 1つだが、実際には選択した各 AZ に ALBノード（ENI）が配置されている
- DNS 名を引くと各 AZ の IP が返り、クライアントはラウンドロビンで選ばれた接続先のある AZ にアクセスする
アプリケーションまわり
EKS について図示します
EKS
- EKS のコントロールプレーン（API Server, etcd）は AWS が管理する VPC 内にある
- 我々が AWS で作成した VPC にある ワーカーノード と AWS が管理するコントロールプレーンは VPC を跨いで通信している
- 1AZ 障害なら継続稼働するが、2AZ 同時障害ではコントロールプレーンが機能しなくなる。コントロールプレーンが落ちると kubectl の操作ができなくなるが、既存の Pod は動き続ける
データまわり
Aurora , ElastiCache , DynamoDB について図示します
Aurora
- Auroraはコンピュート層とストレージ層で分かれている
- ストレージは 3AZ に分散して、各AZ に 2コピーずつ、計 6コピー保持している
- データの分散により、AZ で見ると、1AZ までなら耐えられる設計になっている
（3箇所全てに同じコピーがあるなら 2AZ まで耐えられそう! ...と思いませんか、私は思いました。しかしクオーラムという考えで最新データ取得のために多数決をするので 4コピーは必要で 2AZ は耐えられないそうです。 クロスリージョンスナップショットや Global Database などが対策としてあります）
ElastiCache (Redis / Valkey)
- 全データを16,384分割（ハッシュスロット）し、複数シャードで分担処理する。（図では shard1 ~ shard3）
- シャード毎の Primary / Replica を 別AZ に配置。AZ 障害時は自動で切り替わる
- Valkeyもアーキテクチャや物理配置の考え方は同様で、金銭的なコストが安い
※ シャードの配置は構成例です。設計者の意図によって3AZでない場合もあります
この図の構成だと、耐えられるのは Primary or Replica いずれかで shard1~3 がある、1AZ 障害まで。
DynamoDB
- データはパーティション分割され、3つの AZ に常に同期保存される（ 1AZ 障害は許容）
- 我々がアクセスする際は、Request Router が、パーティションの Leader（書き込み担当） へ誘導する。
- 1AZ 障害まで耐えられる。2025年10月障害では、DNS レコード消失によりデータは無事でも名前解決できず、アクセスできない事態となった
（おわり）
明日は、いよいよクリスマス 🎅
アドベントカレンダーのラストは JaeSoon さんです！ お楽しみに。
読者のみなさんにとって素敵なクリスマスになりますように。
