Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

ロジックモニターブログ

ALB と ELB: どちらの AWS ロードバランサーを使用すべきか、またその理由は?

ロードバランサー、および ALB と ELB の主な類似点と相違点について学びます。

10〜15分

VectorUSA ロゴ

ニュースレター

最新情報のメール配信を登録

最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

シェア

最新のアプリの需要とクラウドのシンプルさのバランスを取ろうとする場合、Application Load Balancer (ALB) と Elastic Load Balancer (ELB) のどちらを選択するかは混乱を招く可能性があります。

どうして？

ELB は一般的な用語であると同時にレガシー オプションでもあるのに対し、ALB はスケーラブルなマイクロサービス駆動型環境向けに特別に構築されているためです。

ALB に切り替えた組織では、分散ワークロード全体でルーティング効率が向上し、リソース利用率が向上します。 

この記事では、ALBとELBを比較し、それぞれをいつ使うべきか、そしてどのように回避するかを説明します。

TL; DR

高度なレイヤー 7 ルーティング、コンテナー、サーバーレス ワークロードをサポートするため、最新のクラウド ネイティブ アプリケーションを実行している場合は ALB を使用します。
コンテンツベースのルーティングや最新のプロトコルを必要としないシンプルなレガシー アプリの場合のみ、ELB を使用してください。
ALB に移行することで、よりスマートにスケーリングし、セキュリティを強化し、可観測性を改善して、長期的な成功を実現できます。
どちらを選択する場合でも、リアルタイム監視はパフォーマンスを最適化し、クラウド コストを抑制するための鍵となります。

クイック比較表 – ALB vs ELBの概要

機能ALBELB（クラシック）
OSI層レイヤー7（アプリケーション）レイヤー4（トランスポート）
ルーティング方法ホスト、パス、クエリ文字列IPアドレス、ポートのみ
プロトコルサポートHTTP、HTTPS、WebSocket、HTTP/2TCP、SSL
ターゲットタイプEC2、コンテナ、Lambda、IPEC2、IP
セキュリティ機能AWS WAF、シールド、SNISSL終了のみ
監視詳細なアクセスログ、CloudWatch基本メトリクス、CloudWatch
適用例マイクロサービス、API、モダンアプリレガシーアプリケーション

ロードバランサーとは何ですか? なぜ重要なのですか?

成長を続けるeコマースウェブサイトを運営しているとしましょう。ホームページ、商品リスト、チェックアウトサービス、管理ダッシュボードがすべて複数のサーバーにホストされています。フラッシュセール中にトラフィックが急増すると、ホームページは問題なく、チェックアウトサービスに過負荷がかかる可能性があります。 

AWS 環境では、適切なロードバランサーが各リクエストを適切なサーバーグループにルーティングすることでこの混乱を管理し、遅延やダウンタイムを回避します。

これを行うには、ラウンドロビンや最小応答時間などのアルゴリズムを使用して、各リクエストの送信先を決定します。

しかし、ロード バランサがないと、ユーザー リクエストが少しでも急増すると、ボトルネックが発生し、顧客がチェックアウト ページで行き詰まるなど、ユーザー エクスペリエンスが低下する可能性があります。 

どうして？ 

バックエンドの容量や目的に関係なく、すべてのトラフィックが同じエントリ ポイントに到達するためです。

デジタル トラフィックが急増するにつれ、インテリジェントなトラフィック管理はもはやオプションではなく、必須になっています。 

アプリケーションロードバランサー（ALB）とは

ALB は、アプリケーション層または OSI の第 XNUMX 層 (Open Systems Interconnections) モデル。複数のシステム間の通信を促進します。 ALB はリクエストを受け取り、リスナー (接続リクエストをチェックするプロセス) ルールを優先順位に従って評価します。基本的には、コンテンツに基づいてリクエストを特定のサブグループにルーティングします。 

ユーザーは、リスナー ルールのアルゴリズムを個別に異なるターゲット グループにルーティングすることを選択できます。 さらに、システム管理者は、プロジェクトや組織の優先順位や要求の変化に応じて、アプリケーションが受け取る全体的な要求を中断することなく、ターゲット グループを簡単に追加または削除できます。  

