SAP-C02-078 · セクション 09 / タスク 2.4

Elastic Load BalancingとLoad Balancer選択

Application Load Balancer / Network Load Balancer / Gateway Load Balancer / Layer 7 / Layer 4 / ターゲットグループ / ヘルスチェック / 静的IP要件 / TLS / 高スループット / ネットワークアプライアンス

ゴール

ロードバランサーを、

ウェブだからALB
高速だからNLB
セキュリティだからGWLB

のような単語だけで選びません。

最初に通信要件を分解します。

HTTP / HTTPSの内容を見て
振り分ける必要があるか
↓
必要
→ Application Load Balancer

TCP / UDPなどの通信を
Layer 4で処理したいか

静的IPアドレスが必要か

大規模な接続負荷を
処理したいか
↓
必要
→ Network Load Balancer

ファイアウォールやIDS / IPSなどの
仮想ネットワークアプライアンスを
透過的に経由させたいか
↓
必要
→ Gateway Load Balancer

重要なのは、どのレイヤーの情報を使って、何を振り分けたいかです。

1. 3種類は処理する通信レイヤーが違う

ロードバランサー	主なレイヤー	主な判断軸
Application Load Balancer	Layer 7	HTTP / HTTPSの内容を見て振り分ける
Network Load Balancer	Layer 4	TCP / UDP系通信、静的IP、高スループット
Gateway Load Balancer	Layer 3	仮想ネットワークアプライアンスへ透過的に転送

現在のNetwork Load Balancerでは、ターゲットグループで、

TCP
TLS
UDP
TCP_UDP
QUIC
TCP_QUIC

を利用できます。

したがって、

NLB
=
TCPだけ

とは考えません。

2. Application Load Balancer：HTTPの内容を判断したい

Application Load BalancerはOSIモデルのLayer 7で動作します。

例えば、

