MENU

【AWS Certified Cloud Practitioner】ロードバランシング超整理:ELB(ALB/NLB/GWLB)とRoute 53で“分散”と“切替”を使い分ける

目次

ロードバランシング(負荷分散)とは何か

ロードバランシングは、ユーザーからの通信(リクエスト/接続)を複数の処理先へ分散し、次を同時に満たすための設計手法です。

  • 性能(Performance):1台に集中させず、処理遅延やタイムアウトを減らす
  • 可用性(Availability):一部が故障してもサービスを継続する
  • スケーラビリティ:需要に合わせて処理先を増減できる

AWSでは主に、ロードバランシングをElastic Load Balancing(ELB)で実現します。ELBは受信トラフィックを複数ターゲットへ分散し、ターゲットのヘルス(正常性)を監視して正常なターゲットのみにルーティングします。公式ドキュメント:https://docs.aws.amazon.com/elasticloadbalancing/


試験で押さえるべき“本質”:切替(フェイルオーバー)と分散(ロードバランス)の違い

クラウドプラクティショナーでは、用語や作り込み手順よりも、「何のために使うか」が問われがちです。特に以下の区別は頻出です。

分散(Load Balancing)

最初から複数台へ分散し、1台への集中を起こさない考え方です。

  • 通常時も複数台へ配る(平常運用が前提)
  • ヘルスチェックで不健康なターゲットを自動的に外す
  • 需要増に合わせてターゲットを追加しやすい

切替(Failover)

基本は片系で動かし、異常時に別系へ切り替える考え方です。

  • 障害対応・災害対策(DR)で登場しやすい
  • DNSやルーティングポリシーで「プライマリ→セカンダリ」へ逃がす構成が典型

DNSレベルの切替は、Amazon Route 53のフェイルオーバールーティングが代表例です(ヘルスチェックと連動)。公式ドキュメント:https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-failover.html


ELBの全体像:ALB / NLB / GWLB(+CLB)

ELBは用途別に複数タイプがあります。Cloud Practitionerでは「どれをどのケースで使うか」を説明できるレベルが目安です。

Application Load Balancer(ALB):L7(HTTP/HTTPS)向け

ALBはOSI第7層(アプリケーション層)で動作し、リクエスト内容(URLパス、Hostヘッダー等)に基づくルーティングができます。公式ドキュメント:https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/introduction.html

  • 例:/apiはAPI群へ、/imagesは画像サービスへ(パスベースルーティング)
  • 例:app.example.comadmin.example.comで振り分け(ホストベース)

Network Load Balancer(NLB):L4(TCP/UDPなど)・高性能向け

NLBはOSI第4層(トランスポート層)で動作し、大量の接続/トラフィックを低レイテンシで扱う用途に向きます。ターゲットグループはTCP/UDP/TLS等をサポートします。公式ドキュメント:https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/introduction.html

  • 例:TCPベースのアプリ、独自プロトコル、超高スループットの入口
  • 例:静的IPが必要なケース(Elastic IPの割り当て等)

Gateway Load Balancer(GWLB):L3(IPパケット)・セキュリティアプライアンス向け

GWLBはOSI第3層(ネットワーク層)で動作し、ファイアウォール/IDS/IPS/ディープパケットインスペクションなどの仮想アプライアンス群を透過的にスケールさせる用途です。公式ドキュメント:https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/gateway/introduction.html

  • 「すべてのトラフィックの入口/出口ポイントを作り、検査アプライアンスへ通す」といった構成で登場

Classic Load Balancer(CLB):前世代(既存向けの位置づけ)

CLBは「前世代のロードバランサー」として位置づけられ、必要条件に応じてALB/NLBが選択されるケースが一般的です(特にVPC利用が前提の現場ではALB/NLBが中心)。参考:Elastic Beanstalkドキュメント内の説明:https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-clb.html

タイプ選定の公式整理(AWS比較ページ):https://aws.amazon.com/compare/the-difference-between-the-difference-between-application-network-and-gateway-load-balancing/


ロードバランスを「本来の使い方」にするための3要素

1) 常時分散(平常運用で効かせる)

「混雑したら切替」ではなく、平常時から複数ターゲットへ分散します。これにより、スパイク(突発的増加)でも各台が余力を持ちやすくなります。

2) ヘルスチェック(正常な先にだけ送る)

ELBはターゲットのヘルスを監視し、正常なターゲットにのみルーティングします。これは可用性の要で、設計時は「何をもって正常とするか(/healthで何を確認するか)」が重要です。

3) 需要変動への追従(Auto Scalingと組み合わせる)

ロードバランサー単体でも分散はできますが、需要増に合わせて処理台数を増やすには、Amazon EC2 Auto Scalingなどと組み合わせるのが王道です。ELBのヘルスチェックとAuto Scalingを連動させる考え方は、信頼性設計の文脈でも扱われます。参考(Well-Architected関連のベストプラクティス例):https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/operational-best-practices-for-wa-Reliability-Pillar.html


Route 53は“ロードバランサー”なのか?(試験で混乱しやすい点)

Amazon Route 53はDNSサービスであり、ELBのように「その場で接続/HTTPリクエストを中継して分散する」ものではありません。一方で、DNS応答の返し方を変えることで、結果としてトラフィックの行き先を分散/切替できます。

Route 53の代表的ルーティングポリシー(覚え方)

  • Weighted(加重):Aに70%、Bに30%など段階的移行に便利
  • Latency(レイテンシ):最も低遅延になりやすいリージョンへ
  • Failover:プライマリが不健康ならセカンダリへ
  • Geolocation/Geoproximity:地理条件で出し分け
  • Multivalue Answer:複数IPを返し、ヘルスチェックで不健康を除外

公式ドキュメント(一覧):https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html

Multivalue Answerの公式説明:https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-multivalue.html

試験的な言い換え
ELB=「アプリ/接続の入口で分散して中継する」
Route 53=「名前解決(DNS応答)で行き先を選ばせる」


よく出る選択問題の型(Cloud Practitioner向け)

  • HTTP/HTTPSのWebアプリ、パスで振り分けたい → ALB
  • TCP/UDP、超高スループット、低レイテンシ → NLB
  • ファイアウォール等の検査アプライアンスを透過的にスケール → GWLB
  • 異常時に別系へ切替(DR/冗長) → Route 53 Failover など

学習の公式ソース(一次情報)

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次