AWS Network Load Balancer(NLB)のソースIPとターゲットのセキュリティグループ留意点まとめ

ども、大瀧です。
AWSの新しいL4ロードバランサとしてNetwork Load Balancer(以下NLB)が登場して3ヶ月、いくつかのアップデートを経てNLBの機能はだいぶ様変わりしてきました。というわけで、ここらでNLBのソースIPに関する挙動とターゲットのセキュリティグループについてまとめておきたいと思います。

おことわり : 本記事の記載内容は独自に検証したものであり、AWSが公表している仕様ではない点、ご注意ください。実際の挙動と同じであることを保証したり、それについて責任を負うものでもありません。

用語の定義と前提要件

まずはこのあとの説明のためのたたき台として、用語と要件を先に示しておきます。NLBの基本的な動きは以下です。

クライアントからロードバランサに届いたリクエストをターゲットに転送、ターゲットのレスポンスをロードバランサがクライアントに返すというシンプルなフローですね。ここで言うソースIPは、ロードバランサがターゲットに渡すトラフィックにおけるソースIPを指すこととします。

ちなみに、NATぽいとかDSRぽいといった既存のLBとの比較は、今回は扱いません。NLBはあくまでNLBですw

ソースIPの挙動

NLBのリリース当初はソースIPはクライアントIPアドレスのままターゲットに届くという挙動でしたが、その後の機能追加でその挙動は既に少数派になっています。現在のNLBは、指定できるターゲットグループのタイプが2つあり、インスタンスタイプとIPタイプでソースIPの挙動が変わります。さらに、異AWSアカウントや異VPCにプライベート接続を提供するPrivateLinkを経由しても挙動が変わります。表にまとめました。

ソースIPは、多くのケースでNLBのPrivate IPになることがわかりますね。ターゲットからの戻りトラフィックのルーティング設計としては、NLBのPrivate IPへの疎通性を確保すればよいだけなので、こちらの方が設計はシンプルに済ませられそうです。

また、IPタイプはPrivate IPの直指定なのでEC2インスタンスとの組み合わせはあまり実用的ではありませんが、最近リリースされたAWS FargateといったENIに紐付くサービスでIPタイプが採用されています。今後もENIを利用するサービスでIPタイプが利用されるケースが増えるのでは、と予想します。

ちなみに、PrivateLinkはNLBに追加で設定するものなので、PrivateLink経由とNLB直接アクセスは共存可能です。とはいえ、インスタンスタイプだと挙動が異なるトラフィックを共通のターゲットで扱うことになるので、運用しにくいかもしれませんね。

セキュリティグループの考慮点

一方で、ソースIPはターゲットに設定するセキュリティグループの許可リストに影響します。

2023年8月追記 NLBがセキュリティグループをサポートしたため、他のELBと同様セキュリティグループ単位でのアクセス制限が可能になりました。以下の考慮点は不要になっています。

クライアントIPの場合は、ターゲットのセキュリティグループでクライアントIPのCIDRとトラフィックの宛先ポートを許可しないと通信できません。インターネット向けのサービスであれば必然的に0.0.0.0/0を指定することになります。

NLBのPrivate IPの場合は、ターゲットのセキュリティグループでNLBを配置するサブネットのCIDRと宛先ポートを許可すればOKです。一見するとセキュアな設定に見えますが、ターゲットからはクライアントIPがわからず、かつNLBにはセキュリティグループが設定できないため、インターネット向けでなくとも実質0.0.0.0/0からの通信を許可することになります。セキュリティグループでは拠点のグローバルIPのみ許可、といったことができない点に注意してください。PrivateLink経由の場合はVPCエンドポイントにセキュリティグループが紐づけられるので、そちらで許可リストを設定することができます。

まとめ

NLBのソースIPに関する挙動と、ターゲットのセキュリティグループについてまとめてみました。PrivateLinkはNLBが必須なので、PrivateLinkを使い倒すためには避けては通れないところです。皆さんもどんどん検証してNLBの理解を深めていきましょう！

参考URL

• Target Groups for Your Network Load Balancers - Elastic Load Balancing