AWS ALB（Application Load Balancer）は、HTTP/HTTPSトラフィックの分散に特化したL7ロードバランサーです。URLパスやホスト名に基づく柔軟なルーティングが可能で、マイクロサービスやコンテナ環境の構築に適しています。NLBがL4で動作するのに対し、ALBはL7で動作し、高度なリクエスト制御に強みを持ちます。本記事では、ALBの機能や他サービスとの違い、VPCやターゲットグループを含む具体的な設定手順、LCUに基づく料金体系とコスト最適化のポイントを解説します。
この記事で分かること
- ALBの基本機能とNLB・CLBとの使い分けの基準
- LCUに基づく利用料金の計算方法とコスト削減のポイント
- VPC設定からターゲットグループ作成までの具体的な構築手順
- ヘルスチェックエラーの原因や固定IP割り当てに関する解決策
AWS ALBの基本概要と特徴
AWS ALBとは何か
AWS ALB（Application Load Balancer）は、Amazon Web Services（AWS）が提供するロードバランシングサービスであるElastic Load Balancing（ELB）の1つです。OSI参照モデルの第7層（アプリケーション層）で動作し、HTTPおよびHTTPSトラフィックの負荷分散に特化しています。
クライアントからのリクエストを受信すると、事前に設定されたルールに基づいて、Amazon EC2インスタンス、コンテナ、IPアドレス、AWS Lambda関数などの複数のターゲットへトラフィックを自動的に振り分けます。これにより、アプリケーションの可用性と耐障害性を高め、トラフィックの増減に柔軟に対応できるシステムを構築することが可能です。
ALBが提供する主な機能とメリット
ALBは、単なるトラフィックの分散にとどまらず、最新のウェブアプリケーションアーキテクチャに適した多くの機能を備えています。
- 高度なルーティング機能：リクエストのURLパス（/api/など）やホスト名（example.comなど）、HTTPヘッダー、HTTPメソッド、クエリパラメータ、送信元IPアドレスなどに基づいて、異なるターゲットグループへトラフィックを振り分けることができます。これにより、1つのALBで複数のマイクロサービスを効率的にホストできます。
- コンテナ環境との高い親和性：Amazon ECSと連携し、動的ポートマッピングをサポートしています。ECSがタスクの起動時に未使用のポートを選んで、そのポートでターゲットグループにタスクを登録するため、コンテナのポート番号が変動する環境でもトラフィックをルーティングできます。
- セキュリティの強化：AWS WAF（Web Application Firewall）をALBと組み合わせることで、ウェブACLのルールに基づいてリクエストを許可またはブロックできます。また、SSL/TLS証明書の管理サービスであるAWS Certificate Manager（ACM）が提供する証明書をHTTPSリスナーに指定でき、HTTPS化を容易に実装できます。
- 柔軟なヘルスチェック：ターゲットが正常に動作しているかを確認するヘルスチェックにおいて、正常と判定するHTTPステータスコードを指定できます。既定値は200で、200〜499の範囲で複数の値や範囲（例：200-299）を設定できます。
他のロードバランサーとの違い
AWSのELBには、ALBのほかにNLB（Network Load Balancer）、CLB（Classic Load Balancer）、GWLB（Gateway Load Balancer）が存在します。要件に応じて適切なロードバランサーを選択することが重要です。以下は、ウェブアプリケーション構築で比較されやすい主要な3つのロードバランサーの違いです。
| 機能 / 種類 | ALB | NLB | CLB |
|---|---|---|---|
| 動作レイヤー | 第7層（HTTP/HTTPS/gRPC） | 第4層（TCP/UDP/TLSなど） | 第4層 / 第7層 |
| ルーティングの柔軟性 | 高い（パス、ホスト名など） | 低い（ポートベース） | 低い |
| 固定IPの割り当て | 不可（※別サービス併用で可能） | 可能（静的IP、Elastic IPの関連付け） | 不可 |
| 主なユースケース | ウェブアプリケーション、マイクロサービス | TCP/UDP通信、固定IPが必要な環境 | 既存アプリケーションの維持（旧世代） |
NLBとの違い
NLB（Network Load Balancer）は、OSI参照モデルの第4層（トランスポート層）で動作し、TCP、UDP、TLSトラフィックを処理します。ALBがHTTP/HTTPSのリクエスト内容を解析してルーティングを行うのに対し、NLBは毎秒数百万のリクエストを処理できるとAWSの公式ドキュメントに記載されており、大量のTCP/UDP通信を扱う用途に向いています。
また、NLBは、有効にしたアベイラビリティーゾーンごとに静的IPアドレスを持ち、インターネット向けのNLBではサブネットごとに1つのElastic IPアドレスを関連付けることもできます。ファイアウォールの設定などで固定IPアドレスが要件となる場合は、NLBが適しています。ウェブトラフィックの柔軟な振り分けが必要ならALB、非常に高い性能や固定IPが必要なTCP/UDP通信ならNLBという基準で使い分けます。
CLBとの違い
CLB（Classic Load Balancer）は、AWSの公式ドキュメントで旧世代のロードバランサーと位置づけられています。第4層と第7層の両方で動作し、TCPおよびSSLリスナーや、アプリケーションが生成するCookieを使ったスティッキーセッションに対応しています。一方、ALBのような高度なリクエストルーティングについては、機能比較のページで確認してください。
AWSの公式ドキュメントでは、CLBは旧世代のロードバランサーと位置づけられており、現行世代のロードバランサーへの移行が推奨されています。ALBとNLBの選び方は、Elastic Load Balancingの機能比較で確認できます。新規に構築する場合は、現行世代のALBまたはNLBから選ぶのが一般的です。
AWS ALBの料金体系とコスト最適化
AWS ALB（Application Load Balancer）を運用する上で、料金体系の正確な理解はインフラコストを適切に管理するために不可欠です。ALBの料金は固定費と従量課金の組み合わせで計算されるため、トラフィックの特性や設定内容によって月々の費用が変動します。
利用料金の計算方法
ALBの利用料金は、主に「時間あたりの基本料金」と「LCU（Load Balancer Capacity Units）による従量課金」の2つの要素から構成されます。東京リージョンにおける具体的な料金単価は、AWS公式のElastic Load Balancing料金ページで最新情報を確認できますが、基本的には稼働時間と処理負荷の両面から課金される仕組みです。
時間あたりの基本料金は、ALBがプロビジョニングされて稼働している時間（1時間未満は切り上げ）に対して発生します。トラフィックの有無にかかわらず、ALBが存在しているだけで発生する固定費用に相当します。
一方、LCUはロードバランサーが処理するトラフィックの負荷を測定するための単位です。LCUは以下の4つのディメンションで測定され、その中で最も使用量の多いディメンションに基づいて課金されます。
| ディメンション | 測定内容の概要 |
|---|---|
| 新しい接続 (New connections) | 1秒あたりに新しく確立された接続の数です。1 LCUは、1秒あたり25個の新しい接続に相当します。 |
| アクティブな接続 (Active connections) | 1分あたりのアクティブな接続の数です。1 LCUは、1分あたり3,000件（相互TLSを使用する場合は1,500件）に相当します。 |
| 処理されたバイト数 (Processed bytes) | ALBが処理したデータ量（GB/時間）です。1 LCUは、EC2インスタンス、コンテナ、IPアドレスのターゲットでは1 GB/時間、Lambda関数のターゲットでは0.4 GB/時間に相当します。 |
| ルール評価 (Rule evaluations) | 1秒あたりのルール評価数です。1 LCUは、1秒あたり1,000件に相当します。ルール評価は「リクエスト率 × （処理されたルールの数 − 無料分の10個）」で計算され、最初の10ルールは無料です。設定したルールが10個以下の場合、このディメンションは無視されます。 |
これらのディメンションは1時間あたりの平均で測定され、最も使用量が多いディメンションに対してのみ課金されます。たとえば、大容量の動画ファイルを配信する場合は「処理されたバイト数」が最大になりやすく、マイクロサービス間で大量の細かいリクエストをさばく場合は「新しい接続」や「ルール評価」が最大になりやすいといった特徴があります。
このほか、AWSの公式料金ページには、次の点が記載されています。
- パブリックIPv4アドレスの料金：ロードバランサーが使用するすべてのパブリックIPv4アドレスに、標準のパブリックIPv4アドレス料金がかかります（単価はVPCの料金ページで確認します）
- LCUの予約：LCUを事前に予約できる機能があります。予約したLCUの時間単位の料金に加えて、予約分を超えて使用したLCUにも料金がかかります
コストを抑えるためのポイント
ALBの料金体系を踏まえると、基本料金の無駄を省きつつ、LCUの消費を最適化することがコスト削減の鍵となります。具体的な対策として、以下の方法が挙げられます。
- 不要なALBの削除と統合
- CloudFrontを活用したトラフィックのオフロード
- ルーティングルールの最適化と整理
まず、開発環境やテスト環境で作成したまま放置されているアイドル状態のALBは、トラフィックがゼロであっても時間あたりの基本料金が発生し続けます。定期的にリソースの棚卸しを行い、使用していないALBを削除することが重要です。また、複数のALBをホストベースルーティングやパスベースルーティングを活用して1つのALBに統合することで、基本料金を削減できます。
次に、CDNサービスであるAmazon CloudFrontをALBの前段に配置することで、静的コンテンツのキャッシュ配信が可能になります。これにより、ALBに到達するリクエスト数や処理されるデータ量が減り、結果としてLCUの「処理されたバイト数」や「新しい接続」の消費を抑えられる可能性があります。
さらに、ALBのリスナーに設定するルーティングルールが複雑で数が多いほど、「ルール評価」のディメンションによるLCU消費が増加する可能性があります。なお、公式料金ページによると、最初の10ルールは無料で、設定したルールが10個以下の場合は「ルール評価」のディメンションは無視されます。ルールの数が多い場合は、不要なルールを整理して、ルールの数を減らすことを検討してください。
AWS ALBの構築と設定方法
AWS環境でApplication Load Balancer（ALB）を構築する手順を解説します。AWSマネジメントコンソールを利用した基本的な構築フローに沿って、ネットワーク設定から動作確認までを順番に進めます。
事前準備とVPCの設定
ALBを配置するためには、基盤となる仮想ネットワーク環境が必要です。Amazon VPC（Virtual Private Cloud）内に、ALB用とバックエンドリソース（EC2インスタンスなど）用のサブネットを用意します。
ALBを作成する際は、少なくとも2つ以上のアベイラビリティーゾーン（AZ）のサブネットを指定する必要があります。AWSの公式ドキュメントによると、各サブネットは異なるAZにあり、/27以上のCIDRブロックと8つ以上の空きIPアドレスが必要です。サブネットの種類（パブリック／プライベート）は、スキーム（インターネット向け／内部向け）に合わせて選択します。また、ALBがクライアントからのトラフィックを受け付けるためのセキュリティグループも作成します。一般的には、HTTP（ポート80）やHTTPS（ポート443）のインバウンド通信を許可するルールを設定します。
ターゲットグループの作成
ターゲットグループは、ALBが受け取ったリクエストをどのリソースに振り分けるかを定義するリソースです。振り分け先となるEC2インスタンスやIPアドレス、AWS Lambda関数をここで指定します。
ターゲットグループを作成する際は、ターゲットの種類とプロトコルを設定した上で、正常なターゲットにのみトラフィックを送るためのヘルスチェックを構成します。
| 設定項目 | 説明 |
|---|---|
| ターゲットの種類 | インスタンス（EC2）、IPアドレス、Lambda関数から選択します。 |
| プロトコルとポート | ターゲットとの通信に使用するプロトコル（HTTP/HTTPSなど）とポート番号（例：80）を指定します。 |
| ヘルスチェックパス | ターゲットの正常性を確認するためのエンドポイント（例：/index.htmlや/health）を指定します。 |
ALB本体の作成とリスナー設定
ネットワーク環境とターゲットグループの準備が整ったら、ALB本体を作成します。EC2ダッシュボードの「ロードバランサー」メニューから「Application Load Balancer」を選択し、構築を開始します。
作成画面では、以下の項目を設定します。
- ロードバランサー名とスキーム（インターネット向けか内部向けか）の指定
- VPCおよび事前準備した2つ以上のサブネットの選択
- ALBに適用するセキュリティグループの割り当て
- リスナーとルーティングの設定
リスナー設定では、ALBがリクエストを待ち受けるポートと、トラフィックを転送するデフォルトのターゲットグループを指定します。HTTPS通信を行う場合は、AWS Certificate Manager（ACM）で管理されているSSL/TLS証明書をここで関連付けます。
詳細な設定手順については、Application Load Balancer の作成の公式ドキュメントも参照してください。
動作確認とテスト
ALBの作成が完了したら、正常にトラフィックが分散されているかを確認します。構築直後はALBのステータスが「Provisioning」となりますが、数分待つと「Active」に変わります。
動作確認は以下の手順で行います。
- ターゲットグループの画面を開き、登録されたターゲットのヘルスステータスが「Healthy」になっていることを確認します。
- ALBの詳細画面から「DNS名」をコピーします。
- ブラウザまたはcurlコマンドを使用して、コピーしたDNS名にアクセスします。
アクセスするたびに、背後にある複数のEC2インスタンスにリクエストが振り分けられていることが確認できれば、構築は成功です。ヘルスステータスが「Unhealthy」になる場合は、ターゲット側のセキュリティグループ、ネットワークACL、ヘルスチェックのパスと成功コードの設定を見直す必要があります。
よくある質問（FAQ）
AWS ALBの料金はどのように計算されますか
AWS ALBの料金は、ロードバランサーの稼働時間と、処理したトラフィック量に応じたLCU（Load Balancer Capacity Units）の使用量に基づいて計算されます。第2章で解説した通り、基本料金と従量課金の組み合わせとなります。
| 課金項目 | 詳細 |
|---|---|
| 稼働時間 | ALBがプロビジョニングされてから削除されるまでの時間（1時間単位で課金） |
| LCU使用量 | 新しい接続数、アクティブな接続数、処理されたバイト数、ルール評価数のうち、最も使用量が多いディメンションに基づいて課金 |
詳細な単価や最新の計算例については、AWS公式のElastic Load Balancing料金ページをご確認ください。
ALBとNLBの使い分けの基準は何ですか
ALB（Application Load Balancer）とNLB（Network Load Balancer）は、主に扱うトラフィックのプロトコルとパフォーマンス要件によって使い分けます。WebアプリケーションのルーティングにはALBが適していますが、固定IPアドレスが必要な場合や、大量のTCP/UDP通信を扱う場合はNLBを選択します。
- ALBを選択する基準：HTTPおよびHTTPSトラフィックを扱い、パスベースやホストベースの柔軟なルーティングが必要な場合
- NLBを選択する基準：TCP、UDP、TLSトラフィックを扱い、毎秒数百万のリクエスト規模の処理や、固定IPアドレスが必要な場合
AWS ALBで固定IPアドレスを割り当てることはできますか
ALB単体では固定IPアドレス（Elastic IP）を直接割り当てることはできません。AWSの公式ドキュメントでは、ALBのIPアドレスは有効にしたAZごとに1つあり、DNS名がそれらのIPアドレスに解決されます。固定IPアドレスが必要な場合は、アーキテクチャを工夫することで対応できます。
具体的には、ALBの前段にAWS Global Acceleratorを配置するか、ALBをターゲットとして登録したNLBを配置する方法があります。これにより、クライアントには固定IPアドレスを提供しつつ、バックエンドでALBの柔軟なアプリケーションレベルのルーティング機能を活用できます。
ALBのヘルスチェックが失敗する主な原因は何ですか
ターゲットグループのヘルスチェックが失敗し、インスタンスが「Unhealthy」と判定される場合、インフラストラクチャやアプリケーションの設定に問題があることがほとんどです。主な原因として以下の点が挙げられます。
- セキュリティグループの設定ミス：ALBからターゲット（EC2インスタンスなど）への通信が、ターゲット側のセキュリティグループのインバウンドルールで許可されていない
- アプリケーションの停止やエラー：ターゲット上のWebサーバーやアプリケーションが正常に稼働していない、または指定されたパスで、成功コードとして設定されたステータスコード（既定値は200）を返していない
- ヘルスチェックのパス設定ミス：ALBに設定したヘルスチェック用のパス（例：/health）が、実際のアプリケーションに存在しない
- ネットワークACLによる遮断：ターゲットとALBのサブネットに関連付けられたネットワークACLが、ヘルスチェックのポートや一時ポート（1024〜65535）の通信を許可していない
AWS ALBとCloudFrontを組み合わせるメリットは何ですか
Amazon CloudFront（CDN）のオリジンとしてALBを指定することで、Webアプリケーションのパフォーマンス向上とセキュリティ強化の両立が可能です。静的コンテンツはCloudFrontのエッジロケーションからキャッシュ配信され、動的コンテンツのみがALBを経由してバックエンドに到達するため、オリジンサーバーの負荷を軽減できる場合があります。
また、CloudFrontとAWS WAFを連携させることで、ウェブACLのルールに基づいて、ALBに到達する前に不正なリクエストをブロックできるため、システム全体の安全性を高めやすくなります。
まとめ
この記事では、AWS ALB（Application Load Balancer）の基本機能や料金体系、具体的な構築手順について解説しました。
- ALBはHTTP/HTTPSに特化し、高度なルーティング機能を提供します。
- 要件に合わせてNLBやCLBと適切に使い分けることが重要です。
- 料金は稼働時間とLCUの利用量に応じて計算されます。
- VPC、ターゲットグループ、リスナーを順に設定して構築します。
ALBを適切に導入することで、システムの可用性を高めることができます。まずは、テスト環境で実際の構築手順を試してみましょう。AWSの公式料金ページには、新規のお客様向けの無料利用枠として、CLBとALBで共有の750時間/月とALBの15 LCUが記載されています。また、2025年7月15日以降に作成されたアカウントには、最大200ドルの無料利用枠クレジット（無料プランは6か月）が付与されると記載されています。適用条件は、公式の料金ページと無料利用枠のページで確認してください。
【補足】本記事の内容は2026年10月時点のAWS公式ドキュメントに基づいています。料金や仕様は変更されることがあるため、利用前にAWS公式の最新情報をご確認ください。
