検証期間中だけALBのIPを固定したい — 要件から逆算してGlobal Acceleratorを選んだ理由

AWS
2026.08.15

この記事のポイント

  • ALBのIPは可変。hostsファイルで名前解決を固定する検証方法が使えない
  • 固定IP実現の方法を3つ調査し、要件に照らして AWS Global Accelerator を採用した
  • 「一時的」「構築が簡単」「既存環境に影響しない」が決め手

はじめに

おつかれさまです。tyamonです。

検証期間中だけALBに固定IPでアクセスさせたい場面で、どの方式が最適か要件ベースで比較検討した記録です。

結論：一時的な固定IPなら AWS Global Accelerator が最もシンプル。

要件の整理

まず、自分が何を実現したいのかを整理する。

#要件補足
1検証期間中だけALBに固定IPでアクセスしたい恒久的な固定IPは不要
2利用者のPCのhostsファイルに1つのIPを書くだけで済ませたい何度も書き換えてもらうのは現実的でない
3既存のALB設定を変更したくない本番切り替え時にリスクを残さない
4アプリ側の改修なしで動くことクライアントIPの保持など
5検証終了後に簡単に撤去できること残骸を残さない

なぜこの問題が発生したか

既存のオンプレアプリをAWSに移管し、ALBを導入した。本番切り替え前に一般利用者へ動作検証を依頼する必要がある。

検証方法として、各PCのhostsファイルにALBのIPアドレスを書いてURLの向き先を変える想定だった。しかしALBのIPアドレスはAWSの仕様上、固定できない。スケーリングやAZ障害時にIPが変わる。

つまり、hostsに書いたIPがいつ無効になるかわからない。

調査した方式

方式1: AWS Global Accelerator ← 採用

PC (hosts → GA固定IP) → Global Accelerator → ALB → バックエンド

Global Acceleratorを作成すると、固定のAnycast IPアドレスが2つ付与される。このIPは変わらない。エンドポイントとしてALBを登録すれば、固定IP経由でALBにアクセスできる。

要件との適合:

要件適合理由
一時的な固定IP◎Accelerator削除で即撤去
hostsに1IP記載○2つ付与されるが片方を書けばOK
ALB設定変更なし◎ALBには一切触らない
アプリ改修なし◎クライアントIP保持がデフォルト有効
撤去の容易さ◎Accelerator削除のみ

コスト: $0.025/時間（≒$18/月）＋ データ転送の上乗せ（少量なら数ドル）

構築手順:

  1. マネジメントコンソール → Global Accelerator → Create accelerator
  2. リスナー追加: Port 443 / Protocol TCP
  3. エンドポイントグループ: ALBと同じリージョン
  4. エンドポイント: 対象のALBを選択
  5. 付与された固定IPのうち1つをhostsに記載

これだけ。5分で終わる。

方式2: NLB前段配置 ← 不採用

PC (hosts → EIP) → NLB → ALB → バックエンド

NLB（Network Load Balancer）にElastic IP（固定IP）を付与し、NLBのターゲットとしてALBを登録する方式。2021年9月以降、NLBのターゲットタイプに「ALB」が追加されたため、直接連携が可能。

不採用の理由:

観点詳細
構築が重いNLB作成 + EIP割当 + ターゲットグループ作成 + リスナー設定 + ヘルスチェック調整。一時利用にしては手間が多い
TLS終端の設計判断が必要NLBをTCPパススルーにするか、NLBでもTLS終端するか決める必要がある。パススルーが無難だが、意識的な判断が求められる
ヘルスチェックが多段NLB → ALB → バックエンドとヘルスチェックが通る必要がある。ヘルスチェック失敗時の切り分けが面倒
X-Forwarded-For問題のリスクターゲットタイプ「ALB」ならクライアントIP保持はデフォルト有効。ただし設定を誤るとALBから見たソースIPがNLBのプライベートIPになり、アプリがクライアントIPを識別できなくなる

この方式が向いているケース:

  • 恒久的に固定IPが必要（ファイアウォールの許可リスト運用など）
  • すでにNLBの運用知見があるチーム

コスト: NLB ~$16/月 + NLCU + EIP $0.005/時間 ≒ $20〜25/月

方式3: VPC IPAM連携 ← 不採用

PC (hosts → IPAMプールのIP) → ALB → バックエンド

2025年3月にローンチされた新機能。VPC IPAMのプールからALBに「予測可能な」IPアドレスブロックを割り当てる。

不採用の理由:

観点詳細
「予測可能」≠「固定」IPAMプールから割り当てられるIPは一定の範囲内に収まるが、スケーリング時に新しいIPが追加される。特定の1IPを固定できるわけではない
プール枯渇時にフォールバックIPAMプールのIPが足りなくなるとAWS管理IPに自動切替。hostsに書いたIPと別のIPになる可能性がある
ALBの設定変更が必要既存ALBの設定を変えることになり、要件3（ALB設定変更なし）に反する
用途が違う本来は外部パートナーへのIPレンジ単位の許可リスト管理や、BYOIPによるパブリックIPv4コスト削減が目的の機能

この方式が向いているケース:

  • 外部連携先に「このIPレンジからアクセスする」と事前通知したい
  • 自社保有IPアドレス（BYOIP）をALBに使いたい
  • パブリックIPv4のコスト最適化

比較まとめ

| 要件 | Global Accelerator | NLB前段 | VPC IPAM |
|——|:-:|:-:|:-:|
| 一時的な固定IP | ◎ | ○ | △ |
| hostsに1IP記載 | ○ | ◎ | × |
| ALB設定変更なし | ◎ | ◎ | × |
| アプリ改修なし | ◎ | ○（要確認） | ◎ |
| 撤去の容易さ | ◎ | ○ | ○ |
| 総合 | 採用 | 次点 | 不採用 |

参考リンク

コメント

タイトルとURLをコピーしました