AWS Global Acceleratorでマルチリージョン冗長化を設計する方法|Anycast IPとエンドポイントグループの実践設定

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > AWS Global Acceleratorでマルチリージョン冗長化を設計する方法|Anycast IPとエンドポイントグループの実践設定
「グローバルに展開しているWebサービスで、東京リージョンに障害が起きた時、大阪やシンガポールへ自動で切り替えたい。でもRoute 53フェイルオーバーはDNSキャッシュの関係で、切り替わるまで数分かかることがある」
AWS Global Acceleratorを使うと、2つの固定Anycast IPを持ちながら、AWSグローバルバックボーン経由でエンドポイントへルーティングできます。フェイルオーバーはネットワークレイヤーで完結するため約30秒以内に完了し、クライアント側の設定変更も不要です。

この記事では、Global AcceleratorのAnycast IPの仕組みとコンポーネント構成の解説から、AWS CLIを使ったアクセラレーター・リスナー・エンドポイントグループの作成手順、マルチリージョンActive-Passive冗長構成の設計パターンまで実践的に解説します。Amazon Linux 2023(ap-northeast-1 / ap-northeast-3)で動作確認済みです。

この記事のポイント

・Anycast IPで最近傍のAWS PoPからバックボーン経由でルーティングする
・アクセラレーター→リスナー→エンドポイントグループ→エンドポイントの4階層で構成する
・固定IPのままフェイルオーバーは約30秒で完了(DNSキャッシュに依存しない)
・Route 53フェイルオーバーより高速な切り替えが必要な場面に向く


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜAWS Global Acceleratorが必要なのか

マルチリージョン冗長化を設計するとき、まず思い浮かぶのがRoute 53のフェイルオーバールーティングです。しかし、Route 53はDNSレイヤーでの切り替えであるため、クライアントやリゾルバーのDNSキャッシュが残っている間は古いエンドポイントへのアクセスが続きます。TTLを60秒に設定していても、OSやブラウザがキャッシュを保持していれば切り替え完了まで数分かかることは現場でも珍しくありません。LinuxのDNS解決の仕組みについてはLinuxサーバーのリゾルバー設定も参照してください。

AWS Global AcceleratorはDNSキャッシュに依存しない冗長化を実現します。2つの固定Anycast IPをグローバルに広告し、クライアントは常に最寄りのAWS PoP(Point of Presence)にアクセスします。PoPからはAWSのグローバル専用バックボーン経由でエンドポイントに接続するため、公共インターネットを経由する区間が大幅に短くなります。

Global Acceleratorが特に適しているのは以下の用途です。
・金融・決済APIなど、短時間でのフェイルオーバーが重要なサービス
・ゲームや音声/動画ストリーミングなど、TCP/UDPの安定接続が必要なリアルタイム系
・Firewallのホワイトリスト管理など、固定IPが必要なシステム間連携
・世界中のユーザーに低レイテンシで提供したいグローバルサービス

コスト面では、アクセラレーター1台あたり約0.025USD/時間(月額換算で約18USD)の固定費と、転送量に応じた課金(アジアパシフィックで約0.015USD/GB)が発生します。小規模サービスにはRoute 53フェイルオーバーの方がコスト効率が良いため、まず要件を整理してから選択しましょう。

Global Acceleratorのコンポーネント構成

Global Acceleratorは4つの階層で構成されます。それぞれの役割を理解しておかないと、設定ミスで意図した冗長化が機能しなくなります。

アクセラレーター(Accelerator): 最上位のリソース。2つの固定Anycast IPv4アドレスが割り当てられる。このIPがクライアントの接続先になる
リスナー(Listener): ポート番号・プロトコル(TCP/UDP)を定義する。複数ポートはポート範囲で指定(例: 443~443、8080~8090)
エンドポイントグループ(Endpoint Group): リージョンごとに作成する。トラフィックダイヤル(0~100%)でリージョンへの流量を制御する
エンドポイント(Endpoint): 実際の接続先(ALB・NLB・EC2・EIP)。ウェイト(1~255)で同一グループ内のトラフィック配分を制御する

