【AWS ELB】ALBでEC2へのトラフィック振り分け

Posted at 2025-07-10

目指すはコレ！

　インターネットからのトラフィックをApplication Load Balancer (ALB) で受け取り、複数のEC2インスタンスへ効率的かつセキュアに振り分けます。 ALBはパブリックサブネットに配置し、Webサーバーを動作させるEC2インスタンスはインターネットに直接接続されていないプライベートサブネットに配置する構成を目指します。各EC2インスタンスで異なるWebページを表示させ、ALBによる負荷分散の挙動をブラウザから確認します。

この構成のメリット

　この構成は、Webアプリケーションにおける負荷分散の強力な基盤となり、システムの安定稼働と効率性を大きく向上させます。

トラフィックの効率的な分散
ALBはユーザーからの大量のリクエストを複数のEC2インスタンスに均等に振り分けます。これにより、単一のインスタンスへの負荷集中を防ぎ、アクセスが急増しても各インスタンスが安定したパフォーマンスを維持しやすくなります。
システムの高可用性
ALBはバックエンドのEC2インスタンスのヘルス状態を常に監視し、異常を検知したインスタンスにはトラフィックをルーティングしません。これにより、仮に一部のインスタンスがダウンしても、残りの正常なインスタンスでサービス提供を継続できるため、ユーザー体験を損なうことなく、アプリケーション全体の可用性を高めます。

アーキテクチャ図

【ALBによるWebサーバー負荷分散アーキテクチャ】

ロードバランサーの種類について

ELB（Elastic Load Balancing）とは？？？

AWSが提供する負荷分散サービスの総称。アプリケーションへのアクセス集中を防ぎ、複数のサーバー（EC2インスタンスなど）へトラフィックを自動で分散させ、システムの安定稼働と高可用性を実現。
ELBには、4種類のロードバランサーがあり、現在よく利用されるのはALB（Application Load Balancer）、NLB（Network Load Balancer） の2つ。

ALB（Application Load Balancer）とは？？？

ELBが提供するロードバランサーの一種で、主にHTTP/HTTPS（Webアプリケーション）のトラフィック負荷分散に特化。リクエストに含まれるURLパスやHTTPヘッダーなど、アプリケーション層（レイヤー7）の情報に基づいて、柔軟なルーティングが可能。

NLB（Network Load Balancer）とは？？？

ELBが提供するロードバランサーの一種で、主にTCP、UDP、TLSトラフィックといったネットワーク層（レイヤー4）の負荷分散に特化。極めて高いパフォーマンスと低レイテンシーが特徴で、毎秒数百万のリクエストを処理可能。

手順

EC2インスタンスの準備
EC2インスタンス起動時にユーザーデータを使用して
HTMLをブラウザから確認する為のApacheをインストール・起動
ターゲットグループの作成
作成したEC2インスタンスをターゲットに設定し
ヘルスチェックなどの設定を行う
ALBの作成
ALBの作成を行う
トラフィックの振り分け確認
ブラウザから動作確認を行う
今回の学び
今回のハンズオンでの学び

EC2インスタンスの準備

　異なる2つのAZに、それぞれプライベートサブネットを作成し、そこに1つずつEC2インスタンスを起動します。
　ユーザーデータを使用して、EC2インスタンス起動時に自動でApacheのインストールと起動、ブラウザに表示させるindex.htmlの作成、ヘルスチェック用のhealthcheck.htmlの作成を行います。

ユーザーデータとは？？？

EC2インスタンスを起動する際に、一度だけ自動実行されるシェルスクリプトやPowerShellスクリプトのこと。OSのアップデート、Webサーバーやアプリケーションのインストール、設定ファイルの配置、必要なサービスの起動など、インスタンスの初期設定や環境構築を自動化するために利用される。これにより、手動での作業を減らし、インスタンスの起動から利用可能になるまでの時間を短縮し、一貫性を保つことができる。

