---
title: "Elastic Load Balancingとは？ELBとALBの違い・4種類の使い分けと料金・設定を解説"
url: "https://www.issoh.co.jp/column/details/2893/"
published: 2024-07-02
updated: 2026-10-21
categories: ["インフラ"]
publisher: "株式会社一創"
---

# Elastic Load Balancingとは？ELBとALBの違い・4種類の使い分けと料金・設定を解説

「ALBとELBは何が違うのか」という疑問には、2通りの答え方があります。現在のAWSでELB（Elastic Load Balancing）はロードバランサー4種類の総称で、ALBはその1種類です。一方、古い資料や現場の会話で「ELB」と書かれているものは、2009年に提供が始まった初代、今のCLB（Classic Load Balancer）を指していることがあります。この記事では両方の意味でALBとの違いを整理したうえで、4種類の使い分け、東京リージョンの料金、ALBのリスナールールの上限、502・503・504エラーの切り分けまでを、AWS公式ドキュメントの現行仕様（2026年10月時点）で解説します。

## まとめ：Elastic Load Balancingは4種類の総称でALBはHTTP向けの一種類

- **ELB（Elastic Load Balancing）**はAWSのロードバランシングサービスの総称で、**ALB・NLB・GWLB・CLB**の4種類を含みます。「ELB」という単体の製品はありません。
- 「ELB」が**CLB**を指す場合の違いは、ALBがURLパス・ホスト名・HTTPヘッダーで振り分けられ、HTTP/2・gRPC・WebSocket・SNI・Lambdaターゲット・認証に対応している点です。CLBはどれも持ちません。
- HTTP/HTTPSのアプリケーションなら**ALB**、静的IPやTCP/UDPの低遅延が要るなら**NLB**を選びます。CLBは既存環境の維持だけに使います。
- ALBの料金は時間料金とキャパシティユニット（LCU）の従量で、東京リージョンのALBは1時間0.0243ドルです（Price List API 2026年9月11日版）。本体を置いておくだけで月17.7ドル前後かかります。
- ALBのリスナールールは1台100個まで（緩和可）。1ルールの条件値5個・ワイルドカード6個は緩和できません。

## Elastic Load Balancing（ELB）の仕組みとALBとの関係

### ELBの4種類と負荷に応じた容量の自動拡張

[AWS公式のユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)は、Elastic Load Balancingを「受信トラフィックを、1つ以上のアベイラビリティゾーン（AZ）にあるEC2インスタンス・コンテナ・IPアドレスなどの複数のターゲットへ自動で分散するサービス」と定義しています。正常なターゲットだけに送り、トラフィックの増減に合わせてロードバランサー自身の容量も拡張します。本体の冗長化とスケールをAWSに任せられる点が、自前の負荷分散サーバーとの違いです。ALB（Application Load Balancer）は、このELBに含まれるHTTP/HTTPS向けの種類です。L4とL7の違いやラウンドロビンなどの振り分け方式から押さえたい場合は、[ロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説【2026年版】](/tech/details/13137/)で一般論を確認してください。

### AZごとのノード・ヘルスチェック・DNSで動くELB共通の基本構造

ELBは有効にしたAZごとに「ロードバランサーノード」を作り、クライアントはDNS名を名前解決して返ってきたノードのIPアドレスへ接続します。[ELBの動作説明ページ](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html)によると、このDNSレコードのTTLは60秒で、ノードのIPアドレスは負荷に応じて入れ替わります。そのため独自ドメインはAレコードにIPを書かず、[Amazon Route 53とは：DNS・ドメイン登録・ルーティング設計とAWS CLI構築手順を実装者目線で解説](/tech/details/15471/)で扱うエイリアスレコードでロードバランサーのDNS名に向けます。ALBは2つ以上のAZを有効にすることが必須です。

| 種類   | クロスゾーン負荷分散の既定         | 振り分けアルゴリズム               |
| ---- | --------------------- | ------------------------ |
| ALB  | 常時有効（ターゲットグループで無効化可）  | ラウンドロビン（既定）              |
| NLB  | 無効（作成後に変更可）           | フローハッシュ                  |
| GWLB | 無効（作成後に変更可）           | 5タプルのフローハッシュ             |
| CLB  | CLI・APIでは無効、コンソールでは有効 | TCP：ラウンドロビン／HTTP：最少未処理要求 |

