AWS ALB（Application Load Balancer）とは？設定方法と料金を初心者にもわかりやすく解説

「AWSでWebサービスを構築したいが、複数のサーバーへ効率的にアクセスを振り分ける方法がわからない」「ALBという言葉は聞いたことがあるが、具体的に何ができるのか、どう設定すればいいのかイメージできない」――DX推進やシステム基盤の刷新を任された担当者の多くが、このような疑問に直面しています。そこで重要になるのが、アプリケーション層で負荷を分散し、システムの安定稼働を支える「ALB（Application Load Balancer）」です。Webアプリケーションやマイクロサービスの運用において、欠かせない役割を果たします。本記事では、ALBの基本的な仕組みから設定手順、料金体系までを初心者にも分かりやすく解説します。この記事を読めば、自社システムへの導入要否を判断し、信頼性向上に向けた具体的な一歩を踏み出せるはずです。

AWS ALB（Application Load Balancer）とは？

AWS ALBを効果的に活用するには、まずその基本概念とリクエスト処理の仕組みを正確に理解することが重要です。

ここでは、ALBが何を解決し、どのようにシステムを支えているのか、初心者の方にもわかりやすく解説します。

AWS ALBの基本概念

ALB（Application Load Balancer）は、AWSが提供するフルマネージド型のロードバランサーです。最大の特徴は、OSI参照モデルの第7層であるアプリケーション層（レイヤー7）で動作するという点にあります。

通信の中身（HTTPヘッダーやURL）を解釈できるため、従来のL4ロードバランサーよりも柔軟できめ細かな振り分けが可能になります。

この特性により、近年主流となっているマイクロサービスやコンテナ環境においても、効率的なトラフィック分散を実現します。EC2インスタンスだけでなくECSやLambdaともスムーズに連携し、アプリケーションの安定稼働と高可用性を強力にサポートします。

ALBの動作フローとリクエスト処理の仕組み

ALBがどのようにリクエストを処理するのか、その流れを順を追って見ていきましょう。まず、ユーザーがALBのDNS名にアクセスすると、DNS名前解決が行われてALBのエンドポイントが特定されます。

次に、HTTP/HTTPSリクエストがALBのリスナーで検知されます。リスナーは指定されたプロトコルとポート番号でトラフィックを待ち受ける役割を担います。

受信したリクエストは、設定されたルールに基づいて適切なターゲットグループが選択され、そのグループ内のターゲットへ転送されます。

ターゲットの健全性は継続的にヘルスチェックで監視されており、応答がない場合は自動的に他の正常なターゲットへフォールバックされます。この一連の流れは完全にマネージドで運用され、スケーラブルかつ可用性の高い通信が保証されています。

ALBのターゲットタイプと柔軟なルーティング

ALBの強みの一つは、多様なターゲットタイプをサポートしている点です。従来のEC2インスタンスはもちろん、ECSで動作するコンテナ、さらにはサーバレスアーキテクチャの要であるLambda関数までをターゲットとして設定できます。

特にLambda関数をターゲットに設定できることで、瞬間的なアクセス増加にも柔軟に対応できるサーバレス構成が可能になります。また、ホストベースルーティングやパスベースルーティングといった機能により、異なるドメインやURLパスに基づいて、リクエストを異なるターゲットグループに振り分けることができます。

AWS ALBの特徴と他サービスとの使い分け

AWSには複数のロードバランサーサービスが存在し、それぞれ異なる特性を持っています。ここでは、ALBならではの特徴を深掘りし、他のロードバランサーとの違いや適切な選択基準、そして実践的な活用シーンを解説します。

ALBのレイヤー7での柔軟な制御

ALBがレイヤー7で動作することの最大のメリットは、HTTPやHTTPSの内容を解析して適切な振り分けができる点です。

単なるIPアドレスやポート番号だけでなく、URLパス、ホスト名、HTTPヘッダー、クエリパラメータなどの情報に基づいて、最適なターゲットを選択できます。

これにより、各サービスごとに異なるターゲットグループを設定し、単一のALBで複数のサービスを効率的に管理できます。また、WebSocketやHTTP/2といった最新のプロトコルもネイティブにサポートしており、リアルタイム通信を必要とするアプリケーションにも対応可能です。

さらに、「スティッキーセッション」機能を有効にすることで、同じユーザーからのリクエストを同一のターゲットに送信し続けることができ、セッション情報を保持しながら負荷分散を実現できます。

