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フェイルオーバーより高速な切り替えが必要な場面に向く
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ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
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" } }
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 } }
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 | +-----------------+---------+---------------+
マルチリージョン冗長設計の全体像については、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・ゲーム/金融 |
トラブルシュート|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
・ヘルスチェックパスが存在しない: `/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のLinux環境構築とネットワーク設計の基礎については、AWSでLinuxサーバーを構築・管理するためのロードマップもあわせてご覧ください。
Global Acceleratorの設定だけでなく、AWSを「実務の型」として身につけませんか?
aws globalaccelerator create-accelerator のコマンドは調べれば分かります。でも「Route 53フェイルオーバーと何が違うのか」「どこまでコストをかける価値があるのか」を、自信を持って答えられますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます