AWS Application Load Balancer (ALB) 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS Application Load Balancer（ALB） は、HTTP/HTTPS/WebSocket トラフィック向けの L7 ロードバランサー です。URL パス・ホスト・HTTP ヘッダー・クエリ文字列に基づく高度なコンテンツベースルーティングで、複数のマイクロサービス・ECS/EKS コンテナ・Lambda サーバーレス機能を 1 つのエントリーポイントに集約します。本ドキュメントは、ALB の概念・ルーティング・セキュリティ・運用を初心者から実務者まで体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています：

初心者向け： ALB とは何か、なぜ必要かを学びたい方
開発者向け： ターゲットグループ・リスナールール・SSL/TLS を設定したい方
DevOps/SRE 向け： ECS/EKS 統合・ヘルスチェック・CloudWatch 監視を実装したい方
セキュリティ向け： WAF・Shield・mTLS・Cognito 認証統合を構築したい方
意思決定者向け： NLB/GWLB との比較・投資判断・他社ツール比較

2026 年の ALB エコシステム

ALB HTTP/3 対応：2025 年より段階的に導入、QUIC によるレイテンシ削減
Anycast Static IPs：複数 AZ 間での同一 IP アドレス公開、BGP ポリシーベースルーティング
mTLS（相互 TLS）GA：ターゲット ↔ ALB 間の暗号化通信
Lambda ターゲットグループ直対応：Lambda@Edge 統合強化
IPv6 完全対応：デュアルスタック設定の簡素化
生成 AI ワークロード向け最適化：大規模トークンストリーミング対応
ALB Insights：CloudWatch Logs ベースの自動トラブルシューティング
AWS WAF v2 統合強化：ルール管理の一元化

概要
ALB が解決する課題
主な特徴
アーキテクチャ
ALB vs NLB vs GWLB vs CLB
リスナーとリスナールール
ターゲットグループ
主要ユースケース
ヘルスチェック
Sticky Session（Cookie ベース）
SSL/TLS（ACM, SNI, mTLS）
ALB と Cognito 認証統合
ALB と OIDC 認証統合
ALB と WAF/Shield 連携
アクセスログ
CloudWatch Metrics と監視
CloudWatch Logs/X-Ray 統合
Cross-Zone Load Balancing
ALB と CloudFront 連携
Internal vs Internet-facing
VPC Lattice との関係
他の類似ツールとの比較
クライアントとエコシステム
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例・活用シーン
導入ロードマップ
実装チェックリスト
まとめ
参考文献

概要

初心者向けメモ： ALB は「HTTP/HTTPS リクエストを URL パス・ホスト・ヘッダー に基づいて複数のバックエンドサーバーに振り分ける」フロントエンド機能です。NLB とは異なり、HTTP の中身を見て判断するため、L7（アプリケーション層）ロードバランサーと呼ばれます。ECS/EKS コンテナ化アプリケーションのデファクトスタンダード。

Application Load Balancer（ALB）は AWS が提供する Layer 7（L7、アプリケーション層）ロードバランサー です。公式ドキュメントに基づくと、ALB は以下を実現します：

HTTP/HTTPS/WebSocket リクエストの高度なルーティング
URL パス・ホスト・HTTP ヘッダー・クエリ文字列・HTTP メソッド・送信元 IP に基づくコンテンツベースルーティング
ECS/EKS マイクロサービスの自動ターゲット登録・削除
AWS Certificate Manager（ACM）による無料 HTTPS 証明書自動更新
AWS Cognito / OIDC IdP との認証統合
AWS WAF との統合によるリクエストフィルタリング
アクセスログ・CloudWatch メトリクス・X-Ray トレース統合

ALB の位置づけ

【図1】AWS ロードバランサーエコシステムにおける ALB の位置：

graph TD
    HTTPReq["HTTP/HTTPS<br/>WebSocket<br/>gRPC"]
    TCPReq["TCP/UDP<br/>TLS"]
    L3Req["IPパケット<br/>（L3フロー）"]

    HTTPReq -->|L7コンテンツベース<br/>ルーティング| ALB["ALB<br/>Layer 7<br/>汎用・ECS/EKS向け"]
    TCPReq -->|L4ポートベース<br/>高速スイッチング| NLB["NLB<br/>Layer 4<br/>超低レイテンシ<br/>固定IP"]
    L3Req -->|透過プロキシ<br/>セキュリティアプライアンス| GWLB["GWLB<br/>Layer 3<br/>セキュリティ機器"]

    CLB["CLB<br/>レガシー<br/>廃止予定"]

    ALB --> ECS["ECS/EKS<br/>コンテナ"]
    ALB --> Lambda["Lambda<br/>サーバーレス"]
    NLB --> Game["ゲーム<br/>オンライン金融"]

ALB が解決する課題

課題	従来（ないしALBなし）	ALB で解決
複数マイクロサービスを 1 つの IP で公開したい	各サービスに個別の DNS を割り当て	`/api/` → API, `/app/` → Web, `/admin/*` → Admin に単一 ALB で振り分け
サービススケーリング時のターゲット管理	手作業で登録・削除	ECS/EKS と統合し自動登録・削除
HTTPS 証明書の更新・更新漏れリスク	自社で更新管理	ACM 統合で無料・自動更新
認証ロジックをバックエンド実装	すべてのアプリに認証コード必須	Cognito/OIDC を ALB で一元化
Web Application Firewall の構築	各アプリに独立した WAF	AWS WAF 統合で L7 攻撃対策
WebSocket チャットアプリの負荷分散	NLB + TCP で対応（L7 ルーティング不可）	ALB が HTTP アップグレード・WebSocket をネイティブ対応
Blue/Green デプロイ時のトラフィック切り替え	手作業または複雑なスクリプト	ALB ターゲットグループ重み付けで自動切り替え

主な特徴

特徴	説明
コンテンツベースルーティング	URL パス・ホスト・ヘッダー・クエリ文字列・HTTP メソッド・送信元 IP に基づいてターゲットを選択
複数プロトコル対応	HTTP/1.1, HTTP/2, WebSocket, wss:// をサポート（HTTP/3 は 2025 年末到来予定）
ECS/EKS 完全統合	タスク追加・停止時にターゲット自動登録・削除。複数ポートマッピング対応
Lambda ターゲット対応	HTTP イベントとして Lambda を直接ターゲットにし、サーバーレスアプリを公開
SSL/SNI 多証明書対応	複数ドメインの HTTPS を 1 つの ALB でホスト
ACM 統合	無料の HTTPS 証明書を自動更新、有効期限切れリスク排除
Cognito / OIDC 認証統合	OpenID Connect IdP（Okta, Auth0 等）と統合し ALB で認証・認可を実施
AWS WAF 統合	L7 フィルタリング（SQLi, XSS, レート制限等）を ALB に付与
AWS Shield DDoS 対策	ALB は自動的に AWS Shield Standard を適用
アクセスログ	S3 へのアクセスログ自動出力
CloudWatch Metrics & Logs	詳細なメトリクス・ログを CloudWatch に統合
X-Ray トレース対応	リクエスト ID を自動埋め込み、X-Ray で分散トレース
Cross-Zone Load Balancing	複数 AZ 間でアクティブに負荷分散（有効化で追加料金あり）
Sticky Session	クッキーベースのセッション維持
HTTP→HTTPS 自動リダイレクト	リスナールールで HTTP 80 → HTTPS 443 をリダイレクト
カスタムヘッダー挿入	ターゲットに X-Forwarded-For, X-Forwarded-Proto 等を自動追加
マネージドサービス	パッチ・スケーリング・冗長化は AWS が管理