NLBやCLBとの違いと選び方

AWSには、ALB以外にもNLB（Network Load Balancer）とCLB（Classic Load Balancer）という選択肢があります。NLBはレイヤー4のトランスポート層で動作し、超高速かつ低レイテンシーを要求される環境に適しています。

TCPやUDPトラフィックを扱うゲームサーバー、IoTデバイスとの通信、リアルタイムストリーミングなどの用途に最適です。

一方、CLBは古い世代のロードバランサーで、レイヤー4と7の両方に対応しますが、柔軟性が低く、現在ではALBやNLBの使用が推奨されています。Webアプリケーションやマイクロサービス構成にはALBを、高スループットや固定IPアドレスが必要な場合にはNLBを選択するのが一般的です。

また、ALBはコンテンツベースのルーティングやAWS WAFとの統合が容易なため、セキュリティ要件が高いWebアプリケーションにも向いています。料金面では、ALBは稼働時間とLCU（Load Balancer Capacity Unit）という使用量ベースの課金体系を採用しており、実際のトラフィック量に応じた適正なコストで運用できます。

種類	動作・特徴	用途・その他
NLB（Network Load Balancer）	レイヤー4のトランスポート層超高速かつ低レイテンシー	TCPやUDPトラフィックを扱うゲームサーバー IoTデバイスとの通信リアルタイムストリーミング高スループットや固定IPアドレスが必要な場合
CLB（Classic Load Balancer）	レイヤー4と7の両方古い世代のロードバランサー柔軟性が低い	現在ではALBやNLBの使用が推奨
ALB（Application Load Balancer）	コンテンツベースのルーティング AWS WAFとの統合が容易	Webアプリケーションやマイクロサービス構成セキュリティ要件が高いWebアプリケーション稼働時間とLCUという使用量ベースの課金体系実際のトラフィック量に応じた適正なコスト

コンテナやLambdaでの活用シーン

ALBは、Amazon ECSなどのコンテナサービスと非常に相性が良く、コンテナの増減に合わせて自動的に通信経路を追従させる機能を持っています。動的にポートが変わるコンテナ環境でも、ALBがターゲットグループを自動更新するため、運用の手間をかけずにスケーラブルな構成を維持できます。

さらに、AWS Lambda関数を直接ターゲットに指定できるため、EC2などのサーバーを一切管理しない「フルサーバレスアーキテクチャ」の構築も可能です。アクセス急増時にはLambdaのオートスケール機能と連動して負荷を処理できるため、コスト効率と可用性の両立に大きく貢献します。

AWS ALBの設計と導入手順：ネットワークからSSL設定まで

ALBの仕組みを理解したら、次は実際の構築ステップに進みましょう。ここでは、可用性を高めるネットワーク設計の鉄則から、リクエストを正しく振り分けるための設定手順、そして安全な通信に不可欠なセキュリティ設定までを解説します。

ネットワークとサブネットの構成ポイント

ALBを導入する際の第一歩は、適切なネットワーク構成を設計することです。ALBはVPC（Virtual Private Cloud）内に配置され、少なくとも2つ以上の異なるアベイラビリティーゾーン（AZ）にまたがるサブネットを指定する必要があります。

これにより、特定のAZで障害が発生した場合でも、他のAZで継続してサービスを提供できる高可用性構成が実現されます。インターネット向けのALBではパブリックサブネットを、内部システム向けではプライベートサブネットを選択することが基本です。

また、ターゲットとなるEC2インスタンスやECSタスクを配置するサブネットも適切に設計する必要があります。セキュリティグループの設定では、ALBからのトラフィックのみを許可し、不要なポートは閉じることで、セキュリティを強化できます。

リスナーとターゲットグループの設定方法

ALBの中核となるのが、リスナーとターゲットグループの設定です。リスナーは、ALBが受け取るトラフィックのプロトコルとポート番号を定義します。例えば、ポート80でHTTPトラフィックをリッスンし、ポート443でHTTPSトラフィックをリッスンするように設定できます。

ターゲットグループは、リクエストが転送される先のリソースをグループ化したもので、EC2インスタンス、ECSタスク、Lambda関数、IPアドレスなどを登録できます。ターゲットグループには、ヘルスチェックの設定も含まれ、定期的にターゲットの健全性を監視します。

