【入門編】 ALBのセキュリティグループ連携と送信元IP制限 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！SRE兼クラウドアーキテクトの私です。日々、AWSやGCPといった巨大な雲の上のインフラストラクチャと格闘しながら、Kubernetesのネットワークの波を乗りこなしています。

インフラの世界に飛び込んだばかりの頃って、次から次へと出てくる専門用語に圧倒されてしまいますよね。「セキュリティグループ？」「ロードバランサー？」「送信元IP？」。なんだか難しそうな壁がそびえ立っているように感じるかもしれませんが、一歩ずつ紐解いていけば、実は私たちの身の回りにある仕組みと全く同じなんです。

今回は、AWSの玄関口を守る超重要コンポーネントである「ALB（Application Load Balancer）のセキュリティグループ連携」について、現実世界の比喩をたっぷり交えながら、優しく、そして現場で使える実践的な知識としてお伝えしていきますね。

それでは、さっそく扉を開けていきましょう！

—

1. 郵便配達員とオートロックマンションに例える「ALBとバックエンドの関係」

まずは、私たちが構築するWebシステムの全体像を、身近な建物に例えてイメージしてみましょう。

インターネットの世界からやってくるユーザーのリクエストは、まるで「あなた宛ての手紙」です。この手紙を安全に、そして確実にお部屋（Webサーバー）まで届けるために、私たちのシステムには強力な門番がいます。それが ALB（Application Load Balancer） です。

そして、その奥で実際に手紙を読み解き、返事を作っているのがバックエンドの EC2（仮想サーバー） たちですね。

ここで、セキュリティを考える上で非常に大切な疑問が浮かびます。
「バックエンドのEC2（お部屋）へは、信頼できるALB（お抱えのコンシェルジュ）から届く手紙だけを受け取りたい。ネットの海から直接やってくる怪しい訪問者は、すべてシャットアウトしたい！」

これを実現するのが、今回メインで取り上げる「セキュリティグループ（SG）を用いた送信元IP制限」なんです。

—

2. セキュリティグループってなに？（超基本のおさらい）

一歩ずつ理解していきましょう！
AWSにおけるセキュリティグループ（Security Group）とは、いわばクラウド上のサーバーやルーターに巻きつける「デジタルな門限表」や「入館証のチェックルール」のようなものです。

インバウンドルール（受信ルール）： 「外から中に入るとき、誰のどんな通信を許可するか」
アウトバウンドルール（送信ルール）： 「中から外へ出るとき、どこへの通信を許可するか」

ALBにも、その後ろにいるEC2にも、それぞれこのセキュリティグループをペタッと貼り付けることができます。

従来の「IPアドレス直書き」が抱えるモヤモヤ

バックエンドのEC2側で「ALBからの通信だけを通したい！」と考えたとき、初心者の頃は「ALBのIPアドレスを調べて、EC2のインバウンドルールに直接書き込めばいいや！」と思いがちです。

でもちょっと待ってください。AWSのALBは、世界中のアクセスをさばくために、裏側で自動的にスケール（増殖・縮小）します。それに伴って、ALB自身のIPアドレスも裏側でペロリと変わってしまうことがあるのです。
「あれ？昨日まで動いていたのに、勝手にIPが変わって通信ができなくなったぞ！？」なんてトラブル、現場のエンジニア泣かせの典型例ですよね。

そこで登場するのが、「セキュリティグループ名（またはID）を直接指定する連携ワザ」です。

—

3. ベストプラクティス：SG同士をつなぐ「合言葉」の魔法

AWSのセキュリティグループのすごいところは、IPアドレスという数字の羅列だけでなく、「特定のセキュリティグループを持つ相手からの通信を丸ごと許可する」という指定ができる点です。

これを現実世界で例えるなら、こんな感じです。

「〇〇マンションの住人（ALB用のセキュリティグループ）から届いた荷物なら、部屋番号が変わっても無条件で受け取りますよ」という合言葉を玄関の扉に設定しておくイメージです。

これなら、ALBのIPアドレスが裏側でどう変動しようとも、ふたつのセキュリティグループが信頼関係を結んでいる限り、通信が途切れることはありません。なんともスマートで、運用に優しい仕組みですよね！

—

4. 実践！ハンズオンで学ぶ設定手順とコード例