ユーザーは、ALB を他のさまざまな AWS サービスと組み合わせて、アプリケーションの可用性とスケーラビリティを最適化できます。 これらのサービスには、AWS Certificate Manager、Amazon EC2、Amazon Route 53、AWS WAF、および Amazon CloudWatch が含まれる場合があります。 

たとえば、Amazon CloudWatch はユーザーにリアルタイムのサービスを提供します。 アプリケーション監視機能提供 迅速なエラー検出 システムの異常やパフォーマンスの遅延に対応するトラブルシューティング。 Amazon Route 53 を使用すると、ユーザーはエイリアス レコードを作成し、DNS リクエストに応答するための複数の IP アドレスを一覧表示できます。これは、地理的に分散したサーバーを管理するための効果的なウェブ ソリューションです。 

ALB の仕組み

ALB は、主にネットワーク負荷を分散します。 パブリッククラウド 可用性と安定性を最適化します。 ALB は、OSI モデルの第 XNUMX レイヤー内のアプリケーションの正常性を監視し、特に正常な登録済みターゲットにトラフィックをルーティングします。 

具体的には、ALBは、 HTTP および HTTPS ヘッダーにより、開発者は各チェックの詳細なレポートを入手し、発生した特定のコードと HTTP 関連のエラーに焦点を当てて確認できます。 

AWS ユーザーは、AWS EC2 インスタンス、アプリケーション (Rest API 経由)、またはコンテナーの前で内部負荷分散を介して ALB を適用できます。 複雑な環境内の複数のサービスは、アプリケーションのニーズに基づいて異なるサーバー クラスターにルーティングするなど、パスベースのルーティングを通じて単一の ALB ロード バランサーを共有する場合があります。 ユーザーは、10 つの ALB の背後で最大 XNUMX 個のアプリケーションをルーティングできます。

知っておくべきALBの主な機能

高度なルーティング

ALBはコンテンツに基づいてスマートなルーティング決定を行います。ホストベース、パスベース、さらにはクエリ文字列パラメータを使用してトラフィックを誘導できます。これは、 複雑なマイクロサービスの管理 アーキテクチャを構築したり、ユーザーを地域固有のコンテンツに誘導したりします。

WebSocketとHTTP/2のサポート

最新のアプリケーションには最新のプロトコルが必要です。ALBは、リアルタイムの双方向通信を実現するWebSocketと、より高速で効率的なネットワーク接続を実現するHTTP/2の両方をサポートしています。これにより、バックエンドに大きな変更を加えることなく、アプリケーションの応答性が向上します。

AWS WAFとShieldによるセキュリティ

ALB は AWS Web Application Firewall (WAF) および AWS Shield と直接統合され、一般的なウェブエクスプロイトや DDoS 攻撃からアプリケーションを保護します。追加のインフラストラクチャオーバーヘッドなしで、セキュリティポリシーの適用やトラフィックの潜在的な脅威の監視を簡単に行うことができます。

柔軟なターゲットタイプ

ALBはEC2インスタンスに限定されません。トラフィックをコンテナ（ECSやEKS上で実行されているものなど）、IPアドレス、さらにはAWS Lambda関数にルーティングできます。そのため、最新のサーバーレス環境やコンテナ化された環境に最適です。

組み込み認証とリダイレクト

ALB は、ロードバランサーで直接ユーザー認証を処理することで、時間を節約し、バックエンドの複雑さを軽減します。Amazon Cognito、Microsoft AD、Google と統合できるほか、組み込みのリダイレクトアクションや固定レスポンスアクションを使用することで、トラフィック管理を簡素化できます。

適切なロード バランサはトラフィックを誘導し、ビジネスをフルスピードで進めます。

Elastic Load Balancer (ELB) とは何ですか?

2009 年に AWS によって導入された ELB (クラシック ロード バランサーとも呼ばれます) は、複数のターゲット間でトラフィック分散プロセスを自動化するソフトウェア ベースのロード バランスです。 これらのターゲットには、コンテナーと IP アドレスが含まれる場合があります。

ELB は、OSI モデルの第 XNUMX 層 (トランスポート層) から動作し、TCP または IP の適用プロトコルに基づいて要求を転送し、同様のバックエンド ターゲットとリンクします。 たとえば、ELB が TCP ポートからクライアント リクエストを受信すると、ロード バランサーのセットアップ中に事前設定されたルールに基づいてリクエストをルーティングします。 

