L4 超低レイテンシ・UDP 対応・PrivateLink 統合ロードバランサー
概要
NLB が解決する課題
主な特徴（Feature Matrix）
アーキテクチャ
コアコンポーネント詳細
PrivateLink 統合（SaaS サービス公開）
セキュリティグループ（2023 年 8 月 GA）
主要ユースケース（12+）
設定例（CLI / SDK / IaC）
類似サービス比較（2025 年）
ベストプラクティス（✅/❌）
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例
導入ロードマップ
まとめ

Network Load Balancer (NLB) 完全ガイド v2.0

L4 超低レイテンシ・UDP 対応・PrivateLink 統合ロードバランサー

概要

Network Load Balancer（NLB） は AWS が提供する L4（トランスポート層）ロードバランサー です。TCP/UDP/TLS トラフィックの超低レイテンシ処理（数百マイクロ秒）、毎秒数百万リクエスト処理、固定 Elastic IP による静的アドレス公開を実現。HTTP ヘッダー解析なしにパケットを高速転送するため、ゲームサーバー・オンライン金融・リアルタイム通信・PrivateLink サービスエンドポイントなど、レイテンシと固定 IP が必須のユースケースに最適化されています。

定義と本質

Network Load Balancer は以下を約束するロードバランサー：

超低レイテンシ：L4 で TCP/UDP をパススルー、数百マイクロ秒の遅延
固定 IP：各 AZ に Elastic IP 割り当て、IP ホワイトリスト登録可能
毎秒数百万 RPS：新規接続・既存接続の高スループット処理
UDP 対応：DNS・ゲーム・RADIUS など UDP トラフィック対応
PrivateLink：VPC エンドポイントサービスのフロントエンド必須

初心者向けメモ

NLB は「高速・固定 IP のロードバランサー」です。ALB は HTTP リクエストを「URL パスを見て振り分ける」という高度なルーティングができますが、NLB は「TCP/UDP パケットを素早く転送する」だけ。代わりに、固定 IP が使える・UDP が対応・遅延がないというメリットがあります。

NLB が解決する課題

課題	ALB・CLB では困る理由	NLB の解決
固定 IP が必要（IP ホワイトリスト）	ALB は DNS で動的 IP	Elastic IP で各 AZ に固定アドレス割り当て
超低レイテンシ要件（ゲーム・金融）	ALB は HTTP 解析で ms 単位の遅延	L4 パススルーでマイクロ秒レベル
UDP ロードバランシング	ALB / CLB は HTTP/HTTPS のみ	NLB が UDP をネイティブ対応
PrivateLink サービス公開	ALB は PrivateLink に非対応	NLB が必須コンポーネント
毎秒数百万リクエスト	ALB は HTTP レイヤーで処理コスト	NLB は L4 で軽量処理

主な特徴（Feature Matrix）

特徴	説明	v2.0 キーポイント
L4 ロードバランシング	TCP / UDP / TLS リスナーで動作	HTTP ヘッダー解析なし
固定 Elastic IP	各 AZ に自動割り当て可能	IP ホワイトリスト登録用
UDP サポート	DNS / ゲーム / RADIUS など	ALB との差別化機能
超低レイテンシ	数百マイクロ秒のレスポンス	RTS ゲーム・高周波取引向き
毎秒数百万 RPS	NLCU（Network LCU）で課金	スループット保証
PrivateLink	VPC エンドポイントサービス必須	SaaS の安全な公開
Source IP 保持	クライアント IP をそのままターゲットに	X-Forwarded-For 不要
クロスゾーン負荷分散	AZ 間での自動分散（有料）	設定で有効・無効切り替え
セキュリティグループ	2023 年 8 月 GA	NLB 自体に SG 関連付け可能
TLS リスナー	ACM 証明書で TLS 終端	SSL/TLS オフロード
Health Check	TCP / HTTP / HTTPS / UDP 対応	ターゲットの生存確認
Connection Draining	Graceful Shutdown 対応	既存接続の完了を待機

アーキテクチャ

図1：NLB のネットワークフロー・固定 IP 構成

