「固定IPが欲しいから、とりあえずElastic IP（EIP）を付けよう」——EC2を触り始めた頃ほど、こうなりがちです。
でもEIPは便利な一方で、課金・運用・高可用性設計の観点で「やってしまいがち」な落とし穴が多い要素でもあります。
SAA-C03では、EIPそのものの暗記よりも「なぜその設計が危ないのか」「代替案は何か」が分かっていると判断が安定します。この記事では、EIPを“固定IP”として雑に扱わず、設計の引き出しを増やす目的で整理します。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
Elastic IPとは何か
EIPは、AWSアカウントに割り当てる固定のパブリックIPv4アドレスです。インスタンス障害などが起きても、EIPを別のリソースへ付け替えることで、同じIPでサービス継続できるのが売りです。
ポイントは「インスタンスに付くIP」ではなく、アカウントに確保され、明示的に解放しない限り残り続けるという性質です。EIPをリソースから外しても、割り当て自体は残ります。
また、EIPはEC2だけの機能ではなく、NAT GatewayやNetwork Load Balancer（NLB）などにも関連します。
課金の落とし穴：EIPは「付けっぱなし」でコストが出る時代
ここが一番つまずきやすいところです。いまは「EIPは使っていれば無料」という感覚だと、請求を見て驚きます。
パブリックIPv4アドレス課金の基本
AWSは、in-use（使用中）でもidle（未使用）でも、パブリックIPv4アドレスに時間課金を適用しています。VPC料金ページ上でも、in-use / idleともに $0.005/時間と明記されています。
さらに、VPCのIPアドレス設計ドキュメントでも「実行中インスタンスに紐づくパブリックIPv4やEIPも課金対象」である点が注意として書かれています。
よくある請求パターン
- EIPを外したのに解放していない
EIPは外しても“確保されたまま”なので課金対象が残ります。 - 停止中インスタンスにEIPを付けたまま
以前から「停止中に付けたまま」等で課金になりやすい話があり、見落としの定番です。
ざっくり年間コスト感
$0.005/時間 × 24 × 365 ≒ $43.8/年（1IPあたり）
「たった1個なら…」が、NAT Gatewayや検証環境で積み上がりやすいのが現実です。
設計の落とし穴：EIPが必要な場面と、不要なのに使ってしまう場面
ここはSAA-C03で判断力が問われやすいポイントです。EIPを選ぶ理由が「固定IPが欲しい」だけだと、だいたい設計が歪みます。
EIPが“効く”代表例
- 送信元IPを固定したい（相手先でIP許可リストが必要）
典型はNAT Gateway＋EIPで、プライベートサブネットの送信元を固定する設計です。 - NLBで静的IPが必要
要件として「固定IPで受けたい」が強いとき、NLB＋EIPが候補になります（ALBは静的IPそのものを固定する設計思想ではない、という整理が大事）。
EIPが“不要なのに付けがち”な例
- EC2を1台立ててEIPで公開（＝固定IPだから安心、と思う）
固定IPでも、インスタンスが落ちたらサービスは落ちます。EIPは“住所”であって“耐障害”ではありません。
可用性が必要なら、まず考えるべきは「複数AZ・負荷分散・自動復旧」で、EIPはその後です。
代替の考え方：IPではなく名前に寄せる
多くのケースで、固定IPに固執せず「DNS名で扱う」方が設計がきれいになります。
EIPをDNSレコードに入れることもできますが、そもそもLBやマネージドサービスのDNS名へ寄せた方が、復旧・拡張の自由度が高くなりやすいです。
高可用性の落とし穴：EIPは“単体でHAにならない”
EIPの説明には「障害をマスクするために素早く付け替えられる」とあります。
ただし、ここで誤解しやすいのが「EIPを付けた＝高可用性」という思い込みです。
EIPフェイルオーバー設計が難しい理由
EIPを付け替えれば復旧できるとしても、実運用では次の壁が出ます。
- 付け替えを誰が、どう検知して、どう自動化するのか
手動は遅いし、夜間は止まりやすい。自動化は監視→判断→API操作が必要になり、運用コストが上がります。 - 片系が前提になりやすい
「普段はAに付け、障害時だけBへ」という設計は、B側が育たず、切り替え訓練もされず、本番で事故りがちです。
“固定IPが必要”かつ“HAも欲しい”なら候補を増やす
固定IPの要件がある場合でも、EIP一本槍にしない方が楽になる場面があります。
- AWS Global Acceleratorで静的IP＋冗長化の選択肢
仕組みとして“固定IPを持ちながら、背後のエンドポイントを切り替える”発想に寄せられます（細部はサービス設計で変わりますが、EIPより設計が素直になるケースがあります）。 - NLB/ALB＋Route 53設計へ寄せる
IP固定ではなく名前固定。可用性の主役をLBに置く。
SAA-C03的には、「EIPをどう頑張るか」より「EIPで頑張らなくて済む構成にできないか」を先に考えられると強いです。
運用の落とし穴：クォータ、棚卸し、解放漏れ
最後は地味だけど効く話です。小さなミスが、積み上がると手戻りになります。
デフォルトクォータにすぐ当たる
EIPにはリージョンごとのクォータがあり、デフォルトは1リージョンあたり5です。
検証を繰り返す人ほど、気づくと上限に達します。
また、NAT Gateway周りも絡みます。VPCのクォータ一覧には、public NAT gatewayあたりのEIP数なども載っています。
「NAT Gatewayを増やしたらEIPも必要になって、いつの間にかクォータに当たった」というのはありがちです。
棚卸しは“コスト最適化の基本動作”
EIPは「外したら終わり」ではなく、解放（release）して初めて片付くものです。AWS公式手順でも、EIPを解放する操作が明確に分かれています。
さらに、Public IPv4課金が始まってからは、IP利用状況を見える化する仕組み（Public IP Insightsなど）で“どこでIPv4を使っているか”を追えるように整理されています。
もう一段上：DRやアカウント移行でのEIP移転
災害対策やアカウント整理の文脈では、EIPをアカウント間で移転するユースケースも公式に用意されています。
ただし、これも「固定IPを守るために運用が複雑になる」方向なので、やるなら意図を明確にして設計するのが大切です。
学習を体系化したい人向け：Udemy教材の使いどころ
ここまでの内容は、単語暗記より「設計の判断軸」を作る話でした。SAA-C03の学習でも、この手の“判断が必要な論点”は、動画で一度体系的に整理してから演習に入るとブレにくくなります。
Udemyでも、VPC・EC2・LB・NAT・Route 53あたりをハンズオン込みで通し理解できる講座があります。例えば、以下のように使うと効率がいいです。
- 最初の1周目：ネットワークと公開方式（Public/Private、NAT、LB、DNS）を図で理解する
- 2周目：問題演習で「EIPを選ぶ/選ばない」の理由を言語化して確認する
- 仕上げ：自分の言葉で設計方針（固定IPが必要な条件、不要な条件）をまとめる
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
EIPは「固定IP」という分かりやすさの裏で、課金・設計・高可用性・運用の落とし穴が一気に詰まった要素です。
- いまはパブリックIPv4が原則課金で、EIPも in-use / idle ともに $0.005/時間が前提になる
- EIPは外しても残る。解放しない限り確保され続け、課金やクォータを圧迫しやすい
- 「EIPを付けた＝HA」ではない。HAの主役は、複数AZ・LB・自動復旧で、固定IP要件があるときだけEIPや別案を検討する
- クォータはデフォルト5/リージョン。NAT Gatewayなど周辺設計でもEIPが増えやすい
SAA-C03の勉強としては、「EIPとは何か」を覚えるより、**“固定IPが必要な要件か？”→“DNS/LB/GAなどに寄せられないか？”→“それでも必要ならEIPをどう運用するか？”**という順で判断できるようになるのが大きいです。
