AWS Global Accelerator入門｜CloudFrontとの違い・エニーキャスト経由でグローバルレイテンシを下げる実践ガイド

グローバルに展開するアプリケーションのレイテンシが高くて困っている、あるいは「AWS Global AcceleratorとCloudFrontのどちらを使えばいいか分からない」という相談を受けることが多い。この2つはどちらも「世界中のAWSインフラを使って通信を高速化する」サービスだが、動作するレイヤーが根本的に異なる。

オンプレ時代にWAN最適化アプライアンスを触ったことがある人には、Global Acceleratorの思想はすぐに馴染むはずだ。この記事では、AWS Global AcceleratorをオンプレのWAN最適化との比較で解説し、CloudFrontとの使い分け・設定手順・料金・実務Tipsまで体系的にまとめる。

なぜAWS Global Acceleratorが必要なのか？

インターネットはBGPによる経路制御で動いており、東京のユーザーが北米のAWSリージョンにアクセスする場合、複数のISPやAS（自律システム）をまたいでパケットが届く。経路が長くなるほど遅延が増し、ネットワークの混雑や経路変動でパケットロスや遅延スパイクが起きやすい。

オンプレ時代の対策はMPLS専用線やWAN最適化アプライアンス（Riverbed SteelHeadなど）だった。専用線は安定しているが高コスト。WANアプライアンスは圧縮・重複排除でスループットを改善するが、Webシステムのグローバル展開には限界がある。

AWS Global Acceleratorは、この問題を次のアプローチで解決する。

・エッジロケーションまでの区間のみパブリックインターネットを使う: クライアントから地理的に最も近いAWSエッジロケーション（POP）への接続だけがインターネット経由になる。
・エッジ→宛先リージョンはAWSの内部ネットワーク経由: エッジロケーションから先は、AWSが管理する冗長性の高いグローバルバックボーンネットワークを使って宛先まで届ける。
・結果として遅延と変動が小さくなる: パブリックインターネットを最短区間しか通らないため、レイテンシが安定し、パケットロスが減少する。

特にゲーム・リアルタイム通信・音声・動画ストリーミングのような「パケットロスが体験に直結するシステム」で効果が大きい。

CloudFrontとの違い（最も混乱しやすいポイント）

Global AcceleratorとCloudFrontは「AWSのエッジを使う」という共通点があるため混乱しやすい。最大の違いは動作レイヤーとキャッシュの有無だ。

シンプルに言い換えると、次のように使い分けるとよい。

・CloudFrontを選ぶ場合: WebサイトやAPIのHTTPレスポンスをキャッシュして配信速度を上げたい。静的コンテンツ（画像・JS・CSS）や動画VODを世界中に効率よく配信したい。
・Global Acceleratorを選ぶ場合: キャッシュが効かない動的コンテンツやTCP/UDPアプリの安定性・低レイテンシを向上させたい。ゲームサーバーやIoTデバイスのようにHTTP以外のプロトコルを使う。

HTTPアプリでも「フォームPOSTが主体でキャッシュが効かない」「常に最新データをオリジンから取得する必要がある」場合は、Global Acceleratorが有効なことがある。CloudFrontの詳細はAmazon CloudFront入門の記事も参照してほしい。

エニーキャストIPの仕組み

Global Acceleratorが発行する2つのIPアドレスは「エニーキャスト（Anycast）」と呼ばれる形式を採用している。エニーキャストとは、同一のIPアドレスを複数のネットワーク拠点から同時にBGPアナウンスし、クライアントからのパケットをネットワーク的に最も近い拠点へ自動的にルーティングする技術だ。

オンプレでもルートリフレクターを使ったAnycasting設定は可能だが、グローバル規模で管理するのは相当な手間になる。Global Acceleratorはこれを全自動で提供する。

静的IPが持つ実務上のメリットも大きい。CloudFrontのIPは動的に変動するため、ファイアウォールでIPホワイトリストを管理している環境では対応が難しい。Global Acceleratorなら2つの固定IPをホワイトリストに登録するだけで済む。セキュリティポリシー上、送信元・宛先IPを固定したい金融機関や官公庁のシステムに向いている。

