※プレゼントキャンペーンは終了しました。ご応募ありがとうございました。

アイレット クラウドインテグレーション事業部の古屋です。
最近はクラフトビールにハマってます。新鮮なビールおいしい。

この記事は、iretスペシャリストによるブログリレーキャンペーン「iretスペシャリストからの挑戦状」の第1弾です。

クラウドをテーマにした技術ブログを2021年度の「iretスペシャリスト」に認定された5名がリレー形式で公開し、最後に出題されるクイズに全問正解した方の中から先着30名様にオリジナルエコバッグをプレゼントします。

iretスペシャリストとはなんぞや？スペシャリストってどんな人たちなの？などの疑問をお持ちの方は、こちらをご覧ください。

iretスペシャリスト認定制度について:https://www.iret.co.jp/recruit/specialist/
インタビュー記事: https://cloudpack.media/57265

私のブログのテーマは「AWS Network Load Balancer」です。

AWS Network Load Balancerとは

AWSで使えるLoad Balancerの種類はいくつかありますが、WebアプリケーションをAWS上で構築された方はApplication Load Balancer(ALB)が馴染み深いかと思います。
パスベースルーティング等、一般的なWebアプリケーションを運用する上で便利な機能が揃っていますしね。

一方Network Load Balancer(NLB)はL4のロードバランサであり、Webアプリケーションの前段でも使えますがどちらかというとTCPやUDPを使った、またはレイテンシにシビアなアプリケーションで使われることが多いと思います。
改めて、NLBの特徴をおさらいします。

固定IPアドレス
ALBと大きく違う点です。AZごとに固定IPを設定できます。

低レイテンシ
毎秒数百万のリクエストを低レイテンシで処理可能です。

TLSオフロード
あとから追加になった機能ですが、TLS証明書をオフロードできます。

今回はこのNLBを実際の案件でどのように使ったのか、また最新の機能についてお伝えします。

ネットワークをまたいだプライベート通信を行うケース

インターネット経由ではなく、AWSのネットワークの中に閉じた通信もしくは専用線経由の通信（ここではプライベートな通信と呼びます）を使ってVPC同士を接続する、および異なるVPCに存在するサービスにアクセスしたいという場合、まず思い浮かぶのがVPC Peeringによる接続です。

VPC同士をPeering接続し、ルートテーブルの設定を書けば特定のCIDRレンジへの通信を希望のVPCに流すことができます。

また、プライベートな通信でVPCにアクセスする場合、VPC同士であればVPNを使うこともできますし、オンプレミスからの接続の場合はVPNやDirect Connectを使います。
このような「VPCとVPC」や、「VPCとオンプレミス」を接続するときに気をつけないといけない点としてCIDRレンジが重複してはいけない、というものがあります。

レンジが重複している場合どこに通信していいかわからなくなってしまうため、VPC Peeringはそもそもレンジが同一または重複する場合、接続できません。
また、以前担当した案件で遭遇した例ですが、オンプレミスからの接続の場合に接続先のCIDRレンジが制限されており、かつ接続したいVPCが適切なCIDRレンジになっていないことがありました。

このように、CIDRレンジの制約によって特定のVPCやオンプレミスと直接接続ができないケースがあります。

PrivateLinkを使ったネットワーク間通信

それを解決するのがNLBをベースにしたPrivateLinkという機能です。
PrivateLinkを利用したインタフェースタイプのVPCエンドポイントを利用することでVPC間やVPC – オンプレミス間の通信をセキュアで簡単に行うことができます。

たとえば、下図のようにCIDRレンジが重複したVPCのサービスにアクセスしたい場合アクセスされる側のVPCでNLBおよびPrivateLinkを使ってサービスを公開しておき、アクセス元からは自身のVPC内に作成されたエンドポイント(IP: 10.0.0.xxx)にアクセスすることでサービスを利用することができます。

先程の例でもあったオンプレミスから接続可能なCIDRレンジが制限されている場合でも制限内のレンジでVPCを新たに作成し、そこにエンドポイントを作成することで任意のCIDRレンジで作成されたVPC内のサービスにアクセスすることができます。

実際このような構成で、対向側VPCにあるWebサービスにアクセスできました。
ただこのときの要件として、サービス側はパスベースのルーティングが必要だったためALBを使っており、このためNLB(PrivateLink)からALBへトラフィックを流す仕組みが必要でした。
この時点では後述の機能がなくNLBから直接ALBにアクセスできなかったため、NLBからALBへトラフィックを流すだけのリバースプロキシを作成していました。
ECS+Fargate上にhttpdコンテナを置くだけのシンプルな構成ですがこの部分の作り込みが必要でした。

余談ですが、ALBのIPをNLBのターゲットとして登録しておきLambdaで随時IPが変わってないかチェックし、変わっていたらNLBの設定を書き換えるという漢らしいソリューションもあったようです。
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/using-aws-lambda-to-enable-static-ip-addresses-for-application-load-balancers/

新機能！NLBのターゲットにALBが指定可能になりました

この構成をシンプルにできるアップデートがつい最近発表されました。
NLBから直接ALBをターゲットにできるようになったため、先程の構成でいうとECS+Fargateの部分がなくなり、よりイイ感じになります。
（構築しているときにこの機能が欲しかった。。。）

まとめ

Webアプリケーション中心に開発・構築をしているとあまり触る機会のないNLBですが、今回ご紹介したように、異なるネットワーク感をいい感じにつないでくれる便利なサービスです。
アップデートもかかりさらに使いやすくなりましたので、活用の機会を探していただければと思います。