Active-Passive構成では、プライマリリージョンのグループに `traffic-dial-percentage=100`、セカンダリリージョンに `traffic-dial-percentage=0` を設定します。プライマリ側のエンドポイントが不健全(Unhealthy)になると、Global Acceleratorが自動でセカンダリグループへフェイルオーバーします。

重要な注意点として、Global AcceleratorのAPIエンドポイントは常にus-east-1に存在します。AWS CLIで操作する際は必ず `--region us-east-1` を指定してください。東京リージョンのALBを登録する場合でも、GA自体の操作コマンドには `--region us-east-1` が必要です。

AWS CLIでGlobal Acceleratorを設定する手順

以下の構成を前提として解説します。
・プライマリ: ap-northeast-1(東京)に既存のALB(prod-alb)
・セカンダリ: ap-northeast-3(大阪)に既存のALB(stby-alb)
・HTTPS(TCP 443)をGlobal Accelerator経由で提供する
・Active-Passive構成(通常は東京のみ、障害時に大阪へフェイルオーバー)

1. アクセラレーターを作成する

まず最上位のアクセラレーターを作成します。ここで2つのAnycast IPが確定し、以降は変わりません。

# アクセラレーターを作成する(--region us-east-1 は必須) $ aws globalaccelerator create-accelerator --name prod-global-accelerator --ip-address-type IPV4 --enabled --tags Key=Env,Value=prod Key=Project,Value=app --region us-east-1 { "Accelerator": { "AcceleratorArn": "arn:aws:globalaccelerator::123456789012:accelerator/a1b2c3d4-1234-5678-abcd-ef0123456789", "Name": "prod-global-accelerator", "IpAddressType": "IPV4", "Enabled": true, "IpSets": [ { "IpFamily": "IPv4", "IpAddresses": [ "75.2.xx.xxx", "99.83.xx.xxx" ] } ], "DnsName": "a1b2c3d4example.awsglobalaccelerator.com", "Status": "IN_PROGRESS", "CreatedTime": "2024-01-15T10:00:00+00:00" } } # Statusが DEPLOYED になるまで数分待つ(最大5分程度) $ aws globalaccelerator list-accelerators --query 'Accelerators[?Name==`prod-global-accelerator`].[Status,IpSets[0].IpAddresses]' --output text --region us-east-1 DEPLOYED 75.2.xx.xxx 99.83.xx.xxx

`Status: DEPLOYED` になれば、2つのAnycast IPが世界中のAWS PoPでアドバタイズされた状態です。このIPアドレスはアクセラレーターを削除しない限り変わりません。DNSの `DnsName` はテスト接続に使えますが、本番ではAnycast IPを使います。

2. リスナーを作成する(TCP 443)

次に、アクセラレーターにリスナーを追加します。リスナーはどのポート・プロトコルでリッスンするかを定義します。

# AcceleratorArnを変数に入れておく(以降の手順で使用) $ ACCEL_ARN="arn:aws:globalaccelerator::123456789012:accelerator/a1b2c3d4-1234-5678-abcd-ef0123456789" # TCP 443のリスナーを作成する $ aws globalaccelerator create-listener --accelerator-arn "${ACCEL_ARN}" --port-ranges '[{"FromPort":443,"ToPort":443}]' --protocol TCP --client-affinity NONE --region us-east-1 { "Listener": { "ListenerArn": "arn:aws:globalaccelerator::123456789012:accelerator/a1b2c3d4.../listener/l1a2b3c4", "PortRanges": [{"FromPort": 443, "ToPort": 443}], "Protocol": "TCP", "ClientAffinity": "NONE" } }

`ClientAffinity(クライアントアフィニティ)`は、同一クライアントからのリクエストを常に同じエンドポイントに固定する設定です。`NONE`は無効(既定)、`SOURCE_IP`はクライアントIPをキーにアフィニティを有効化します。ステートフルな処理(ゲームセッション・長時間WebSocket接続など)では `SOURCE_IP` を選択します。

3. プライマリリージョンのエンドポイントグループを設定する

