この記事のポイント
- 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/月）＋ データ転送の上乗せ（少量なら数ドル）
構築手順:
- マネジメントコンソール → Global Accelerator → Create accelerator
- リスナー追加: Port 443 / Protocol TCP
- エンドポイントグループ: ALBと同じリージョン
- エンドポイント: 対象のALBを選択
- 付与された固定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設定変更なし | ◎ | ◎ | × |
| アプリ改修なし | ◎ | ○（要確認） | ◎ |
| 撤去の容易さ | ◎ | ○ | ○ |
| 総合 | 採用 | 次点 | 不採用 |
コメント