graph TB
    subgraph Internet["インターネット"]
        Client1["クライアント 1<br/>203.0.113.0"]
        Client2["クライアント 2<br/>203.0.113.1"]
    end

    subgraph NLB["Network Load Balancer<br/>internet-facing"]
        NLBAZ1["NLB ノード（AZ-a）<br/>固定 IP: 52.1.2.3"]
        NLBAZ2["NLB ノード（AZ-c）<br/>固定 IP: 52.4.5.6"]
    end

    subgraph Targets["ターゲットグループ"]
        T1["ターゲット 1<br/>10.0.1.10:8080<br/>AZ-a"]
        T2["ターゲット 2<br/>10.0.2.20:8080<br/>AZ-c"]
        T3["ターゲット 3<br/>10.0.3.30:8080<br/>AZ-d"]
    end

    Client1 -->|TCP 443| NLBAZ1
    Client2 -->|TCP 443| NLBAZ2

    NLBAZ1 -->|source IP 保持<br/>203.0.113.0| T1
    NLBAZ1 -->|クロスゾーン有効なら| T2
    NLBAZ2 -->|source IP 保持<br/>203.0.113.1| T2
    NLBAZ2 -->|クロスゾーン有効なら| T3

    style NLBAZ1 fill:#ff6b6b
    style NLBAZ2 fill:#ff6b6b
    style T1 fill:#4dabf7
    style T2 fill:#4dabf7
    style T3 fill:#4dabf7

図2：ALB / NLB / GWLB 比較アーキテクチャ

