

AWSは、ロードバランサーサービスとして「AWS ELB(Elastic Load Balancing)」を提供しています。トラフィックの分散においては不可欠なサービスであり、すでに利用している方も多いでしょう。また、AWSの構成図などでELBのアイコンを目にしたことがある方もいるはずです。
さまざまなシステム構成で活用されるサービスですが、AWS ELBの詳細を正確に理解している人は意外と少ないかもしれません。今回は、このAWSのロードバランサーサービスである AWS ELB について、詳しく解説します。
目次 <Contents>
AWS ELBとはどのようなサービスか

AWS ELB(Elastic Load Balancing)は、その名のとおり「負荷分散(Load Balancing)」を担うサービスです。アプリケーションへのトラフィックを複数のサーバーへ自動的に振り分ける役割を果たします。
たとえば、複数のEC2インスタンスで1つのWebサービスを構成している場合、ELBを使用することで、ユーザーからのリクエストを適切なインスタンスに振り分けることが可能です。これにより、高い可用性とスケーラビリティを実現でき、システムの安定性も大きく向上します。AWS ELBは、大規模な商用サービスから、小規模なアプリケーションまで幅広く利用されている重要なインフラサービスのひとつです。
AWS ELBの種類
現在、AWS ELBは大きく分けて4種類のロードバランサを提供しています。
ALB | NLB | GWLB | CLB | |
OSI層 | 第7層(アプリケーション層) | 第4層(トランスポート層) | 第3層(ネットワーク層) | 第4層 / 第7層 |
対応プロトコル | HTTP, HTTPS | TCP, UDP, TLS | 任意のIPトラフィック | HTTP, HTTPS, TCP |
主な用途 | Webアプリ、API、コンテナ環境 | ゲーム、VoIP、金融系アプリ | 仮想ファイアウォール、監視連携 | レガシーWebアプリ |
スループット性能 | 中〜高 | 非常に高い | 中〜高(用途による) | 中 |
固定IP対応 | ✕(DNS名のみ) | ○(Elastic IP可) | ✕(内部トラフィック用) | ✕(DNS名のみ) |
WAFとの統合 | ○(統合可能) | ✕(別途構成が必要) | ✕ | ✕ |
主な連携サービス | ECS, EKS, Lambda | 高速TCPアプリ、VPN接続等 | IDS/IPS, サードパーティ製品 | EC2(旧式環境) |
新規利用の推奨 | ◎ | ◎ | △(高度な用途) | ✕(非推奨・移行推奨) |
ヘルスチェックの詳細設定 | パス・コードなど細かく設定可 | ポート単位で設定 | 仮想アプライアンスが判断 | 限定的 |
アプリケーションロードバランサー(ALB)
アプリケーションロードバランサーは、AWS内で標準的に利用されているロードバランサーサービスです。ロードバランサーを導入する際は、まずこのALBの利用が推奨されていると捉えましょう。
ALBはOSI参照モデルの第7層(アプリケーション層)で動作し、HTTPおよびHTTPSトラフィックのルーティングが主な役割です。また、パスベースやホストベースのルーティングにも対応し、複雑なWebアプリケーションやマイクロサービス環境においても採用されています。
特に、ECSやEKSといったコンテナ基盤との相性が良いロードバランサです。近年は、トラフィックの内容に基づいた細かい制御を実現するためにも使われるようになりました。
ネットワークロードバランサー(NLB)
ネットワークロードバランサーは、毎秒数百万のリクエストを処理できる高性能なロードバランサーです。短時間に大量のトラフィックを処理する必要があるケースでは、ALBよりもNLBのほうが適しています。
NLBは、OSI参照モデルの第4層(トランスポート層)で動作し、TCPやUDPなどのトラフィックを扱うことが可能です。また、DNSレベルのトラフィック分散にも対応し、レイテンシの低さや高いスケーラビリティが求められる場面で採用されています。
たとえば、金融系やゲームサーバーでは、通信のリアルタイム性が重視されがちです。そのため、ALBよりもNLBがよく使われます。
ゲートウェイロードバランサー(GWLB)
ゲートウェイロードバランサーは、第3層(ネットワーク層)で動作し、主にセキュリティ関連のサービスと連携するロードバランサーです。仮想ファイアウォール、IDS/IPSなどをトラフィック経路に取り入れることで、高い透明性で通信を中継できます。
たとえば、複数のVPC間にまたがるトラフィックを一元的に処理したい場合や、サードパーティのセキュリティ製品を導入する際に有効です。
ただ、基本的には内部用に用いられるロードバランサであるといえます。ALBのように、直接的なWeb公開として用いることはおすすめできません。
クラシックロードバランサー(CLB)
クラシックロードバランサーは、AWSが提供していた初期型のロードバランサーです。アプリケーション層(HTTP/HTTPS)およびトランスポート層(TCP)双方に対応していました。
現在は新規での利用は非推奨であり、ALBやNLBへの移行が推奨されています。ただし、レガシーシステムとの互換性のために一部の環境ではまだ利用が残っている状況です。
AWS ELBの特徴
AWS ELBを活用することによるメリットやデメリットなど、主な特徴は以下のとおりです。
簡単に負荷分散できる
AWS ELBはロードバランサーであるため、導入するだけで簡単に負荷分散を実現できます。アプリケーションロードバランサーを使えばHTTP/HTTPS通信の負荷分散が可能です。
また、AWS内での負荷分散だけでなく、オンプレミスサーバーと連携したハイブリッドな構成にも対応が可能です。近年はクラウドとオンプレミスを組み合わせることも増加しているため、柔軟なアーキテクチャ設計を実現できます。
自動的にスケーラビリティが変化する
自動的にスケーラビリティが変化するため、突発的に大量のアクセスが発生した場合でも自動で負荷分散できます。その結果、サービスが安定することもメリットといえるでしょう。
大量のリクエストがある場合は、ネットワークロードバランサーを利用して分散処理を実現できます。ただ、ロードバランサがボトルネックになっては意味がありません。AWS ELBならば、このような状況を自動的なスケーラビリティで回避できるのです。
もちろん、それに対応したサーバー構成が求められます。とはいえ、適切に設計できていれば、可用性や耐障害性を高められる点は大きなメリットです。
各種モニタリングに対応している
AWS ELBは、アプリケーションのモニタリング機能にも対応しています。あらかじめ監視対象を設定しておくことで、サーバーの正常性やパフォーマンスを常時評価することが可能です。これにより、負荷状況に応じたルーティング制御や自動スケーリングを実行できます。
本来であれば、人手による監視と対応が必要な作業でしょう。しかし、AWSではこれらのプロセスを自動化できるため、運用負担を大きく軽減できます。
独自ドメインに対応している
AWS ELBは独自ドメインの設定が可能で、インターネットからのアクセスを容易に実現できます。ELBに割り当てられたドメイン名と、ユーザーが所有する独自ドメインをRoute 53などのDNSサービスで紐づけることで、ロードバランサーを外部へ公開できるのです。
ただし、固定IPアドレスを使用したい場合は、Route 53とElastic IPを組み合わせるなどの対応が求められます。実現したいアーキテクチャによっては、追加の設定が必要になり、設計が難しくなるため注意しましょう。
SSLやTLSに対応している
AWS ELBは、SSL/TLSによるセキュアな通信にも対応しています。ドメインに対してSSL証明書を適用することで、通信内容を暗号化し、セキュリティを向上させることが可能です。
また、AWS Certificate Manager(ACM)と連携することで、証明書の発行・更新・適用が容易に実現できます。これらセキュリティの設定は「難しそうだ」と思われがちですが、AWSのUIでは最小限の操作で適用できるのです。初心者にも扱いやすい設計であり、AWS ELBのセキュリティを高めつつ運用できます。
AWS WAFと連携できる
Webアプリケーションへの攻撃対策として、AWS WAF(Web Application Firewall)との連携が可能です。ELBとWAFを組み合わせることで、悪質なリクエストを遮断し、アプリケーションを保護できます。
一般的には、ロードバランサー構築時にあわせてWAFも導入すべきです。AWSでは数クリックで設定でき、用意されているルールのテンプレートを選ぶため、大きな負担ではありません。初心者でも基本的なセキュリティ対策を講じることができるような設計です。ただし、細かなチューニングには専門知識が必要であり、その点には注意してください。
ロードバランサーを運用しやすい
一般的に、ロードバランサーなどネットワーク機器の運用は手間がかかるものです。しかし、AWS ELBはAWSマネジメントコンソールから直感的に操作でき、管理の負担が軽減されます。他のAWSサービスと同様に、わかりやすい直感的なUIで構成されているからです。
また、AWS ELBは利用者が多く、公式ドキュメントやヘルプ機能も充実しています。不明点があっても自己解決しやすい点も魅力でしょう。
AWS ELBの料金体系
AWS ELBの料金は、稼働時間、処理されたリクエスト数、転送されたデータ量に応じて変動します。ELBには種類があり、それぞれで料金体系が異なります。
料金のイメージ
東京リージョンの場合、AWS ELBの料金は以下のとおり加算されます。
料金 | 単位 | |
ALB | USD 0.0243USD | ALB時間 (または 1 時間未満) |
USD 0.008 | LCU 時間 (または 1 時間未満) | |
USD 0.0054 | ALB に関連付けられたトラストストアごとに相互 TLS の使用 1 時間 (または 1 時間未満) | |
NLB | USD 0.0243 | Network Load Balancer 時間 (または 1 時間未満) |
USD 0.006 | NLCU 時間 (または 1 時間未満) | |
GWLB | USD 0.0135 | AZ あたりの Gateway Load Balancer 時間 (または 1 時間未満) |
USD 0.004 | GLCU 時間 (または 1 時間未満) | |
CLB | USD 0.027USD 0.008 | CLB により処理されたデータの GB 単位 |
料金に関連するキーワードの意味は以下のとおりです。
- ● LCU:ALBがトラフィックを処理する際「新しい接続」「アクティブ接続」「処理タイプ」「ルール評価」から算出
- ● NLCU:NLBがトラフィックを処理する際「新しい接続」「アクティブ接続」「処理バイト」から算出
- ● GLCU:GWLBがトラフィックを処理する際「新しい接続」「アクティブ接続」「処理バイト」から算出
想定外のコストには注意
ELBは、インスタンスのように「停止」ができるものではなく、常に稼働している限り課金が発生します。そのため、EC2インスタンスを停止したとしても、ELBが稼働していれば課金対象となります。
コスト削減を図るには、不要なELBを削除する、またはスケジューリングやスクリプトを活用して一時的に構成を見直すといった工夫が求められます。物理的なロードバランサーと比較すれば導入コストは低いものの、継続的な運用コストをしっかり見積もっておくことが重要です。
まとめ
AWS ELBは、AWSのロードバランサーサービスであり、外部に公開するサービスでは必須ともいえる存在です。小規模な仮想サーバーはもちろん、AWSを選ぶことで、サーバーレスアーキテクチャと組み合わせることも可能です。従量課金制であり、物理的なロードバランサーよりもコストを抑えやすい点もポイントといえます。
また、AWSらしく、セキュリティなど関連するサービスとも簡単に連携できます。ロードバランシングを中心に、可用性の高い構成を簡単に構築できる点に注目しましょう。オートスケーリングと組み合わせることで、トラフィックの増減にも柔軟に対応でき、安定したサービス運用にも貢献してくれます。