【入門編】 NLBのセキュリティグループ連携（パケットフィルタリングの仕様） – クラウド＆コンテナネットワーク実践ガイド

こんにちは！クラウドやKubernetesのインフラ現場を駆け巡るSREの皆さん、そしてこれからインフラの仕組みを深く知りたいとワクワクしている初学者の皆さん、いつも本当にお疲れ様です。

クラウドの世界へ足を踏み入れたとき、最初にぶつかる大きな壁の一つが「ロードバランサー（負荷分散装置）」の仕組みではないでしょうか。中でも、AWSの「NLB（Network Load Balancer）」は、超高速かつ大量のトラフィックをさばくための頼もしい相棒です。

「パケットをガンガンさばくNLBに、セキュリティグループ（防火壁）が付けられるようになったらしいぞ！」と聞いて、喜び勇んで設定を試みたものの、「あれ？思った通りに通信が通らない……」「ステートフルって一体どういうこと？」と、現場で頭を抱えた経験はありませんか？

今回は、インフラの仕組みに初めて触れる方でもスッと腑に落ちるように、NLBとセキュリティグループの連携仕様について、身近な例えを交えながらじっくり紐解いていきましょう。一歩ずつ、丁寧に解説していくので安心してくださいね！

—

1. NLBとセキュリティグループ：現実世界に例えてみよう

まずは、NLB（Network Load Balancer）がネットワークの世界でどんな役割をしているのか、イメージを膨らませてみましょう。

郵便局の本局窓口に例えるNLB

想像してみてください。あなたの街に、世界中から大量の荷物が届く巨大な「中央郵便局（NLB）」があるとします。
この郵便局には、毎日ものすごい数のトラックがやってきます。局員（NLB）は、届いた荷物を一つひとつ細かく検品する暇はありません。「とにかくスピーディーに、裏で待機している配達員たち（バックエンドのEC2インスタンスやKubernetesのPod）へ荷物を振り分けること！」これが彼らの最大のミッションです。

従来のNLBは、この「郵便局の建物自体」にがっちりとした門限や警備員（セキュリティグループ）を直接配置することができませんでした。「届いた荷物は、とにかく中にいる配達員にパスする！」という、ちょっと無防備なところがあったのです。

しかし、近年のアップデートにより、NLB自体にもセキュリティグループを直接アタッチできるようになりました。これにより、郵便局の入口で「怪しいトラックはそもそも敷地に入れない」という強力な門限が作れるようになったというわけです。

—

2. 「ステートフル」なパケット制御ってなぁに？

セキュリティグループを語る上で絶対に外せないキーワードが、この「ステートフル（Stateful）」という仕組みです。なんだか難しそうな名前ですが、これも身近な例で考えると驚くほどシンプルですよ。

高級クラブの「会員制リスト」の例え

あなたは格式高い会員制クラブのドアマンです。

行き（リクエスト）のチェック: お客さんが店に入ろうとしたとき、あなたは「会員証はお持ちですか？」と厳重にチェックします（これがセキュリティグループのインバウンドルールです）。
帰り（レスポンス）のチェック: 無事に入店したお客さんが、用事を済ませて外に出ようとします。このとき、あなたは再び身分証のチェックをするでしょうか？

……いいえ、しませんよね。「さっき厳しい審査をクリアして中に入った人だ」と、あなたの頭（状態・State）に記憶されているからです。だから、帰りのドアはスッと開けて通してあげますよね。

これがステートフル（状態を保持する）の仕組みです。
AWSのセキュリティグループは、この「行き（インバウンド）」の許可さえ出してしまえば、そこから派生して出ていく「帰り（アウトバウンド）」の通信は、自動的に許可される優しい仕様になっています。自分で帰りのルール（アウトバウンド）をわざわざ書かなくていいのは、このおかげなんですね。

—

3. NLBにセキュリティグループを適用する際の重要な仕様

さて、ここからが少し実務的なお話になります。NLBにセキュリティグループを紐付けるとき、ネットワークの現場で「おや？」とハマりやすいポイントがいくつかあります。

ポイント①：ソースIP（送信元IP）の保持とクライアントの視点

NLBは、基本的にクライアントのIPアドレス（本当の送信元）をそのまま後ろのサーバーに届けてくれます（これを「クライアントIP保持」と呼びます）。
そのため、NLBのセキュリティグループでインバウンドルールを絞る際は、「どの国やどのIPからのアクセスを許可するか」を非常にクリアに意識する必要があります。