クラシック ロード バランサーは、アプリケーション スタックのセキュリティを強化し、管理を容易にし、信頼性を高めるためのさまざまな機能を提供します。 

具体的には、ELB は Web ネットワークに次のような機能を提供します。

  • 登録済みの正常なインスタンス間のトラフィック分散
  • SSL証明書の集中管理
  • 公開鍵インフラストラクチャを使用したユーザー認証
  • IPv4とIPv6の両方のトラフィックをサポート
  • EC2 インスタンスへのトラフィックを管理するための単一のエントリ ポイント

ELB は、EC2 インスタンスのユーザーに単一のエントリ ポイントを提供し、利用可能なターゲット間でトラフィックを効率的に分散します。 構成されたヘルス チェックを使用すると、ELB は登録された各ターゲットの状態を綿密に監視し、トラフィックの分散を正常な場所に制限して、フォールト トレランスを向上させることができます。

AWSは廃止されたようですが 2年のEC2022-ClassicネットワークClassic Load Balancer は引き続きサポートされます。Classic Load Balancer が既に VPC 内にデプロイされている場合は、変更は必要ありません。EC2-Classic に関連付けられている場合は、VPC 環境への移行を推奨します。

ELB のしくみ  

Classic Load Balancer は OSI モデルのレイヤー 4 で動作し、TCP および IP プロトコルに基づいてトラフィックを管理します。Classic Load Balancer を作成する際は、バックエンドインスタンスを直接 Classic Load Balancer に登録し、XNUMX つ以上のアベイラビリティーゾーン (AZ) に割り当てます。

リージョン内の AZ の背後に複数のサーバーを配置すると、ネットワークの可用性が向上し、ELB はアクセスできないときにトラフィックを利用可能な AZ に再ルーティングできます。 ELB は、デフォルト設定中に AZ 間でトラフィックを均等にルーティングします。 ただし、サーバーがリクエストに応答しない場合、デフォルト設定は過負荷/負荷の不均衡につながる可能性があります。 

クロスゾーン負荷分散を有効にすると、各バランサー ノードは、有効なすべての AZ の登録済みターゲットにトラフィックを分散できます。 または、クロスゾーン負荷分散を無効にすると、各バランサー ノードが特定の AZ にトラフィックを分散するように制限されます。 そのため、ゾーン間の負荷分散により、潜在的な負荷の不均衡のリスクが軽減されます。 

知っておくべきELBの主要機能

レイヤー4負荷分散

ELB は TCP および IP プロトコルに基づいてトラフィックをルーティングするため、コンテンツ認識ルーティングを必要としないシンプルなアプリケーションやレガシー アプリケーションに最適です。

ターゲットインスタンスのヘルスチェック

ELBは登録されたターゲットに対して定期的なヘルスチェックを実行し、正常なインスタンスにのみトラフィックをルーティングします。これにより、アプリケーションの可用性が維持され、ユーザーがリクエストを処理できないリソースに誘導されることがなくなります。

SSL証明書管理

ロードバランサー上で SSL 証明書を集中管理することで、各バックエンド サーバーで直接証明書を構成することなく、安全な通信のための暗号化を簡素化できます。

IPv4 および IPv6 のサポート

ELB は IPv4 と IPv6 の両方をサポートしているため、アプリケーションは追加の構成なしで最新の IP トラフィック標準を処理できます。

ゾーン間負荷分散

クロスゾーン負荷分散を有効にすると、各ELBノードは、有効化されたすべてのアベイラビリティゾーン内の正常なインスタンス全体にトラフィックを均等に分散できます。これにより、インスタンス障害時やトラフィック量が多い時間帯における過負荷を防ぎ、フォールトトレランスを向上させます。

Elastic Load Balancer と Application Load Balancer の比較

ALB と ELB は、それぞれ特殊な機能を備えているにもかかわらず、いくつかのコア機能と機能を共有しています。

  • スティッキーセッション: クッキーまたは IP トラッキングを使用して、繰り返しのトラフィックを同じサーバーに送信することで、ユーザー セッションを維持します。 
  • SSL終了: SSL/TLS 復号化をロードバランサーにオフロードして、バックエンド サーバーの処理負荷を軽減します。
  • アイドルセッションの終了: 設定された期間後に非アクティブな接続を自動的に閉じて、リソースを解放します。
  • 接続ドレイン: インスタンスがローテーションから削除される前に、進行中のリクエストを完了できるようにします。
  • ヘルスチェック: バックエンドのターゲットを継続的に監視し、トラフィックを正常なリソースにのみルーティングします。