/api/*
↓
API用ターゲットグループ

/images/*
↓
画像用ターゲットグループ

というURLパスによるルーティングができます。

また、

api.example.com
↓
API

shop.example.com
↓
ECサイト

のようなホスト名によるルーティングも可能です。

HTTPヘッダー、HTTPメソッド、クエリ文字列などを条件にすることもできます。

したがってALBの決定条件は、HTTP / HTTPSリクエストの内容を理解して処理先を選ぶ必要があることです。

3. ALBではターゲットグループによって処理先を分離する

ALBではリスナールールからターゲットグループへ転送します。

HTTPS : 443
     ↓
リスナー
     ↓
┌────────────────┐
│ /api/*         │
│      ↓         │
│ API用          │
│ ターゲット群   │
├────────────────┤
│ /images/*      │
│      ↓         │
│ 画像用         │
│ ターゲット群   │
└────────────────┘

ターゲットグループごとに、

転送先
プロトコル
ポート
ヘルスチェック

を分離できます。

ALBのターゲットタイプは、

instance
ip
lambda

です。例えばLambda関数もALBのターゲットとして登録できます。

4. ALBはgRPCの内容を理解してルーティングできる

ALBではターゲットグループのプロトコルバージョンとしてgRPCを利用できます。

gRPCリクエストについて、

パッケージ
サービス
メソッド

を解析して、適切なターゲットグループへ転送できます。

したがって、

gRPC
↓
必ずNLB

ではありません。

gRPCのアプリケーション情報に基づいて処理先を決めたいならALBを評価します。

5. Network Load Balancer：Layer 4の通信を扱う

Network Load Balancerは主にOSIモデルのLayer 4で通信を処理します。

現在のNLBでは、

TCP
TLS
UDP
TCP_UDP
QUIC
TCP_QUIC

を使用できます。

例えば、

独自TCPプロトコル
UDPサービス
QUIC通信
大量の接続

などで、HTTPの内容を解析する必要がない場合に候補になります。

6. 高スループットだけで機械的にNLBを選ばない

NLBは急激なトラフィック増加や大規模な接続負荷へ対応できます。

したがって、

非常に大きな接続負荷
+
Layer 7判断不要

なら強い候補です。

ただし、

トラフィック量が多い
↓
必ずNLB

ではありません。

大量のHTTP通信でも、

URLパス
ホスト名
HTTPヘッダー

を使って処理先を変える必要があるなら、Layer 7要件を優先してALBを評価します。

7. 静的IPアドレス要件ではNLBを評価する

Network Load Balancerは、有効化したアベイラビリティーゾーンごとに静的IPアドレスを持ちます。

インターネット向けNLBでは、作成時に各AZへElastic IPアドレスを割り当てることもできます。

例えば、

取引先ファイアウォール

接続先として許可する
IPv4アドレスを
事前登録する必要がある

なら、

Network Load Balancer
+
AZごとのElastic IP

を評価できます。

8. ALBのIPアドレスを利用者管理の固定EIPとは考えない

Application Load BalancerにもIPアドレスは存在します。

しかし、

利用者が
任意のElastic IPを
ALBへ固定

する方式ではありません。

そのため、取引先の許可リストへ利用者管理の固定IPを登録する必要があるならNLBなどの構成を評価します。

9. 静的IPとLayer 7の両方が必要ならNLB → ALBを評価する

次の要件を考えます。

取引先
↓
固定IPだけ許可可能

さらに

/api/*
/images/*
など
HTTP内容で振り分けたい

NLBだけではALBのようなURLパスベースの振り分けはできません。

一方、ALB単体では利用者管理のElastic IPを直接割り当てる構成にはできません。

そこで、

利用者
↓
Network Load Balancer
静的IP
↓
Application Load Balancer
Layer 7ルーティング
↓
アプリケーション

を評価できます。

NLBのターゲットタイプとしてalbを指定できます。この場合、NLB側ではTCPリスナーを使用します。

10. TLSはロードバランサー選択条件の1つとして扱う

TLSの暗号化方式そのものではなく、どのロードバランサーでTLS通信を扱う必要があるかを選択条件として確認します。

例えば、

静的IPが必要
+
Layer 7ルーティング不要
+
ロードバランサーでTLS終端

なら、

Network Load Balancer
+
TLSリスナー

を評価できます。

TLSをどこで終端するか、暗号化をどこまで維持するかという詳細設計は、既に扱ったTLS設計の知識を前提にします。

11. Gateway Load Balancer：通常のアプリケーション負荷分散ではない

Gateway Load Balancerは、通常のウェブサーバーやAPIサーバーへURL単位で通信を振り分けるためのロードバランサーではありません。

主な対象は、

ファイアウォール
IDS / IPS
ディープパケットインスペクション
その他の仮想ネットワークアプライアンス

です。

Gateway Load BalancerはOSIモデルのLayer 3で動作します。

通信
↓
Gateway Load Balancer
↓
正常なネットワークアプライアンス
↓
検査
↓
元の通信経路

という用途を考えます。

12. GWLBとアプライアンス間ではGENEVE / UDP 6081を使用する

Gateway Load Balancerと登録した仮想アプライアンスの間では、

GENEVE
UDP 6081

を使用します。

GWLBは元のパケットをGENEVEでカプセル化し、仮想アプライアンスへ渡します。

元のIPパケット
↓
GWLB
↓
GENEVEでカプセル化
↓
ファイアウォール
↓
カプセル化解除
↓
検査

したがって、GWLBと統合する仮想アプライアンスはGENEVEを処理できる必要があります。

13. Gateway Load Balancer Endpointとルートテーブルで検査経路へ入れる

GWLBを作成しただけでは、

VPC内の全通信
↓
自動的にGWLB経由

にはなりません。

サービス利用側VPCではGateway Load Balancer Endpointを利用できます。

アプリケーションVPC
↓
ルートテーブル
↓
Gateway Load Balancer Endpoint
↓
Gateway Load Balancer
↓
仮想アプライアンス

のように、ルートテーブルでGWLB Endpointを次ホップとして利用し、検査対象通信を経路へ組み込みます。

GWLB Endpointは、サービス利用側VPCと仮想アプライアンスを配置したVPCとの間でプライベートな接続を提供します。

14. ターゲットグループはロードバランサーとバックエンドの契約

ターゲットグループでは、

何を転送先にするか
どのプロトコル / ポートで送るか
どのヘルスチェックを使うか

を定義します。

例えばALBでは、

instance
ip
lambda

をターゲットタイプとして利用できます。

NLBでは通常のインスタンスやIPアドレスに加えて、

alb

を使用してApplication Load Balancerをターゲットにする構成もあります。

重要なのは、ロードバランサーの種類だけでなく、その後ろに何を登録するかも設計条件ということです。

15. ヘルスチェックの通信は利用者通信と同じとは限らない

ここでは正常性判定の詳細を再び扱うのではなく、利用者から受ける通信と正常性確認用の通信を分けられることを押さえます。

例えばNLBで、

利用者通信
UDP : 5000

正常性確認
HTTP : 8080 /health

とできます。

UDPやQUIC系のターゲットグループでも、

TCP
HTTP
HTTPS

によるヘルスチェックを利用できます。

したがって、

UDPサービス
↓
ヘルスチェックも
必ずUDP

ではありません。

16. 3種類を同じ判断軸で比較する

要件	主な候補	決定打
URLパス / ホスト名 / HTTPヘッダーなどで振り分け	ALB	Layer 7
gRPCの内容を理解してルーティング	ALB	アプリケーション層の情報
TCP / UDP / QUIC系通信	NLB	Layer 4
大規模な接続負荷	NLB	高スループット
AZ単位の静的IP / Elastic IP	NLB	静的IP要件
Layer 4でTLS終端	NLB	TLSリスナー
静的IP + HTTP内容ルーティング	NLB → ALB	Layer 4機能 + Layer 7機能
ファイアウォール / IDS / IPSの水平拡張	GWLB	ネットワークアプライアンス
VPC通信をアプライアンス検査へ組み込む	GWLB + GWLB Endpoint	ルートテーブルによる経路制御

17. シナリオ1：URLパスごとにマイクロサービスへ振り分ける

要件：

/api/orders/*
↓
注文サービス

/api/users/*
↓
ユーザーサービス

この場合はApplication Load Balancerを評価します。

決定条件は、HTTPのURLパスを理解してターゲットグループを選ぶことです。

18. シナリオ2：UDPサービスを大量接続で公開する

要件：

UDP
+
急激に増える大量トラフィック
+
HTTP内容の解析不要

ならNetwork Load Balancerを評価します。

ALBはこのUDP要件の候補ではありません。

19. シナリオ3：取引先の許可リストに固定IPが必要

要件：

取引先ファイアウォール
↓
接続先IPv4を
事前許可する必要あり

通信はTLS

Layer 7ルーティング不要

なら、

Network Load Balancer
+
Elastic IP
+
TLSリスナー

を評価できます。

20. シナリオ4：固定IPもパスルーティングも必要

要件：

固定IPだけ許可される

さらに

/api/*
/web/*
で
転送先を変更

なら、

Network Load Balancer
↓
Application Load Balancer

を評価できます。

21. シナリオ5：ファイアウォール群を水平拡張する

要件：

VPC通信
↓
仮想ファイアウォール群
↓
必ず検査

障害したアプライアンスは
経路から外したい

ならGateway Load Balancerを評価します。

さらに、

ルートテーブル
↓
Gateway Load Balancer Endpoint
↓
GWLB
↓
ファイアウォール群

として、検査対象通信をその経路へ入れます。

22. 混同ポイント

混同	正しい判断
HTTPなら必ずALB	Layer 7の情報で処理先を変える必要があるかを見る
高トラフィックなら必ずNLB	Layer 7判断が必要ならALBも評価
NLBはTCPだけ	UDP / QUIC系にも対応
ALBへ利用者所有のElastic IPを直接固定できる	固定EIP要件ならNLBなどを評価
静的IPが必要ならLayer 7ルーティングを諦める	NLBからALBへ転送できる
TLS通信ならALBだけ	NLBでもTLS終端可能
GWLB = 高性能なNLB	GWLBはネットワークアプライアンス向け
GWLBを作れば自動的に全通信を検査	GWLB Endpointとルートテーブルで経路へ組み込む
ALBのターゲットはEC2だけ	instance / ip / lambdaを利用可能
UDPサービスならUDPヘルスチェックが必要	NLBではTCP / HTTP / HTTPSで正常性確認できる

23. SAP-C02判断フロー

ロードバランサーが必要
↓
何を見て転送先を決める？
│
├─ HTTP / HTTPSの内容
│   ├─ ホスト名
│   ├─ URLパス
│   ├─ HTTPヘッダー
│   └─ gRPC情報
│        ↓
│      ALB
│
├─ Layer 4通信
│   ├─ TCP
│   ├─ UDP
│   ├─ QUIC系
│   ├─ 静的IP
│   └─ 大規模接続
│        ↓
│      NLB
│
└─ IPパケットを
    ファイアウォール / IDS / IPSへ
    透過的に通す
         ↓
       GWLB
         ↓
    GWLB Endpoint
    + ルートテーブル

さらに
↓
静的IP + Layer 7の両方？
↓
NLB → ALBを評価

TLS終端要件は？
↓
必要に応じて
TLSリスナーなどを選択

最後に
↓
ターゲットグループ
+
ヘルスチェック
を通信要件に合わせる

まとめ

Elastic Load Balancingの選択では、

負荷分散したい
↓
どれでもよい

ではありません。

まず、

Layer 7の内容を見るのか
Layer 4通信として扱うのか
ネットワークアプライアンスへ通すのか

を分けます。

そのうえで、

静的IP
TLS終端位置
通信プロトコル
スループット
ターゲットタイプ
正常性確認

を追加条件として確認します。

最終的には、

ALB
=
アプリケーション内容を理解して振り分ける

NLB
=
Layer 4通信・静的IP・高スループット

GWLB
=
仮想ネットワークアプライアンス

という責任の違いから判断します。

主要AWS公式資料

AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
Elastic Load Balancing — 各ロードバランサーの概要
Application Load Balancer — ターゲットグループ
Network Load Balancer — リスナー
Network Load Balancer — ターゲットグループ
Network Load Balancer — ターゲットとしてApplication Load Balancerを使用する
Gateway Load Balancer — 概要
Gateway Load Balancer — ターゲットグループ
Gateway Load Balancer — 使用開始方法

理解確認

このページの内容を10問で確認します。

理解確認10問へ →