[ALBのヘルスチェック仕様](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)では、ターゲット種別がinstance・ipで、プロトコルバージョンがHTTP/1.1またはHTTP/2のときの既定は間隔30秒・タイムアウト5秒・異常判定2回連続・正常復帰5回連続・成功コード200・パス`/`です。既定のままだと、ターゲットが落ちてから切り離されるまで最大で約1分かかります。ターゲットグループ内の全ターゲットが異常になると、ALBは「フェイルオープン」して全ターゲットへ送り続けます。理由コード別の対処は[ELBヘルスチェックの設定と失敗原因の調べ方｜ALB・NLBの既定値と理由コード](/tech/details/18067/)にまとめています。

### 「ELB」がCLBを指す理由と2009年当時の名称から続く用語のずれ

2009年にAWSが提供したロードバランサーは1種類だけで、単に「Elastic Load Balancing」と呼ばれていました。2016年にALBが加わったときに初代はClassic Load Balancer（CLB）と呼び分けられ、ELBは複数の種類を束ねるサービス名になりました。古い資料や現場で「ELB＝CLB」の意味が残っているのはこのためです。APIも世代で分かれていて、ALB・NLB・GWLBは`elbv2`（API version 2015-12-01）、CLBは`elb`（2012-06-01）です。CLIのコマンドが`aws elbv2`と`aws elb`に分かれているのも同じ理由で、`aws elb describe-load-balancers`に出てくるのはCLBだけです。

## ALBとCLB（旧ELB）の違い：公式の機能比較で見る移行の判断材料