ALB と ELB の違い

ALBとELBはコア機能の一部を共有していますが、大きな違いもあります。違いを見ていきましょう。

機能 / 制限アプリケーション ロード バランサー (ALB)エラスティックロードバランサー（ELB / クラシック）
導入された年20162009
リスナー管理リスナールーティングルールの表示と編集をサポートリスナーの追加/削除のみを許可します
ルーティングロジックホスト名、パス、クエリ文字列、IP、ポートに基づくコンテキスト認識ルーティングTCP ポートに基づくルート (コンテンツベースのロジックなし)
複数ポート転送サポートサポートされていません
ターゲットタイプの互換性Fargate 上の EKS、IP ベースのターゲット、コンテナと互換性がありますFargateおよびIPベースのルーティングと互換性がない
WebSocket と HTTP/2 のサポート完全にサポートサポートされていません
ドメイン名の取り扱い複数のドメインのサーバー名表示（SNI）をサポート単一ドメインに限定
基盤プロトコルのサポートHTTP、HTTPS、HTTP/2、WebSocketTCP、HTTP、HTTPS
高度な機能複数の同時リクエスト、高度なルーティング、動的なルール更新のネイティブサポート基本的な負荷分散機能

一般的な使用例: それぞれを選択するタイミング

両方のロードバランサーの類似点と相違点がわかったので、それぞれをいつ使用すべきかを確認しましょう。 

次の場合は ALB を選択してください:

  • 最新のクラウドネイティブアプリケーションまたはマイクロサービスを実行している
  • URLパス、ホスト名、クエリ文字列に基づいた高度なルーティングが必要な場合
  • アプリケーションでリアルタイム通信にWebSocketまたはHTTP/2のサポートが必要な場合
  • コンテナ（ECS、EKS）またはサーバーレスアーキテクチャ（AWS Lambda）を扱っている
  • ロードバランサで組み込みのユーザー認証と簡単なリダイレクト処理が必要な場合
  • セキュリティを最優先に考え、AWS WAFとShieldを統合する予定である

次の場合は ELB を選択します。

  • 単純なTCPまたはSSLトラフィックルーティングに依存するレガシーアプリケーションをサポートしている
  • ワークロードは EC2 Classic で実行されます（ただし、ネットワークは段階的に廃止されていることに注意してください）
  • コンテンツベースのルーティングや高度なトラフィック管理は必要ありません
  • 環境は比較的静的であり、コンテナやサーバーレスアーキテクチャを活用していない
  • 追加の設定の複雑さのない、シンプルなレイヤー4ロードバランサが必要です

Albがより良い選択肢である理由

トラフィックを単一のポート経由でしかルーティングできないELBとは異なり、ALBは複数のポートにまたがるルーティングやAWSへのルーティングもサポートします。 ラムダ関数これにより、ALB はサーバーレス アーキテクチャに最適となり、サーバーを管理せずにバックエンド ロジックを実行したり、API を構築したり、Web アプリを提供したりできるようになります。

ALBは、ロードバランサーレベルでより高度なタスクを直接実行し、アプリケーションサーバーの負荷を軽減します。具体的には以下のとおりです。

  • 事前設定されたリダイレクトまたは固定応答
  • LDAP、Microsoft AD、Googleなどのプロバイダーによる組み込みのユーザー認証

ALB はこれらの機能を上流で処理することにより、アプリケーションがコアビジネス ロジックに集中できるようにし、効率とパフォーマンスを向上させます。

その他の注目すべきALB機能

ALB のその他の優れた機能は次のとおりです。

  • コンテナベースのアプリのサポート: 1 つのインスタンスで複数のコンテナをホストでき、各コンテナは異なるポートをリッスンしますが、同じターゲット グループで管理されます。
  • きめ細かなヘルスチェック: ALB はポート レベルでヘルス チェックを実行でき、よりきめ細かな制御のためにタグ、リソース、IAM 権限によるコンソール フィルタリングをサポートしています。
  • 詳細なアクセスログ: ALB ログには、元の HTTP 応答、応答処理時間、要求タイプ、タイムスタンプなどの豊富なメタデータが含まれており、すべて圧縮形式で安全に保存されます。