リスナールールを設定することで、特定のURLパスやホスト名に基づいて異なるターゲットグループへルーティングすることも可能です。

例えば、/apiへのリクエストはAPIサーバーのターゲットグループへ、それ以外はWebサーバーのターゲットグループへ、といった柔軟な振り分けが実現できます。

SSL終端とヘルスチェックの設定

HTTPS接続を実現するには、SSL/TLS証明書をALBに設定する必要があります。AWS Certificate Manager（ACM）を利用することで、証明書の発行、管理、自動更新が簡単に行えます。

ALBでSSL終端を行うことで、バックエンドのターゲットではHTTP通信を使用でき、証明書管理の負荷を軽減できます。

ヘルスチェックは、ターゲットの健全性を監視するための重要な機能です。ヘルスチェックの設定では、チェック間隔、タイムアウト値、正常と判断するための閾値、異常と判断するための閾値を指定します。適切なヘルスチェック設定により、障害のあるターゲットを迅速に検知し、トラフィックを正常なターゲットのみに振り向けることができます。

例えば、Webアプリケーションの場合、特定のURLパスに対してHTTP GETリクエストを送信し、200番台のレスポンスコードが返ってくることを確認する、といった設定が一般的です。

ヘルスチェックパスは、データベース接続など重要な依存関係も含めて確認できるエンドポイントを指定することが推奨されます。

AWS ALBのコスト見積もりのポイント

AWS ALBの導入を検討する際、技術的なメリットと同じくらい重要なのがコストです。ALBは便利な反面、料金体系が少し複雑です。ここでは、何に対して課金されるのか、どうすればコストを最適化できるのかを解説します。

「時間単位」と「LCU」の2つの課金要素

ALBの料金は、基本的に「ALBが稼働している時間」と「ALBが処理した量」の2つの要素で構成されています。初期費用や最低利用期間はありません。

「ALB使用時間」は、ALBが起動している時間に対して発生する固定の料金です。トラフィックが全くない状態でも、ALBが存在する限り1時間ごとに課金され、東京リージョンの場合は1時間あたり約3.8円が目安となります。

「LCU使用量」は、ALBが実際に処理したトラフィック量や接続数といった負荷に応じて変動する従量課金部分です。

小規模なWebサイトであれば時間単価のみで済むことも多いですが、アクセス数が増えるとLCUの料金が占める割合が大きくなります。

LCU（Load Balancer Capacity Unit）の仕組み

初心者の方が最も悩みやすいのが「LCU」の計算方法です。LCUは、以下の4つの指標のうち、最も使用率が高かったディメンションに基づいて算出されます。

新規接続数： 新しく確立された接続の数（秒間あたり）。
アクティブ接続数： 維持されている接続の数（分間あたり）。
処理データ量（帯域幅）： 送受信されたバイト数（GB単位）。
ルール評価数： リクエストに対して処理されたリスナールールの数。

これら4つをすべて足すのではなく、その時間帯で「最も負荷が高かった指標」のみが課金対象となります。例えば、動画配信サイトなら「データ量」が、WebSocketを多用するチャットアプリなら「アクティブ接続数」がLCUを決定する主な要因になります。

コストを抑えるための節約テクニック

ALBのコストを最適化する最も効果的な方法は、ALBの集約です。ALBは1つ起動するだけで時間課金が発生するため、サービスごとにALBを個別に作成するとコストが積み上がります。

ALBの「リスナールール」を活用すれば、1つのALBで複数のドメインやサービスへの振り分けを処理できます。開発環境や小規模なマイクロサービス群であれば、ALBを共有することで時間課金分を大幅に節約可能です。

また、AWSには12ヶ月間の無料利用枠（CLB/ALB/NLBの合計で月750時間など）が用意されている場合があるため、学習や検証の段階ではこれらを活用してコスト感覚を掴むことをお勧めします。

AWS ALBの運用監視とトラブル対処

ALBを導入した後、システムを安定稼働させるためには「監視体制の構築」と「障害時の切り分け」が重要になります。ここでは、AWS標準機能を活用した効率的なモニタリング方法から、よくあるエラーの原因と具体的な対処手順までを解説します。

アクセスログとCloudWatchでの監視