※インスタンス起動前の事前準備※
インターネットに接続されていないプライベートサブネット内のEC2インスタンスからは、Apache のインストールはできません。そのため、S3ゲートウェイエンドポイントを作成しルートテーブルに関連付けることで、Amazon Linux の yum コマンドが依存する AWS管理の S3 バケットに保存されているパッケージメタデータへアクセスできるようにする必要があります。
→今回の学びを参照

　EC2インスタンスを起動する画面の一番下にある「高度な詳細」タブにユーザーデータを設定する項目があります。

【ユーザーデータ設定画面】

ユーザーデータ（EC2-A用）

#!/bin/bash
yum update -y # OSをアップデート (任意だが推奨)
yum install -y httpd # Apacheをインストール
systemctl start httpd # Apacheサービスを開始
systemctl enable httpd # システム起動時にApacheを自動起動

# EC2-A用の内容をindex.htmlに書き込む
echo "<html><body><h1>Hello from EC2-A!</h1></body></html>" > /var/www/html/index.html

# ヘルスチェック用のhtmlを作成
echo "OK" > /var/www/html/healthcheck.html

ユーザーデータ（EC2-B用）

#!/bin/bash
yum update -y # OSをアップデート (任意だが推奨)
yum install -y httpd # Apacheをインストール
systemctl start httpd # Apacheサービスを開始
systemctl enable httpd # システム起動時にApacheを自動起動

# EC2-B用の内容をindex.htmlに書き込む
echo "<html><body><h1>Hello from EC2-B!</h1></body></html>" > /var/www/html/index.html

# ヘルスチェック用のhtmlを作成
echo "OK" > /var/www/html/healthcheck.html

EC2インスタンス用セキュリティグループの作成

インバウンドルール
HTTP（80）接続の許可
「ソース」に後ほど作成するALBへアタッチするセキュリティグループのIDを指定
アウトバウンドルール
HTTPS（443）接続の許可
「送信先」にS3のプレフィックスリストIDを指定
プレフィックスリストID とは？？？
【セキュリティグループのアウトバウンド設定画面】

ターゲットグループの作成

ターゲットグループとは？？？

ロードバランサー（ALBやNLBなど）にトラフィックを分散させたいEC2インスタンスやIPアドレス、Lambda関数などをまとめた論理的なグループ。ロードバランサーは、このターゲットグループに登録されたリソースに対してトラフィックを転送し、定期的なヘルスチェックを通じて各リソースの状態を監視。これにより、正常なターゲットにのみリクエストが送られ、アプリケーションの高可用性が保たれる。

【設定情報】

基本的な設定
- ターゲットタイプの選択
  インスタンス
- ターゲットグループ名
  任意
- プロトコル／ポート
  HTTP／80
- IPアドレスタイプ
  IPv4
- VPC
  ハンズオンを行うVPCを指定
- プロトコルバージョン
  HTTP1
ヘルスチェック
- ヘルスチェックプロトコル
  HTTP
- ヘルスチェックパス
  /healthcheck.html
  → ロードバランサーがターゲットの正常性を確認するため、定期的にアクセスする特定のURLパス。このパスへのリクエストに対して、ターゲットがHTTPステータスコード200 (OK) を返せば、正常稼働中と判断される。
- ヘルスチェックの詳細設定
  デフォルト

　ターゲットグループの作成後に、起動した2つのEC2インスタンスをターゲットを登録することで、ヘルスチェックが行われ、EC2が正常稼働中か確認することができます。

ALBの作成

【設定情報】

ロードバランサータイプ
Application Load Balancer
基本的な設定
- ロードバランサー名
  任意
- スキーム
  インターネット向け
- ロードバランサーの IP アドレスタイプ
  IPv4
ネットワークマッピング
- VPC
  ハンズオンを行うVPCを指定
- IP プール
  チェック無し
