🏨 たとえ話で理解する
NLBは「配達ルーティングセンター」🚚
インターネットから届いたパケット（荷物）を、どの宛先に届けるかを決める仕組みです
🌐
インターネット
荷物を送ってくる人
→
🏭
NLB
配達ルーティングセンター
「どこに届ける？」を決める
「どこに届ける？」を決める
→
📦
ターゲット
実際の配達先
instance or ip
instance or ip
⚖️ 2つのターゲットタイプ（同列・均等比較）
ターゲットタイプ 1
instance
EC2ノードに届ける
📮 たとえ話
「マンション棟（ノード）に荷物を届ける」棟の受付（NodePort）が受け取り、
中の部屋（Pod）に内線で転送する
パケットの流れ
🏭 NLB
→
🏢 EC2 Node
NodePort で受信
NodePort で受信
→
📦 Pod
✓
EC2インスタンスID をターゲットとして登録
✓
kube-proxy が NodePort → Pod へ転送（1ホップ追加）
✓
クラスター外から見ると「ノードのIP」が宛先
✓
設定がシンプル、既存クラスターにすぐ適用
💡 向いている場面
シンプルなk8s Service（type: LoadBalancer）EKS / self-managed どちらでも簡単に使える
ターゲットタイプ 2
ip
Pod IPに直接届ける
📬 たとえ話
「部屋番号（Pod IP）に直接届ける宅配便」棟の受付を介さず、
部屋のドア前（Pod）に直接ポスト投函
パケットの流れ
🏭 NLB
→
🔢 Pod IP
直接指定
直接指定
→
📦 Pod
✓
Pod の IP アドレスをターゲットとして登録
✓
NodePort を経由しないのでレイテンシが低い
✓
クライアントの送信元IPがPodに直接伝わる
✓
AWS Load Balancer Controller が必要（EKS推奨）
💡 向いている場面
パフォーマンス重視 / 送信元IP保持が必要な本番 EKS ワークロード
📊 詳細比較表
| 項目 | 🔵 instance | 🟠 ip |
|---|---|---|
| ターゲットの正体 | EC2インスタンスID | Pod のIPアドレス |
| ホップ数 | NLB → Node → Pod（2段） | NLB → Pod（1段） |
| NodePort 必要？ | ✅ 必要 | ❌ 不要 |
| 送信元IP 保持 | kube-proxyが変換（失われる場合あり） | Pod に直接伝わる |
| レイテンシ | やや高い（中継あり） | 低い（直接） |
| 設定の複雑さ | シンプル | LBコントローラー必要 |
| Podスケール追従 | ノード単位で追従 | Pod単位でリアルタイム追従 |
| 代表的な利用 | 汎用 k8s Service | EKS 本番環境 |
🤔 どっちを選ぶ？ 判断チャート
🔵 instance を選ぶとき
- クイックに試したい・学習目的
- EKS以外（self-managed）を使っている
- 送信元IPの保持が不要
- シンプルさを最優先したい
🟠 ip を選ぶとき
- EKS + AWS LB Controller 環境
- レイテンシを最小化したい
- 送信元IPをアプリで使いたい
- Podレベルの細かいヘルスチェックが必要