ALBの運用において、アクセスログは問題調査やトラフィック分析に欠かせない情報源です。ALBのアクセスログ機能を有効にすると、すべてのリクエストの詳細がS3バケットに保存されます。ログには、クライアントのIPアドレス、リクエストのタイムスタンプ、処理時間、ターゲットの応答コードなどが記録され、障害発生時の原因特定や、パフォーマンスのボトルネック分析に活用できます。

Amazon CloudWatchとの統合により、ALBのメトリクスをリアルタイムで監視できます。主要なメトリクスには、リクエスト数、アクティブ接続数、ターゲットの応答時間、ヘルシーおよびアンヘルシーなターゲット数などがあります。

これらのメトリクスに対してアラームを設定することで、異常を迅速に検知し、対応できます。

例えば、ターゲットの応答時間が閾値を超えた場合や、アンヘルシーなターゲット数が増加した場合に、運用チームに通知を送ることで、問題の早期に検知し、迅速な対応ができます。

スケーリングと高可用性の構成

ALB自体は自動的にスケーリングされるため、トラフィックの増減に応じて手動でキャパシティを調整する必要はありません。しかし、バックエンドのターゲットについては、適切なスケーリング戦略を設計する必要があります。

EC2インスタンスをターゲットとする場合は、Auto Scalingグループを構成し、CPUやメモリの使用率、あるいはALBのメトリクスに基づいて自動的にインスタンス数を調整できます。ECSの場合は、ECS Service Auto Scalingを利用し、タスク数を動的に調整することで、コストと性能のバランスを最適化できます。

高可用性を確保するためには、複数のAZにターゲットを分散配置し、それぞれのAZに十分なキャパシティを確保しておくことが重要です。また、クロスゾーン負荷分散を有効にすることで、各AZ間でトラフィックを均等に分散し、特定のAZへの負荷集中を防げます。

よくある障害と具体的な対処手順

ALBの運用において、いくつかの典型的な障害パターンが存在します。最も多いのは、すべてのターゲットがアンヘルシーになり、503エラーが返されるケースです。

この場合、まずヘルスチェックの設定を確認し、ヘルスチェックパスが正しく設定されているか、ターゲットが実際に応答できる状態にあるかを確認します。

セキュリティグループの設定ミスも頻繁に発生する問題です。ALBからターゲットへのトラフィックが許可されていない場合、ヘルスチェックが失敗し、ターゲットがアンヘルシーと判定されます。ターゲットのセキュリティグループで、ALBのセキュリティグループからのトラフィックを明示的に許可する必要があります。

また、SSL証明書の有効期限切れも注意すべきポイントです。ACMを使用している場合は自動更新されますが、外部の証明書をインポートしている場合は、有効期限を監視し、適切なタイミングで更新する必要があります。CloudWatchアラームを設定して、証明書の有効期限が近づいた際に通知を受け取るようにしておくと安心です。

まとめ

本記事では、AWS ALB（Application Load Balancer）の基本概念から、他のロードバランサーとの違い、具体的な設計・設定手順、そして運用監視のポイントまでを体系的に解説してきました。

ALBは、レイヤー7のインテリジェントなルーティング機能により、現代的なWebアプリケーションやマイクロサービス構成に最適なロードバランサーです。EC2インスタンス、ECSコンテナ、Lambda関数といった多様なターゲットタイプをサポートし、柔軟かつスケーラブルなシステム構成を実現できます。

適切なネットワーク設計、リスナーとターゲットグループの設定、そして継続的な監視とスケーリング戦略により、高可用性と安定性を備えたインフラストラクチャを構築できます。ヘルスチェックの適切な設定や、セキュリティグループの正確な構成は、トラブルを未然に防ぐ上で特に重要なポイントです。

しかし、AWSのサービスを最大限に活用し、自社のビジネス要件に最適なアーキテクチャを設計・構築するには、専門的な知識と豊富な経験が必要です。

単にALBを設定するだけでなく、全体のシステム設計、セキュリティ対策、コスト最適化、そして運用保守まで見据えた総合的なアプローチが求められます。もし、AWS ALBの導入や既存システムの改善について、より具体的なアドバイスやサポートが必要な場合は、経験豊富な開発パートナーに相談することをお勧めします。

国内エンジニアによる上流設計と、海外拠点での開発を組み合わせたハイブリッド体制により、品質とコストのバランスを取りながら、ビジネスの成功に貢献できるパートナーが理想的です。