「ELB」が旧来のCLBを指している資料や会話では、ALBとの違いはALBとCLBの機能差のことです。この比較には、AWSの[Elastic Load Balancing features](https://aws.amazon.com/elasticloadbalancing/features/)の比較表がそのまま使えます。主な項目を抜き出すと次のとおりです。

| 項目                   | ALB              | CLB（旧ELB）              |
| -------------------- | ---------------- | ---------------------- |
| 動作階層                 | L7               | L4／L7                  |
| リスナーのプロトコル           | HTTP・HTTPS       | TCP・SSL/TLS・HTTP・HTTPS |
| パス・ホスト・ヘッダーでの振り分け    | 対応               | 非対応                    |
| リダイレクト・固定レスポンス       | 対応               | 非対応                    |
| HTTP/2・gRPC          | 対応               | 非対応                    |
| WebSocket            | 対応               | 非対応                    |
| SNI（1リスナーに複数証明書）     | 対応               | 非対応                    |
| ターゲットの種類             | インスタンス・IP・Lambda | EC2インスタンス              |
| IPv6（デュアルスタック）       | 対応               | 非対応（IPv4のみ）            |
| ユーザー認証（Cognito・OIDC） | 対応               | 非対応                    |
| 同一インスタンスの複数ポート       | 対応               | 非対応                    |
| 東京の時間料金              | 0.0243ドル         | 0.027ドル                |

IPv6の可否は[ELBの動作説明ページ](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html)のIPアドレス種別の表によります。CLBの方が勝っている項目はほとんどありません。比較表でCLBだけに付いているのは、暗号スイートを自分で組み合わせる「カスタムセキュリティポリシー」くらいです。新規構築ではALBかNLBを選びます。既存CLBの移行では、時間料金だけでなく、通信方式、TLSポリシー、移行後の従量料金と切り替え作業を確認します。

移行には、EC2コンソールのCLB画面から使える[移行ウィザード](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html)があります。ただし、このウィザードはCLBを変換するのではなく、同じ設定のALBかNLBを新しく作るだけです。トラフィックの切り替え（DNSの向け先変更）は自分で行います。ALBへ移行する場合は、CLBのサブネットが1つだけなら2つ目のサブネットの指定が必要で、カスタムのセキュリティポリシーは新しいロードバランサーの既定ポリシーに置き換わります。TLSの要件が厳しいシステムでは、切り替え前に新しいALBのセキュリティポリシーを確認してください。

## ELBの4種類（ALB・NLB・GWLB・CLB）の違いと要件別の使い分け方

4種類は動作する階層と扱えるプロトコルが違い、そこから用途が決まります。新規構築なら、HTTPアプリケーションはALB、TCP/UDPの低遅延通信や静的IPが要る通信はNLBが基本です。

| 種類   | 階層    | 主なプロトコル            | 静的IP           | 主な用途             |
| ---- | ----- | ------------------ | -------------- | ---------------- |
| ALB  | L7    | HTTP・HTTPS（gRPC可）  | 非対応            | Web・API・マイクロサービス |
| NLB  | L4    | TCP・UDP・TLS        | 対応（Elastic IP） | 低遅延通信・IP許可リスト    |
| GWLB | L3    | IP（GENEVE）         | 非対応            | ファイアウォール・IDS/IPS |
| CLB  | L4／L7 | TCP・SSL・HTTP・HTTPS | 非対応            | 既存環境の維持          |

### ALB：HTTP/HTTPSのコンテンツルーティングとWAF・認証を担うL7

ALBはHTTP/HTTPSを解釈するL7ロードバランサーで、URLパス（`/api/*`）・ホスト名・HTTPヘッダー・クエリ文字列でリクエストを振り分けられる唯一の種類です。AWS WAFの適用やCognito・OIDCによる認証もリスナー側で構成できます。HTTP/2はHTTPSリスナーでのみ使え、1接続で並列に送れるリクエストは最大128です。2025年11月には、リクエストヘッダーのJWTの署名・有効期限・クレームをALBで検証する[JWT検証](https://aws.amazon.com/about-aws/whats-new/2025/11/application-load-balancer-jwt-verification/)（サービス間通信のOAuth 2.0クライアントクレデンシャル向け）と、ターゲットごとの同時リクエスト数に上限を設ける[Target Optimizer](https://aws.amazon.com/about-aws/whats-new/2025/11/aws-application-load-balancer-target-optimizer/)が加わりました。Target Optimizerはターゲット側でAWS提供のエージェントを動かす方式で、有効にしたターゲットグループはLCUの消費が通常より多くなり、WebSocketも使えません。推論のように1件の処理が重いワークロード向けの機能です。

### NLB：TCP/UDP通信の負荷分散とElastic IPによる静的IP

NLBはL4で動作し、TCP・UDPの通信を転送します。TLSリスナーではTLSを終端し、暗号化したまま通す場合はTCPリスナーを使います。ALBにない静的IP（Elastic IPの割り当て）を持てるため、取引先のファイアウォールでIP許可リストを組む必要があるときはNLBを選びます。1本のTCP接続は切れるまで同じターゲットへ送られ、送信元IPもターゲットまで保持できます。2025年11月にはQUICのパススルーに対応し、QUICのコネクションIDで、クライアントのIPが変わっても同じターゲットへ送り続けられるようになりました。2026年7月にはNLBにも[リスナールール](https://aws.amazon.com/about-aws/whats-new/2026/07/aws-network-load-balancer-supports-listener-rules/)が入りました。ただし条件は送信元IPアドレスの種別（IPv4かIPv6か）だけで、デュアルスタックのNLB 1台でIPv4とIPv6を別のターゲットグループへ分けるための機能です。パスやホスト名で振り分けたいならALBが必要という前提は変わりません。

### GWLB：ファイアウォールやIDS/IPSを経路へ透過挿入するL3専用

GWLB（Gateway Load Balancer）は、サードパーティのファイアウォールやIDS/IPSといった仮想アプライアンスを通信経路へ透過的に挟むための専用ロードバランサーです。GENEVEプロトコル（ポート6081）で検査機器へパケットを渡し、同じフローは常に同じアプライアンスへ届けます。ルートテーブルのエントリで経路に入れる仕組みで、一般的なWeb・APIの負荷分散には使いません。

## ELBの料金体系：東京リージョンの時間料金とLCU課金の目安

### 4種類の時間料金とキャパシティユニット単価（2026年9月時点）

ELBに初期費用はなく、基本料金は稼働時間と処理量で決まります。処理量はALB・NLB・GWLBではキャパシティユニット、CLBではGB単位で課金されます。AWSの[Price List APIの東京リージョン（ap-northeast-1）料金ファイル](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/ap-northeast-1/index.json)（publicationDate 2026-09-11）から単価を取り出すと次のとおりです。課金の考え方は[Elastic Load Balancingの料金ページ](https://aws.amazon.com/elasticloadbalancing/pricing/)にあります。

| 種類   | 時間料金（1時間） | 処理量の単価         | 固定分（730時間） |
| ---- | --------- | -------------- | ---------- |
| ALB  | 0.0243ドル  | 0.008ドル／LCU時間  | 約17.7ドル    |
| NLB  | 0.0243ドル  | 0.006ドル／NLCU時間 | 約17.7ドル    |
| GWLB | 0.0135ドル  | 0.004ドル／GLCU時間 | 約9.9ドル     |
| CLB  | 0.027ドル   | 0.008ドル／GB     | 約19.7ドル    |

ALBで相互TLS（mTLS）を使う場合は、トラストストアを関連付けている時間に1時間0.0054ドルが加わります。検証環境のALBを消し忘れると、トラフィックがゼロでも1台あたり月17ドル台が積み上がります。表の固定分はロードバランサー本体の時間料金だけで、インターネット向けのロードバランサーが使うパブリックIPv4アドレスの料金（VPCの料金表で課金）やデータ転送料金は別にかかります。環境ごとにALBを分けるより、ホスト名ルールで1台にまとめるほうが固定費は下がります。単価は改定されることがあるので、見積もりの直前に料金ページで取り直してください。

### ALBのLCUを決める4指標と配信・ルール評価で料金が膨らむ構成パターン

ALBの1LCUは次の4指標の上限量で定義され、1時間のうち最も消費の大きかった1指標のLCU数で課金されます。

- 新規接続数：毎秒25接続（HTTPSではRSA鍵2,048ビット以下、ECDSA鍵256ビット以下の場合。鍵サイズが大きい証明書では換算値が異なります）
- アクティブ接続数：毎分3,000接続（相互TLS使用時は1,500）
- 処理バイト数：EC2・コンテナ・IPターゲットは1時間1GB、Lambdaターゲットは1時間0.4GB
- ルール評価数：毎秒1,000評価（最初の10ルールは無料）

画像や動画など転送量の大きい構成では、処理バイト数がLCU料金を押し上げます。画像や動画をALB経由で返すと1時間1GBの枠をすぐ超えるため、静的ファイルはCloudFrontとS3に逃がします。次に効くのがルール評価数で、ルールを数十本並べたリスナーに高頻度のリクエストが来ると、無料の10ルールを超えた評価がLCUを押し上げます。ALB・NLB・GWLBにはLCUを事前に確保する「LCU予約」もありますが、予約分は使わなくても課金されます。

## ALBの構成要素：リスナー・ルール・ターゲットグループの流れ

ALBでは、リクエストが「リスナー → ルール → ターゲットグループ」の順に流れます。リスナーは指定したプロトコル（HTTPかHTTPS）とポート（1〜65535）で接続を待ち受ける入口で、1つも無いとALBはトラフィックを受け取れません。HTTPSリスナーには証明書を置いて暗号化・復号をALBに任せます。証明書は[AWS Certificate Managerとは？有効期間198日化とACME対応・料金と採用判断を実装者目線で解説](/tech/details/15898/)で扱うACMのパブリック証明書を無料で使えます。各リスナーには必ずデフォルトアクションがあり、どのルールにも一致しなかったリクエストはここで処理されます。

ルールは「条件」と「アクション」の組で、一致したリクエストをforward（ターゲットグループへ転送）・redirect・fixed-response（固定レスポンス）のいずれかで処理します。ターゲットグループはEC2・コンテナ・Lambda・IPアドレスをまとめた単位で、ヘルスチェックもここに設定します。EC2をAuto Scalingグループと組めば、インスタンスの起動・終了に合わせてターゲットの登録と解除が自動で行われます（EC2側の構成は[Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説](/tech/details/15424/)）。コンテナなら[ECSでDockerコンテナを動かす手順：ECRへのpush・タスク定義・料金とEKSとの違い【2026年10月】](/tech/details/3870/)のECSサービスの前段にALBを置き、パスごとに別のコンテナへ振り分ける構成が典型です。

## AWS CLIでALBを作成する手順：ターゲットグループからリスナーまで

AWS CLIの認証と対象リージョンの設定、既存VPC、異なる2つのAZのパブリックサブネット、通信を許可したセキュリティグループ、同じリージョンの発行済みACM証明書、8080番で稼働するEC2上のアプリを前提に、HTTPSのALBを作る最小手順です。引数は[AWS CLIのelbv2リファレンス](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-load-balancer.html)に合わせています。IDやARNは自分の環境の値に置き換えてください。

```
# 1. ターゲットグループを作る（ヘルスチェックは専用パスに向ける）
TG_ARN=$(aws elbv2 create-target-group \
  --name web-tg --protocol HTTP --port 8080 \
  --vpc-id vpc-0123456789abcdef0 --target-type instance \
  --health-check-path /healthz --matcher HttpCode=200 \
  --query 'TargetGroups[0].TargetGroupArn' --output text)

# 2. ALB本体を作る（2つ以上のAZのサブネットが必須）
ALB_ARN=$(aws elbv2 create-load-balancer \
  --name web-alb --type application --scheme internet-facing \
  --subnets subnet-0aaa1111bbbb2222c subnet-0ddd3333eeee4444f \
  --security-groups sg-0123456789abcdef0 \
  --query 'LoadBalancers[0].LoadBalancerArn' --output text)

# 3. EC2インスタンスをターゲットとして登録する
aws elbv2 register-targets --target-group-arn "$TG_ARN" \
  --targets Id=i-0123456789abcdef0 Id=i-0fedcba9876543210

# 4. HTTPSリスナーを作り、既定の転送先をターゲットグループにする
aws elbv2 create-listener --load-balancer-arn "$ALB_ARN" \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/EXAMPLE \
  --default-actions Type=forward,TargetGroupArn="$TG_ARN"

# 5. ターゲットのヘルス状態を確かめる（healthyになれば受付開始）
aws elbv2 describe-target-health --target-group-arn "$TG_ARN"
```

手順5でunhealthyのまま進まないときは理由コードを見ます。`Target.Timeout`ならセキュリティグループでALBからターゲットのポートへの通信が許可されていない、`Target.ResponseCodeMismatch`ならヘルスチェックのパスが200以外を返している、という切り分けが典型です。HTTPの80番はHTTPSへのredirectだけを持つリスナーにしておき、本番ではこの手順をCloudFormationやTerraformのコードに落とします。

## ALBリスナールールの設定：条件6種類・優先度・上限クォータの実務

### 条件（コンディション）6種類の振り分け基準とマッチ方式の違い

リスナールールの条件は6種類です。1つのルールでは、host-header・http-request-method・path-pattern・source-ipを各1つまで、http-headerとquery-stringを複数まで組み合わせられます。

| 条件タイプ               | 振り分けの基準      | マッチ方式        |
| ------------------- | ------------ | ------------ |
| host-header         | ホスト名         | ワイルドカード／正規表現 |
| path-pattern        | URLのパス       | ワイルドカード／正規表現 |
| http-header         | 任意のHTTPヘッダー値 | ワイルドカード／正規表現 |
| http-request-method | HTTPメソッド     | 完全一致         |
| query-string        | クエリ文字列のキーと値  | ワイルドカード      |
| source-ip           | 送信元IPアドレス    | CIDR         |

ワイルドカードは`*`が0文字以上、`?`が任意の1文字です。host-headerとpath-patternの値は最大128文字で、path-patternはクエリ文字列を除いたパスに対して大文字小文字を区別して評価されます。source-ipはプロキシ経由だとプロキシのIPで判定されるため、元のクライアントIPで振り分けたいときはhttp-header条件でX-Forwarded-Forを見ます。

### リスナールールの優先度と評価順序：限定的な条件を小さい番号に置く設計

優先度は1〜50000の整数で、ALBは小さい番号から順に評価し、最初に一致したルールのアクションを実行します。デフォルトルールは常に最後です。限定的な条件（例：`/api/admin/*`）を包括的な条件（例：`/api/*`）より小さい番号に置かないと、限定ルールには到達しません。番号は10や100刻みで空けて採番しておくと、後からルールを差し込めます。

### ルール数100の上限と緩和できない比較文字列・評価数のクォータ

[ALBのクォータ一覧](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)（2026年10月時点）では、リスナールール関連の上限は次のとおりです。

| 項目                         | 既定値   | 緩和 |
| -------------------------- | ----- | -- |
| ルール数／ALB（デフォルト除く）          | 100   | 可  |
| 条件値（Condition Values）／ルール  | 5     | 不可 |
| ワイルドカード／ルール                | 6     | 不可 |
| 照合数（Match evaluations）／ルール | 5     | 不可 |
| リスナー／ALB                   | 50    | 可  |
| ターゲットグループ／ALB              | 100   | 不可 |
| ターゲット／ALB                  | 1,000 | 可  |
| ALB／リージョン                  | 50    | 可  |

ルール数はService Quotasから緩和を申請できますが、1ルールに書ける条件値やワイルドカードの数は増やせません。100本に近づいたら、まずホスト名やパスの設計で条件をまとめられないかを見直します。次章の正規表現条件を使うと、ワイルドカードで書き分けていた複数のルールを1本に寄せられることがあります。

## 正規表現とURL・ホストヘッダー書き換え：2025年10月追加機能の使いどころ

2025年10月15日の[アップデート](https://aws.amazon.com/about-aws/whats-new/2025/10/application-load-balancer-url-header-rewrite/)で、host-header・http-header・path-patternの条件に正規表現が使えるようになり、転送前にパスやホストヘッダーを置き換える[transforms](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/rule-transforms.html)（URL書き換え・ホストヘッダー書き換え）も追加料金なしで提供されました。デフォルト以外の各ルールに付けられるのは、ホストヘッダー書き換えとURL書き換えが1つずつです。`/api/v1/users`を`/users`に書き換えてプレフィックスを外す処理が、NGINXなどのプロキシ層なしで書けます。正規表現では先読み・後読み・後方参照・atomic group・所有量指定子・再帰・Unicode文字クラス（`\p{L}`など）が使えないため、既存のNGINX設定から移すときは式を書き直す前提で見積もってください。

## ALBの502・503・504エラー：ELB側かターゲット側かの切り分け

ALBのURLで5xxが返ったとき、最初に確かめるのは「ALB自身が返したのか、ターゲットが返したのか」です。CloudWatchでは`HTTPCode_ELB_5XX_Count`がALB自身の生成分、`HTTPCode_Target_5XX_Count`がターゲットの生成分で、互いの数を含みません。アクセスログでも、ターゲットから応答が無かったリクエストは`target_status_code`が`-`になります。ALBが返す502・503・504の主な原因は、[ALBのトラブルシューティング](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html)に次のように列挙されています。

| コード | ALBが返す主な原因              | 最初に見る設定              |
| --- | ----------------------- | -------------------- |
| 502 | ターゲットがRST・FINで接続を切った    | ターゲットのkeep-alive     |
| 502 | 応答ヘッダーが不正・合計32KB超       | アプリの応答               |
| 502 | Lambdaの応答本文が1MB超・エラー    | Lambdaの戻り値           |
| 503 | 登録ターゲットなし・全ターゲットがunused | ターゲットグループ            |
| 504 | ターゲットへの接続が10秒で確立しない     | セキュリティグループ           |
| 504 | アイドルタイムアウト内に応答が無い       | idle\_timeout（既定60秒） |
| 504 | ネットワークACLがエフェメラルポートを拒否  | NACLの1024-65535      |

504は、ターゲットへの接続が10秒以内に確立しない場合と、接続した後にアイドルタイムアウトの間ターゲットから何も返らない場合とで対処が分かれます。前者はセキュリティグループやネットワークACLの問題で、タイムアウトを延ばしても解消しません。後者のように接続後の無通信が原因なら、ALBの属性`idle_timeout.timeout_seconds`の延長で解消する場合がありますが、長い同期処理を待たせる設計そのものを見直す方が先です。逆に502が断続的に出るときは、ターゲット側（NginxやNode.jsなど）のkeep-aliveがALBのアイドルタイムアウトより短く、ALBが再利用しようとした接続をターゲットが先に閉じている可能性を疑います。ターゲットのkeep-aliveはALBのアイドルタイムアウトより長くしておくのが原則です。API Gatewayの29秒の上限による504とは原因が別なので、前段にAPI Gatewayがある構成は[API Gatewayのタイムアウト：29秒の上限を引き上げる手順と504の切り分け・非同期化](/tech/details/18479/)を参照してください。

## ELB採否判断：CloudFront・Global Acceleratorとの役割分担

### ELBを置くべき構成：ターゲット2台以上・AZ冗長・入口を1つに束ねたい場合

ターゲットが2台以上ある、またはスケールアウトする前提がある。1つのAZが落ちても動き続けたい。ドメインやパスの入口を1か所に束ね、背後のサービスを差し替えたい。このどれかに当てはまるならELBを置きます。可用性の目標値の置き方は[可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】](/tech/details/13423/)で整理しています。ALBをインターネットに直接さらしたくない場合は、前段にCloudFrontを置いてALBをプライベートのままにする構成があり、手順は[CloudFront VPCオリジンとは？ALB・EC2をプライベートのまま公開する設定と制約](/tech/details/4767/)にあります。複数リージョンのALBを固定のエニーキャストIPで束ねたいなら、[AWS Global Acceleratorの料金と仕組み｜東京リージョンの月額試算とCloudFrontとの違い](/tech/details/6816/)がELBの上に乗ります。ELBはリージョン内の分散、CloudFrontとGlobal Acceleratorはリージョンの外側の入口と分けて考えると、構成図で迷いません。

### ELBが過剰になる場面：単一サーバー・静的サイト・サーバーレスの場合

EC2が1台だけで冗長化の予定もない社内ツールに、HTTPS終端のためだけにALBを置くと、トラフィックがほぼゼロでも月17ドル台の固定費が続きます。静的サイトならS3とCloudFrontで足ります。API Gateway＋Lambdaのサーバーレス構成でも、通常は入口にELBは要りません。Lambdaの前段にALBとAPI Gatewayのどちらを置くかは[API GatewayとALBの違い：Lambda・ECSの前段をタイムアウト・料金・認証で選ぶ](/tech/details/18499/)で比べています。ECSでWebアプリを最小構成で出すなら、ALBの作成と設定を肩代わりする[ECS Express Mode](/tech/details/9958/)も選択肢です。

動いているからとCLBを放置するのも避けたい判断です。更改のタイミングでALBかNLBへの移行を計画に入れてください。ロードバランサーの設計やCLBからの移行、コンテナ基盤を含むインフラ構成の見直しは、一創の[AWS・Google Cloud・Azureのインフラ構築支援](https://www.issoh.co.jp/service/system/aws/)で要件整理から構築・運用まで対応しています。Azureで同じ役割を担うL7ロードバランサーとの比較は[Azure Application Gatewayとは？L7負荷分散・WAF・料金とv2の構築手順【2026年版】](/tech/details/7273/)が参考になります。

## よくある質問

### Elastic Load Balancing（ELB）とは何ですか？

AWSのロードバランシングサービスの総称です。ALB・NLB・GWLB・CLBの4種類を含み、受信トラフィックを1つ以上のAZにある複数のターゲット（EC2インスタンス、コンテナ、IPアドレスなど）へ分散します。正常なターゲットだけに送り、トラフィック量に合わせて自身の容量も拡張します。

### ALBとELBの違いは何ですか？

ELBが総称、ALBはその中のHTTP/HTTPS向けの1種類という関係です。「ELB」が旧来のCLBを指している文脈なら、違いはALBがURLパスやホスト名で振り分けられ、HTTP/2・WebSocket・SNI・Lambdaターゲット・認証に対応している点です。新規構築でCLBを選ぶ理由はほとんどありません。

### ALBとNLBはどう使い分けますか？

パスやヘッダーでの振り分け・認証・WAF連携が要るHTTP/HTTPSのアプリケーションならALBです。TCP/UDPを低遅延でそのまま通したい、静的IP（Elastic IP）が要る、HTTP以外のプロトコルを扱う、といった要件ならNLBです。取引先からIPアドレスでの許可を求められたときにNLBが必要になる、というのが典型です。

### ALBのLCUとは何ですか？

ALBの処理量を測る課金単位（Load Balancer Capacity Unit）です。新規接続数・アクティブ接続数・処理バイト数・ルール評価数の4指標のうち、各指標を1時間平均のLCU使用量に換算し、最も大きい指標で課金されます。東京リージョンでは1LCU時間あたり0.008ドルで、時間料金0.0243ドルに加算されます（2026年9月時点）。

### ALBのリスナールールはいくつまで作れますか？

デフォルトルールを除いて1つのALBあたり100個が既定の上限で、Service Quotasから緩和を申請できます。1ルールあたりの条件値（5個）・ワイルドカード（6個）・照合数（5個）は緩和できません。最初の10ルールを超えた評価はLCUの計算対象になるため、ルール数は料金にも響きます。

## 関連記事

- [ロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説【2026年版】](/tech/details/13137/)
- [ELBヘルスチェックの設定と失敗原因の調べ方｜ALB・NLBの既定値と理由コード](/tech/details/18067/)
- [API GatewayとALBの違い：Lambda・ECSの前段をタイムアウト・料金・認証で選ぶ](/tech/details/18499/)
- [AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・設定例を解説【2026年版】](/tech/details/3304/)
- [VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点](/tech/details/2326/)

---

出典: [Elastic Load Balancingとは？ELBとALBの違い・4種類の使い分けと料金・設定を解説](<https://www.issoh.co.jp/column/details/2893/>)（株式会社一創）