ポイント②：ロードバランサー自体の属性設定

NLBでセキュリティグループを有効にするには、NLBを作成または変更する際に、セキュリティグループを明示的にアタッチし、さらに適切な属性を有効にする必要があります。

それでは、実際にAWS CLIを使って、セキュリティグループが紐づいたNLBを作成する手順をコードで見てみましょう。もちろん、実務でそのままコピー＆ペーストして調整できるように丁寧なコメントを添えています。

# =====================================================================
タリア設定サンプル：セキュリティグループ連携型NLBの作成
=====================================================================

# 1. まず、NLB用に割り当てるセキュリティグループを作成します
# （例：インターネットからのHTTP/HTTPSトラフィックのみを許可する門限を設定）
aws ec2 create-security-group \
    --group-name "my-nlb-security-group" \
    --description "Security group for my high-performance NLB" \
    --vpc-id "vpc-0123456789abcdef0"

# 2. 作成したセキュリティグループに、インバウンドルール（入ってくる通信の許可）を追加します
# 今回は、世界中（0.0.0.0/0）からのポート80（HTTP）のアクセスを許可します
aws ec2 authorize-security-group-ingress \
    --group-id "sg-0123456789abcdef0" \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

# 3. 実際にNLBを作成し、先ほどのセキュリティグループをアタッチします
# --enable-security-group-for-nlb-with-elastic-ip-enabled などのフラグを意識しつつ構築します
aws elbv2 create-load-balancer \
    --name "my-super-nlb" \
    --subnets "subnet-aaaaa" "subnet-bbbbb" \
    --security-groups "sg-0123456789abcdef0" \
    --scheme internet-facing \
    --type network \
    --ip-address-type ipv4

—

4. トラブルシューティングの現場から：よくある落とし穴

SREとして現場を歩いていると、「セキュリティグループを設定したのに、なぜかパケットが通らない！」という悲鳴をよく耳にします。ここでは、初学者が陥りがちな代表的な罠を2つご紹介します。

トラブル例1：バックエンド（EC2やKubernetes）側のセキュリティグループとの二重チェック

「NLBのセキュリティグループで許可したから完璧！」と思いきや、後ろで待ち受けているEC2インスタンスやKubernetesのNode/Pod側のセキュリティグループが、NLBからの通信をブロックしているケースです。

解決のヒント:

パケットは「NLBの門」をくぐった後、さらに「バックエンドサーバーの門」を通る必要があります。バックエンド側では、NLBのセキュリティグループからの通信（またはNLBが存在するサブネットのCIDR）をしっかりと許可してあげましょう。

トラブル例2：クロスゾーン負荷分散とターゲットのヘルスチェック

NLBがマルチAZ（複数のデータセンター）にまたがって配置されている場合、片方のAZのセキュリティグループ設定に不備があると、そちら側のルートを通るパケットだけがブラックホールに吸い込まれたように消えていきます。
ターゲットのヘルスチェック（死活監視）が「Unhealthy（異常あり）」になってしまったら、まずはセキュリティグループのインバウンド・アウトバウンドのすれ違いがないかを疑ってみてください。

—

5. まとめ：安全で快適なクラウドネットワークの旅へ

今回は、NLBのセキュリティグループ連携とステートフルなパケット制御の仕組みについて、郵便局の例えや実務的な設定例を交えて解説してきました。

NLBのセキュリティグループは、いわば「巨大な郵便局の入口にある厳重な門限」。
ステートフルな仕組みのおかげで、行きを許可すれば帰りの通信は自動で通るスマートな設計になっている。
トラブルが起きたときは、「NLBの門」だけでなく「後ろのサーバーの門」という2段階のチェックポイントを疑うのがSREの定石。

ネットワークやインフラの世界は、一見すると冷たくて難しい用語の羅列に見えますが、こうして現実世界の仕組みに置き換えてみると、エンジニアたちの工夫や優しさがたくさん詰まっていることが分かりますよね。

この記事が、皆さんのクラウドインフラ学習や日々の開発業務のちょっとした道しるべになれば最高に嬉しいです。それでは、また次回の技術でお会いしましょう！安全で快適なクラウドライフを！