それでは、このベストプラクティスを実際のクラウド環境（AWS）でどう表現するのか、具体的な手順と設定を見ていきましょう。
インフラの構成管理ツールとして今や必須となっている Terraform を使ったコード例で解説します。もちろん、AWSマネジメントコンソール（Web画面）でポチポチ設定する場合も考え方はまったく同じです。

ステップ1：ALB用のセキュリティグループを作る

まずは、インターネットの荒波に一番最初に立ち向かう、ALB用のセキュリティグループを作ります。HTTP（80番ポート）やHTTPS（443番ポート）を世界中に開放します。

# ALB用のセキュリティグループ（インターネットからの玄関口）
resource "aws_security_group" "alb_sg" {
  name        ="web-alb-sg"
  description = "Security group for Internet-facing Application Load Balancer"
  vpc_id      = aws_vpc.main.id

  # 世界中どこからでも、安全なHTTPS（443）通信を受け入れる
  ingress {
    description = "Allow HTTPS from the Internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # インターネット全体を許可
  }

  # ALBから外への通信はすべて自由（デフォルト）
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-alb-sg"
  }
}

ステップ2：EC2用のセキュリティグループを作り、ALBを指名する

次に、バックエンドのEC2（Webサーバー）にアタッチするセキュリティグループを作ります。ここが今回のキモです！インバウンドルールで「IPアドレス」ではなく、先ほど作ったALB用のセキュリティグループのIDを指定します。

# バックエンドEC2用のセキュリティグループ（お部屋の扉）
resource "aws_security_group" "ec2_sg" {
  name        ="web-ec2-sg"
  description = "Security group for Backend EC2 instances"
  vpc_id      = aws_vpc.main.id

  # 【超重要】「web-alb-sg」を持つ相手からの通信だけを許可する！
  ingress {
    description     = "Allow HTTP traffic only from the ALB"
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    
    # ここがポイント！IPアドレスではなく、ALBのセキュリティグループを指定する
    security_groups = [aws_security_group.alb_sg.id]
  }

  # データベース等への通信やパッチ当てのための外部通信を許可（適宜調整）
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-ec2-sg"
  }
}

この設定を行うことで、バックエンドのEC2は「ALB以外の直接アクセス（例えば、悪意ある攻撃者がEC2のパブリックIPを直接叩こうとする試みなど）」を、セキュリティグループのレベルで完全に拒絶することができるようになります。鉄壁の守りですね！

—

5. トラブルシューティング：現場でよくある「繋がらない！」の罠

最後に、現場のSREたちがよく遭遇する「あれ、ALB経由でWebサイトを見に行ったら 502 Bad Gateway エラーが出るぞ…？」という時の、リアルなトラブルシューティングの視点をお伝えします。

1. バックエンドのセキュリティグループが、本当にALBのSGを向いているか？

コンソール画面で、EC2のインバウンドルールを開き、送信元（Source）の欄がIPアドレスではなく、ちゃんと別のセキュリティグループ名（またはID）になっているか確認しましょう。

2. Webサーバー（NginxやApacheなど）がリクエストを受け付けるポート番号は合っているか？

ALBからEC2へ転送する際のターゲットグループの設定（例：ポート80番や8080番など）と、EC2側のセキュリティグループで許可しているポートが一致しているか、指さし確認が大切です。

3. そもそもEC2自体がプライベートサブネットにいるか？

セキュリティを万全にするなら、バックエンドのEC2はパブリックIPを持たせず、インターネットから直接見えないプライベートサブネットに配置するのがセオリーです。

—

まとめ

いかがでしたでしょうか？
今回は、クラウドインフラの基本でありながら非常に重要な「ALBのセキュリティグループ連携と送信元IP制限」について解説しました。

ALBはインターネットからの玄関口。
バックエンドのEC2は、IPアドレスではなく「ALBのセキュリティグループ」を名指しして許可する。
この設計にしておけば、ALBのIPが変化してもビクともしない堅牢なシステムが作れる。

インフラの世界は一見すると冷たいコードや記号の羅列に見えますが、その裏側には必ず「どうやって安全に、どうやってスムーズにデータを届けるか」という人間らしい設計思想が隠されています。

一つひとつの仕組みを丁寧に紐解いていけば、あなたも必ず頼れるクラウドエンジニア・SREになれますよ。一緒に楽しくインフラを育てていきましょう！