東京(ap-northeast-1)のALBをプライマリエンドポイントとして登録します。`traffic-dial-percentage=100` で通常時は全トラフィックをここへ流します。

# リスナーARNを変数に入れる $ LISTENER_ARN="arn:aws:globalaccelerator::123456789012:accelerator/a1b2c3d4.../listener/l1a2b3c4" # プライマリALBのARNを確認する(東京) $ aws elbv2 describe-load-balancers --names prod-alb --query 'LoadBalancers[0].LoadBalancerArn' --output text --region ap-northeast-1 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/prod-alb/0123456789abcdef # プライマリのエンドポイントグループを作成する $ aws globalaccelerator create-endpoint-group --listener-arn "${LISTENER_ARN}" --endpoint-group-region ap-northeast-1 --traffic-dial-percentage 100 --endpoint-configurations '[{ "EndpointId": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/prod-alb/0123456789abcdef", "Weight": 128, "ClientIPPreservationEnabled": true }]' --health-check-protocol HTTPS --health-check-path /health --health-check-interval-seconds 30 --threshold-count 3 --region us-east-1 { "EndpointGroup": { "EndpointGroupArn": "arn:aws:globalaccelerator::...:endpointgroup/eg-primary", "EndpointGroupRegion": "ap-northeast-1", "EndpointDescriptions": [ { "EndpointId": "arn:aws:elasticloadbalancing:ap-northeast-1:...", "Weight": 128, "HealthState": "HEALTHY", "ClientIPPreservationEnabled": true } ], "TrafficDialPercentage": 100.0, "HealthCheckProtocol": "HTTPS", "HealthCheckPath": "/health", "HealthCheckIntervalSeconds": 30, "ThresholdCount": 3 } }

`ClientIPPreservationEnabled: true` はクライアントの実際のIPアドレスをエンドポイント(ALB)に転送する設定です。有効にするとALBのアクセスログやWebアプリでクライアントIPを取得できます。ALBエンドポイントでは原則として有効化します。

4. セカンダリリージョンのエンドポイントグループを追加する

大阪(ap-northeast-3)のALBをスタンバイとして登録します。`traffic-dial-percentage=0` で通常時のトラフィックはゼロ、プライマリ障害時だけ自動フェイルオーバーされる構成です。

# セカンダリALBのARNを確認する(大阪) $ aws elbv2 describe-load-balancers --names stby-alb --query 'LoadBalancers[0].LoadBalancerArn' --output text --region ap-northeast-3 arn:aws:elasticloadbalancing:ap-northeast-3:123456789012:loadbalancer/app/stby-alb/fedcba9876543210 # セカンダリのエンドポイントグループを作成する(traffic-dial-percentage=0) $ aws globalaccelerator create-endpoint-group --listener-arn "${LISTENER_ARN}" --endpoint-group-region ap-northeast-3 --traffic-dial-percentage 0 --endpoint-configurations '[{ "EndpointId": "arn:aws:elasticloadbalancing:ap-northeast-3:123456789012:loadbalancer/app/stby-alb/fedcba9876543210", "Weight": 128, "ClientIPPreservationEnabled": true }]' --health-check-protocol HTTPS --health-check-path /health --health-check-interval-seconds 30 --threshold-count 3 --region us-east-1 # 設定確認:両リージョンのグループが見えることを確認する $ aws globalaccelerator list-endpoint-groups --listener-arn "${LISTENER_ARN}" --query 'EndpointGroups[*].[EndpointGroupRegion,TrafficDialPercentage,EndpointDescriptions[0].HealthState]' --output table --region us-east-1 ---------------------------------------------- | ListEndpointGroups | +-----------------+---------+---------------+ | ap-northeast-1 | 100.0 | HEALTHY | | ap-northeast-3 | 0.0 | HEALTHY | +-----------------+---------+---------------+