基本的なセットアップ手順

AWSマネジメントコンソールからの設定手順を紹介する。

1. アクセラレーターの作成

AWSコンソールで「Global Accelerator」を開き、「アクセラレーターの作成」をクリックする。

・アクセラレーター名: 任意の名前（例: my-app-accelerator）
・IPアドレスタイプ: IPv4（デフォルト）またはデュアルスタック（IPv4/IPv6）
・IPアドレス: AWSが自動割り当て。必要であれば自分のBYOIPアドレスも利用可能

作成後、2つの静的エニーキャストIPアドレスとDNS名（例: xxxxxxxx.awsglobalaccelerator.com）が払い出される。

2. リスナーの設定

リスナーは受け付けるポートとプロトコルの組み合わせを定義する。

・ポート: 受け付けるポート番号を指定（例: 80、443、複数指定も可）
・プロトコル: TCP または UDP を選択
・クライアントアフィニティ: 「なし」（デフォルト）か「送信元IP」を選択。ゲームや音声通話のようにセッション中は同一バックエンドへ固定したい場合は「送信元IP」を使う

3. エンドポイントグループの設定

エンドポイントグループはリージョンごとに作成する。ここでトラフィックを向けるAWSリージョンを指定する。

・リージョン: バックエンドが存在するリージョンを選択（例: ap-northeast-1 東京リージョン、us-east-1 バージニア北部リージョン）
・Traffic Dial（トラフィックダイヤル）: 0～100%でこのエンドポイントグループへ流すトラフィックの割合を指定。段階的な移行やカナリアデプロイに活用できる
・ヘルスチェック設定: プロトコル（TCP/HTTP/HTTPS）、ポート、パス、チェック間隔を設定

4. エンドポイントの追加

各エンドポイントグループ内にトラフィックの宛先（エンドポイント）を追加する。対応するエンドポイントの種類は次のとおり。

# 対応エンドポイントの種類
# ・Application Load Balancer（ALB）
# ・Network Load Balancer（NLB）
# ・Amazon EC2インスタンス（Elastic IP付き）
# ・Elastic IPアドレス

# 例: ALBをエンドポイントに設定する場合
# エンドポイントID: ALBのARNを指定
# 重みづけ（Weight）: 0～255で設定（複数エンドポイント間のトラフィック分散比率）
# クライアントIPアドレスの保持: 有効にするとALBのアクセスログで実際のクライアントIPを確認できる

ALBをエンドポイントにする構成が最も一般的だ。ALBの詳細についてはAWS ELB入門（ALB/NLB/CLB）の記事を参考にしてほしい。

料金の仕組み（コスト感覚）

AWS Global Acceleratorの料金は「アクセラレーター固定料金」と「データ転送プレミアム（DT-Premium）」の2本立てだ。

アクセラレーター固定料金

アクセラレーターが稼働している時間に対して時間単位で課金される（2026年7月時点の参考値: 約$0.025/時間）。月換算では約$18程度になる。アクセラレーターを削除しない限り稼働時間に応じて発生し続けるため、テスト後の削除忘れに注意すること。

データ転送プレミアム（DT-Premium）

通常のデータ転送料金に加えて、Global Acceleratorを経由したことによるプレミアム料金が加算される。エッジロケーションとリージョン間の距離・トラフィックの方向（受信/送信）・クライアントの所在地によって単価が変わる。アジアパシフィック発のトラフィックはDT-Premiumが高めになる傾向があるため、通信量が多いシステムでは事前にコスト試算をしておくこと。

【コスト判断の目安】

・月間データ転送量が少ない（数十GB以下）: 固定料金が主なコストになり影響は軽微
・大量のUDP通信（ゲームなど）: CloudFrontではキャッシュが効かないためGlobal Acceleratorが現実的。コストよりレイテンシを優先する
・静的コンテンツやHTTP API: CloudFrontのキャッシュが効く場合は、CloudFrontの方がコスト効率が高い可能性がある

