AWS ELBについて

AWS Elastic Load Balancerには複数のLoadBalancerタイプが存在する。2021年6月時点で存在するのは以下の4種類

Application Load Balancer（ALB)
Network Load Balancer（NLB)
Gateway Load Balancer
Classic Load Balancer(CLB)

このうち新規利用するにあたってはCLBは推奨されておらずALBもしくはNLBを利用することになる。
Gateway Load Balancerはサードパーティのアプライアンスを利用する際に有用ということでALB・NLBと明らかに性格が異なる。

ALBはアプリケーションレイヤー、NLBはトランスポートレイヤーで機能するロードバランサという違いがあるが使おうと思えばどちらでも使えるというユースケースもあるのでその差異を明確にする。

この記事を書く背景

数年前までNLBは純粋にトランスポートレイヤーのロードバランサとして「スピードは速くスケーリング性能はALBよりも高いが特にHTTPS通信を処理することを前提としたとしたときにはALBと比べて圧倒的に機能不足」という印象だったが最近NLBについて調べた際、アプリケーションレイヤの処理に近いこともできるようになった印象を受けたので2021年6月時点でのALB・NLBの機能比較を行った。

機能比較

通信を受けるにあたっての機能

No	機能	ALB	NLB
1	リスナーに設定可能なプロトコル	HTTP/HTTPS	TCP/TLS/UDP/TCP_UDP(*1)
2	Internet向け/内部向けの選択	○	○
3	Global Acceleratorとの連携	○	○
4	カスタムドメインの利用(SSLオフロード）	○	○
5	セキュリティポリシーの設定（SSL利用時のみ）	○	○
6	SecurityGroupの設定	○	-
7	IPアドレスの固定	-	○
8	リスナールールの利用	○	-
9	固定レスポンスの返却	○	-
10	HTTP→HTTPSのリダイレクト	○	-

*1.1つのポートでTCPとUDPの両方をサポートする場合はTCP_UDPを選択する

2.バックエンドに通信する際の機能

No	機能	ALB	NLB	機能説明
1	ターゲットグループに設定可能なプロトコル	HTTP/HTTPS	TCP/TLS/UDP/TCP_UDP(*2)
2	ターゲットタイプ	インスタンス/IP/Lambda	インスタンス/IP
3	ヘルスチェックの設定	プロトコル＆パスと監視間隔・レスポンスコードの指定	プロトコル＆パスと監視間隔・レスポンスコードの指定(*3)
4	Connection　termination on deregistration	○	○	既存ターゲットへの通信を完了させてからターゲットの登録解除をするまでの猶予時間の設定
5	セッションスティッキー	○	○	冗長構成のシステムで同じクライアントからの通信を同じターゲットに送るための設定
6	プロキシプロトコル	○	○	Proxy Protocol v2を使って送信元・送信先などの情報をターゲットに送信する
7	Preserve Client IP addresses	○	○	クライアントIPの保存を有効にするかどうかの設定

*2.リスナーとの関係で設定できるプロトコルが変動する。詳細は以下表の通り。

（出典：https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay）

*3.ALBとの違いとしてHealthy threashold とUnhealthy threasholdを同一の値にする必要がある

3.その他の機能

No	機能	ALB	NLB
1	WAFのアタッチ	○	-
2	アクセスログの取得	○	△(*4)
3	リクエストのトレース	○	-

*4.リスナーでTLSを設定している場合のみ可能、但しL4レイヤーの情報のためALBのアクセスログと比べると情報のレベルは低い

ユースケースごとのサービス選定の例

上記の差異を受けてユースケースごとでALB・NLBのいずれを選択するかいくつか選定の例を記載する。

WebサイトでInternetからの通信を受ける場合

ALBを利用すべき。
理由はセキュリティ面（WAF・SecurtyGroup）、また、アクセスログで必要な情報が収集できる点を考慮してもALBをファーストチョイスにすべき。

但し、NLBはALB以上にスケーリング性能が高いので、もしセキュリティレベルが低くても問題がなく、突発的に大量の通信を処理するケースが見込まれる場合にはNLBの採用もあり得る。

APIGWとバックエンドの中継をする場合

NLBを利用する。
APIGWの機能仕様としてNLBだけが利用できるため。
（ALBからInternet経由でALBに通信させるということもできなくはないがかなり強引）

同一VPCの中でサーバ間通信の中継をする場合

例えばApache用のサーバ→Tomcat用のサーバに通信するようなケースにおいては、ALBでもNLBでもどちらでも良い。
突発的なスケーリングが必要な場合にはNLBを選択した方が良いが、できるだけわかりやすいログで見たい場合や、Internet側のLBにALBを利用していてInternet側も内部側も同じサービスで統一したいならALBでも、という程度か。

DirectConnectからAWS側のバックエンドに中継する場合

LBのIPアドレスを固定する必要がある場合にはNLBを利用する。

ALBを利用しようとする場合にはRoute53ResolverのInboundEndpointを作成し、接続元（オンプレミス環境など）でDNS Forwarder設定を行ってそのEndpointに対して名前解決の通信を行う必要がある。
そういった対応を行うことができない場合にはIPアドレスを固定する必要があるためNLBを利用することになる。

但し、その場合に懸念すべき事項としてNLBのIPアドレスはSubnetごとに割り振られる。
そのため複数AZにまたがってNLBを配置し可用性を高めた場合にはAZの数だけIPアドレスが払い出され、接続元はその中のどれかのIPアドレスに対して通信をすることになる。
利用しているIPアドレスを持つAZが障害となった場合には他AZが正常稼働していても通信不可となって接続元側で利用するIPアドレスの切り替えを行う必要がある。
（オンプレのLBでよくあるVirtualIPではない）

SFTPサーバなどHTTP以外のバックエンドに通信する場合

NLBを利用すべき。
ALBはHTTP・HTTPS専用のLBなのでそれ以外のプロトコルを利用する場合にはNLBを利用する。

#参考URL