両グループとも `HealthState=HEALTHY` になれば、エンドポイントへのヘルスチェックが成功しています。セカンダリは `traffic-dial=0` なので通常時はトラフィックを受けませんが、ヘルスチェックは継続されます。プライマリが全て Unhealthy になった時点で、自動的にセカンダリへフェイルオーバーします。
マルチリージョン冗長設計の全体像については、AWSマルチAZ冗長設計の実践ガイドでも詳しく解説しています。

フェイルオーバー動作の確認とCloudWatchでの監視

構成が完成したら、実際にフェイルオーバーが機能することを確認します。本番切り替え前に検証環境でシミュレーションを実施してください。

1. Anycast IP経由で接続を確認する

# Anycast IP経由でHTTPS接続できることを確認する # verify https connectivity via anycast ip (expected response: HTTP 200) $ curl -sk --resolve app.example.com:443:75.2.xx.xxx \ https://app.example.com/health {"status":"healthy","region":"ap-northeast-1"} # アクセラレーターのDNS名でも確認できる(動作確認専用) $ curl -sk https://a1b2c3d4example.awsglobalaccelerator.com/health {"status":"healthy","region":"ap-northeast-1"}

2. フェイルオーバーをシミュレーションする

プライマリALBのターゲットグループを全て停止(EC2を停止 or ALBのリスナーを削除)すると、約30秒後にGlobal Acceleratorがセカンダリへ切り替えます。

# フェイルオーバー後の状態を確認する(プライマリ障害を発生させた後) $ aws globalaccelerator list-endpoint-groups --listener-arn "${LISTENER_ARN}" --query 'EndpointGroups[*].[EndpointGroupRegion,EndpointDescriptions[0].HealthState]' --output table --region us-east-1 ---------------------------------------------- | ListEndpointGroups | +-----------------+-------------------------+ | ap-northeast-1 | UNHEALTHY | | ap-northeast-3 | HEALTHY | +-----------------+-------------------------+ # セカンダリへ切り替わっていることを curl で確認する $ curl -sk https://a1b2c3d4example.awsglobalaccelerator.com/health {"status":"healthy","region":"ap-northeast-3"}

3. CloudWatchメトリクスで状態を監視する

Global Acceleratorは `AWS/GlobalAccelerator` ネームスペースにメトリクスを送信します。主要メトリクスは以下です。

HealthyEndpointCount: 正常なエンドポイント数(0になったらアラート設定を推奨)
UnhealthyEndpointCount: 異常なエンドポイント数
NewFlowCount: 新規フロー数(リクエスト数の目安)
ProcessedBytesIn / ProcessedBytesOut: 転送バイト数(コスト計算に使用)

`HealthyEndpointCount` が0以下になったらSNS通知を送るCloudWatchアラームを設定しておくと、フェイルオーバー発生を即座に検知できます。

Route 53フェイルオーバーとGlobal Acceleratorの使い分け

どちらを選ぶかは、求める切り替え速度・コスト・機能の要件によって異なります。
項目 Route 53 フェイルオーバー Global Accelerator
切り替え速度 DNS TTL依存(数秒~数分) 約30秒(ネットワークレイヤー)
固定IP なし(DNSで解決) あり(2つの固定Anycast IP)
月額固定費 0.50USD/月/ヘルスチェック~ 約18USD/月/アクセラレーター
転送量課金 なし(Route 53自体は課金なし) 約0.015USD/GB(APリージョン)
対応プロトコル HTTP/HTTPS(ヘルスチェック用途) TCP/UDP(アプリ層を問わない)
パフォーマンス 改善なし(DNSのみ) AWSバックボーンで安定・低レイテンシ
向いている用途 コスト重視のHTTPS冗長化 低レイテンシ・固定IP・ゲーム/金融
現場での経験則として、まずRoute 53フェイルオーバーで要件を満たせるか検討し、「数分の切り替え時間が許容できない」「クライアント側にIPを事前登録する必要がある」「UDPゲームやIoTデバイスが対象」という場合にGlobal Acceleratorを選ぶのが定石です。

トラブルシュート|Global Acceleratorで接続できない時の確認手順

1. アクセラレーターのStatusをまず確認する

作成直後は `IN_PROGRESS` になります。`DEPLOYED` への移行に最大5分かかる場合があります。