ELBからALBへの移行

まだ Classic Load Balancer を使用している場合は、ALB に移行することがアーキテクチャの最新化に向けた賢明な動きです。 

どうして？

ALB は、高度なルーティング、向上したパフォーマンス、クラウドネイティブ アプリケーションをより適切にサポートする組み込みの統合を提供するためです。 

しかし、移行をスムーズかつ低リスクにするには、慎重に検討した移行計画が必要です。

ステップ1: 現在のELB設定を監査する

現在ELBに依存しているアプリケーションを特定します。次のような主要な設定を文書化します。

  • リスナー構成
  • ヘルスチェックパラメータ
  • SSL証明書の詳細
  • バックエンドインスタンスのマッピング

これにより、明確なベースラインが得られ、移行中に予期せぬ事態が発生するのを回避できます。

ステップ2: ALBの準備状況を評価する

次のような ALB のレイヤー 7 機能がワークロードにメリットをもたらすかどうかを判断します。

  • パスベースまたはホストベースのルーティング
  • コンテナ化されたターゲット（ECS や EKS など）
  • Lambda またはサーバーレスサービスとの統合

アプリのアーキテクチャが最新であるか、その方向へ進んでいる場合は、ALB の方が適している可能性があります。

ステップ3: 構成のマッピングと調整

ALB はほとんどの ELB 機能をサポートしていますが、一部の機能はより高度であり、更新が必要になる場合があります。

  • ヘルスチェックにはより詳細なオプションがあります
  • SSL終了とリスナールールはよりカスタマイズ可能
  • 認証、リダイレクト、固定応答がロードバランサでネイティブに処理されるようになりました

つまり、複製ではなく最適化にこの時間を使用してください。

ステップ4: DNSとルーティングを更新する

ALBの設定とテストが完了したら、Route 53（またはDNSプロバイダ）を更新して、トラフィックが新しいロードバランサーに送信されるようにしてください。この段階で、慎重に切り替えを行い、実際のトラフィックを監視してください。

ステップ5: 並列実行（可能な場合）

さらなる安全性のために:

  • 既存のELBと並行してALBをデプロイする
  • 交通シミュレーションを実行するか、段階的な切り替えを実施する
  • パフォーマンス、ログ、フェイルオーバーの動作を検証する

すべてがスムーズに動作すると確信できた場合にのみ、ELB を廃止してください。

LogicMonitorでALBまたはELBの監視を開始しましょう 

組み込みのダッシュボード、リアルタイム メトリック、自動アラートを備えた LogicMonitor は、クラウド環境がどんなに複雑になっても、トラフィックの急増に先手を打って対応し、トラブルシューティングを迅速化し、自信を持って拡張するために必要なすべてを提供します。

ロードバランサーの管理を簡素化し、問題に先手を打つ準備はできていますか?
今すぐ始める

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。

関連ブログ

可観測性ROI：実際の導入による真のコスト削減
Blog

可観測性ROI：実際の導入による真のコスト削減

可観測性を高めることで、アラートのノイズを減らし、インシデント対応を迅速化し、ダウンタイムを削減し、エンジニアが計画的な作業に費やす時間を増やすことができます。LogicMonitorの顧客は、これらのメリットを活用してコストを削減し、より適切なインフラストラクチャの意思決定を行っています。
2026 年 9 月 9 日
さらに詳しく
HTTPSは中間者攻撃への解決策となるのか？
Blog

HTTPSは中間者攻撃への解決策となるのか？

合成監視によって隠れたHTTPリダイレクト攻撃がどのように明らかになったか、そしてHTTPS、HSTS、配信経路の可視化がユーザーを傍受から守る理由をご覧ください。
2026 年 9 月 9 日
さらに詳しく
古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法
Blog

古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法

権威サーバーは正しいIPアドレスを返しているにもかかわらず、ユーザーが古いIPアドレスにアクセスしてしまうケースがあります。ここでは、古いグルーレコードを見つけて、親ゾーンのリファラルを修正する方法をご紹介します。
2026 年 9 月 9 日
さらに詳しく