最新料金はAWS公式の料金ページ（「AWS Global Accelerator 料金」で検索）で必ず確認してほしい。

応用・実務Tips

Traffic Dialで段階的にトラフィックを移行する

エンドポイントグループのTraffic Dialを使うと、新旧環境に流すトラフィック比率を細かく制御できる。例えば旧リージョン（us-east-1）に90%、新リージョン（ap-northeast-1）に10%を流した状態で動作確認し、問題なければ段階的に100%へ切り替える。Blue-GreenデプロイやカナリアリリースとAWSの話とも組み合わせやすい。

ヘルスチェックによる自動フェイルオーバー

エンドポイントが不健全と判定されると、Global Acceleratorはそのエンドポイントへのトラフィックをゼロにし、他の健全なエンドポイントへ切り替える。オンプレのGSLB（Global Server Load Balancing）と同様の仕組みだが、設定がはるかにシンプルだ。

マルチリージョン構成を組む際はAWSマルチリージョン設計入門も参考にしてほしい。

カスタムルーティング（Custom Routing Accelerator）

通常のAcceleratorとは別に「カスタムルーティングアクセラレーター」という種類も選択できる。これは特定のセッションを特定のEC2インスタンスに固定してルーティングする機能で、VoIPやマルチプレイヤーゲームのように「同一セッション中は必ず同じバックエンドへ」という要件がある場合に使う。

AWS ShieldとGlobal Acceleratorの組み合わせ

Global AcceleratorはAWS Shield Standard（無料）と自動的に統合されており、L3/L4のDDoS攻撃に対する基本的な保護が付いてくる。追加料金でShield Advancedを適用することもできる。

よくあるトラブルと対処法

「Global Acceleratorを設定したがレイテンシが改善しない」

最も多いケースはシングルリージョン構成での導入だ。Global Acceleratorの効果は、クライアントとバックエンドが地理的に離れているほど大きい。東京リージョンに東京のユーザーがアクセスする構成では、インターネット経路がもともと短いため、効果を実感しにくい。複数リージョンへの展開を検討しているか、海外ユーザーが多い場合に導入を検討すること。

「2つの固定IPのうち片方にしかpingが通らない」

仕様。2つのIPはエニーキャストなので、ネットワーク的に近い方のエッジロケーションに自動で転送される。どちらのIPでも同じアクセラレーターに届くため、機能的に問題はない。

「エンドポイントのヘルスチェックが不健全になる」

よくある原因として、セキュリティグループがGlobal Acceleratorからのヘルスチェックトラフィックをブロックしているケースがある。Global Acceleratorのヘルスチェック送信元IPレンジを確認し、セキュリティグループのインバウンドルールに追加すること。対象CIDRはAWSドキュメントの「Global Accelerator のIPアドレス範囲」で確認できる。

「クライアントIPがバックエンドで取得できない」

ALBをエンドポイントに使う場合、エンドポイント設定の「クライアントIPアドレスの保持」を有効にしないとALBのアクセスログに実クライアントIPが記録されない。NLBの場合は設定方法が異なるため、AWSドキュメントで確認すること。

「CloudFrontとGlobal Acceleratorを同時に使いたい」

HTTP/HTTPSコンテンツはCloudFront、TCPゲームや低レイテンシAPIはGlobal Acceleratorとアプリの種類で分けるのが基本。同一アプリに両方を直列に挟む構成は複雑になりメリットが出づらい。要件を整理してどちらかを選ぶことを推奨する。

本記事のまとめ

AWS Global Acceleratorの要点を整理する。

オンプレのGSLBやWAN最適化装置を使ったことがある人には、Global Acceleratorの「エッジまでの区間をできるだけ短くしてバックボーンに乗せる」という発想はすぐに馴染むはずだ。まずはTraffic Dialを100%→段階移行という形で小さく試し、レイテンシの改善を計測しながら本番展開することを推奨する。

ネットワーク全体の設計についてはAmazon VPC入門やAWS Direct Connect vs Site-to-Site VPNの記事もあわせて参照してほしい。