- アベイラビリティーゾーンとサブネット
  EC2インスタンスを起動した2つのAZに、それぞれ1つずつパブリックサブネットを作成しそのサブネットを指定
  →ALBはインターネットからのアクセスを受けるためパブリックサブネットに配置
  また、可用性を高めるため少なくとも2つ以上のAZにあるパブリックサブネットに配置
セキュリティグループ（ALB用）
- インバウンドルール
  HTTP（80）接続の許可
  0.0.0.0/0（すべてのIPアドレス）からの、ポート80（HTTP）のトラフィックを許可
- アウトバウンドルール
  HTTP（80）接続の許可
  「送信先」にEC2へアタッチしたセキュリティグループのIDを指定
リスナーとルーティング
- プロトコル
  HTTP
- ポート
  80
- デフォルトアクション
  作成したターゲットグループを指定

リスナーとは？？？

ロードバランサーが着信接続リクエストを待機する「ポート」と「プロトコル」の組み合わせ。今回のハンズオンでは、「ポート80でHTTPリクエストを待機する」といった設定。リスナーは、受信したリクエストをどのターゲットグループに転送するかを決定するルールを持ち、これによりALBはトラフィックを適切に振り分ける。HTTPSトラフィックの場合は、SSL/TLS証明書もリスナーに関連付ける。

トラフィックの振り分け確認

ブラウザにて確認

　以下のURLで、ALB経由でプライベートサブネット内のEC２インスタンスへの接続が確認できます。

URL

http://作成したALBのDNS名

　今回のトラフィック振り分け方式はデフォルトの、リクエストを順番に正常なターゲットに均等にルーティングする「ラウンドロビン」 なので、ブラウザの更新ボタンを押下するたびに、「Hello from EC2-A!」と「Hello from EC2-B!」が交互に表示されます。
【ALB経由でのEC2-Aアクセス結果】

【ALB経由でのEC2-Bアクセス結果】

今回の学び

今回のハンズオンを通じて、特に以下の点で学びを深めることができました。

Amazon Linux リポジトリはAmazon S3バケットでホストされている
上記の理由から、S3用のゲートウェイエンドポイントを利用すれば
プライベートサブネット内のEC2インスタンスからでも
Apattchなどのソフトウェアをインストールできる！
（事前に今回使ったユーザーデータをパブリックサブネット内で利用して、Apacheがインストールされていることが確認できたので、何も考えずにプライベートサブネット内でも使えるだろうと考え、やってみたがうまくいかず。。。確かに、閉鎖された環境でどっからインストールすんねんって気づかされました）
[以下参考]
https://repost.aws/ja/knowledge-center/ec2-al1-al2-update-yum-without-internet?utm_source=chatgpt.com
Apacheのルートディレクトリ
ターゲットグループのヘルスチェックパスは、Apacheのドキュメントルート（デフォルトでは /var/www/html/）を基準に指定する必要がある。
→ヘルスチェックパスの「/」は「/var/www/html/」を意味する
（EC2インスタンスのパスから記載していたので、参照先のパスがなくヘルスチェックがずっと異常になっていた）
セキュリティグループ設定におけるプレフィックスリストIDの活用
インバウンド／アウトバウンドルールで、特定のAWSサービスへのトラフィックを許可したい場合、「ソース」にそのサービスのプレフィックスリストIDを指定することができる！（IPアドレスしか指定できないと思っていた）
【メリット】
セキュリティグループやネットワークACLのルールで、特定のAWSサービスへのアクセスを許可する際に、そのサービスのIPアドレス範囲を個別に手動で入力する必要がなくなる。手動でIPアドレスを入力すると、変更があった際にルールを更新し続ける必要があるが、プレフィックスリストIDであれば、AWSが自動的に最新のIPアドレス範囲を管理するので不要。

プレフィックスリストIDとは？？？

AWSが管理している特定のAWSサービスまたはリージョンのIPアドレス範囲をグループ化したもの。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up