アーキテクチャ

初心者向けメモ： ALB は図のとおり 3 層構造です。「リスナー」でポート 80/443 を受信 → 「リスナールール」で URL を検査 → 「ターゲットグループ」にトラフィック転送。各層が独立しているため、ルールを追加・変更しても別の層に影響しません。

【図2】ALB アーキテクチャ（Listener → Rule → TargetGroup → Targets）：

graph TD
    Client["クライアント<br/>ブラウザ / API"]
    
    Client -->|HTTP/HTTPS| ENI["ALB ENI<br/>複数 AZ"]
    
    ENI --> L["Listener<br/>（ポート 80/443）"]
    
    L --> R["Listener Rule<br/>（優先度 1-100）"]
    
    R -->|Path /api/*| TG1["TargetGroup A<br/>API Service"]
    R -->|Path /static/*| TG2["TargetGroup B<br/>S3 / CloudFront"]
    R -->|Host api.example.com| TG3["TargetGroup C<br/>別マイクロサービス"]
    R -->|DEFAULT| TG4["TargetGroup Default<br/>Fallback"]
    
    TG1 --> T1["Target 1<br/>ECS Task<br/>Port 8080"]
    TG1 --> T2["Target 2<br/>ECS Task<br/>Port 8080"]
    TG1 --> T3["Target 3<br/>EC2 Instance"]
    
    TG3 --> T4["Target 4<br/>Lambda<br/>Synchronous"]
    
    T1 -->|Health Check| HC["Health Check<br/>GET /health"]

コアコンポーネント

1. リスナー（Listener）

ALB がリッスンするエントリーポイント。複数リスナーが同じ ALB に存在可能。

# HTTP リスナーの作成（ポート 80）
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:... \
  --protocol HTTP \
  --port 80 \
  --default-actions '[{
    "Type": "redirect",
    "RedirectConfig": {
      "Protocol": "HTTPS",
      "Port": "443",
      "StatusCode": "HTTP_301"
    }
  }]'

# HTTPS リスナーの作成（ポート 443、ACM 証明書）
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:... \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:region:account:certificate/cert-id \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:...:targetgroup/default-tg/..."
  }]'

2. リスナールール（Listener Rule）

HTTP ヘッダー・パス・ホスト・クエリ文字列などの条件に基づいて、リクエストをどのターゲットグループに振り分けるかを決定。

# Path-based ルーティング：/api/* → API TargetGroup
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 10 \
  --conditions '[{
    "Field": "path-pattern",
    "PathPatternConfig": {"Values": ["/api/*"]}
  }]' \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:...:targetgroup/api-tg/..."
  }]'

# Host-based ルーティング：api.example.com → API TargetGroup
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 20 \
  --conditions '[{
    "Field": "host-header",
    "HostHeaderConfig": {"Values": ["api.example.com"]}
  }]' \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:..."
  }]'

# Header-based ルーティング：X-Request-Type: mobile → Mobile TargetGroup
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 30 \
  --conditions '[{
    "Field": "http-header",
    "HttpHeaderConfig": {
      "HttpHeaderName": "X-Request-Type",
      "Values": ["mobile"]
    }
  }]' \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:..."
  }]'

# Method-based ルーティング：POST /orders → Order Service, GET /orders → Query Service
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 40 \
  --conditions '[
    {
      "Field": "path-pattern",
      "PathPatternConfig": {"Values": ["/orders"]}
    },
    {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {"Values": ["POST"]}
    }
  ]' \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:..."
  }]'

# Query String ルーティング：?version=v2 → v2 API
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 50 \
  --conditions '[{
    "Field": "query-string",
    "QueryStringConfig": {
      "Values": [{"Key": "version", "Value": "v2"}]
    }
  }]' \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:..."
  }]'

# Source IP ルーティング：内部ネットワークのみ特定ターゲットへ
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 60 \
  --conditions '[{
    "Field": "source-ip",
    "SourceIpConfig": {"Values": ["10.0.0.0/16"]}
  }]' \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:..."
  }]'

ルール評価順序と優先度

✅ 優先度は 1 が最高。複数条件は AND で評価。

優先度	条件	アクション
1（最高）	Path = `/api/*` AND Method = POST	→ API Service
10	Path = `/api/*`	→ API Service
20	Host = `api.example.com`	→ API Service
100（最低）	(なし) → デフォルトルール	→ Default TargetGroup

ターゲットグループ

ターゲットグループは ALB が転送先として管理するエンドポイント群。ヘルスチェック結果に基づき、健全なターゲットへのみトラフィックを送信。

ターゲットタイプ

タイプ	説明	用途
Instance	EC2 インスタンス ID・セキュリティグループで指定	従来型 EC2 ホスト
IP	プライベート IP アドレス / ECS Fargate タスク IP	ECS Fargate / オンプレミス
Lambda	Lambda 関数 ARN	サーバーレス API
ALB	別の ALB	ALB チェーニング（複数段構成）

# ターゲットグループの作成（Instance タイプ）
aws elbv2 create-target-group \
  --name web-service-tg \
  --protocol HTTP \
  --port 8080 \
  --vpc-id vpc-xxx \
  --target-type instance \
  --health-check-protocol HTTP \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --matcher HttpCode=200-299

# ターゲットグループの作成（IP タイプ、ECS Fargate）
aws elbv2 create-target-group \
  --name api-fargate-tg \
  --protocol HTTP \
  --port 8080 \
  --vpc-id vpc-xxx \
  --target-type ip \
  --health-check-protocol HTTP \
  --health-check-path /healthz

# ターゲットグループの作成（Lambda タイプ）
aws elbv2 create-target-group \
  --name lambda-api-tg \
  --protocol HTTP \
  --target-type lambda

# ターゲット登録（Instance）
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web-service-tg/... \
  --targets Id=i-1234567890abcdef0 Id=i-0987654321fedcba0

# ターゲット登録（IP）
aws elbv2 register-targets \
  --target-group-arn arn:... \
  --targets Id=10.0.0.10:8080 Id=10.0.0.20:8080

# ターゲット登録（Lambda）
aws elbv2 register-targets \
  --target-group-arn arn:... \
  --targets Id=arn:aws:lambda:region:account:function:my-api-function

# ターゲット登録解除
aws elbv2 deregister-targets \
  --target-group-arn arn:... \
  --targets Id=i-1234567890abcdef0

属性管理

# Sticky Session の有効化（1 日間）
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes \
    Key=stickiness.enabled,Value=true \
    Key=stickiness.type,Value=lb_cookie \
    Key=stickiness.lb_cookie.duration_seconds,Value=86400

# Connection Draining の設定（ターゲット削除時の猶予時間）
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes Key=deregistration_delay.timeout_seconds,Value=300

# アイドルタイムアウトの変更（WebSocket 用）
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes Key=load_balancing.algorithm.type,Value=least_outstanding_requests

ALB vs NLB vs GWLB vs CLB

比較項目	ALB（L7）	NLB（L4）	GWLB（L3）	CLB（L4/L7）
適用レイヤー	Application（L7）HTTP/HTTPS	Transport（L4）TCP/UDP	Network（L3）IP	混合（L4/L7）
処理スピード	中（L7 解析オーバーヘッド）	✅ 極速（μs 単位）	中	遅い（レガシー）
コンテンツルーティング	✅ パス・ホスト・ヘッダー	❌ なし	❌ なし	△ 限定的
超低レイテンシ	❌	✅	❌	❌
固定 IP アドレス	❌（DNS のみ）	✅（Elastic IP）	❌	❌
ECS/EKS 統合	✅ 標準	△ UDP/TCP	❌	△
WebSocket 対応	✅	❌	❌	❌
gRPC 対応	✅	❌	❌	❌
セキュリティアプライアンス	❌	❌	✅（WAF デバイス）	❌
ゲーム / オンライン金融	❌	✅	❌	❌
WAF 統合	✅	❌	❌	❌
Cognito 認証統合	✅	❌	❌	❌
CloudFront オリジン	✅	✅	❌	✅
Lambda ターゲット	✅	❌	❌	❌
mTLS（Target 暗号化）	✅（2025 GA）	❌	❌	❌
コスト	中	高（超高速料金）	高	廉（廃止予定）
採用トレンド	✅ 標準	✅ ゲーム等	△	❌ レガシー

採用ルール：

✅ HTTP/HTTPS のコンテンツルーティング → ALB
✅ 超低レイテンシ・ゲーム・金融 TCP → NLB
✅ セキュリティアプライアンス（IPS/IDS/WAF デバイス） → GWLB
❌ 新規プロジェクトで CLB は非推奨

リスナーとリスナールール

6 つのルーティング条件タイプ

ルーティングタイプ	条件フィールド	例
Path-based	`path-pattern`	`/api/`, `/admin/`, `/static/*`
Host-based	`host-header`	`api.example.com`, `www.example.com`
Header-based	`http-header`	X-Request-Type: mobile, X-API-Version: v2
Method-based	`http-request-method`	`POST`, `GET`, `DELETE`
Query String	`query-string`	`?version=v2`, `?tenant=acme`
Source IP	`source-ip`	`10.0.0.0/8`（内部ネットワーク）

複合ルーティングの例

# 複合条件：/api/* かつ POST で、かつ モバイル デバイスのリクエスト
# → Mobile API Service へ
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 5 \
  --conditions '[
    {
      "Field": "path-pattern",
      "PathPatternConfig": {"Values": ["/api/*"]}
    },
    {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {"Values": ["POST"]}
    },
    {
      "Field": "http-header",
      "HttpHeaderConfig": {
        "HttpHeaderName": "User-Agent",
        "Values": ["*Mobile*", "*Android*"]
      }
    }
  ]' \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:...:targetgroup/mobile-api-tg/..."
  }]'

# トラフィック重み付け分散（Blue/Green デプロイ）
# 90% → Blue (旧バージョン), 10% → Green (新バージョン)
aws elbv2 modify-rule \
  --rule-arn arn:... \
  --actions '[{
    "Type": "forward",
    "ForwardConfig": {
      "TargetGroups": [
        {
          "TargetGroupArn": "arn:...targetgroup/blue-api/...",
          "Weight": 90
        },
        {
          "TargetGroupArn": "arn:...targetgroup/green-api/...",
          "Weight": 10
        }
      ],
      "StickynessConfig": {
        "Enabled": true,
        "DurationSeconds": 3600
      }
    }
  }]'

# リダイレクト：HTTP → HTTPS
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 1 \
  --conditions '[{"Field": "path-pattern", "Values": ["/*"]}]' \
  --actions '[{
    "Type": "redirect",
    "RedirectConfig": {
      "Protocol": "HTTPS",
      "Port": "443",
      "StatusCode": "HTTP_301"
    }
  }]'

# 固定レスポンス（メンテナンスモード）
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 1 \
  --conditions '[{"Field": "path-pattern", "Values": ["/*"]}]' \
  --actions '[{
    "Type": "fixed-response",
    "FixedResponseConfig": {
      "MessageBody": "Service is under maintenance",
      "StatusCode": "503",
      "ContentType": "text/plain"
    }
  }]'

主要ユースケース

初心者向けメモ： ALB は「マイクロサービス」「コンテナ」「サーバーレス」の標準的なゲートウェイです。あなたのシステムが複数のサービス・複数のポート・複数のドメイン・複数の API バージョンを扱っていれば、ALB は必須です。

1. マイクロサービス API ゲートウェイ

複数の独立した API サービスを 1 つの ALB でホスト。パスベースルーティングで振り分け。

client.example.com/user/* → User Service (port 8001)
client.example.com/order/* → Order Service (port 8002)
client.example.com/payment/* → Payment Service (port 8003)

利点： 1 つの HTTPS 証明書・WAF ルール・アクセスログで全サービスを管理。

2. ECS/EKS コンテナオーケストレーション

ECS サービス・EKS Deployment のタスク数が変動する際、ALB が自動的にターゲットを登録・削除。

AWS::ECS::Service → ALB TargetGroup（自動登録）
autoscaling.minSize = 2, maxSize = 10 → ALB が健全なタスクのみ転送

3. Lambda サーバーレス API

Lambda 関数を ALB ターゲットにし、HTTP リクエストから Lambda イベントへの自動変換。

# API GW 不要で Lambda を公開
ALB:443 + TargetGroup(Lambda) → GetUserById, CreateUser など

利点： API Gateway より低レイテンシ・コスト削減。

4. Blue/Green デプロイ

新バージョン（Green）を段階的にロールアウト。CloudFormation + CodeDeploy と統合。

100% → Blue  (旧バージョン)
↓ カナリアテスト
90% Blue + 10% Green
↓ 成功確認
0% Blue + 100% Green（完全切り替え）

5. A/B テスト・カナリアデプロイ

ユーザーセグメント・リクエスト属性でトラフィックを分岐。

User-Agent: Chrome → 新 UI
User-Agent: Firefox → 旧 UI

6. WebSocket リアルタイム通信

チャット・リアルタイム通知・ゲームのコマンド受信。ALB は WebSocket アップグレードをネイティブ対応。

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade

アイドルタイムアウト： デフォルト 60 秒。WebSocket は max 4000 秒に設定可能。

7. gRPC マイクロサービス

Protocol Buffers でのバイナリ通信。ALB は HTTP/2 をサポート。

rpc GetUser (UserId) returns (User) {}

8. HTTP/2 プッシュ

サーバープッシュ・Server-Sent Events（SSE）をサポート。

9. ハイブリッドアプリケーション

オンプレミス + AWS アプリを 1 つの ALB で統合。IP ターゲットグループで両方を登録。

ALB → ECS Task (AWS)
ALB → 10.100.0.10:8080 (On-prem DC)

10. グローバル分散・CloudFront 統合

CloudFront オリジンとしても使用可能。エッジロケーション → ALB → バックエンド。

11. ハイブリッドオンプレミス

Direct Connect / VPN でオンプレミス環境と接続し、IP ターゲットで登録。

12. Cognito 認証ポータル

内部ツール・管理画面に Cognito 認証を付与。ALB レベルで認証フロー実装。

ヘルスチェック

ヘルスチェックが失敗したターゲットへはトラフィックが送信されません。

ヘルスチェック設定

# ヘルスチェック設定の修正
aws elbv2 modify-target-group \
  --target-group-arn arn:... \
  --health-check-protocol HTTP \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --health-check-timeout-seconds 5 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --matcher HttpCode=200-299

# ヘルスチェック結果の確認
aws elbv2 describe-target-health \
  --target-group-arn arn:... \
  --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State,TargetHealth.Reason]' \
  --output table

パラメータ	値	説明
protocol	HTTP, HTTPS, TCP, TLS	ヘルスチェックプロトコル
path	`/health`, `/status`	HTTP(S) チェック対象パス
port	8080, traffic	デフォルトはターゲットと同一ポート
interval_seconds	30（デフォルト）	チェック間隔。5-300 秒
timeout_seconds	5（デフォルト）	タイムアウト時間。2-120 秒
healthy_threshold	2（デフォルト）	健全と判定されるまでのチェック回数
unhealthy_threshold	3（デフォルト）	不健全と判定されるまでのチェック回数
matcher	`200-299`	成功判定の HTTP ステータスコード範囲

ヘルスチェック状態

状態	説明
healthy	✅ チェック成功。トラフィック受信中
unhealthy	❌ チェック失敗。トラフィック受信なし
initial	⏳ 初回チェック待機中（新規登録後）
draining	🚪 Deregistration 中（既存コネクション完了待機）
unused	灰ターゲットグループに属していない

Sticky Session（Cookie ベース）

クライアントを同じターゲットに固定。セッション状態を保持するアプリ向け。

# Sticky Session 有効化（1 日間）
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes \
    Key=stickiness.enabled,Value=true \
    Key=stickiness.type,Value=lb_cookie \
    Key=stickiness.lb_cookie.duration_seconds,Value=86400

# Stickiness クッキー名（カスタマイズ）
# AWSALB（デフォルト）
# 有効期限：24 時間まで

⚠️ 注意： Sticky Session は負荷分散の有効性を低下させます。セッションを分散するか、Redis 等の外部セッションストアの使用を推奨。

SSL/TLS（ACM, SNI, mTLS）

HTTP → HTTPS リダイレクト

# ポート 80 リスナーで HTTP → HTTPS リダイレクト
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol HTTP \
  --port 80 \
  --default-actions '[{
    "Type": "redirect",
    "RedirectConfig": {
      "Protocol": "HTTPS",
      "Port": "443",
      "StatusCode": "HTTP_301"
    }
  }]'

ACM 証明書統合

AWS Certificate Manager が提供する無料の HTTPS 証明書。自動更新・自動デプロイ。

# ACM 証明書リクエスト
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names www.example.com api.example.com \
  --validation-method DNS

# リスナーに証明書をバインド
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:region:account:certificate/id \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions '[{
    "Type": "forward",
    "TargetGroupArn": "arn:..."
  }]'

SNI（Server Name Indication）- 複数ドメイン

1 つのリスナーで複数の HTTPS ドメインをホスト。

# リスナーに証明書を追加（SNI）
aws elbv2 add-listener-certificates \
  --listener-arn arn:... \
  --certificates CertificateArn=arn:aws:acm:region:account:certificate/another-cert-id

# リスナーの証明書確認
aws elbv2 describe-listener-certificates \
  --listener-arn arn:... \
  --query 'Certificates[*].[CertificateArn,IsDefault]' \
  --output table

機能	説明
SNI	✅ Client Hello で送信されたホスト名で証明書を選択。複数ドメインを 1 ポートでホスト
ワイルドカード	✅ `*.example.com` で複数サブドメイン対応
証明書更新	✅ ACM が自動更新（有効期限 60 日前）

mTLS（相互 TLS）- ターゲット暗号化

✨ 2025 年 GA 予定

ALB とバックエンドターゲット間の通信を TLS で暗号化。

# mTLS 有効化
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes \
    Key=deregistration_delay.connection_termination.enabled,Value=true \
    Key=alb.target_group.deregistration_delay.timeout_seconds,Value=300

# TLS クライアント認証の設定（ターゲット側で相互検証）
# AWS Secrets Manager にクライアント証明書を保存
aws secretsmanager create-secret \
  --name /alb/mtls/client-cert \
  --secret-string file://client-cert.pem

ALB と Cognito 認証統合

AWS Cognito で ALB レベルの認証・認可を実装。バックエンドアプリには認証ロジック不要。

Cognito ユーザープール作成

# Cognito ユーザープール作成
aws cognito-idp create-user-pool \
  --pool-name my-app-users \
  --policies 'PasswordPolicy={MinimumLength=8,RequireUppercase=false,RequireLowercase=false,RequireNumbers=false,RequireSymbols=false}'

# アプリクライアント作成
aws cognito-idp create-user-pool-client \
  --user-pool-id ap-northeast-1_xxxxx \
  --client-name my-app-client \
  --explicit-auth-flows ADMIN_NO_SRP_AUTH \
  --allowed-oauth-flows code implicit \
  --allowed-oauth-scopes email openid profile

ALB リスナールールに Cognito 認証を追加

# /protected/* パスに Cognito 認証を追加
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 1 \
  --conditions '[{"Field": "path-pattern", "Values": ["/protected/*"]}]' \
  --actions '[
    {
      "Type": "authenticate-cognito",
      "Order": 1,
      "AuthenticateCognitoConfig": {
        "UserPoolArn": "arn:aws:cognito-idp:ap-northeast-1:account:userpool/ap-northeast-1_xxxxx",
        "UserPoolClientId": "client-id",
        "UserPoolDomain": "my-domain.auth.ap-northeast-1.amazoncognito.com",
        "OnUnauthenticatedRequest": "authenticate"
      }
    },
    {
      "Type": "forward",
      "Order": 2,
      "TargetGroupArn": "arn:..."
    }
  ]'

# ヘッダー挿入：認証後、X-Amzn-Cognito-* ヘッダーがバックエンドに渡される
# バックエンド側で以下を参照：
# - X-Amzn-Cognito-Authentication-Provider: Cognito IdP ARN
# - X-Amzn-Cognito-Authentication-Time: ユーザー認証時刻
# - X-Amzn-Cognito-Identity-Id: Cognito Identity ID
# - X-Amzn-Cognito-Identity-Pool-Id: Cognito Identity Pool ID

ALB と OIDC 認証統合

AWS Cognito 以外の OpenID Connect IdP（Okta, Auth0, Google, GitHub など）と統合。

# OIDC 認証ルール
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 2 \
  --conditions '[{"Field": "path-pattern", "Values": ["/secure/*"]}]' \
  --actions '[
    {
      "Type": "authenticate-oidc",
      "Order": 1,
      "AuthenticateOidcConfig": {
        "Issuer": "https://auth0.example.com",
        "AuthorizationEndpoint": "https://auth0.example.com/authorize",
        "TokenEndpoint": "https://auth0.example.com/oauth/token",
        "UserInfoEndpoint": "https://auth0.example.com/userinfo",
        "ClientId": "your-client-id",
        "ClientSecret": "your-client-secret",
        "OnUnauthenticatedRequest": "authenticate"
      }
    },
    {
      "Type": "forward",
      "Order": 2,
      "TargetGroupArn": "arn:..."
    }
  ]'

IdP	Issuer URL	備考
Okta	`https://org.okta.com`	OIDC 標準準拠
Auth0	`https://org.auth0.com`	Web App フロー推奨
Google	`https://accounts.google.com`	Consent Screen 設定必須
GitHub	`https://github.com/login/oauth`	OAuth 2.0（OIDC 非準拠）
AWS Cognito	`https://cognito-idp.region.amazonaws.com/user-pool-id`	フルマネージド

ALB と WAF / Shield 連携

AWS WAF で ALB 層の攻撃を検知・ブロック。

WAF Web ACL 作成

# IP セット作成（ブロック IP）
aws wafv2 create-ip-set \
  --region ap-northeast-1 \
  --scope REGIONAL \
  --name blocked-ips \
  --address-definition-format IPV4 \
  --addresses '["203.0.113.0/24"]'

# Web ACL 作成（SQL インジェクション、XSS 対策）
aws wafv2 create-web-acl \
  --region ap-northeast-1 \
  --scope REGIONAL \
  --name my-app-waf \
  --default-action Block={} \
  --rules '[
    {
      "Name": "AWSManagedRulesSQLiRuleSet",
      "Priority": 1,
      "OverrideAction": {"None": {}},
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesSQLiRuleSet"
        }
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "SQLiProtection"
      }
    },
    {
      "Name": "AWSManagedRulesKnownBadInputsRuleSet",
      "Priority": 2,
      "OverrideAction": {"None": {}},
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesKnownBadInputsRuleSet"
        }
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "BadInputProtection"
      }
    },
    {
      "Name": "RateLimitRule",
      "Priority": 3,
      "Action": {"Block": {}},
      "Statement": {
        "RateBasedStatement": {
          "Limit": 2000,
          "AggregateKeyType": "IP"
        }
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "RateLimitProtection"
      }
    }
  ]' \
  --visibility-config 'SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=my-app-waf'

# ALB に WAF を関連付け
aws wafv2 associate-web-acl \
  --region ap-northeast-1 \
  --web-acl-arn arn:aws:wafv2:ap-northeast-1:account:regional/webacl/my-app-waf/id \
  --resource-arn arn:aws:elasticloadbalancing:ap-northeast-1:account:loadbalancer/app/my-alb/...

AWS Shield 統合

# Shield Standard：自動適用（無料）
# DDoS 基本対策 + CloudWatch メトリクス

# Shield Advanced（有料）：購読
aws shield subscribe-to-drt \
  --region ap-northeast-1

機能	Shield Standard	Shield Advanced
DDoS 基本対策	✅	✅
WAF 統合	❌	✅
DDoS 専門チーム（DRT）	❌	✅ 24/7
DDoS 費用補償	❌	✅
コスト	無料	$3000/月

アクセスログ

ALB がすべてのリクエストを S3 に出力。分析・監視に活用。

# S3 バケット作成
aws s3 mb s3://alb-logs-bucket

# ALB 用 S3 バケット ポリシー設定
# ALB のサービスアカウント（アカウント ID を地域別に確認）
# https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

cat > bucket-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::582318560864:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::alb-logs-bucket/*"
    }
  ]
}
EOF

aws s3api put-bucket-policy \
  --bucket alb-logs-bucket \
  --policy file://bucket-policy.json

# ALB にアクセスログを有効化
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes \
    Key=access_logs.s3.enabled,Value=true \
    Key=access_logs.s3.bucket,Value=alb-logs-bucket \
    Key=access_logs.s3.prefix,Value=my-app-logs

# ログフォーマット例
# http 2.0 2024-01-01T12:00:00.000000Z my-alb-1234567890abcdef0 192.0.2.1:51670 10.0.0.100:8080 0.001 0.001 0.001 200 200 200 1000 "GET http://example.com/api/users HTTP/2.0" "curl/7.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:acm:... "-" "-" "-" "-" "-" "-" "-" "-" "-" "-" "-" "-" "-" "root_id=1234567890abcdef0" "-" "-"

ログフィールド

フィールド	説明
http	プロトコルバージョン（HTTP/1.1, HTTP/2）
timestamp	リクエスト時刻
elb	ALB 名
client:port	クライアント IP とポート
target:port	ターゲット IP とポート（または “-”）
request_processing_time	ALB で処理された時間（秒）
target_processing_time	ターゲットで処理された時間（秒）
response_processing_time	ALB でレスポンス処理された時間（秒）
elb_status_code	ALB が返した HTTP ステータスコード
target_status_code	ターゲットが返した HTTP ステータスコード
received_bytes	クライアント → ALB で受け取ったバイト数
sent_bytes	ALB → クライアントに送信したバイト数
request	リクエスト行（メソッド, URI, プロトコル）
user_agent	User-Agent ヘッダー
ssl_cipher	SSL/TLS 暗号スイート
ssl_protocol	SSL/TLS プロトコルバージョン
ssl_certificate_arn	ACM 証明書 ARN

CloudWatch Metrics と監視

ALB の主要メトリクスを CloudWatch で監視。

# CloudWatch ダッシュボード作成（ALB メトリクス）
aws cloudwatch put-metric-alarm \
  --alarm-name alb-high-latency \
  --alarm-description "Alert when ALB latency exceeds 1 second" \
  --metric-name TargetResponseTime \
  --namespace AWS/ApplicationELB \
  --statistic Average \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:account:my-topic

# 5xx エラー監視
aws cloudwatch put-metric-alarm \
  --alarm-name alb-5xx-errors \
  --alarm-description "Alert on ALB 5xx errors" \
  --metric-name HTTPCode_Target_5XX_Count \
  --namespace AWS/ApplicationELB \
  --statistic Sum \
  --period 60 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold

メトリクス	説明	単位
RequestCount	リクエスト総数	カウント
TargetResponseTime	ターゲット応答時間（中央値）	秒
HTTPCode_Target_2XX_Count	ターゲット 2xx カウント	カウント
HTTPCode_Target_4XX_Count	ターゲット 4xx カウント	カウント
HTTPCode_Target_5XX_Count	ターゲット 5xx カウント	カウント
HTTPCode_ELB_5XX_Count	ALB 5xx エラーカウント	カウント
TargetConnectionCount	アクティブコネクション数	カウント
ProcessedBytes	ALB が処理したバイト数	バイト
NewConnectionCount	新規コネクション数（秒）	カウント
RejectedConnectionCount	接続拒否数	カウント
UnHealthyHostCount	不健全なターゲット数	カウント
HealthyHostCount	健全なターゲット数	カウント

CloudWatch Logs/X-Ray 統合

CloudWatch Logs 統合

# CloudWatch Logs グループ作成
aws logs create-log-group --log-group-name /aws/alb/my-app

# ALB から CloudWatch Logs へ出力（アクセスログの詳細化）
# → アクセスログ + CloudWatch Insights で高度な分析

X-Ray 統合

# X-Ray トレーシング有効化
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes Key=access_logs.s3.enabled,Value=false

# ALB が Request ID を自動埋め込み
# X-Amzn-Trace-Id: Root=1-xxx;Parent=yyy;Sampled=1

# バックエンド側で AWS X-Ray SDK を使用
import aws_xray_sdk.core as xray_sdk
xray_sdk.configure(context_missing='LOG_ERROR')

Cross-Zone Load Balancing

複数 AZ 間でのアクティブな負荷分散。

# Cross-Zone LB 有効化
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

# 料金に注意：有効化すると AZ 間のデータ転送料金が発生

有効化	コスト	利点
disabled	低	AZ 内のみ負荷分散
enabled	中（AZ 間転送料）	複数 AZ で均等分散

ALB と CloudFront 連携

CloudFront オリジンとして ALB を使用。エッジロケーション → ALB → バックエンド。

# CloudFront ディストリビューション作成（オリジン = ALB）
aws cloudfront create-distribution \
  --distribution-config '{
    "CallerReference": "my-alb-origin",
    "Origins": {
      "Quantity": 1,
      "Items": [{
        "Id": "my-alb",
        "DomainName": "my-alb-1234567890abcdef0.ap-northeast-1.elb.amazonaws.com",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        }
      }]
    },
    "DefaultCacheBehavior": {
      "TargetOriginId": "my-alb",
      "ViewerProtocolPolicy": "redirect-to-https",
      "ForwardedValues": {
        "QueryString": true,
        "Cookies": {"Forward": "all"}
      },
      "TrustedSigners": {
        "Enabled": false,
        "Quantity": 0
      }
    },
    "Enabled": true
  }'

利点：

✅ グローバル CDN キャッシング
✅ DDoS 保護（Shield Advanced）
✅ WAF 統合（CloudFront WAF）
✅ レイテンシ削減

Internal vs Internet-facing

タイプ	アクセス	用途
Internet-facing	Public Internet から接続可能	クライアント向け API / Web サイト
Internal	VPC 内部のみ	マイクロサービス間通信 / 内部ツール

# Internet-facing ALB
aws elbv2 create-load-balancer \
  --name my-public-alb \
  --subnets subnet-1 subnet-2 \
  --security-groups sg-1 \
  --scheme internet-facing \
  --type application

# Internal ALB（VPC 内部専用）
aws elbv2 create-load-balancer \
  --name my-internal-alb \
  --subnets subnet-1 subnet-2 \
  --security-groups sg-1 \
  --scheme internal \
  --type application

VPC Lattice との関係

✨ AWS VPC Lattice：新世代のマイクロサービスロードバランシング（プレビュー）。ALB を補完する位置付け。

観点	ALB	VPC Lattice
対象	HTTP/HTTPS リクエスト	マイクロサービス（任意プロトコル）
管理単位	ロードバランサー	Service Network（複数サービス）
セキュリティ	セキュリティグループ	IAM ベース（mTLS 必須）
マルチアカウント	VPC ピアリング必要	✅ クロスアカウント対応
サービスディスカバリー	手動登録	✅ 自動検出（Service RegistryAPI）
トレーシング	X-Ray	✅ 完全統合
成熟度	GA（本番運用向け）	Preview（評価段階）

推奨： 現在は ALB が主流。VPC Lattice は複雑なマイクロサービスメッシュに向く（将来）。

他の類似ツールとの比較

ツール	レイヤー	特徴	用途
ALB	L7	AWS ネイティブ・ECS/EKS 統合・WAF/Cognito	AWS マイクロサービス
NGINX	L7	オープンソース・軽量・高速	オンプレミス・Kubernetes
HAProxy	L7	高機能・ハイパフォーマンス	オンプレミス・エンタープライズ
Envoy	L7	メッシュ統合・リアルタイム	Istio サイドカー
Cloudflare LB	L7	グローバル CDN・DDoS	クラウドネイティブ企業
GCP Cloud LB	L4/L7	GCP ネイティブ	Google Cloud
Azure LB	L4/L7	Azure ネイティブ	Microsoft Azure
Istio	L7	Service Mesh・トラフィックポリシー	Kubernetes（高度なルーティング）

クライアントとエコシステム

AWS CLI / SDK

# AWS CLI で ALB 操作
aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[*].[LoadBalancerName,LoadBalancerArn,State.Code]' \
  --output table

# Python boto3
import boto3
client = boto3.client('elbv2', region_name='ap-northeast-1')
response = client.describe_load_balancers()

Terraform

# Terraform で ALB 定義
resource "aws_lb" "main" {
  name               = "my-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = aws_subnet.public[*].id
}

resource "aws_lb_target_group" "app" {
  name     = "app-tg"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    healthy_threshold   = 2
    unhealthy_threshold = 3
    timeout             = 5
    interval            = 30
    path                = "/health"
    matcher             = "200-299"
  }
}

resource "aws_lb_listener" "main" {
  load_balancer_arn = aws_lb.main.arn
  port              = 443
  protocol          = "HTTPS"
  certificate_arn   = aws_acm_certificate.main.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

resource "aws_lb_listener_rule" "api" {
  listener_arn = aws_lb_listener.main.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api.arn
  }

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

AWS CDK（TypeScript/Python）

// AWS CDK で ALB 定義
import * as elbv2 from 'aws-elasticloadbalancingv2';

const lb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
  vpc: vpc,
  internetFacing: true,
});

const tg = lb.addTargets('AppTargets', {
  port: 8080,
  targets: [ec2Instance],
  healthCheck: {
    path: '/health',
    interval: Duration.seconds(30),
  },
});

lb.addListener('HttpsListener', {
  port: 443,
  protocol: elbv2.ApplicationProtocol.HTTPS,
  certificates: [certificate],
  defaultTargetGroups: [tg],
});

AWS Load Balancer Controller for Kubernetes

EKS で Kubernetes Ingress を使用すると、自動的に ALB が作成・管理される。

# EKS Ingress リソース
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.aws/scheme: internet-facing
    alb.ingress.aws/target-type: ip
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
    - host: www.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

ベストプラクティス

1. セキュリティ

✅ HTTPS の強制

# HTTP → HTTPS リダイレクト
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol HTTP \
  --port 80 \
  --default-actions '[{
    "Type": "redirect",
    "RedirectConfig": {
      "Protocol": "HTTPS",
      "Port": "443",
      "StatusCode": "HTTP_301"
    }
  }]'

✅ WAF 統合

aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:region:account:regional/webacl/name/id \
  --resource-arn arn:aws:elasticloadbalancing:region:account:loadbalancer/app/name/...

✅ セキュリティグループ制限

# ALB セキュリティグループ：HTTP/HTTPS のみ許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxx \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-xxx \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# ターゲット セキュリティグループ：ALB からのみ許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-yyy \
  --protocol tcp \
  --port 8080 \
  --source-group sg-xxx

2. 高可用性

✅ 複数 AZ 配置

aws elbv2 create-load-balancer \
  --subnets subnet-1a subnet-1c \
  --scheme internet-facing

✅ Cross-Zone LB 有効化

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

3. パフォーマンス

✅ 接続ドレイン設定

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes Key=deregistration_delay.timeout_seconds,Value=300

✅ アイドルタイムアウト調整（WebSocket）

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes Key=idle_timeout.timeout_seconds,Value=4000

4. コスト最適化

❌ アンチパターン： Sticky Session を無理に使用（負荷分散が偏る）

✅ 推奨： 外部セッションストア（Redis/DynamoDB）を使用

❌ アンチパターン： Cross-Zone LB をデフォルト有効化（データ転送料金増加）

✅ 推奨： トラフィックパターンを分析した上で有効化判断

❌ アンチパターン： ALB でサーバーレスアプリをスケーリング

✅ 推奨： ECS Fargate + Auto Scaling Group で自動スケーリング

5. 監視・ロギング

✅ アクセスログを S3 に出力

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:... \
  --attributes \
    Key=access_logs.s3.enabled,Value=true \
    Key=access_logs.s3.bucket,Value=my-bucket

✅ CloudWatch アラーム設定

aws cloudwatch put-metric-alarm \
  --alarm-name high-response-time \
  --metric-name TargetResponseTime \
  --namespace AWS/ApplicationELB \
  --threshold 1.0 \
  --comparison-operator GreaterThanThreshold

✅ X-Ray トレーシング有効化

トラブルシューティング

1. ターゲットが Unhealthy

症状： ALB がすべてのターゲットを unhealthy と判定

原因チェック：

# ターゲットのヘルスチェック結果確認
aws elbv2 describe-target-health \
  --target-group-arn arn:... \
  --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State,TargetHealth.Reason]'

# → Reason が "Health checks failed with these codes: [503]" の場合
#   ターゲット側で /health エンドポイントが 5xx を返している

対策：

# ヘルスチェック間隔を長くする（ウォームアップ時間）
aws elbv2 modify-target-group \
  --target-group-arn arn:... \
  --health-check-interval-seconds 10 \
  --healthy-threshold-count 3

# ターゲット側でヘルスチェック エンドポイントを実装
# 例：Node.js
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok' });
});

2. 502 Bad Gateway エラー

症状： クライアントが 502 エラーを受け取る

原因チェック：

# ALB が ターゲットに接続できていない
# 原因：セキュリティグループ・ネットワーク ACL の設定ミス

# セキュリティグループ確認
aws ec2 describe-security-groups \
  --group-ids sg-xxx \
  --query 'SecurityGroups[0].IpPermissions[*].[FromPort,ToPort,IpProtocol]'

対策：

# ターゲット セキュリティグループに ALB からのアクセス許可追加
aws ec2 authorize-security-group-ingress \
  --group-id sg-target \
  --protocol tcp \
  --port 8080 \
  --source-group sg-alb

3. Sticky Session が機能しない

症状： 同じクライアントが異なるターゲットに振り分けられる

原因：

# Sticky Session が有効化されていない or 設定期間が短すぎる
aws elbv2 describe-target-group-attributes \
  --target-group-arn arn:... \
  --query 'Attributes[?Key==`stickiness.enabled`]'

対策：

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes \
    Key=stickiness.enabled,Value=true \
    Key=stickiness.type,Value=lb_cookie \
    Key=stickiness.lb_cookie.duration_seconds,Value=86400

4. ターゲットのコネクション数が急増

症状： ターゲットの NewConnectionCount が異常に多い

原因： Connection Draining タイムアウト切れ・ターゲット側で接続をクローズしていない

対策：

# Connection Draining タイムアウト延長
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:... \
  --attributes Key=deregistration_delay.timeout_seconds,Value=600

# Keep-Alive を有効化（HTTP 1.1）
# ターゲット側で Connection: Keep-Alive をサポート

2025-2026 最新動向

HTTP/3 対応（Upcoming）

✨ 予定： 2025 年 Q4

QUIC プロトコルによる超低レイテンシ化。

# HTTP/3 が GA になれば
aws elbv2 create-listener \
  --load-balancer-arn arn:... \
  --protocol HTTP3 \
  --port 443

Anycast Static IPs

✨ 2025 年リリース予定

複数 AZ 間で同一 Elastic IP を共有。BGP ルーティングで最寄り AZ への自動ルーティング。

# Anycast を使用した ALB 作成
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-1a subnet-1c \
  --address-type ipv4 \
  --anycast-static-ip enabled

mTLS GA

✨ 2025 年 GA 予定

ALB ↔ ターゲット間の相互 TLS 認証。セキュアなバックエンド通信。

Lambda ターゲットグループ強化

✨ 2025 年強化予定

Lambda@Edge・ストリーミングレスポンス対応。大規模 AI モデルレスポンスの効率化。

IPv6 完全対応

✨ 2025 年完全移行

デュアルスタック対応の簡素化。IPv6 専用環境をネイティブサポート。

ALB Insights

✨ 2025 年新機能

CloudWatch Logs ベースの自動トラブルシューティング。502 エラー・遅延・不健全ターゲットを自動診断。

学習リソース

AWS 公式ドキュメント（2026 年版）

AWS トレーニング

AWS Skill Builder： Application Load Balancer セッション
AWS Well-Architected： Reliability ピラー（高可用性設計）

コミュニティリソース

AWS フォーラム - Application Load Balancing カテゴリ
Stack Overflow aws-alb タグ

実装例・活用シーン

シーン 1：マイクロサービス API ゲートウェイ

# 3 つのマイクロサービス（user, order, payment）を 1 ALB でホスト

# ALB 作成
ALB_ARN=$(aws elbv2 create-load-balancer \
  --name api-gateway-alb \
  --subnets subnet-1a subnet-1c \
  --query 'LoadBalancers[0].LoadBalancerArn' \
  --output text)

# ターゲットグループ作成
USER_TG=$(aws elbv2 create-target-group \
  --name user-service-tg \
  --port 8001 \
  --protocol HTTP \
  --vpc-id vpc-xxx \
  --query 'TargetGroups[0].TargetGroupArn' \
  --output text)

ORDER_TG=$(aws elbv2 create-target-group \
  --name order-service-tg \
  --port 8002 \
  --protocol HTTP \
  --vpc-id vpc-xxx \
  --query 'TargetGroups[0].TargetGroupArn' \
  --output text)

# リスナー作成（HTTPS）
LISTENER=$(aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:... \
  --default-actions "[{\"Type\":\"fixed-response\",\"FixedResponseConfig\":{\"MessageBody\":\"Not Found\",\"StatusCode\":\"404\",\"ContentType\":\"text/plain\"}}]" \
  --query 'Listeners[0].ListenerArn' \
  --output text)

# ルール追加：/user/* → User Service
aws elbv2 create-rule \
  --listener-arn $LISTENER \
  --priority 10 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/user/*"]}}]' \
  --actions "[{\"Type\":\"forward\",\"TargetGroupArn\":\"$USER_TG\"}]"

# ルール追加：/order/* → Order Service
aws elbv2 create-rule \
  --listener-arn $LISTENER \
  --priority 20 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/order/*"]}}]' \
  --actions "[{\"Type\":\"forward\",\"TargetGroupArn\":\"$ORDER_TG\"}]"

# ターゲット登録
aws elbv2 register-targets \
  --target-group-arn $USER_TG \
  --targets Id=10.0.1.10:8001 Id=10.0.2.10:8001

aws elbv2 register-targets \
  --target-group-arn $ORDER_TG \
  --targets Id=10.0.1.20:8002 Id=10.0.2.20:8002

シーン 2：ECS + Blue/Green デプロイ

# Blue（旧）バージョン：100%
# Green（新）バージョン：0%
# → Green を 10% → 50% → 100% と段階的に増加

aws elbv2 modify-rule \
  --rule-arn arn:... \
  --actions '[{
    "Type":"forward",
    "ForwardConfig":{
      "TargetGroups":[
        {"TargetGroupArn":"arn:...blue-tg","Weight":100},
        {"TargetGroupArn":"arn:...green-tg","Weight":0}
      ]
    }
  }]'

# 10% に切り替え（カナリアテスト）
aws elbv2 modify-rule \
  --rule-arn arn:... \
  --actions '[{
    "Type":"forward",
    "ForwardConfig":{
      "TargetGroups":[
        {"TargetGroupArn":"arn:...blue-tg","Weight":90},
        {"TargetGroupArn":"arn:...green-tg","Weight":10}
      ]
    }
  }]'

# CloudWatch メトリクス監視
# Green TG の エラー率が低い場合 → 100% に切り替え
# エラー率が高い場合 → Blue に即座にロールバック

aws elbv2 modify-rule \
  --rule-arn arn:... \
  --actions '[{
    "Type":"forward",
    "ForwardConfig":{
      "TargetGroups":[
        {"TargetGroupArn":"arn:...blue-tg","Weight":0},
        {"TargetGroupArn":"arn:...green-tg","Weight":100}
      ]
    }
  }]'

シーン 3：Cognito + 内部管理画面

# 管理画面を Cognito で保護

aws cognito-idp create-user-pool \
  --pool-name admin-portal-users

# ALB で認証ルール追加
aws elbv2 create-rule \
  --listener-arn arn:... \
  --priority 1 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/admin/*"]}}]' \
  --actions '[
    {
      "Type":"authenticate-cognito",
      "Order":1,
      "AuthenticateCognitoConfig":{
        "UserPoolArn":"arn:aws:cognito-idp:...",
        "UserPoolClientId":"xxx",
        "UserPoolDomain":"admin-portal.auth.ap-northeast-1.amazoncognito.com"
      }
    },
    {
      "Type":"forward",
      "Order":2,
      "TargetGroupArn":"arn:..."
    }
  ]'

導入ロードマップ

フェーズ 1：計画（1 週間）

[ ] ルーティング要件を整理（パスベース・ホストベース・その他）
[ ] ターゲットのポート・プロトコルを確認
[ ] セキュリティ・ACM 証明書を手配
[ ] VPC・サブネット・セキュリティグループを確認

フェーズ 2：デプロイ（2-3 週間）

[ ] ALB 作成（Internet-facing / Internal を選択）
[ ] ターゲットグループ作成
[ ] リスナー・ルール設定
[ ] ヘルスチェック設定・動作確認
[ ] ターゲット登録

フェーズ 3：セキュリティ（1 週間）

[ ] HTTPS リスナー設定（ACM 証明書）
[ ] HTTP → HTTPS リダイレクト
[ ] WAF ルール設定（SQLi, XSS, レート制限）
[ ] セキュリティグループ制限

フェーズ 4：運用・監視（継続）

[ ] CloudWatch アラーム設定
[ ] アクセスログを S3 に出力
[ ] X-Ray トレーシング有効化
[ ] CloudWatch Insights で定期的に分析

実装チェックリスト

デプロイ前チェック

[ ] ALB 名・DNS 名を記録
[ ] ターゲットグループの health check パスが正しいか
[ ] セキュリティグループで ALB ↔ ターゲット間の通信が許可されているか
[ ] ACM 証明書が自動更新されるよう設定されているか
[ ] リスナールールの優先度が正しく設定されているか

セキュリティチェック

[ ] HTTP を HTTPS にリダイレクトしているか
[ ] AWS WAF が有効化されているか
[ ] セキュリティグループが最小権限の原則に従っているか
[ ] X-Forwarded-For ヘッダーを信頼しすぎていないか

運用チェック

[ ] アクセスログが S3 に出力されているか
[ ] CloudWatch アラームが設定されているか（高レイテンシ・5xx エラー）
[ ] ターゲットのヘルスチェック状態を定期確認しているか
[ ] Sticky Session が必要な場合、外部セッションストアも配置されているか

まとめ

Application Load Balancer（ALB） は AWS の L7 ロードバランサー として、HTTP/HTTPS トラフィックの高度なコンテンツベースルーティングを実現します。URL パス・ホスト・ヘッダー・クエリ文字列・HTTP メソッド・送信元 IP に基づくルーティングで、複数のマイクロサービス・ECS/EKS コンテナ・Lambda サーバーレス機能を 1 つのエントリーポイントに集約できます。

主な活用シーン

✅ マイクロサービス API ゲートウェイ - パスベースで複数サービスを統合 ✅ ECS/EKS コンテナオーケストレーション - 自動ターゲット登録・削除 ✅ Lambda サーバーレス API - API Gateway より低コスト・低レイテンシ ✅ Blue/Green デプロイ - 段階的なトラフィック切り替え ✅ WebSocket / gRPC - リアルタイム通信をネイティブサポート ✅ 内部マイクロサービスメッシュ - Internal ALB で VPC 内部統合

キーポイント

NLB との使い分け：HTTP/HTTPS ルーティングが必要なら ALB。超低レイテンシ・固定 IP が必要なら NLB
セキュリティ統合：ACM（無料証明書）+ WAF（L7 フィルタリング）+ Cognito/OIDC（認証）で完全なセキュリティスタック
ECS/EKS 統合：AWS Load Balancer Controller で Kubernetes Ingress から自動生成
マルチテナント対応：Listener Rule で複数ドメイン・複数テナントを管理
コスト最適化：LCU（ロードバランサーキャパシティユニット）ベースの料金体系。新しい ALB が自動スケーリングで不要な場合は削除

推奨： 2025 年以降、HTTP/3・Anycast Static IPs・mTLS GA が提供予定。新機能が安定後の採用検討も視野に。

目次

AWS Application Load Balancer (ALB) 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の ALB エコシステム

目次

概要

ALB の位置づけ

ALB が解決する課題

主な特徴

アーキテクチャ

コアコンポーネント

1. リスナー（Listener）

2. リスナールール（Listener Rule）

ルール評価順序と優先度

ターゲットグループ

ターゲットタイプ

属性管理

ALB vs NLB vs GWLB vs CLB

リスナーとリスナールール

6 つのルーティング条件タイプ

複合ルーティングの例

主要ユースケース

1. マイクロサービス API ゲートウェイ

2. ECS/EKS コンテナオーケストレーション

3. Lambda サーバーレス API

4. Blue/Green デプロイ

5. A/B テスト・カナリアデプロイ

6. WebSocket リアルタイム通信

7. gRPC マイクロサービス

8. HTTP/2 プッシュ

9. ハイブリッドアプリケーション

10. グローバル分散・CloudFront 統合

11. ハイブリッドオンプレミス

12. Cognito 認証ポータル

ヘルスチェック

ヘルスチェック設定

ヘルスチェック状態

Sticky Session（Cookie ベース）

SSL/TLS（ACM, SNI, mTLS）

HTTP → HTTPS リダイレクト

ACM 証明書統合

SNI（Server Name Indication）- 複数ドメイン

mTLS（相互 TLS）- ターゲット暗号化

ALB と Cognito 認証統合

Cognito ユーザープール作成

ALB リスナールールに Cognito 認証を追加

ALB と OIDC 認証統合

ALB と WAF / Shield 連携

WAF Web ACL 作成

AWS Shield 統合

アクセスログ

ログフィールド

CloudWatch Metrics と監視

CloudWatch Logs/X-Ray 統合

CloudWatch Logs 統合

X-Ray 統合

Cross-Zone Load Balancing

ALB と CloudFront 連携

Internal vs Internet-facing

VPC Lattice との関係

他の類似ツールとの比較

クライアントとエコシステム

AWS CLI / SDK

Terraform

AWS CDK（TypeScript/Python）

AWS Load Balancer Controller for Kubernetes

ベストプラクティス

1. セキュリティ

2. 高可用性

3. パフォーマンス

4. コスト最適化

5. 監視・ロギング

トラブルシューティング

1. ターゲットが Unhealthy

2. 502 Bad Gateway エラー

3. Sticky Session が機能しない

4. ターゲットのコネクション数が急増

2025-2026 最新動向

HTTP/3 対応（Upcoming）