クラウドの境界線で迷うエンジニアたちへ：EIPとパブリックIPの本当のハナシ
クラウドインフラの設計や運用を任されると、避けて通れないのが「ネットワークの境界線」の設計です。VPCの構築を始めたばかりのころ、誰もが一度は次のような疑問にぶつかります。
「EC2インスタンスを立ち上げるとき、自動で割り当てられる『パブリックIPv4アドレス』と、わざわざ別途取得してアタッチする『Elastic IP (EIP)』の決定的な違いって何なんだ？」
「インスタンスを再起動したらIPアドレスが変わってしまい、外部APIのホワイトリスト（IP制限）に弾かれてシステムが止まった……」
現場で数々の修羅場をくぐり抜けてきたシニアエンジニアなら、この痛みが痛いほどわかるはずです。今回は、AWSのネットワーキングの根幹を支える「パブリックIP」と「Elastic IP」の仕様の裏側を、パケットの挙動や実務でのユースケースを交えながら徹底的に紐解いていきます。
—
1. パブリックIPv4アドレス vs Elastic IP：仕様の決定的な違い
まずは、両者の最も根本的な違いを整理しましょう。どちらもAWSの外側（インターネット）と通信するために必要なグローバルIPアドレスを提供しますが、その「ライフサイクル」と「コスト構造」が大きく異なります。
| 特性 | パブリックIPv4アドレス (Public IPv4) | Elastic IP (EIP) |
| :— | :— | :— |
| ライフサイクル | インスタンスのライフサイクルに完全に依存する | インスタンスから切り離してもAWSアカウント内に保持される |
| 再起動時の挙動 | 停止（Stop）/起動（Start）でアドレスが変わる可能性がある | 割り当てを解除しない限り、絶対に変わらない（静的） |
| コスト | インスタンス起動中は無料（AWSの無料枠の範囲内等） | インスタンスにアタッチされていない状態（孤立状態）のときに課金される |
| 主な用途 | 一時的なテスト環境、動的なスケールアウトを前提としたWebサーバー | 外部APIのIP制限（ホワイトリスト）対策、固定IPが必要なSSH踏み台 |
パケットの動きから見る仕組み
AWSのVPC内部において、EC2インスタンスには通常プライベートIPアドレス（例: 10.0.1.100）のみが割り当てられています。インターネットへ通信する際、AWSの基盤ネットワーク（VPCルーターやNATゲートウェイ、あるいはENI直近の仮想ルーター）でNAT（Network Address Translation）が行われ、パブリックIPやEIPに変換されて外の世界へと飛び出します。
このとき、通常のパブリックIPは「インスタンスという器」に紐づいているため、インスタンスを停止して再度起動した際、AWSのプールから別のIPアドレスが再割り当てされるリスクがあります。一方、EIPはあなたのアカウントに「予約された不動産」のようなものであり、どのインスタンスに紐づくかを自由に付け替えることができます。
—
2. アドレス枯渇対策とAWSの巧妙な課金体系
「静的なIPが便利なら、全部EIPにしておけばいいじゃないか」と思いがちですが、ここにAWSの巧妙な（そして理にかなった）IPv4アドレス枯渇対策が隠されています。
IPv4アドレスは世界的に枯渇しており、AWSにとっても貴重な資産です。そのため、使われていないIPv4アドレスが遊休状態になるのを防ぐため、EIPには次のような厳格な課金ポリシーが適用されています。
1. インスタンスにアタッチされているEIP: 無料
2. 停止中のインスタンスにアタッチされているEIP: 無料（インスタンスが停止していても、アタッチ状態であれば課金対象外）
3. どのリソースにもアタッチされていない（解放されていない）EIP: 有料（時間単位で課金）
もし、不要になったテスト環境を「インスタンスだけ削除して、EIPの解放を忘れた」なんてことをやらかすと、じわじわとAWS利用料を押し上げる原因になります。インフラのコスト最適化（FinOps）の観点からも、EIPのライフサイクル管理は厳重に行う必要があります。
—
3. 実務で役立つ設定とデバッグの作法
ここからは、実務でAWS CLIやTerraformを使ってEIPを扱い、アプリケーションから外部へリクエストを飛ばす際の実装パターンを見ていきましょう。
AWS CLIによるEIPの取得とアタッチ
まずは、手動またはスクリプトでEIPを確保し、特定のEC2インスタンスに紐づける手順です。
# 1. VPCスコープで新しいElastic IPを取得する
# 出力される AllocationId と PublicIp をメモしておきます
aws ec2 allocate-address --domain vpc
# 2. 取得した AllocationId と対象のインスタンスIDを指定してアタッチする
aws ec2 associate-address \
--instance-id i-0123456789abcdef0 \
--allocation-id eipalloc-0123456789abcdef0
# 【Tips】デバッグ時：現在の割り当て状況を確認するコマンド
aws ec2 describe-addresses --allocation-ids eipalloc-0123456789abcdef0Python (requests) を使ったグローバルIPの確認スクリプト
「今、自分のアプリケーションがどのパブリックIP（EIP）で外に出ていかっているのか？」を確認したいときは、外部のIP確認サービスを叩くスニペットを常備しておくと、セキュリティグループのミスやルートテーブルのルーティング漏れ（IGWへのルートがあるか）を瞬時に切り分けられます。
import requests
def check_outbound_ip():
"""
自信のインスタンスがインターネット側からどのIPアドレスで見えているかを確認する関数。
外部のIPエコーサービスを利用して、現在ルーティングに使われているパブリックIP/EIPを特定する。
"""
try:
# パブリックIPをプレーンテキストで返してくれる信頼性の高いエンドポイント
response = requests.get('https://api.ipify.org?format=json', timeout=5)
response.raise_for_status()
ip_data = response.json()
print(f"[SUCCESS] 現在のアウトバウンドIPアドレス: {ip_data['ip']}")
except requests.exceptions.RequestException as e:
print(f"[ERROR] ネットワーク接続または名前解決に失敗しました: {e}")
if __name__ == '__main__':
check_outbound_ip()—
4. 現場でありがちなトラブルとシニアからの教訓
最後に、実際の現場で遭遇しがちなトラブルシューティングの知見をいくつかシェアします。
トラブル1: 外部APIの接続元IP制限に弾かれる
- 原因: インスタンスをメンテナンスのために一度Stop/Startした際、パブリックIPアドレスが変わってしまった。
- 対策: 外部APIベンダーから「IPアドレス制限をかける」と言われたら、必ずElastic IPを採用し、そのIPをホワイトリストに登録してもらうこと。通常のパブリックIPを信用してはいけません。
トラブル2: EIPを使っているのに、外部と通信できない
- 原因: EIPはあくまで「IPの紐づけ」であり、ルーティングを保証するものではありません。VPCのルートテーブルにインターネットゲートウェイ（
igw-xxxxxxxx）へのデフォルトルート（0.0.0.0/0）が設定されているか、およびセキュリティグループの送信（Egress）ルールが閉じられていないかを確認する必要があります。 - デバッグ手順: まず
tracerouteやncコマンドでどこまでパケットが飛んでいるかを確認し、セキュリティグループのインバウンド/アウトバウンドを疑うのが定石です。
—
まとめ
Elastic IPとパブリックIPの違いは、単なる「仕様の暗記」ではありません。システムが外部のサードパーティAPIと連携する際の「信頼性の担保」であり、クラウドコストを最適化するための「リソース管理の要」です。
「いつ、どのタイミングでIPが変わるべきか、あるいは変わってはいけないのか」――この視点を持つだけで、あなたのVPC設計の品質は一段とプロフェッショナルなものになります。日々のインフラ運用の現場で、ぜひこの知見を役立ててください。
コメント