AWS Application Load Balancer (ALB) ベストプラクティス

AWS Well-Architected Framework の観点（信頼性・セキュリティ・パフォーマンス・コスト・運用）に沿って、ALB を設計・運用する際の主なポイントをまとめる。

目次

1. 設計・アーキテクチャ

ALB を選ぶべきケース

要件推奨
HTTP/HTTPS、パス・ホストベースのルーティングALB
TCP/UDP、超低レイテンシ、固定IP、TLSパススルーNLB
サードパーティのアプライアンス（FW/IDS）挿入GWLB
gRPC、WebSocket、HTTP/2ALB（対応済み）
  • 固定 IP が必要な場合は NLB → ALB（ALB タイプのターゲットグループ）構成や AWS Global Accelerator を検討する。

マルチ AZ 構成

  • 最低 2 つ以上（推奨 3 つ）の AZ にサブネットを割り当てる。
  • 各 AZ にターゲットを均等に配置する（AZ 障害時の容量を確保）。
  • ALB 用サブネットは /27 以上（空き IP 8 個以上）を確保する。ALB はスケール時に IP を追加消費するため、余裕を持たせる。
  • クロスゾーン負荷分散は ALB ではデフォルト有効。ターゲット数が AZ 間で偏る場合は有効のままにする。

内部 / インターネット向けの分離

  • 外部公開用（internet-facing）と内部用（internal）の ALB を分ける。
  • internet-facing ALB はパブリックサブネット、ターゲットはプライベートサブネットに配置する。

2. セキュリティ

通信の暗号化

  • HTTPS リスナーを基本とし、HTTP(80) は HTTPS(443) へリダイレクトするルールを設定する。
  • 証明書は AWS Certificate Manager (ACM) で発行・自動更新する。
  • セキュリティポリシーは最新の TLS 1.2 / 1.3 対応ポリシーを選択する（例: ELBSecurityPolicy-TLS13-1-2-2021-06 系）。古い TLS 1.0/1.1 を許可するポリシーは避ける。
  • コンプライアンス要件がある場合は FIPS 対応ポリシーやポスト量子暗号対応ポリシーを検討する。
  • ALB → ターゲット間も機密性が求められる場合は HTTPS でバックエンド通信を行う。
  • クライアント証明書認証が必要な場合は mTLS（相互 TLS） 機能とトラストストアを利用する。

セキュリティグループ

  • ALB の SG：必要なポート（443/80）のみ、必要な送信元からのみ許可する。
  • ターゲットの SG：送信元を ALB の SG ID に限定する（CIDR ではなく SG 参照）。
  • CloudFront 経由のみ許可したい場合は、CloudFront のマネージドプレフィックスリストを ALB の SG に設定し、さらにカスタムヘッダーで検証する。

AWS WAF / Shield

  • internet-facing ALB には AWS WAF を関連付ける。
    • AWS マネージドルール（Core rule set、Known bad inputs、SQLi、IP reputation など）から始める。
    • レートベースルールで過剰なリクエストを制限する。
    • 新規ルールはまず Count モードで影響を確認してから Block に切り替える。
  • DDoS 対策が重要なシステムでは AWS Shield Advanced を検討する。

その他の設定

  • 削除保護（Deletion protection）を有効化する。
  • 無効なヘッダーフィールドの削除（routing.http.drop_invalid_header_fields.enabled）を有効化する。
  • Desync 緩和モードは defensive（デフォルト）または strictest に設定し、HTTP リクエストスマグリング対策を行う。
  • X-Forwarded-For の扱い（append / preserve / remove）をアプリケーションの要件に合わせて明示的に設定する。
  • 認証が必要なアプリは ALB の認証機能（Amazon Cognito / OIDC） の利用を検討し、アプリ側の実装負荷を下げる。

3. 信頼性

ヘルスチェック

  • 専用のヘルスチェックエンドポイント（例: /health）を用意する。
    • 軽量で高速に応答すること。
    • 依存先（DB 等）の障害でターゲット全体が異常判定されないよう、浅いチェック（liveness）と深いチェック（readiness）を使い分ける。依存先障害で全ターゲットが落ちると ALB は全ターゲットにフェイルオープンするため、意図した挙動か確認しておく。
  • 主なパラメータの目安：
パラメータ目安
間隔（Interval）10〜30 秒
タイムアウト間隔より短く（例: 5 秒）
正常しきい値2〜3
異常しきい値2〜3
成功コード200（必要に応じて 200-399）
  • ターゲットグループの ヘルス要件設定（DNS フェイルオーバー / ルーティングフェイルオーバーの最小正常ターゲット数） を設定し、AZ 単位の劣化時に適切に切り離す。

登録解除の遅延（Deregistration delay）

  • デフォルトは 300 秒。アプリのリクエスト処理時間に合わせて短縮（例: 30〜60 秒）するとデプロイが速くなる。
  • 長時間接続（WebSocket、ファイルアップロード等）がある場合は十分な値を確保する。

スロースタート

  • JIT コンパイルやキャッシュウォームアップが必要なアプリでは スロースタートモード（30〜900 秒）を設定し、新規ターゲットへの急激な負荷を避ける。

タイムアウトの整合性

  • ALB のアイドルタイムアウト（デフォルト 60 秒） < バックエンドの Keep-Alive タイムアウトとなるよう設定する。逆になると 502 エラーの原因になる。
    • 例: ALB 60 秒、Nginx/アプリ側 keepalive_timeout 65〜75 秒。
  • 長時間処理が必要な API は、アイドルタイムアウトを延ばすより非同期処理化を検討する。

