AWS ELB VISUALIZER

AWS ELB ロードバランサールーティング

受信トラフィックを複数のターゲットに自動分散するロードバランシングサービス

シナリオ

リクエストを順番に A→B→C→A→B→C... と均等に振り分ける最もシンプルな方式

ステップ1 / 31

◎

ルーティング

ラウンドロビン: リクエストを順番に各インスタンスへ振り分ける

ラウンドロビンは最もシンプルなアルゴリズムです。リクエストが届くたびに A → B → C → A → B → C ... と順番に振り分けます。全インスタンスに均等にリクエストが配分されます。

ARCHITECTURE DIAGRAM

ELB → Auto Scaling Group ルーティング

STEP 1

CODE VIEW

── Auto Scaling Group 構成 ──
 
  ELB (Elastic Load Balancer)
    ├─ インスタンス A  [Healthy]
    ├─ インスタンス B  [Healthy]
    └─ インスタンス C  [Healthy]
 
  ルーティングアルゴリズム: ラウンドロビン
  ◎ リクエストを順番に A → B → C → A → ... と振り分ける

ELB (ロードバランサー)

ルーティング先

Unhealthy

Auto Scaling Group

未選択

解説

⚖️
ELB（Elastic Load Balancing）とは何か

ELB（Elastic Load Balancing）は、AWSが提供するフルマネージドのロードバランサーサービスです。複数のEC2インスタンスやコンテナにトラフィックを自動的に分散させることで、アプリケーションの可用性・耐障害性・スケーラビリティを高めます。ELB自体もAWSが冗長化して管理しているため、ロードバランサー自身が単一障害点になることはありません。

ELBの主な役割は、リクエストの分散（複数ターゲットへのトラフィック振り分け）、ヘルスチェック（異常なターゲットの自動除外）、SSL/TLS終端（暗号化処理のオフロード）の3つです。Auto Scaling Groupと組み合わせることで、負荷に応じたインスタンスの自動増減にも対応できます。

# ELBの現在のターゲットヘルスを確認
$ aws elbv2 describe-target-health \
    --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456:targetgroup/my-tg
 
{ "TargetHealthDescriptions": [
    { "Target": { "Id": "i-0abc1234" }, "TargetHealth": { "State": "healthy" } },
    { "Target": { "Id": "i-0def5678" }, "TargetHealth": { "State": "healthy" } },
    { "Target": { "Id": "i-0ghi9012" }, "TargetHealth": { "State": "healthy" } }
] }

初心者向け: ELBは「レストランの案内係」のようなものです。お客さん（リクエスト）が来たら、空いているテーブル（インスタンス）に案内します。満席や休憩中（Unhealthy）のテーブルには案内せず、空きがあるテーブルに均等にお客さんを振り分けます。

🛤️
リスナーとターゲットグループ

ELBの振り分けはリスナー → ルール評価 → ターゲットグループという3段階で行われます。リスナーはポート（80や443）で待ち受け、届いたリクエストに対してルールを上から順に評価し、最初にマッチしたルールのアクション（転送・リダイレクト・固定レスポンスなど）を実行します。

ターゲットグループ（TG）は、ELBがトラフィックを転送する先のサーバー群をまとめたものです。EC2インスタンス、ECSコンテナ、Lambda関数、IPアドレスなどをターゲットとして登録できます。1つのリスナーに最大100個のルールを設定でき、どのルールにもマッチしなかった場合はデフォルトアクションが実行されます。

