AWSでIPアドレスを固定する方法とは？NLBとGlobal Acceleratorの使い分けを解説
AWSでIPアドレスを固定化する選択肢：NLBとGlobal Acceleratorの使い分け
AWSを利用してシステムを構築する際、EC2やALB（Application Load Balancer）には通常、動的なパブリックIPやDNS名が割り当てられます。
しかし、実務においては「IPアドレスを固定化したい」という要件に直面することが多々あります。
今回は、AWSでIP固定化を実現するための主要な2つのアプローチである Network Load Balancer (NLB) と AWS Global Accelerator について、それぞれの特徴と使い分けの基準を整理します。
なぜIP固定化が必要になるのか
クラウドネイティブな設計ではDNSベースでの通信が推奨されますが、対外的な接続要件によってはIP固定が必須となるケースがあります。
具体的には以下のようなシナリオです。
- ファイアウォール設定: 取引先企業のセキュリティポリシーで、IPアドレスによるホワイトリスト登録（許可リスト）を求められる場合。
- SaaS連携: 固定IPからのアクセスのみを許可する外部APIやSaaSと連携する場合。
- DNSの制約: クライアント側でDNSキャッシュの問題が発生しやすく、安定した通信先IPを担保したい場合。
これらの課題を解決するために、AWSでは主に以下の2つのサービスが選択肢となります。
1. Network Load Balancer (NLB)
NLB は、L4（トランスポート層）で動作するロードバランサーです。
Webアプリケーションでよく使われるALBとは異なり、Elastic IP (EIP) を割り当てることができるのが最大の特徴です。
特徴とメリット
- 各アベイラビリティーゾーン（AZ）に対して1つの静的IPアドレスを割り当て可能。
- TCP/UDPトラフィックを非常に低いレイテンシで処理できる。
- ALBの前段にNLBを配置することで、「Webアプリ（L7機能）＋固定IP」という構成も実現可能。
向いているケース
- 単一のAWSリージョン内で完結するシステム。
- VPC内部、または特定のリージョン間での通信で固定IPが必要な場合。
- コストを抑えつつIP固定化を実現したい場合。
2. AWS Global Accelerator
AWS Global Accelerator は、AWSのグローバルネットワークを活用してトラフィックを最適化するサービスです。
このサービスを作成すると、Anycast IP と呼ばれるグローバルで一意な2つの静的IPアドレスが払い出されます。
特徴とメリット
- ユーザーに最も近いエッジロケーションからAWSネットワークへ入り、バックボーンを通ってエンドポイントへ到達するため、インターネット経由よりも高速かつ安定する。
- 複数のAWSリージョンにまたがるエンドポイントをバックエンドに指定できる。
- IPアドレスを変更することなく、裏側のエンドポイント（ALBやEC2）を即座に切り替えるフェイルオーバーが可能。
向いているケース
- グローバル規模でサービスを展開しており、通信遅延を最小化したい場合。
- マルチリージョン構成でDR（Disaster Recovery）対策を行いたい場合。
- ALBのIPアドレスが変動する問題を、NLBを挟まずに解決したい場合（ALBの前段に直接配置可能）。
使い分けの基準
どちらを採用すべきか迷った際は、以下の観点で比較すると判断しやすくなります。
| 比較項目 | Network Load Balancer (NLB) | AWS Global Accelerator |
|---|---|---|
| スコープ | 単一リージョン向け | グローバル / マルチリージョン対応 |
| IPの仕組み | Elastic IP (リージョン固有) | Anycast IP (グローバル共通) |
| 主な目的 | 安定したL4通信・IP固定 | 通信経路の最適化・高速化・冗長化 |
| コスト | 比較的安価 | 高め (固定費 + データ転送量課金) |
| フェイルオーバー | DNS切り替え等が必要 | IPそのままで自動ルーティング |
まとめ
IPアドレスを固定化するという目的だけであれば、多くのケースで NLB がコストパフォーマンスの良い選択肢となります。
一方で、「グローバル規模での低レイテンシ」や「即時のフェイルオーバー」といった付加価値が必要な場合、あるいは「ALBのIPを固定化したいが、NLBの管理運用は避けたい」といった場合には、Global Accelerator が強力なソリューションになります。
要件における「通信範囲」と「可用性レベル」を軸に、適切なアーキテクチャを選定してみてください。
Discussion