自動復旧・ゾーンシフト

  • Auto Scaling グループでは ELB ヘルスチェックを有効化し、異常インスタンスを自動置換する。
  • AZ 障害に備え Amazon Application Recovery Controller のゾーンシフト / ゾーンオートシフトを有効化しておく。

急激なトラフィック増加

  • ALB は自動スケールするが、急激なスパイク（セール・イベント等）が予測される場合は LCU 予約（キャパシティ予約） や事前のスケール要請を検討する。

4. パフォーマンス

ルーティング

  • ホストベース・パスベース・ヘッダー・クエリ文字列・送信元 IP などリスナールールを活用し、1 つの ALB で複数サービスを集約する（ALB 数の削減）。
  • ルールの優先度を整理し、よく使われるルールを上位に配置する。
  • 固定レスポンスやリダイレクトはアプリまで届かせず ALB のアクションで返す。

負荷分散アルゴリズム

アルゴリズム用途
ラウンドロビン（デフォルト）リクエスト処理時間が均一な場合
最小未処理リクエスト（LOR）処理時間にばらつきがある場合
加重ランダム + 異常緩和（Automatic Target Weights）一部ターゲットの異常を自動で回避したい場合

その他

  • HTTP/2 はクライアント側でデフォルト有効。バックエンドで gRPC を使う場合はプロトコルバージョンを gRPC に設定する。
  • 静的コンテンツは CloudFront でキャッシュし、ALB へのリクエスト数を削減する。
  • スティッキーセッションは負荷の偏りを生むため、可能ならセッション情報を ElastiCache / DynamoDB 等へ外出しして使わない設計にする。

5. 監視・ロギング

CloudWatch メトリクス（アラーム推奨）

メトリクス監視ポイント
HTTPCode_ELB_5XX_CountALB 起因の 5xx（502/503/504）
HTTPCode_Target_5XX_Countアプリ起因の 5xx
TargetResponseTimeレイテンシ（p90/p99 で監視）
UnHealthyHostCount / HealthyHostCountターゲットの正常性
RejectedConnectionCount接続上限到達
TargetConnectionErrorCountターゲットへの接続失敗
RequestCountトラフィック傾向・異常検知
ConsumedLCUsコスト・スケール傾向
  • エラー件数だけでなく エラー率（Metric Math） でアラームを設定すると誤検知が減る。
  • CloudWatch Anomaly Detection の活用も有効。

ログ

  • アクセスログを S3 に出力する（デフォルト無効）。
    • Amazon Athena でクエリできるようにテーブルを定義しておく。
    • S3 ライフサイクルで古いログを低コストストレージへ移行・削除する。
  • 接続ログ（mTLS 利用時等）や ヘルスチェックログ も必要に応じて有効化する。
  • 設定変更の監査には AWS CloudTrail を利用する。

トレーシング

  • ALB が付与する X-Amzn-Trace-Id ヘッダーをアプリのログに出力し、ALB ログとアプリログを突合できるようにする。
  • AWS X-Ray や OpenTelemetry と組み合わせて分散トレーシングを行う。

6. デプロイ戦略

  • 加重ターゲットグループを使い、ブルー/グリーンやカナリアリリースを ALB のリスナールールで実現する（例: 新 90% / 旧 10%）。
  • ECS では ECS ネイティブのブルー/グリーンデプロイ や CodeDeploy と連携する。
  • 切り替え中は 5xx 率・レイテンシを監視し、閾値超過で自動ロールバックする。
  • 登録解除の遅延とヘルスチェック間隔を適切に設定し、デプロイ時のエラーを防ぐ。

7. コスト最適化

  • ALB の料金は 時間料金 + LCU（新規接続数・アクティブ接続数・処理バイト数・ルール評価数の最大値）。
  • ホスト/パスベースルーティングで ALB を集約し、台数を減らす。
  • 不要な ALB（ターゲットなし・リクエストなし）を定期的に棚卸しする（Trusted Advisor で検出可能）。
  • CloudFront によるキャッシュで処理バイト数・リクエスト数を削減する。
  • パブリック IPv4 アドレスは課金対象のため、デュアルスタック / IPv6 対応やパブリック IPv4 不要の構成（CloudFront VPC オリジン等）を検討する。
  • ルール数が多いと LCU のルール評価が増えるため、不要なルールを整理する。

8. 運用・IaC

  • ALB・リスナー・ルール・ターゲットグループは CloudFormation / CDK / Terraform でコード管理する。
  • タグ付け（環境・システム名・オーナー・コストセンター）を徹底する。
  • AWS Config ルールで設定のドリフトを検知する（例: elb-deletion-protection-enabled、alb-http-to-https-redirection-check、alb-waf-enabled、elb-logging-enabled）。
  • AWS Security Hub の基本的なベストプラクティス標準で ELB 関連のコントロールを継続チェックする。

チェックリスト

セキュリティ

  • HTTPS リスナー + HTTP→HTTPS リダイレクト
  • ACM 証明書を利用
  • 最新の TLS セキュリティポリシーを選択
  • ターゲットの SG は ALB の SG からのみ許可
  • AWS WAF を関連付け
  • 無効なヘッダーの削除を有効化
  • 削除保護を有効化

信頼性

  • 2 つ以上の AZ に配置
  • 専用ヘルスチェックエンドポイントを設定
  • ALB アイドルタイムアウト < バックエンド Keep-Alive
  • 登録解除の遅延をアプリに合わせて調整
  • ASG で ELB ヘルスチェックを有効化
  • ゾーンシフト / ゾーンオートシフトを検討

運用

  • アクセスログを S3 に出力
  • 主要メトリクスに CloudWatch アラームを設定
  • X-Amzn-Trace-Id をアプリログに出力
  • IaC で管理・タグ付け
  • AWS Config / Security Hub で継続チェック

参考資料

0件のページ

    バックリンク