# ALBリスナールールの設定例
リスナー (HTTPS:443)
  ├─ ルール1 (優先度10): IF path=/api/*    THEN Forward → api-tg
  ├─ ルール2 (優先度20): IF path=/images/* THEN Forward → img-tg
  ├─ ルール3 (優先度30): IF host=admin.*   THEN Forward → admin-tg
  └─ DEFAULT:  Fixed Response 404

🔄
ルーティングアルゴリズム

ELBがターゲットグループ内のどのインスタンスにリクエストを振り分けるかを決めるルーティングアルゴリズムには主に2つの方式があります。ALBのデフォルトはラウンドロビンですが、ターゲットグループの属性で変更できます。

ラウンドロビン（Round Robin）

リクエストを順番に各インスタンスへ振り分けます。A → B → C → A → B → C ... のように均等に分配されます。最もシンプルで、各インスタンスのスペックが同じ場合に適しています。ALBのデフォルトのアルゴリズムです。

最小リクエスト数（Least Outstanding Requests）

各インスタンスが現在処理中のリクエスト数を追跡し、最も空いているインスタンスに新しいリクエストを送ります。重い処理（レポート生成など）と軽い処理（ヘルスチェック応答など）が混在する場合に効果的です。

加重ターゲットグループ（Weighted Target Groups）

複数のターゲットグループに重み（Weight）を設定して、トラフィックの割合を制御します。カナリアデプロイ（新バージョンに10%、旧バージョンに90%など）に活用されます。

📌
セッション固定（Sticky Session）

セッション固定（Sticky Session）を有効にすると、同じクライアントからのリクエストは常に同じインスタンスに振り分けられます。ELBが発行するAWSALBCookieでクライアントとインスタンスの紐付けを管理します。

ショッピングカートやログインセッションをサーバー側のメモリで保持している場合に必要です。ただし、特定のインスタンスに負荷が偏るリスクがあるため、可能であればセッション情報をElastiCache（Redis）やDynamoDBに外部化することが推奨されます。

Duration-Based Cookie（ELB生成）

ELBが自動的にAWSALBCookieを生成・管理します。有効期間（1秒〜7日）を設定し、期間経過後は再分散されます。最も簡単な設定方法です。

Application-Based Cookie（アプリ生成）

アプリケーションが生成するカスタムCookieで固定先を制御します。ログアウト時にCookieを削除して再分散させるなど、アプリ側でセッション管理を柔軟に制御できます。

// セッション固定の有効化（Duration-Based）
$ aws elbv2 modify-target-group-attributes \
    --target-group-arn arn:aws:...:targetgroup/my-tg \
    --attributes Key=stickiness.enabled,Value=true \
                Key=stickiness.type,Value=lb_cookie \
                Key=stickiness.lb_cookie.duration_seconds,Value=86400

💓
ヘルスチェックとフェイルオーバー

ELBは各インスタンスに定期的にヘルスチェック（HTTP GETリクエスト）を送信します。応答がない、またはステータスコードが異常な場合、そのインスタンスをUnhealthyと判定し、ルーティング対象から自動除外します。復旧すると自動的にルーティング対象に戻ります。

設定	デフォルト	説明
パス	/health	チェック用のHTTPパス
間隔	30秒	チェックの実行間隔
成功しきい値	5回連続	Healthyに戻すまでの回数
失敗しきい値	2回連続	Unhealthyにするまでの回数
タイムアウト	5秒	応答待ちの最大時間
成功コード	200	Healthyと判定するHTTPステータス

重要: Unhealthyなインスタンスが復旧してヘルスチェックに5回連続で成功すると、自動的にHealthyに戻りルーティング対象に復帰します。この仕組みにより、手動介入なしで障害から回復できます。

⚖️
ELB の種類: ALB vs NLB vs CLB

ELBには3種類のロードバランサーがあります。動作するレイヤーと得意分野が異なるため、ユースケースに合わせて選択します。SAA試験では「このシナリオにはどのELBが最適か？」が頻出です。

ALB（Application Load Balancer）— L7

HTTP/HTTPSの中身（URLパス、ホスト名、HTTPヘッダー、クエリパラメータ）を読み取って高度なルーティングが可能。WebSocket対応。Webアプリ・API・マイクロサービス向け。SSL/TLS終端、認証（Cognito/OIDC）統合、WAF連携にも対応。

NLB（Network Load Balancer）— L4

TCP/UDPレベルで超高速ルーティング（数百万req/sec、超低レイテンシ）。固定IP・Elastic IP対応。ゲームサーバー、IoT、金融取引、VPNエンドポイント向け。PrivateLinkの背後に配置可能。

CLB（Classic Load Balancer）— レガシー

旧世代。新規では非推奨。EC2-Classicネットワーク向けに設計されたもの。既存のCLBはALBまたはNLBへの移行が推奨されます。移行ウィザードも提供されています。

📈
Auto Scaling Group との連携

ELBはAuto Scaling Group（ASG）と組み合わせることで真価を発揮します。ASGが負荷に応じてインスタンスを自動増減し、ELBは新しいインスタンスを自動的にルーティング対象に追加します。

スケールアウト時は、新しいインスタンスがヘルスチェックに合格した時点でトラフィックを受け始めます。スケールイン時は、Connection Draining（Deregistration Delay）により処理中のリクエストが完了するまで待ってからインスタンスを終了します。デフォルト300秒です。

// ASG + ELB の接続設定
$ aws autoscaling attach-load-balancer-target-groups \
    --auto-scaling-group-name my-asg \
    --target-group-arns arn:aws:...:targetgroup/my-tg
 
// スケーリングポリシー: CPU 70% 超でスケールアウト
$ aws autoscaling put-scaling-policy \
    --policy-type TargetTrackingScaling \
    --target-tracking-configuration \
      TargetValue=70,PredefinedMetricSpecification={
        PredefinedMetricType=ASGAverageCPUUtilization}

🌐
Cross-Zone Load Balancing

AWSでは複数のアベイラビリティゾーン（AZ）にまたがってインスタンスを配置するのがベストプラクティスです。Cross-Zone Load Balancingを有効にすると、ELBはすべてのAZのインスタンスに均等にトラフィックを分散します。

無効の場合、各AZのELBノードはそのAZ内のインスタンスにのみトラフィックを転送します。AZ間でインスタンス数が異なる場合、少ないAZのインスタンスに負荷が集中してしまいます。ALBではデフォルトで有効、NLBではデフォルトで無効です。

SAA試験ポイント: ALBではCross-Zone Load Balancingがデフォルトで有効であり、追加料金はかかりません。NLBでは無効がデフォルトで、有効にするとAZ間のデータ転送料金が発生します。「AZ間でインスタンス数が偏っているのに負荷が均等でない」という問題が出たら、Cross-Zoneの設定を確認しましょう。

🔒
SSL/TLS終端とセキュリティ

ALBはSSL/TLS終端（Termination）に対応しており、ACM（AWS Certificate Manager）で発行した無料のSSL証明書をアタッチできます。クライアントとELB間はHTTPSで暗号化し、ELBとバックエンドEC2間はHTTPで通信することで、EC2側のCPU負荷を軽減できます。

さらにALBはAWS WAFと連携でき、SQLインジェクションやXSSなどの攻撃をELBの手前でブロックできます。Cognito / OIDC認証をALBに統合すれば、アプリケーションコードを変更せずにログイン認証を追加することも可能です。

ACM証明書（無料SSL）

AWS Certificate Managerで発行したSSL/TLS証明書は無料で自動更新されます。ALBにアタッチするだけでHTTPS化が完了し、証明書の更新作業が不要になります。

AWS WAF連携

ALBにWAFを関連づけると、SQLインジェクション・XSS・レートリミットなどのルールでリクエストをフィルタリングできます。AWSマネージドルールを使えば設定も簡単です。

認証統合（Cognito / OIDC）

ALBのリスナールールに認証アクションを追加すると、Amazon CognitoやOIDCプロバイダー（Google, Oktaなど）によるログイン認証をアプリコード変更なしで実装できます。

🎓
AWS 認定試験（SAA）レベルの問題

Q1. ECサイトのWebアプリケーションが3台のEC2インスタンスで稼働しています。ユーザーがショッピングカートに商品を追加した後、別のページに遷移するとカートの内容が消えてしまうという報告があります。ELBのルーティングアルゴリズムは Round Robin です。最も適切な解決策はどれですか？

Q2. Auto Scaling Group に接続された ALB でWebアプリケーションを運用しています。定期的にインスタンスがスケールインされる際、一部のユーザーが "502 Bad Gateway" エラーを報告しています。この問題の最も適切な解決策はどれですか？

Q3. マイクロサービスアーキテクチャで、/api/users/* と /api/orders/* を異なるECSサービスにルーティングしたい場合、最適なロードバランサーはどれですか？

AWS ELB ロードバランサールーティング

⚖️
ELB（Elastic Load Balancing）とは何か

🛤️
リスナーとターゲットグループ

🔄
ルーティングアルゴリズム

📌
セッション固定（Sticky Session）

💓
ヘルスチェックとフェイルオーバー

⚖️
ELB の種類: ALB vs NLB vs CLB

📈
Auto Scaling Group との連携

🌐
Cross-Zone Load Balancing

🔒
SSL/TLS終端とセキュリティ

🎓
AWS 認定試験（SAA）レベルの問題

関連コンテンツ

AWS IAM ポリシー評価ロジック

AWS IAM AssumeRole（STS）

AWS RDS マルチAZ構成

AWS RDS リードレプリカ

AWS RDS Proxy

AWS RDS バックアップとスナップショット

⚖️ELB（Elastic Load Balancing）とは何か

🛤️リスナーとターゲットグループ

🔄ルーティングアルゴリズム

📌セッション固定（Sticky Session）

💓ヘルスチェックとフェイルオーバー

⚖️ELB の種類: ALB vs NLB vs CLB

📈Auto Scaling Group との連携

🌐Cross-Zone Load Balancing

🔒SSL/TLS終端とセキュリティ

🎓AWS 認定試験（SAA）レベルの問題

関連コンテンツ

AWS IAM ポリシー評価ロジック

AWS IAM AssumeRole（STS）

AWS RDS マルチAZ構成

AWS RDS リードレプリカ

AWS RDS Proxy

AWS RDS バックアップとスナップショット

⚖️
ELB（Elastic Load Balancing）とは何か

🛤️
リスナーとターゲットグループ

🔄
ルーティングアルゴリズム

📌
セッション固定（Sticky Session）

💓
ヘルスチェックとフェイルオーバー

⚖️
ELB の種類: ALB vs NLB vs CLB

📈
Auto Scaling Group との連携

🌐
Cross-Zone Load Balancing

🔒
SSL/TLS終端とセキュリティ

🎓
AWS 認定試験（SAA）レベルの問題