マルチリージョンとCloudFront｜基礎を学ぶ

このレッスンでできるようになること。世界中の利用者へ配る要件と災害対策の要件を切り分け、CloudFront、Global Accelerator、マルチリージョン構成のどれを当てるかを選べるようになります。

要件の文から入る

ある会社が、S3 に置いた画像と動画を世界中の利用者へ配信しています。要件は次の2つです。「海外からの表示が遅いので改善したい」「S3 バケットを公開せず、CloudFront を経由したアクセスだけを許可したい」。何を設定しますか。

前半は素直に CloudFront です。静的なコンテンツを世界のエッジロケーションにキャッシュして、利用者に近い場所から返します。問題は後半で、ここが定番の出題です。答えは OAC (オリジンアクセスコントロール) です。CloudFront ディストリビューションに OAC を設定し、S3 のバケットポリシーで「この OAC を持つ CloudFront からのアクセスだけを許可する」と書き、パブリックアクセスブロックは有効のままにします。これで S3 の URL を直接叩いても届かず、CloudFront 経由だけが通ります。

古い教材では OAI (オリジンアクセスアイデンティティ) が同じ役割で説明されますが、現在の推奨は OAC です。

CloudFront と Global Accelerator の線引き

ここが第8章で最も間違えやすい対比です。どちらも「AWS のグローバルネットワークを使って利用者体験を速くする」ため、要件文をよく読まないと選べません。

観点	CloudFront	Global Accelerator
何をするか	コンテンツをエッジにキャッシュして、そこから返す	利用者から最寄りのエッジで AWS 網に入れ、最適な経路で正常なエンドポイントへ運ぶ
対象のプロトコル	HTTP と HTTPS	TCP と UDP。HTTP 以外も含む
キャッシュ	する	しない
利用者に見える宛先	ディストリビューションのドメイン名	固定の静的 IP アドレス
切り替えの速さ	オリジン側のフェイルオーバー設定に従う	ヘルスチェックに基づき、DNS のキャッシュに影響されずに経路を切り替えられる
向いている要件	画像・動画・静的サイト・API のキャッシュ配信	ゲームや音声のような非 HTTP、固定 IP が要る、即時のリージョン切り替え

一文でまとめます。キャッシュできる HTTP のコンテンツを速く配るのが CloudFront、キャッシュできない TCP や UDP の経路を最適化して素早く寄せ替えるのが Global Accelerator です。「UDP」「固定 IP をファイアウォールに登録したい」「DNS のキャッシュに左右されず切り替えたい」なら Global Accelerator、「静的コンテンツ」「オリジンの負荷を下げたい」なら CloudFront です。

マルチリージョンの配り方

災害対策としてリージョンを2つ使う場合、前段に何を置くかで挙動が変わります。

前段	挙動	向いている要件
Route 53 のフェイルオーバー	DNS の応答を切り替える	DNS の切り替え時間を許容できる一般的な Web
CloudFront のオリジンフェイルオーバー	オリジングループを作り、1つ目が失敗したら2つ目のオリジンへ	配信面は同じまま、背後のオリジンだけ切り替えたい
Global Accelerator	エンドポイントグループの重みと正常性で経路を切り替える	切り替えの即時性が要る、非 HTTP を含む

データ層も忘れずに揃えます。S3 はクロスリージョンレプリケーション、DynamoDB はグローバルテーブル、Aurora はグローバルデータベースが対応します。前段の振り分けだけ作ってデータを複製し忘れた構成は、選択肢としてよく紛れ込みます。

要件語から構成への対応表

要件文の言い回し	選ぶもの
世界中で画像や動画の表示を速くしたい	CloudFront
S3 を公開せず CloudFront 経由だけ許可	OAC とバケットポリシー。パブリックアクセスブロックは有効のまま
UDP を使うアプリの遅延を減らしたい	Global Accelerator
ファイアウォールに登録できる固定 IP が要る	Global Accelerator
DNS のキャッシュに左右されずリージョンを切り替えたい	Global Accelerator
オリジンが落ちたら別リージョンのオリジンへ	CloudFront のオリジンフェイルオーバー
オリジンへの同時アクセスを減らしたい	CloudFront のキャッシュ
特定の国からのアクセスを遮断したい	CloudFront の地理的制限

よくある引っ掛け

1つめは、S3 の保護をバケットポリシーの IP 制限で答えてしまうものです。エッジの送信元アドレスの範囲は変わり得るため、管理し続ける前提の構成になります。OAC が正解のところで選ぶと落とします。

2つめは、非 HTTP の要件に CloudFront を当ててしまうものです。UDP を使うゲームや音声の遅延改善は CloudFront の担当ではありません。プロトコルが書かれていたら必ず読み取ります。

3つめは、CloudFront を災害対策そのものと読んでしまうものです。CloudFront はキャッシュと配信の層なので、オリジンが1つしかなければオリジン障害には耐えられません。オリジングループか背後のマルチリージョン構成まで含めて答えます。

まとめ

CloudFront は HTTP のキャッシュ配信、Global Accelerator は TCP と UDP の経路最適化です
S3 を隠して CloudFront 経由だけ通すのは OAC とバケットポリシーの組み合わせです
固定 IP、非 HTTP、DNS に依存しない即時切り替えは Global Accelerator の要件語です
マルチリージョンは前段の振り分けとデータの複製を必ず一組で設計します
CloudFront だけでは災害対策になりません。オリジン側の冗長化まで見ます