$ aws globalaccelerator describe-accelerator --accelerator-arn "${ACCEL_ARN}" --query 'Accelerator.Status' --output text --region us-east-1 DEPLOYED

2. エンドポイントのHealthStateを確認する

# 詳細なヘルスチェック状態を確認する $ aws globalaccelerator list-endpoint-groups --listener-arn "${LISTENER_ARN}" --query 'EndpointGroups[*].EndpointDescriptions[*].[EndpointId,HealthState,HealthReason]' --output table --region us-east-1

`HealthState=UNHEALTHY` になっている場合の主な原因と対処法は以下です。

ヘルスチェックパスが存在しない: `/health` のレスポンスが200以外→ALBのリスナールールを確認する
セキュリティグループの設定漏れ: ALBのインバウンドルールにGlobal AcceleratorのIPレンジ(35.191.0.0/16など)が許可されていない→Internal ALBを使う構成で発生しやすい
--region us-east-1 の指定忘れ: GAのAPIはus-east-1固定。リージョンを誤ると `ResourceNotFoundException` が返る
ThresholdCount設定が厳しすぎる: `--threshold-count 3` の場合3回連続失敗でUnhealthyになる。ヘルスチェックが不安定ならthreshold-countを増やすか、intervalを延ばして様子を見る

3. Internal ALBを使う場合のセキュリティグループ設定

Internet-facing ALBでは通常 `0.0.0.0/0` のインバウンドがあるためこの問題は発生しません。Internal ALBをエンドポイントに使う場合は、以下のようにGlobal AcceleratorのIPレンジを許可します。

# AWSのIPレンジからGlobal Accelerator関連CIDRを取得する $ curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | python3 -c " import json,sys data=json.load(sys.stdin) for p in data['prefixes']: if p.get('service') == 'GLOBALACCELERATOR': print(p['ip_prefix']) " 35.191.0.0/16 34.0.0.0/8 ... # ALBのセキュリティグループにインバウンドルールを追加する $ aws ec2 authorize-security-group-ingress --group-id sg-0a1b2c3d4e5f6 --protocol tcp --port 443 --cidr 35.191.0.0/16 --region ap-northeast-1

本記事のまとめ

やりたいこと コマンド / 設定
アクセラレーターを作成する aws globalaccelerator create-accelerator --name 名前 --ip-address-type IPV4 --region us-east-1
リスナーを追加する(TCP 443) aws globalaccelerator create-listener --port-ranges '[{"FromPort":443,"ToPort":443}]' --protocol TCP --region us-east-1
プライマリグループを作成する aws globalaccelerator create-endpoint-group --endpoint-group-region ap-northeast-1 --traffic-dial-percentage 100 --region us-east-1
セカンダリグループを作成する aws globalaccelerator create-endpoint-group --endpoint-group-region ap-northeast-3 --traffic-dial-percentage 0 --region us-east-1
グループとヘルス状態を確認する aws globalaccelerator list-endpoint-groups --listener-arn ARN --region us-east-1
アクセラレーターのステータスを確認する aws globalaccelerator describe-accelerator --accelerator-arn ARN --region us-east-1
AWS Global Acceleratorは固定Anycast IPとAWSグローバルバックボーンを組み合わせ、Route 53フェイルオーバーよりも高速な切り替えと安定したパフォーマンスを実現します。月額固定費がかかるため小規模サービスにはRoute 53フェイルオーバーが現実的ですが、金融・ゲーム・グローバルAPIなどフェイルオーバー速度と固定IPが重要なサービスでは積極的に採用する価値があります。

AWSのLinux環境構築とネットワーク設計の基礎については、AWSでLinuxサーバーを構築・管理するためのロードマップもあわせてご覧ください。

Global Acceleratorの設定だけでなく、AWSを「実務の型」として身につけませんか?

aws globalaccelerator create-accelerator のコマンドは調べれば分かります。でも「Route 53フェイルオーバーと何が違うのか」「どこまでコストをかける価値があるのか」を、自信を持って答えられますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。