graph LR
    subgraph ALB_Arch["ALB (L7)"]
        ALBClient["HTTP/HTTPS<br/>WebSocket"]
        ALBLogic["URL / Host<br/>Header 解析"]
        ALBTG1["API サービス"]
        ALBTG2["Web サービス"]

        ALBClient --> ALBLogic
        ALBLogic -->|/api/*| ALBTG1
        ALBLogic -->|/web/*| ALBTG2
    end

    subgraph NLB_Arch["NLB (L4)"]
        NLBClient["TCP / UDP<br/>TLS"]
        NLBPass["パススルー<br/>ポートのみ判定"]
        NLBTG1["ゲームサーバー 1"]
        NLBTG2["ゲームサーバー 2"]

        NLBClient -->|ポート解析のみ| NLBPass
        NLBPass -->|:7777| NLBTG1
        NLBPass -->|:7778| NLBTG2
    end

    style ALBLogic fill:#ffd93d
    style NLBPass fill:#ffd93d

コアコンポーネント詳細

1. リスナー設定

NLB が受け付けるプロトコル・ポートを定義。複数リスナーをサポート。

# TCP リスナー（ポート 80）
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:... \
  --protocol TCP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:...

# TLS リスナー（ポート 443）
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol TLS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:... \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=arn:...

# UDP リスナー（DNS / ゲーム）
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol UDP \
  --port 53 \
  --default-actions Type=forward,TargetGroupArn=arn:...

# TCP_UDP リスナー（同一ポートで TCP と UDP 両対応）
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol TCP_UDP \
  --port 3784 \
  --default-actions Type=forward,TargetGroupArn=arn:...

2. ターゲットグループ

ロードバランサーが振り分ける先の論理グループ。ヘルスチェック・登録解除のタイムアウトを管理。

# TCP ターゲットグループ
aws elbv2 create-target-group \
  --name tcp-service \
  --protocol TCP \
  --port 8080 \
  --vpc-id vpc-xxx \
  --target-type instance \
  --health-check-protocol TCP \
  --health-check-interval-seconds 10 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2

# UDP ターゲットグループ
aws elbv2 create-target-group \
  --name udp-dns \
  --protocol UDP \
  --port 53 \
  --vpc-id vpc-xxx \
  --target-type instance \
  --health-check-protocol UDP \
  --health-check-path /health

# IP ターゲットグループ（ECS Fargate / Lambda）
aws elbv2 create-target-group \
  --name container-service \
  --protocol TCP \
  --port 8080 \
  --vpc-id vpc-xxx \
  --target-type ip  # ip は awsvpc ネットワークモード必須

3. ターゲット登録

# EC2 インスタンスをターゲットに登録
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:... \
  --targets Id=i-1234567890abcdef0,Port=8080

# ECS Fargate タスク（IP ターゲット）
aws elbv2 register-targets \
  --target-group-arn arn:... \
  --targets Id=10.0.1.10,Port=8080 Id=10.0.2.20,Port=8080

# Lambda（同期呼び出し）
aws elbv2 register-targets \
  --target-group-arn arn:... \
  --targets Id=arn:aws:lambda:ap-northeast-1:123456789:function:my-handler

4. ヘルスチェック設定

# TCP ヘルスチェック（3-way handshake のみ）
aws elbv2 modify-target-group \
  --target-group-arn arn:... \
  --health-check-protocol TCP \
  --health-check-interval-seconds 10 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2

# HTTP ヘルスチェック（ステータスコード確認）
aws elbv2 modify-target-group \
  --target-group-arn arn:... \
  --health-check-protocol HTTP \
  --health-check-path /health \
  --matcher HttpCode=200,201 \
  --health-check-interval-seconds 10

# UDP ヘルスチェック
aws elbv2 modify-target-group \
  --target-group-arn arn:... \
  --health-check-protocol UDP \
  --health-check-interval-seconds 10

5. クロスゾーン負荷分散（AZ 間分散）

# クロスゾーン負荷分散有効化
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

# 有効化時の影響：
# - コスト：AZ 間データ転送料金 $0.01/GB 発生
# - パフォーマンス：全 AZ にいるターゲットに均等分散
# - 推奨：ECS Fargate（AZ 間に均等配置）で有効化

# 無効化（デフォルト）：
# aws elbv2 modify-load-balancer-attributes \
#   --load-balancer-arn arn:... \
#   --attributes Key=load_balancing.cross_zone.enabled,Value=false
#
# - 各 AZ のターゲットに地元トラフィック振り分け
# - AZ 間データ転送料金なし
# - 注意：片方の AZ がターゲット多いと不均衡

PrivateLink 統合（SaaS サービス公開）

パターン：SaaS プロバイダーが NLB を PrivateLink サービスで公開

SaaS プロバイダー側：
    EC2 / ECS アプリケーション
        ↓
    NLB（サービスのフロントエンド）
        ↓
    VPC エンドポイントサービス設定
        ↓
    顧客 AWS アカウントに 許可を出す

顧客側：
    VPC エンドポイント（Interface 型）を作成
        ↓
    プライベート IP で SaaS に接続
    ※ インターネット経由なし
    ※ VPC ピアリング / TGW 不要

セットアップ例

# SaaS 側：VPC エンドポイントサービス設定
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:... \
  --acceptance-required

# 顧客を許可リストに追加
aws ec2 modify-vpc-endpoint-service-configuration \
  --service-configuration-id vpce-svc-xxx \
  --add-allowed-principals arn:aws:iam::customer-account-id:root

# 顧客側：VPC エンドポイント作成
aws ec2 create-vpc-endpoint \
  --service-name com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxx \
  --vpc-id vpc-customer \
  --subnet-ids subnet-a subnet-b \
  --security-group-ids sg-xxx

# 顧客が SaaS API にアクセス
# 例：https://my-saas-endpoint.vpc-endpoint-id.vpce.amazonaws.com/api/v1/resource

メリット

セキュア：プライベート接続（インターネット経由なし）
スケーラブル：複数顧客を同一 NLB でサービス
簡単：顧客側は VPC エンドポイント作成のみ

セキュリティグループ（2023 年 8 月 GA）

NLB への SG 関連付け

# NLB 作成時にセキュリティグループを指定
aws elbv2 create-load-balancer \
  --name my-nlb \
  --type network \
  --subnets subnet-aaa subnet-bbb \
  --security-groups sg-xxx  # ここで SG を指定

# 既存 NLB に SG を設定（新規作成時のみ）
# ※ 既存 NLB への SG 追加は不可（作成時のみ）

# セキュリティグループルール例
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxx \
  --protocol tcp \
  --port 443 \
  --cidr 10.0.0.0/8  # VPC CIDR のみ許可

aws ec2 authorize-security-group-ingress \
  --group-id sg-xxx \
  --protocol udp \
  --port 53 \
  --cidr 203.0.113.0/24  # 特定の外部ネットワーク

注意点

NLB のセキュリティグループは 作成時のみ指定可能（後付け不可）

ターゲットのセキュリティグループは 別途設定が必要

# ターゲット SG にはルール追加が必須
aws ec2 authorize-security-group-ingress \
  --group-id sg-target \
  --source-security-group-id sg-nlb-sg \
  --protocol tcp \
  --port 8080

主要ユースケース（12+）

#	ユースケース	プロトコル	特徴
1	ゲームサーバー負荷分散	UDP	超低レイテンシ、Source IP 保持
2	金融・高周波取引	TCP / TLS	マイクロ秒遅延、固定 IP
3	DNS サーバー	UDP	port 53 マルチ AZ
4	VoIP・リアルタイム通信	UDP	リアルタイムトラフィック
5	RADIUS 認証	UDP	IoT / VPN デバイス認証
6	IoT デバイス接続	TCP / MQTT	数百万接続スケール
7	QUIC / HTTP/3	UDP	次世代プロトコル
8	PrivateLink SaaS	TCP / TLS	顧客への安全な API 公開
9	IP ホワイトリスト	TCP / UDP	固定 IP でパートナー連携
10	複数 AZ HA	全て	自動フェイルオーバー
11	マイクロサービス（gRPC）	TCP	Protocol Buffers
12	エッジコンピューティング	TCP / UDP	Outposts での低遅延

設定例（CLI / SDK / IaC）

AWS CLI：完全な NLB セットアップ

#!/bin/bash

# 1. NLB 作成
NLB_ARN=$(aws elbv2 create-load-balancer \
  --name my-nlb \
  --type network \
  --scheme internet-facing \
  --ip-address-type ipv4 \
  --subnets subnet-aaa subnet-bbb \
  --tags Key=Environment,Value=production \
  --query 'LoadBalancers[0].LoadBalancerArn' \
  --output text)

# 2. ターゲットグループ作成
TG_ARN=$(aws elbv2 create-target-group \
  --name my-nlb-tg \
  --protocol TCP \
  --port 8080 \
  --vpc-id vpc-xxx \
  --target-type instance \
  --health-check-protocol TCP \
  --health-check-interval-seconds 10 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2 \
  --query 'TargetGroups[0].TargetGroupArn' \
  --output text)

# 3. ターゲット登録
aws elbv2 register-targets \
  --target-group-arn $TG_ARN \
  --targets Id=i-1234567890abcdef0,Port=8080 Id=i-0987654321fedcba0,Port=8080

# 4. リスナー作成
aws elbv2 create-listener \
  --load-balancer-arn $NLB_ARN \
  --protocol TCP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

# 5. クロスゾーン有効化
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn $NLB_ARN \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

CloudFormation テンプレート

Resources:
  MyNLB:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: my-nlb
      Type: network
      Scheme: internet-facing
      IpAddressType: ipv4
      Subnets:
        - subnet-aaa
        - subnet-bbb
      Tags:
        - Key: Environment
          Value: production

  MyTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: my-nlb-tg
      Port: 8080
      Protocol: TCP
      VpcId: vpc-xxx
      TargetType: instance
      HealthCheckEnabled: true
      HealthCheckProtocol: TCP
      HealthCheckIntervalSeconds: 10
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      Targets:
        - Id: i-1234567890abcdef0
          Port: 8080
        - Id: i-0987654321fedcba0
          Port: 8080

  MyListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref MyNLB
      Port: 80
      Protocol: TCP
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref MyTargetGroup

  CrossZoneAttribute:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancerAttribute
    Properties:
      LoadBalancerArn: !Ref MyNLB
      Attributes:
        - Key: load_balancing.cross_zone.enabled
          Value: 'true'

Terraform

resource "aws_lb" "nlb" {
  name               = "my-nlb"
  internal           = false
  load_balancer_type = "network"
  ip_address_type    = "ipv4"
  subnets            = ["subnet-aaa", "subnet-bbb"]

  enable_cross_zone_load_balancing = true

  tags = {
    Environment = "production"
  }
}

resource "aws_lb_target_group" "nlb_tg" {
  name        = "my-nlb-tg"
  port        = 8080
  protocol    = "TCP"
  vpc_id      = "vpc-xxx"
  target_type = "instance"

  health_check {
    healthy_threshold   = 2
    unhealthy_threshold = 2
    timeout             = 3
    interval            = 10
    protocol            = "TCP"
  }

  tags = {
    Name = "my-nlb-tg"
  }
}

resource "aws_lb_target_group_attachment" "instance1" {
  target_group_arn = aws_lb_target_group.nlb_tg.arn
  target_id        = "i-1234567890abcdef0"
  port             = 8080
}

resource "aws_lb_listener" "nlb_listener" {
  load_balancer_arn = aws_lb.nlb.arn
  port              = "80"
  protocol          = "TCP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.nlb_tg.arn
  }
}

類似サービス比較（2025 年）

観点	NLB	ALB	GWLB	CLB	HAProxy	Envoy
プロトコル	TCP/UDP/TLS	HTTP/HTTPS/WS	IP パケット	TCP/HTTP	TCP	TCP/HTTP/gRPC
レイテンシ	数百 μs	数 ms	数 ms	数 ms	数 ms	数 ms
固定 IP	✅	❌	❌	❌	△	❌
UDP	✅	❌	❌	❌	✅	△
PrivateLink	✅	❌	❌	❌	❌	❌
管理	AWS マネージド	AWS マネージド	AWS マネージド	AWS マネージド	セルフ	セルフ
スケーリング	自動	自動	自動	手動	手動	手動
AWS 統合	★★★★★	★★★★★	★★★★	★★★	★★	★★

ベストプラクティス（✅/❌）

選択・設計

✅ DO：

ゲーム・金融・リアルタイムなら NLB を選択（レイテンシ重視）
固定 IP が必要なら NLB（ALB は動的 IP）
UDP プロトコルなら NLB（ALB は非対応）
PrivateLink でサービス公開するなら NLB（必須）
ECS Fargate で複数 AZ に均等配置ならクロスゾーン有効化

❌ DON’T：

HTTP/HTTPS の URL ルーティングに NLB を選択 → ALB を使用
NLB に AWS WAF を設置 → WAF は ALB / CloudFront / API Gateway のみ
ターゲットに Lambda を使用して HTTP リクエスト多数 → ALB / API Gateway を使用
Security Group を後付け → NLB は作成時のみ SG 指定可能
クロスゾーン有効化でコスト確認なし → AZ 間転送料金 $0.01/GB 発生

パフォーマンス

✅ DO：

Health Check は TCP / UDP で軽量にする
Connection Draining を設定（Graceful Shutdown）
複数 AZ にターゲット配置（冗長性）
監視：Target Response Time / Active Connection Count

❌ DON’T：

HTTP Health Check（遅い）→ TCP Health Check で十分
Health Check Timeout を短く設定 → 10 秒が標準
ターゲット 1 台に集中 → 複数 AZ に分散

コスト

✅ DO：

NLCU（Network LCU）= 新規接続数・既存接続・帯域幅の最大値
低 RPS なら Serverless 検討（複数言語・ユースケース向け）
クロスゾーン無効化（片 AZ に集中可能なら）
不使用のターゲットグループを削除

❌ DON’T：

クロスゾーン有効化でコスト管理忘れ → AZ 間転送料金注視
複数リッスナーを無計画作成 → ターゲットグループ数が増加
Elastic IP を複数割り当て（使用しないまま）

トラブルシューティング

症状	原因	解決策
接続できない	SG ルール不足、ターゲット未登録	SG ルール・ターゲット登録確認
遅延が大きい	ターゲットが遠い AZ、クロスゾーン無効	クロスゾーン有効化検討
ターゲットがアンヘルシー	Health Check 失敗	ターゲット応答・SG ルール確認
コスト急増	クロスゾーン有効化で AZ 間転送	クロスゾーン無効化 / 設定見直し
WAF が設置できない	NLB は WAF 未対応	ALB に変更 / WAF は別途アプリで対応

2025-2026 最新動向

セキュリティグループ（2023 年 8 月〜）

NLB 自体にセキュリティグループを関連付け可能に
作成時のみ指定（後付け不可）

UDP サポート継続強化

QUIC / HTTP/3 での実績増加
ゲームサーバー・IoT での採用拡大

PrivateLink SaaS 展開

PrivateLink による SaaS 公開の事例増加
VPC Endpoint Service で複数顧客への安全な配信

学習リソース

公式ドキュメント

AWS ブログ・記事

OSSツール

実装例

小規模（ゲームサーバー）

構成：NLB + EC2 × 2 台（UDP）
コスト：$50～100/月
用途：カジュアルゲーム（数千プレイヤー）

構成：
- NLB（UDP ポート 7777）
- EC2 ゲームサーバー × 2（AZ-a, AZ-c）
- Health Check：UDP

中規模（PrivateLink SaaS）

構成：NLB + PrivateLink + ECS Fargate × 3
コスト：$500～1,000/月
用途：決済 API（複数顧客へプライベート公開）

流れ：
1. NLB を VPC エンドポイントサービス設定
2. 顧客アカウントに 許可
3. 顧客が VPC エンドポイント作成
4. プライベート接続で API アクセス

大規模（金融・高周波取引）

構成：NLB（TLS） + EC2 × 6（専用インスタンス）
コスト：$3,000+/月
用途：超低遅延取引プラットフォーム

特性：
- 固定 Elastic IP で IP ホワイトリスト登録
- TLS で暗号化通信
- マイクロ秒レベルのレイテンシ
- 複数 AZ で冗長化

導入ロードマップ

フェーズ 1：PoC（1 週間）

[ ] NLB ドメイン作成
[ ] TCP / UDP リスナー設定
[ ] ターゲットグループ・登録
[ ] Health Check 動作確認

フェーズ 2：パイロット（1～2 週間）

[ ] 本番 NLB 構築（複数 AZ）
[ ] セキュリティグループ設定
[ ] Elastic IP 割り当て・確認
[ ] PrivateLink / IP ホワイトリスト（必要に応じて）
[ ] バックアップ・復旧テスト

フェーズ 3：本番化（1～2 週間）

[ ] トラフィック段階的移行
[ ] 監視・アラート設定（CloudWatch）
[ ] Connection Draining・Health Check チューニング

フェーズ 4：最適化（継続）

[ ] NLCU 使用量分析・コスト最適化
[ ] クロスゾーン設定見直し（コスト vs 分散）

まとめ

Network Load Balancer は 超低レイテンシ・UDP・固定 IP・PrivateLink の統合ロードバランサーです。L4 パススルーで数百マイクロ秒遅延を実現し、ゲームサーバー・オンライン金融・リアルタイム通信・PrivateLink SaaS など、ALB では対応できないユースケースを強力にサポート。

2025 年のセキュリティグループ統合により、ネットワークセキュリティがさらに強化。固定 IP を活かしたパートナー企業との安全な連携・PrivateLink によるプライベート API 公開が、デジタル化時代の企業間連携を加速します。

参考文献

AWS 公式ドキュメント

AWS ブログ・アナウンス

OSSリファレンス・比較

最終更新：2026-04-26 バージョン：v2.0

目次

Network Load Balancer (NLB) 完全ガイド v2.0

L4 超低レイテンシ・UDP 対応・PrivateLink 統合ロードバランサー

概要

定義と本質

初心者向けメモ

NLB が解決する課題

主な特徴（Feature Matrix）

アーキテクチャ

図1：NLB のネットワークフロー・固定 IP 構成

図2：ALB / NLB / GWLB 比較アーキテクチャ

コアコンポーネント詳細

1. リスナー設定

2. ターゲットグループ

3. ターゲット登録

4. ヘルスチェック設定

5. クロスゾーン負荷分散（AZ 間分散）

PrivateLink 統合（SaaS サービス公開）

パターン：SaaS プロバイダーが NLB を PrivateLink サービスで公開

セットアップ例

メリット

セキュリティグループ（2023 年 8 月 GA）

NLB への SG 関連付け

注意点

主要ユースケース（12+）

設定例（CLI / SDK / IaC）

AWS CLI：完全な NLB セットアップ

CloudFormation テンプレート

Terraform

類似サービス比較（2025 年）

ベストプラクティス（✅/❌）

選択・設計

パフォーマンス

コスト

トラブルシューティング

2025-2026 最新動向

セキュリティグループ（2023 年 8 月〜）

UDP サポート継続強化

PrivateLink SaaS 展開

学習リソース

公式ドキュメント

AWS ブログ・記事

OSSツール

実装例

小規模（ゲームサーバー）

中規模（PrivateLink SaaS）

大規模（金融・高周波取引）

導入ロードマップ

フェーズ 1：PoC（1 週間）

フェーズ 2：パイロット（1～2 週間）

フェーズ 3：本番化（1～2 週間）

フェーズ 4：最適化（継続）

まとめ

参考文献

AWS 公式ドキュメント

AWS ブログ・アナウンス

OSSリファレンス・比較