Elastic Load Balancing本番運用Vol1｜ALB・NLB・GWLB選定と設計

1. ロードバランシングの本番課題とELBファミリーの全体像

本番環境でWebアプリケーション、コンテナ、マイクロサービスを安定運用するには、複数のバックエンドインスタンスへトラフィックを適切に分散するロードバランサーが不可欠です。サービスが成長するにつれ、可用性・スケーラビリティ・セキュリティという3つの次元で高い要求が課せられます。

本番ロードバランシングが直面する3つの課題

可用性の確保

単一インスタンスでサービスを提供していると、ハードウェア障害・OS再起動・デプロイのたびにダウンタイムが発生します。ロードバランサーはヘルスチェックで異常なターゲットを自動的に切り離し、正常なターゲットへトラフィックを迂回させることで、バックエンドの障害をエンドユーザーから隠蔽します。複数のAvailability Zone(AZ)にターゲットを分散することで、AZ障害に対しても高可用性を実現できます。ヘルスチェックの応答が設定したしきい値を超えた時点でターゲットは即座にローテーションから外れ、復旧が確認されると自動的に組み込まれます。

スケーラビリティの実現

アクセス集中時にターゲットを水平スケールアウトするには、新しく追加したインスタンスへトラフィックを即座に振り分ける仕組みが必要です。Auto Scalingグループとロードバランサーを連動させると、スケールアウトで追加されたインスタンスが自動的にターゲットグループへ登録され、ヘルスチェック通過後にトラフィックの受け取りを開始します。スケールインで不要になったインスタンスは、コネクションドレイン(登録解除遅延)により既存セッションを処理し終えてからサービスアウトするため、ユーザーへの影響を最小化できます。ELB自体もトラフィック量に応じて内部的にスケールするため、手動での容量管理は不要です。

セキュリティの強化

TLS終端をロードバランサーに集約することで、バックエンドへの証明書配布が不要になります。ACM(AWS Certificate Manager)で証明書を一元管理し、有効期限前の自動更新も適用されます。ALBはWAF(Web Application Firewall)と直接統合し、SQLインジェクション・XSSといったOWASP攻撃をHTTP/HTTPSのレイヤーで検出・遮断します。相互TLS(mutual TLS)認証でクライアント証明書を検証することで、ゼロトラスト要件にも対応できます。アクセスログをS3へ出力してAthenaで分析するといった監査要件も満たせます。

自前ロードバランサーの限界

Nginx・HAProxyを自前で構築・運用するアプローチは設定の柔軟性が高い反面、以下の課題を抱えます。

• 冗長化の複雑さ: Active-Standby構成でも、フェイルオーバーにDNS切り替えやVRRP制御が必要で、設定ミスがダウンタイムにつながります
• スケールの困難さ: トラフィック急増時にロードバランサー自体のキャパシティが上限に達することがあり、台数増設やElastic IPの付け替えを手動で行う運用負荷が生じます
• 証明書更新の負担: 複数のインスタンスそれぞれへ証明書を配布・更新する作業は、規模が大きくなるほど漏れやミスのリスクが高まります
• ヘルスチェック設計の手間: HTTP・gRPC・TCPなど多様なプロトコルに対応したヘルスチェックを自前実装・チューニングするには専門知識と継続的なメンテナンスが必要です
• 運用インフラの維持コスト: ロードバランサー自体のOSパッチ・モニタリング・バックアップを管理するオーバーヘッドが、エンジニアリングリソースを継続的に消費します

Elastic Load Balancing(ELB)はフルマネージドサービスとしてこれらの課題を解消します。可用性・スケーリング・証明書管理・ヘルスチェックをAWSが担い、利用者はアプリケーション自体の価値提供に集中できます。2024〜2025年にかけてもAutomatic Target Weights・ALB mutual TLS・QUIC対応といった新機能が継続的に追加されており、最新の本番要件に対応し続けています。

ELBファミリーの全体像

ELBファミリーには、動作するOSIレイヤーと用途が異なる3種類のロードバランサーがあります。

Application Load Balancer (ALB) — L7 HTTP/HTTPS

ALBはHTTP/HTTPSトラフィックをレイヤー7で処理するロードバランサーです。リクエストのURL・ホスト名・HTTPヘッダ・メソッド・クエリパラメーターといったアプリケーション層の情報をもとにルーティングルールを評価し、マイクロサービスの適切なターゲットグループへトラフィックを転送します。

主な特徴は以下のとおりです。

• コンテンツベースルーティング: /api/*・/static/* などのパスパターンや、ホスト名ベースでターゲットグループを切り替えます
• 高度なプロトコルサポート: WebSocket・HTTP/2・gRPCに対応し、モダンなAPIサービスにも適用できます
• 認証統合: HTTPSリスナーにauthenticate-oidc/authenticate-cognitoアクションを設定することで、認証ロジックをアプリケーションコードから切り離せます
• WAF統合: Web ACLをアタッチしてOWASP攻撃をレイヤー7でブロックします
• Lambdaターゲット: ターゲットとしてLambda関数を指定し、サーバーレスバックエンドへルーティングできます

ALBはHTTPSの終端で証明書を処理し、バックエンドへはHTTP/HTTPSで転送します。Webアプリケーション・REST API・GraphQL API・マイクロサービスといったHTTPベースのワークロード全般に最適です。

Network Load Balancer (NLB) — L4 TCP/UDP/TLS

NLBはレイヤー4のTCP/UDP/TLSトラフィックを超低遅延で処理するロードバランサーです。毎秒数百万リクエストの処理能力を持ち、急峻なトラフィックスパイクにもミリ秒単位で対応します。

主な特徴は以下のとおりです。

• 固定IP: 各AZにElastic IP(静的IPアドレス)を割り当てられるため、ファイアウォールやオンプレミス機器での送信元IP許可リスト管理が容易になります
• PrivateLink: NLBをVPCエンドポイントサービスとして公開することで、他のVPCやAWSアカウントからパブリックインターネットを経由せずにサービスへアクセスできます
• 加重ターゲットグループ: 複数のターゲットグループに静的な重みを設定し、ブルー/グリーンデプロイやカナリアリリースをゼロダウンタイムで実施できます
• クライアントIP保持: バックエンドが送信元IPを直接参照できるため、IPベースのアクセス制御や監査ログへの記録が可能です
• QUIC対応: UDP上のQUICプロトコルをサポートし、HTTP/3トラフィックにも対応しています

ゲームサーバー・IoT・金融取引システム・データストリーミングなど、超低遅延や固定IPが必要なワークロードに最適です。

Gateway Load Balancer (GWLB) — L3 セキュリティアプライアンス挿入

GWLBはレイヤー3のIPパケットをサードパーティ仮想アプライアンスへ透過的に転送するロードバランサーです。ファイアウォール・侵入検知システム(IDS/IPS)・ディープパケットインスペクション(DPI)装置をアプライアンスフリートとして束ね、スケールと可用性を確保します。

主な特徴は以下のとおりです。

• GENEVEカプセル化: トラフィックをGENEVEプロトコル(ポート6081)でカプセル化してアプライアンスへ転送し、インスペクション後に元のパスへ戻します
• 5タプルスティッキネス: 送信元IP・宛先IP・プロトコル・送信元ポート・宛先ポートの5タプルでフローをスティッキーにし、双方向のパケットが同一アプライアンスを通過するようにします
• 集中インスペクション: GWLB EndpointはPrivateLinkを活用した仕組みで、アプライアンスを別VPC(インスペクションVPC)に集中配置し、複数のワークロードVPCのトラフィックを一括検査できます
• 透過性: アプリケーション側のIPアドレスや設定を変更せずにインラインインスペクションを実現でき、既存環境への適用が容易です

コンプライアンス要件でネットワークトラフィックのインスペクションが求められる環境や、サードパーティのセキュリティアプライアンスをAWS環境へ展開する際に最適です。

3種の選定軸

ELBの3種はワークロード特性・性能要件・統合サービスの3軸で選択します。

ユースケース別の選定指針

ALBを選ぶ場合

HTTP/HTTPSのパスベース・ホストベースルーティングが必要なマイクロサービス分散、gRPCやWebSocketを扱うモダンなAPI、Cognito/OIDCによる認証をロードバランサー層で処理したい場合に選択します。HTTPレイヤーの豊富なルーティングルール(最大100条件/ルール)と認証統合は、複雑なWebサービスのトラフィック制御に不可欠です。

NLBを選ぶ場合

TCP/UDPの超低遅延通信が必要なゲームサーバー・金融取引システム・IoT、固定IPが必要なオンプレミスとの接続や外部ファイアウォール許可リスト管理、他のVPC・アカウントへPrivateLinkでサービスを公開する場合に選択します。L4で動作するためHTTPヘッダの処理がなく、ALBより低いレイテンシを達成できます。

GWLBを選ぶ場合

サードパーティのファイアウォール・IDS・IPSをAWS環境へ透過的に挿入する場合、コンプライアンス要件でネットワーク全トラフィックのインスペクションが必要な場合に選択します。GENEVEカプセル化とGWLB Endpointにより、アプライアンスを集中管理しながら複数のVPCへサービスを提供できます。

複数の要件が絡む場合は組み合わせも有効です。CloudFront → ALB(L7ルーティング)、NLBをPrivateLinkエンドポイントとして公開しその背後でALBへ転送するチェーン構成も本番環境でよく採用されます。

バックエンドのEC2/Auto Scalingはこちら（Compute本番運用 Vol1）

2. Application Load Balancer(ALB) — L7ルーティング

Application Load Balancer(ALB)はHTTP・HTTPS・gRPC・WebSocketに対応したL7ロードバランサーです。リクエストの内容を解析して最適なターゲットへ転送するため、マイクロサービスアーキテクチャやAPIゲートウェイ統合で広く採用されています。

2.1 ALBが対応するプロトコル

ALBはOSI参照モデルのアプリケーション層(L7)で動作し、以下のプロトコルをサポートしています。

gRPCはHTTP/2上で動作します。ターゲットグループのプロトコルにgRPCを指定すると、/package.service/method形式のパスでgRPCメソッド単位のルーティングが可能です。バックエンドはgRPCサーバーとして動作しており、ALBがHTTP/2コネクションを維持してgRPCフレームを転送します。

WebSocketはHTTPアップグレードリクエスト(Upgrade: websocket)を検知してロングコネクションへ移行します。ALBはWebSocketを透過的にサポートするため、バックエンドの設定変更は不要です。スティッキーセッションと組み合わせることで、WebSocketセッション中のターゲット固定も実現できます。

HTTP/2はALBとクライアント間で使用し、ALBからバックエンドへは通常HTTP/1.1でリクエストを転送します。バックエンドがHTTP/2に対応している場合は、ターゲットグループのプロトコルバージョンをHTTP2に指定することで、ALBからバックエンドへのHTTP/2接続も利用できます。

2.2 リスナーとルールの設計

リスナーはALBが受け付けるポート・プロトコルの定義です。1つのALBに複数のリスナーを設定できます。

各リスナーには優先度付きのルールを設定します。ルールは優先度の高い順に評価され、最初にマッチした条件のアクションを実行します。ルール数の上限はリスナーあたり100件です。

ルールの条件タイプ:

複数の条件を組み合わせるとAND条件として評価されます。「ホスト=api.example.com かつ パス=/v2/*」のような複合条件でv2専用ターゲットグループへ振り分ける構成が典型例です。

ルールのアクションタイプ:

• forward — 1つまたは複数のターゲットグループへ転送します。加重指定でカナリアリリースも可能です
• redirect — HTTPSリダイレクト・パス書き換え・ポートを変更します(301または302)
• fixed-response — 指定したHTTPステータスコードと本文を返します(ヘルスチェック専用エンドポイントなど)
• authenticate-oidc — OIDCプロバイダーで認証した後にターゲットへ転送します
• authenticate-cognito — Cognito User Poolsで認証した後にターゲットへ転送します

デフォルトルールはどの条件にもマッチしないリクエストの処理を定義します。fixed-response: 404またはメインターゲットグループへのforwardを設定するのが一般的です。

HTTPリスナーでHTTPSへ強制リダイレクトする設定は以下のとおりです。

2.3 ターゲットグループの設計

ターゲットグループはALBがトラフィックを転送する宛先の集合です。ターゲットのタイプ・プロトコル・ポート・ヘルスチェックを定義します。

ターゲットタイプの比較:

ECS FargateはawsvpcネットワークモードでタスクごとにIPが割り当てられます。そのためターゲットタイプはipを使います。ECSサービス定義でターゲットグループARNを指定すると、タスクの起動・停止に連動してターゲットが自動登録・解除されます。

ヘルスチェックの設計指針:

ヘルスチェック間隔が異常検知の遅延に直結します。間隔30秒・異常しきい値3回の設定では、ターゲット障害から最大90秒後にトラフィックが切り離されます。SLAに合わせて間隔を調整することで検知遅延を低減できます。

ヘルスチェックパスにはDBアクセスや外部APIを含まない軽量なエンドポイントを使います。重い処理を含むヘルスチェックはタイムアウトや誤検知の原因となります。専用の/healthエンドポイントを実装して、アプリのプロセスが生きていれば200 OKを返すよう設計するのが推奨です。

2.4 認証統合 — OIDC・Cognito User Pools

ALBのHTTPSリスナーに認証アクションを設定することで、アプリ側に認証ロジックを追加せずにOIDC/Cognito認証を挿入できます。この機能はHTTPSリスナーにのみ設定可能です。HTTPリスナーには設定できません。

認証フローの流れ:

1. 未認証ユーザーからのリクエストをALBが検知します
2. OIDCプロバイダーまたはCognitoのログイン画面へリダイレクトします
3. 認証成功後、ALBがセッションクッキー(AWSELBAuthSessionCookie)を発行します
4. 以降のリクエストはクッキーで認証済みと判定して直接転送します
5. バックエンドへのリクエスト転送時にX-AMZN-OIDC-*ヘッダを付与します

バックエンドへ付与されるヘッダ:

X-AMZN-OIDC-DATAのペイロードをBase64デコードするとユーザーのemail・sub等のクレームを取得できます。バックエンドはこのヘッダを読み取ることで、OIDC認証済みユーザーの情報を活用できます。

authenticate-cognitoアクションの設定例:

{
  "Type": "authenticate-cognito",
  "AuthenticateCognitoConfig": {
 "UserPoolArn": "arn:aws:cognito-idp:ap-northeast-1:123456789012:userpool/ap-northeast-1_XXXX",
 "UserPoolClientId": "your_client_id",
 "UserPoolDomain": "auth.example.com",
 "Scope": "openid email profile",
 "OnUnauthenticatedRequest": "authenticate"
  }
}

OnUnauthenticatedRequestには3つの選択肢があります。authenticateはログインページへリダイレクト、denyは403を返す、allowは認証をバイパスします。APIエンドポイントにdenyを設定してトークンなしのアクセスを明示的に拒否するパターンも有効です。

Cognito User Pools自体の詳細な設定(ユーザープール作成/IdP連携/MFA/アドバンスドセキュリティ)は専用記事を参照してください。ここではALBとCognitoの連携レイヤーに集中した解説とします。

2.5 加重ターゲットグループ — Blue/Green・カナリアリリース

forwardアクションで複数のターゲットグループに重みを指定すると、トラフィック比率を制御できます。追加のデプロイツールなしでBlue/GreenデプロイとカナリアリリースをALBレイヤーで実現できます。

カナリアリリースの段階的な手順:

コネクションドレイン(登録解除遅延)のデフォルト値は300秒です。ターゲットのドレイン中は新規リクエストを送らず、進行中のリクエストが完了するまで待機します。デプロイ時の接続エラーを防ぐために必ず設定します。

スティッキーセッションの種類:

カナリアリリース中にスティッキーセッションを有効にすると、同一ユーザーのリクエストが同じターゲットグループに固定されるため、一貫したユーザー体験を維持できます。ただし加重変更直後はスティッキークッキーが残るため、重みの変更が実際のトラフィック分散に反映されるまでクッキーの有効期限(TTL)分の時間がかかります。

3. Network Load Balancer(NLB) — L4超低遅延

Network Load Balancer(NLB)は、TCP・UDP・TLSをレイヤー4(L4)で処理するマネージドロードバランサーです。HTTPヘッダを解析しない分、オーバーヘッドが極めて小さく、マイクロ秒単位の超低遅延と毎秒数百万接続を超える高スループットを実現します。固定IP要件・PrivateLink公開・超高速接続が必要なワークロードに最適です。

対応プロトコルとリスナー設定

NLBのリスナーはTCP・UDP・TLS・TCP_UDPの4プロトコルをサポートします。TLSリスナーを選択するとNLB自身がTLSを終端し、バックエンドへはTCPで転送します。この構成ではACM証明書をNLBに紐付け、バックエンドサーバーの証明書管理を不要にできます。

プロトコルの使い分け:

クライアントIPはALBのX-Forwarded-Forとは異なり、パケットの送信元IPとして保持されます。バックエンドでクライアントIPを参照するにはセキュリティグループやACLのルールにクライアントIPレンジを直接記載します。

AZごとの静的IPとElastic IP

NLBを作成すると、有効化した各アベイラビリティゾーン(AZ)にひとつのネットワークインターフェースが割り当てられ、固有のIPアドレスが付与されます。ALBはIPアドレスが変動しますが、NLBは変わりません。

さらにElastic IP(EIP)をNLBノードに紐付けることで、ロードバランサーのIPアドレスを事前に確定できます。外部パートナーやオンプレミスのファイアウォール許可リストに事前登録できるため、IP固定が要件のシステムで必須の機能です。

EIPの割り当ては作成時にサブネットマッピングで指定します:

aws elbv2 create-load-balancer \
  --name my-nlb \
  --type network \
  --subnet-mappings SubnetId=subnet-abc123,AllocationId=eipalloc-xyz789

AZを3つ使う場合は3つのEIPが必要です。EIPはリージョン内のサービスクォータ(デフォルト5個)に含まれるため、必要数を事前に確認してください。

静的IPが必要な典型的なシナリオ:
– 取引先企業のファイアウォールでAWSサービスのIPを許可リストに登録する場合
– 法規制やコンプライアンス上、送信元IPを固定する必要がある金融決済システム
– オンプレミスとのサイト間VPNやDirect Connectで特定IP宛てのルートのみ許可する構成

PrivateLinkとVPCエンドポイントサービス

NLBはAWS PrivateLinkのバックエンドとして機能できます。サービス提供側がNLBの前面にVPCエンドポイントサービスを作成し、利用側が各自のVPCにインターフェース型VPCエンドポイントを作成することで、インターネットを経由せずにプライベートなサービス接続が実現します。

エンドポイントサービスの作成手順:

1. バックエンドのターゲットグループとNLBを作成して正常稼働させる
2. VPCコンソール → 「エンドポイントサービス」 → NLBを指定して作成
3. 接続を許可するAWSアカウントIDまたはIAM ARNを承認リストに追加する(または自動承認を有効化)
4. 利用側がインターフェース型VPCエンドポイントを作成し、プライベートDNS名で接続する

主な活用パターン:

マルチアカウント内部API公開: 自アカウントのアプリケーションAPIをPrivateLinkで別アカウントへプライベートに提供します。エンドポイントのDNS名はVPC内部で解決され、インターネットに露出しません。IPアドレスのオーバーラップがあるVPC間でも接続できる点がVPCピアリングと異なります。

SaaSサービスのプライベート提供: サービス提供者がNLBとPrivateLinkで接続口を公開し、顧客がインターフェース型エンドポイントを作成して接続します。AWSマーケットプレイス経由での提供も可能です。

クロスアカウント集中ログ収集: ログ収集サービスをひとつのアカウントに集中させ、他アカウントのエージェントはPrivateLinkを通じてデータを送信します。Transit GatewayやVPCピアリングを必要とせず、構成をシンプルに保てます。

PrivateLinkを使う際の注意点:
– エンドポイントサービスのヘルスチェックが失敗するとサービスが「利用不可」と表示されます。NLBのターゲットグループを常に正常に保つことが前提です
– プライベートDNS名の有効化はVPCのenableDnsHostnamesとenableDnsSupportが有効でなければ機能しません
– エンドポイントサービスを受け入れる側は、接続リクエストを承認するか自動承認を設定する必要があります

加重ターゲットグループ(Weighted Target Groups)

2024年にGA(一般提供)となった加重ターゲットグループを使うと、NLBのリスナーから複数のターゲットグループへ任意の重みでトラフィックを分散できます。

リスナーのデフォルトアクションにForward設定で複数のターゲットグループと重みを指定します:

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/net/my-nlb/... \
  --default-actions Type=forward,ForwardConfig='"'"'{"TargetGroups":[
 {"TargetGroupArn":"arn:...:targetgroup/blue/...","Weight":90},
 {"TargetGroupArn":"arn:...:targetgroup/green/...","Weight":10}
  ]}'"'"'

主な活用パターン:

Blue/Greenデプロイ: 本番環境のBlueターゲットグループに90%、新バージョンのGreenターゲットグループに10%から始め、Greenの動作確認をしながら重みを徐々にシフトします。100%移行後にBlueを廃止します。問題が発生した場合はBlueの重みを100に戻すだけでロールバックが完了します。

カナリアリリース: 全体の5〜10%のトラフィックを新バージョンへ流し、エラー率とレイテンシを監視します。問題がなければ重みを段階的に上げます。ABテストや機能フラグと組み合わせることで、ユーザーセグメント単位での段階展開も可能です。

加重ターゲットグループはALBでも利用できますが、NLBはL4でのTCP/UDP接続を対象にするため、HTTPヘッダを必要としないプロトコルでもトラフィックシフトが行えます。

QUIC対応

NLBはQUICプロトコルをUDPリスナーで受け付けます。QUICはUDPベースのトランスポートプロトコルで、HTTP/3の下位層として使われます。TCPと比べてハンドシェイクのラウンドトリップが少なく、パケットロス時のHead-of-Line Blockingが発生しないため、モバイル環境や高パケットロス環境での低遅延通信に優れます。

NLBでQUICを扱う場合の構成:
– UDPリスナー(ポート443が一般的)を作成します
– バックエンドターゲットにQUICを処理するアプリケーション(nginx 1.25+・Envoy・Caddy等)を配置します
– NLBはパケットをL4レベルでそのままターゲットへ転送するため、QUIC接続の終端はターゲット側で行います
– セッション継続性はConnection IDとUDP5タプルの組み合わせでスティッキー管理されます

ヘルスチェックの設定

NLBのヘルスチェックはTCP・HTTP・HTTPSの3形式をサポートします。

代表的な設定パラメータ:
– チェック間隔: 10〜300秒(デフォルト30秒)。速い検出が必要なら10秒に短縮します
– 正常しきい値: 連続成功回数(デフォルト3回)。素早い復帰を優先するなら2回に短縮します
– 異常しきい値: 連続失敗回数(デフォルト3回)
– タイムアウト: レスポンスの待機時間。プロトコルやターゲットに応じて設定します

NLBは既存のTCP接続をターゲット異常後も即断しません。進行中の接続はConnection Draining(登録解除遅延)の設定時間が経過するか接続が完了するまで維持されます。デプロイ時やスケールインを安全に行うために、アプリケーションの平均接続保持時間に合わせてdraining時間を設定します。

クライアントIP保持とセキュリティグループ

NLBはデフォルトでクライアントのIPアドレスをパケットの送信元IPとしてバックエンドへ伝えます。ALBのX-Forwarded-Forとは仕組みが異なり、ネットワーク層でIPを保持するため、バックエンドはクライアントIPを直接参照できます。この動作はターゲットグループの設定から無効化でき、無効化するとNLBノードのIPが送信元として見えます。

2024年以降、NLBにもセキュリティグループをアタッチできるようになりました。これにより、特定のIPアドレス範囲や他のセキュリティグループからの通信のみを許可するきめ細かな制御が可能です。

主なユースケース

NLBは「HTTPレイヤーのルーティングが不要で、超低遅延・固定IPが必要」という要件に最適な選択肢です。ALBと組み合わせて、外部のHTTPSはALBで受け、内部のマイクロサービス間通信にNLBを使う構成もよく採用されます。
NLBがセットアップされると、ALBと同じCloudWatchメトリクス(ActiveConnectionCount・ProcessedBytes等)で監視でき、CloudWatchアラームによるスケーリングポリシーとの組み合わせで安定した運用が可能です。

4. Gateway Load Balancer(GWLB) — L3セキュリティアプライアンス挿入

Gateway Load Balancer(GWLB)は、ALB(L7)・NLB(L4)とは根本的に異なる設計思想を持つロードバランサーです。ALBはHTTPリクエストを終端してバックエンドへ転送し、NLBはTCP/UDPコネクションを終端または透過的に転送します。GWLBはトラフィックを終端せず、L3(IPパケット層)でパケットをセキュリティアプライアンスへ透過的にリダイレクトし、検査後に元のルートへ戻すという仕組みで動作します。この透過挿入モデルにより、アプリケーションを変更せずにファイアウォール・IDS・IPS・DLPといったサードパーティ製セキュリティアプライアンスをトラフィックパス上に配置できます。

GWLBの動作原理 — GENEVEカプセル化

GWLBの中心技術はGENEVE(Generic Network Virtualization Encapsulation)プロトコルです。RFC 8926で標準化されたGENEVEはUDPポート6081を使用し、元のIPパケットをカプセル化してアプライアンスへ送信します。カプセル化により、アプライアンスはパケットの内容（送信元/宛先IP・ポート・プロトコル）を完全に参照しながら検査・変更・ドロップを判断できます。

トラフィックの流れは次のとおりです。送信元からのパケットがGWLBエンドポイント(GLBe)に到達します。GLBeはVPC内に配置されたPrivateLinkベースのエンドポイントで、ルートテーブルの設定により特定のトラフィックをGLBe経由にルーティングします。GLBeからGWLBへトラフィックが転送され、GWLBがGENEVEでカプセル化してアプライアンスインスタンスへ送ります。アプライアンスが検査を完了するとGWLBへ返送し、GWLBはカプセルを解除して元の宛先（またはGLBe経由で送信元VPCへ）へ転送します。このラウンドトリップにより、アプリケーションはアプライアンスの存在を意識せずに通信できます。

フロースティッキーは5タプル(送信元IP・宛先IP・送信元ポート・宛先ポート・プロトコル)に基づきます。同一フローは常に同じアプライアンスインスタンスへ転送されるため、アプライアンス側でのセッション状態(ファイアウォールステートフルテーブル等)を一貫して維持できます。アプライアンスがスケールアウト/スケールインしても、既存フローのスティッキーは維持され、新規フローだけが新しいインスタンスへ振り分けられます。

GENEVEのカプセルには、VPIと呼ばれる可変長オプションフィールドを含めることができます。GWLBはVPIフィールドにVPCエンドポイントのIDとポートを付与してアプライアンスへ送信します。アプライアンスはVPIフィールドを読み取ることで、どのGLBe(どのスポークVPC)からのトラフィックなのかを識別できます。この仕組みにより、インスペクションVPCの単一アプライアンスフリートで複数のスポークVPCからのトラフィックを区別して処理し、スポークVPCごとに異なるポリシーを適用できます。

アーキテクチャの基本構成 — インスペクションVPC

GWLBを活用する標準的なアーキテクチャはインスペクションVPCパターンです。アプリケーションが動作するVPC(スポークVPC)とは別に、セキュリティアプライアンスを集中配置するインスペクションVPCを用意します。スポークVPCとインスペクションVPCを分離することで、セキュリティ資産の管理権限とアプリケーション開発の権限を異なるAWSアカウントに分離でき、最小権限原則とセキュリティチームの統括管理を両立できます。

インスペクションVPCには以下のコンポーネントを配置します。GWLBはAZ横断でアプライアンスフリート(ターゲットグループ)へトラフィックを分散します。アプライアンスEC2インスタンス群はGWLBのターゲットグループに登録し、GENEVEでカプセル化されたトラフィックを受信します。Auto ScalingグループとGWLBのヘルスチェックを組み合わせることで、トラフィック量に応じてアプライアンスをスケールアウト/インしながら高可用性を維持します。

スポークVPCにはGWLBエンドポイント(GLBe)を作成します。GLBeはAZごとに配置するのが推奨で、AZ間の通信コスト削減と可用性向上を両立できます。GLBeを作成したら、スポークVPC側のルートテーブルを編集して対象トラフィックをGLBe経由に向けます。インバウンド検査の場合はインターネットゲートウェイ(IGW)に関連付けたIngress Routing(Edge Association)を使用し、IGWへの受信トラフィックをGLBeへ誘導します。

インスペクションVPCのアドレス空間はスポークVPCと重複しないCIDRを割り当てます。GWLBとGLBe間の通信はAWSのバックボーンネットワークを通るためVPCピアリングは不要ですが、アプライアンスインスタンスがインターネット経由でシグネチャを更新する場合はNATゲートウェイを配置します。アプライアンスの管理通信(SSH・APIアクセス)はSession ManagerまたはプライベートなVPCエンドポイント経由で行い、管理ポートをインターネットに直接公開しないことがセキュリティ上の基本です。セキュリティグループはGWLBからのGENEVEトラフィック(UDP/6081)のみを許可し、不要なポートは閉じておきます。

GWLBエンドポイント(GLBe)の詳細

GWLBエンドポイントはPrivateLinkの仕組みを活用しており、GWLBをVPCエンドポイントサービスとして別VPC・別AWSアカウントのスポークVPCへ安全に公開できます。これにより、セキュリティチームがインスペクションVPCを一元管理し、各ビジネスユニットのスポークVPCからは単純にGLBe経由でトラフィックを流すだけで済みます。権限管理はエンドポイントサービスのプリンシパル許可リストで制御でき、どのAWSアカウントがGWLBを利用できるかを絞り込めます。

GLBeはElastic Network Interface(ENI)として実装され、スポークVPC内の指定サブネットに配置されます。GLBeのIPアドレスをルートテーブルのネクストホップとして指定することで、特定のCIDRへの通信をGWLBへ誘導できます。GLBeはゲートウェイタイプのVPCエンドポイントに分類されており、ルートテーブル経由でのルーティングを行います。

典型的な構成パターン — 3方向のインスペクション

①インバウンドトラフィック検査(Ingress Inspection)は最も一般的なパターンです。インターネットからスポークVPCへの受信トラフィックを検査します。IGWのEdge Associationルートテーブルで受信トラフィックをGLBe経由に向け、アプライアンスで検査後にアプリケーションサーバーへ転送します。不正アクセスや脆弱性攻撃をアプリケーション到達前にブロックできます。構成のポイントは、スポークVPCのパブリックサブネットにGLBeを配置し、IGWからの受信パスとアプリケーションへの転送パスの両方をルートテーブルで正確に設定することです。

②East-West検査(VPC間トラフィック)はVPC間・AWSアカウント間の横断トラフィックを検査するパターンです。Transit Gateway(TGW)を中央ハブとして使用し、スポークVPCからTGWへのトラフィックをインスペクションVPCのGLBe経由にルーティングします。マルチアカウント環境での内部通信の監視・ポリシー適用に適しており、ゼロトラストアーキテクチャの実現に貢献します。TGWのルートテーブルとアタッチメントの設計が複雑になるため、Transit Gatewayのルートドメインを適切に分割することが重要です。

③アウトバウンド検査(Egress Inspection)はVPC内のリソースからインターネットへの送信トラフィックを検査するパターンです。スポークVPCからNATゲートウェイへ向かうルートをGLBe経由に変更し、アプライアンスでDLP(Data Loss Prevention)・URLフィルタリング・マルウェア通信ブロックを実行します。機密データの外部流出防止や、侵害されたインスタンスからのC2通信検出に有効です。

アプライアンスのスケーリングとヘルスチェック

GWLBのターゲットグループには複数のアプライアンスEC2インスタンスを登録します。ヘルスチェックはTCPまたはHTTP/HTTPSで設定でき、アプライアンスが応答しない場合は自動的にターゲットから除外されます。ヘルスチェックの設定項目(プロトコル/ポート/パス/間隔/タイムアウト/正常しきい値/異常しきい値)はALB・NLBと共通の考え方ですが、アプライアンスの起動時間が長い場合は異常しきい値を大きめに設定して誤排除を防ぐことが重要です。

Auto Scalingグループとの統合では、GWLBのターゲットグループをAuto Scalingグループのライフサイクルフックと組み合わせます。スケールアウト時は新しいインスタンスがヘルスチェックに合格してから自動的にターゲットグループに追加されます。スケールイン時はコネクションドレイン(登録解除遅延)を設定することで、処理中のフローが完了するまでインスタンスへの新規振り分けを止めながらも既存フローは継続できます。GWLBはターゲットが0台になるとトラフィックを転送できなくなるため、最小インスタンス数は本番環境で2台以上に設定し、AZ障害時の冗長性を確保します。

アプライアンスのスケーリング指標にはCPU使用率・ネットワーク帯域・セッション数が使われます。セキュリティアプライアンスはステートフルな性質上、急激なスケールインはセッション切断につながるため、スケールインポリシーのクールダウン期間を長めに設定することが推奨されます。

アプライアンスチェーン — 複数装置の直列挿入

高度なセキュリティ要件では複数のセキュリティ装置を組み合わせるアプライアンスチェーンが必要になります。例えば、まずNGFW(次世代ファイアウォール)でポリシーフィルタリングを実施し、次にIDSでパターンマッチングによる検査をし、さらにSSL Inspection専用装置でTLS復号・再暗号化を経てからアプリケーションへ転送するという多段構成です。

GWLBで直接的なマルチホップチェーンを実現する場合、各アプライアンスを別々のターゲットグループに分け、スポークVPC側でルートテーブルを段階的に設定する方法があります。ただし設計が複雑になるため、アプライアンスベンダーが提供するインライン多機能装置(単一インスタンスで複数機能を担う)を使う構成や、アプライアンス内部でチェーン処理を完結させる構成の方がシンプルです。

AWS Marketplace製品との統合

GWLBに対応したサードパーティ製品はAWS Marketplaceで入手できます。代表的な製品と選定のポイントを示します。

Palo Alto Networks VM-Seriesは次世代ファイアウォールで、アプリケーション識別・ユーザー識別・脅威防御・URLフィルタリングを単一プラットフォームで提供します。GWLB向けのCloudFormationテンプレートが公式リポジトリで公開されており、インスペクションVPCの初期構築を自動化できます。また、AWS Autoscaling統合も公式にサポートしており、Panoramaによる集中ポリシー管理とGWLBのターゲットグループ自動登録を組み合わせることでゼロタッチのスケールアウトが実現できます。

Check Point CloudGuard Network SecurityはCheck Point社のクラウドネイティブNGFWです。Unified Security Management(USM)でオンプレミスと同じポリシーをAWSに適用でき、ハイブリッドクラウドのセキュリティ一元管理に適しています。

Fortinet FortiGate-VMはAWS上でFortiOSを動作させる仮想アプライアンスです。FortiManagerやFortiAnalyzerと統合して集中管理・ログ分析が可能です。BYOL(Bring Your Own License)とSubscriptionの両モデルが利用できます。

これらのMarketplace製品はGWLB統合に必要なGENEVE対応を実装済みであり、製品ガイドに沿ってターゲットグループへの登録とヘルスチェックポートを設定するだけでGWLBと連携できます。

製品選定では機能要件(NGFW/IDS/IPS/DLP/SSL Inspection)だけでなく、ライセンス形態・スループット上限・管理コンソールの使い勝手・既存オンプレミス環境との一元管理可否を考慮します。オンプレミスで既にPalo Alto NetworksやCheckpointを導入している場合は、同一ベンダーのAWS版を選ぶことでポリシー管理を統合できます。クラウドネイティブでゼロから始める場合は、AWSが管理するAWS Network Firewallとの比較も重要です。AWS Network FirewallはGWLBと異なりAWSマネージドのIPS機能を提供し、Suricataルール互換のカスタムルールグループで高度な脅威検知を設定できますが、サードパーティ製品のような詳細なアプリケーション識別やユーザー識別機能は持ちません。コンプライアンス要件でサードパーティの検証済みFWが必須なら実績あるMarketplace製品を選び、AWSネイティブ管理を優先するならAWS Network Firewallを選ぶという使い分けになります。

Infrastructure as Code(IaC)によるGWLB構築

GWLBはTerraformまたはAWS CloudFormationで完全自動化できます。Terraformではaws_lbリソースでload_balancer_type = "gateway"を指定してGWLBを作成し、aws_lb_target_groupでGENEVEプロトコル・ポート6081のターゲットグループを定義します。アプライアンスEC2インスタンスはaws_lb_target_group_attachmentでターゲットグループに登録します。GWLBエンドポイントサービスはaws_vpc_endpoint_serviceで作成し、スポークVPCのGLBeはaws_vpc_endpointでvpc_endpoint_type = "GatewayLoadBalancer"を指定します。

ルートテーブルはエンドポイントIDを参照して設定します。IGWのEdge Associationはaws_route_tableとaws_route_table_associationでgateway_idにIGWのIDを指定して関連付け、対象CIDRのルートをGLBe宛てに設定します。IaCでGWLBを管理する最大の利点は、インスペクションVPCとスポークVPCの構成を再現性高く複数環境(dev/stg/prod)にデプロイできることです。環境ごとにアプライアンスのインスタンスタイプ・台数・ヘルスチェック設定を変えながら同一のコードベースを活用できます。

Auto ScalingグループのLaunch Templateでは、アプライアンスの起動後にGENEVEインターフェースを設定するUserDataスクリプトを組み込みます。多くのMarketplace製品はGENEVE設定をブートストラップスクリプトで自動化するAMIを提供しているため、UserDataとAMIを適切に組み合わせることでゼロタッチのスケールアウトが実現できます。

マルチアカウント環境でのGWLB集中管理

AWS Organizations環境ではセキュリティアカウントにGWLBを集中配置し、各メンバーアカウントのスポークVPCからGLBe経由でトラフィックを検査する構成が一般的です。この構成ではAWS Resource Access Manager(RAM)を使ってGWLBエンドポイントサービスをOrganization全体に共有し、各メンバーアカウントがGLBeを作成できるようにします。セキュリティチームはインスペクションVPCのアプライアンスポリシーを一元管理し、各開発チームはアプリケーションVPCの開発に専念できます。

このマルチアカウントパターンはAWS Security Hubのセキュリティ統制やSecurity Lake(集中ログ管理)と組み合わせることで、組織全体のセキュリティ可視性を高められます。アプライアンスのログをSecurity Lakeへ送信し、Amazon Athenaやサードパーティのツールで分析することで、組織横断の脅威ハンティングが可能になります。

マルチアカウント構成でのGWLBエンドポイントサービス共有では、AWS RAM(Resource Access Manager)のリソース共有を使います。セキュリティアカウントでエンドポイントサービスを作成し、RAMでOrganizationまたは特定のOUに共有します。メンバーアカウント側では共有されたエンドポイントサービスを参照してGLBeを作成できます。エンドポイントサービスの受け入れ設定(acceptance_required)をfalseにすることで、自動承認でGLBe作成を許可し、各チームが手動承認を待たずにセルフサービスでGLBeを追加する運用も実現できます。セキュリティポリシー上、自動承認を許可する対象アカウントをプリンシパル許可リストで絞り込むことで、無制限な利用を防止します。

ルートテーブル設計 — トラフィック誘導の要

GWLBを正しく動作させるためには、ルートテーブルの設計が最も重要なポイントです。誤ったルート設定はパケットループや通信断の原因になります。

インバウンド検査パターンでのルートテーブル設定例を示します。IGWに関連付けるEdge Associationルートテーブルには、スポークVPCのパブリックサブネットCIDR宛てのトラフィックをGLBe(GLBe-subnet-az1)へ向けるエントリを追加します。これにより、インターネットからの受信パケットがGLBe経由でGWLBへ転送されます。アプライアンスサブネットのルートテーブルは、GWLB経由で戻ってきたトラフィックをアプリケーションVPC方向へ転送するために、デフォルトルート(0.0.0.0/0)をGLBe宛てに設定します。アプリケーションサーバーが存在するプライベートサブネットのルートテーブルは通常変更不要で、戻りトラフィックはアプライアンスを経由せずに直接IGWへ返送します(非対称ルーティングを許可するアプライアンスの場合)。対称ルーティングが必要なアプライアンスでは、送信方向のルートもGLBe経由に設定します。

Transit Gateway経由のEast-West検査では、TGWのルートドメインを分離します。インスペクションVPCのアタッチメントはインスペクション専用ルートドメインに属し、スポークVPCからのトラフィックはすべてインスペクションVPCへルーティングされます。インスペクションVPC内のルートテーブルでGLBe経由への誘導を設定し、アプライアンス検査後に本来の宛先スポークVPCへTGW経由で転送します。

GWLBのコスト構造

GWLBのコストはGWLBエンドポイントの時間料金とGWLBが処理したデータ量(GBあたり)で構成されます。アプライアンスEC2インスタンス自体のコスト(インスタンス料金・Marketplace製品ライセンス費)は別途かかります。

コスト最適化の観点から、GWLBエンドポイントはAZごとに配置するのが推奨ですが、AZをまたぐGWLBエンドポイントへのルーティングはAZクロストラフィック料金が発生します。トラフィック量が多いワークロードでは、AZごとに独立したGLBe+GWLBを配置するAZ分離構成がコスト面でも有利です。アプライアンスのインスタンスタイプ選定も重要で、セキュリティアプライアンスはCPUとネットワーク帯域の両方を消費するため、compute-optimized(C系)またはネットワーク強化インスタンス(N系)が適しています。

GWLBとアプライアンスを合わせた総コスト試算では、処理トラフィック量・アプライアンス台数・インスタンスタイプ・Marketplaceライセンス(BYOL vs サブスクリプション)の4要素が支配的です。月間1TBのインスペクショントラフィックを想定すると、GWLB処理費・GLBe時間料金・アプライアンスEC2(m5.xlarge×2台、高可用性構成)・ライセンス費の合計が概算の基準になります。コスト試算はAWS Pricing Calculatorで各リソースを個別に見積もり、合算することを推奨します。

GWLBの可用性設計

GWLBはAZをまたぐクロスゾーン負荷分散をサポートします。クロスゾーンを有効にすると、一部AZのアプライアンスが障害を起こした場合でも、他のAZのアプライアンスがトラフィックを引き継ぎます。ただし、AZ間転送コストが発生するため、コストと可用性のトレードオフを考慮して設定します。

本番環境のGWLBアーキテクチャでは最低でも2AZ構成を取り、各AZに1台以上のアプライアンスを配置します。AZ障害時の影響を最小化するために、GLBe・GWLBターゲットグループ・Auto Scalingグループをすべてマルチ-AZ構成にします。Transit Gatewayと組み合わせるEast-West検査パターンでは、TGWのAZアフィニティ設定(Appliance Mode)を有効にすることで、送受信トラフィックが同一AZ内のアプライアンスを経由するように制御でき、ステートフルなアプライアンスでのセッション一貫性を維持できます。

GWLBの運用監視

CloudWatchで監視すべき主要メトリクスを示します。ActiveFlowCountはアプライアンスへの現在のアクティブフロー数を示します。このメトリクスが急増する場合はアプライアンスのキャパシティ不足を示している可能性があります。ProcessedBytesはGWLBが処理したトラフィック量を示し、コスト見積もりと容量計画に使用します。HealthyHostCountとUnHealthyHostCountはターゲットグループ内の健全・不健全なアプライアンス数を示します。UnHealthyHostCountが増加した場合はアプライアンスの障害を示すため、即座にアラートを設定しておきます。NewFlowCountは新規フロー数を示し、アプライアンスのスケールアウト判断に使用します。

アプライアンス自体のメトリクス(CPU・メモリ・ネットワーク帯域)はEC2またはアプライアンス固有のCloudWatchエージェントで収集します。GWLBのCloudWatchメトリクスとアプライアンスのメトリクスを組み合わせることで、トラフィック増加に先回りしてスケールアウトポリシーを設定できます。

GWLBの制限値とクォータ

設計時に考慮すべきGWLBの主要な制限値を示します。AWSアカウントあたりのGWLB数のデフォルト上限はリージョンごとに設定されており、上限引き上げはService Quotasコンソールから申請できます。ターゲットグループあたりのターゲット数(アプライアンスインスタンス数)にも上限があります。GWLBエンドポイントサービスを受け入れられる接続リクエスト数やエンドポイントの最大接続数もクォータが存在するため、マルチアカウント展開前にService Quotasで現在値を確認します。

スループットについては、GWLBは内部的に水平スケールするため、単一インスタンスのALB/NLBとは異なり帯域の事前プロビジョニングは不要です。ただし、アプライアンスEC2インスタンスのネットワーク帯域はインスタンスタイプに依存します。10Gbps以上の帯域が必要な場合は、インスタンスタイプの帯域スペックとアプライアンスのライセンス帯域上限を両方確認します。

よくある構成ミスと対処

パケットルーピングはGWLBの設定で最も頻発するトラブルです。アプライアンスが検査後にパケットを戻す際のルートが誤設定されていると、パケットが無限にGWLBとアプライアンスの間を循環します。対処はアプライアンスサブネットのルートテーブルを精査し、GWLBへの戻りルートとスポークVPCへの転送ルートを明確に分離することです。

ヘルスチェックポートの不一致もよく発生します。GWLBターゲットグループのヘルスチェックポートとアプライアンスが実際にリッスンするポートが異なると、アプライアンスが常にUnhealthyと判定されます。Marketplace製品によってヘルスチェック用のポートが異なるため、製品ドキュメントで確認してから設定します。

Transit GatewayのAppliance Mode未設定によるセッション不整合も頻出です。East-West検査でTGWを使用する場合、Appliance Modeを有効にしないと、同一フローの往復が異なるAZのアプライアンスを経由し、ステートフルなファイアウォールがセッションを追跡できなくなります。必ずTGWアタッチメントのAppliance Modeを有効化します。

ALB/NLBとの設計上の違いと選定

ALBとNLBはトラフィックを終端します。ALBはHTTPリクエストを解析してバックエンドへの新しいHTTP接続を確立し、NLBはL4でコネクションを処理します。GWLBはトラフィックを透過します。元のパケットヘッダーを保持したままGENEVEでカプセル化して転送するため、アプライアンスは本物のクライアントIPや宛先IPを参照して検査できます。

もう一つの違いはプロトコルの対象範囲です。ALBはHTTP(80)/HTTPS(443)を扱います。NLBは指定したTCP/UDPポートを処理します。一方のGWLBはすべてのIPトラフィック(プロトコル不問)を透過的に処理します。このためGWLBはIPSec・GRE・ICMPなど任意のL3プロトコルを含むトラフィックの検査に対応できます。

選定の判断軸はシンプルです。HTTP/HTTPSのL7ルーティングや認証が必要ならALB、超低遅延・静的IP・PrivateLinkサービス公開が必要ならNLB、サードパーティのセキュリティアプライアンスをトラフィックパス上に透過挿入してコンプライアンス・脅威検知要件を満たす必要があるならGWLBを選択します。3つを組み合わせることも可能で、例えばインターネット受信をGWLBがセキュリティ検査したのちALBへ転送し、ALBがL7ルーティングでバックエンドへ振り分けるアーキテクチャは本番環境で広く採用されています。GWLBはセキュリティコンプライアンス要件(PCI DSS・HIPAA・FISC等)でサードパーティのNGFWやIDSを導入することが求められる環境において、AWS上でのアプライアンス統合の標準的なアプローチとなっています。

GWLBを選ぶ際に重要な視点として、アプライアンスの運用コストと習熟コストがあります。GWLBはインフラ側の高可用性とスケーリングを担保しますが、アプライアンスのポリシー管理・シグネチャ更新・ライセンス管理は引き続きセキュリティチームの責務です。GWLBを導入することで、アプライアンスのインスタンス管理負荷は大幅に軽減されますが、アプライアンス自体のセキュリティポリシー維持は変わらず必要であることを計画段階で認識しておくことが、導入後の運用成功につながります。

GWLBはセキュリティアーキテクチャの中でルータやスイッチではなく、「透過的なトラフィック分散基盤」として機能します。従来のオンプレミスではファイアウォールをネットワークの境界に物理的に挿入しましたが、GWLBはこの概念をクラウド上で仮想化・スケール可能にします。AWSのロードバランサーファミリーの中で最も異質な存在ですが、クラウド環境でのセキュリティ要件を満たすうえで不可欠なコンポーネントとなっています。

5. ヘルスチェック・SSL/TLS・セキュリティ

5.1 ヘルスチェック設計

ヘルスチェックはELBがターゲットの正常性を判断するための仕組みです。設計を誤ると、アプリケーションが正常でも除外されたり、障害を検知できなかったりします。

プロトコルと設定パラメーター

ALBとNLBではサポートするヘルスチェックプロトコルが異なります。

主要な設定パラメーターと推奨値は以下の通りです。

チェック間隔を短くすると異常検知は速くなりますが、ターゲットへの負荷が増えます。間隔30秒・閾値3回の構成では最悪90秒で異常検知できますが、間隔10秒・閾値2回では20秒で検知できます。本番では要件に応じてトレードオフを検討してください。

ヘルスチェックエンドポイントの実装

ヘルスチェック専用のエンドポイント(/healthや/healthz)を実装することをお勧めします。メインのAPIエンドポイントをヘルスチェックに使うと、認証/認可エラーや重いDB処理が誤判定を引き起こします。

推奨するヘルスチェックエンドポイントの要件は次の通りです。

• アプリプロセスが生きていれば200を返す(ロジックは最小限)
• DBやキャッシュへの接続確認は任意。ただし依存サービス障害でヘルスチェックを落とす場合はパターンを意識する
• レスポンスタイムはタイムアウト値(通常5秒)を確実に下回る
• ロードバランサーの送信元IP(ALBのVPCサブネットCIDR等)をアクセス許可する

gRPCを使うサービスではALBのgRPCヘルスチェックを利用できます。grpc.health.v1.Health/Checkに対してgRPCステータスコードで正常性を判断します。

ヘルスチェック失敗時の動作

UnhealthyThresholdCountに達すると、該当ターゲットはunhealthyとマークされて分散対象から除外されます。ターゲットが登録解除されると、接続ドレイン(DeregistrationDelay、既定300秒)が開始され、既存の接続はドレイン完了後に切断されます。

ターゲットグループのすべてのターゲットがunhealthyになった場合、ALBは503(Service Unavailable)を返します。一方、ALBの「最後のリソースへのルーティング(All targets unhealthy)」を有効にすると、全unhealthyターゲットにも分散を続けます。部分障害より全断を避けたい場合に検討してください。

5.2 SSL/TLS証明書管理(ACM)

ACM証明書のALBへのアタッチ

ALBのHTTPSリスナーにACM証明書をアタッチするには、リスナーの「デフォルト証明書」に設定します。加えて、SNIを使った追加証明書も最大25枚まで登録できます。

# HTTPSリスナーへの証明書追加
aws elbv2 add-listener-certificates \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/xxx \
  --certificates CertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/yyyy

SNI(Server Name Indication)によるマルチドメイン対応

SNIはTLSハンドシェイク時にクライアントが接続先ホスト名を通知する拡張仕様です。ALBはSNIを利用して1つのIPアドレス/ポートで複数のドメイン向け証明書を使い分けます。

動作の流れは以下の通りです。

1. クライアントがTLSハンドシェイクでServer Name(例: api.example.com)を通知します
2. ALBが登録済み証明書の中からCN/SANが一致するものを選択します
3. 一致する証明書がなければデフォルト証明書を使用します

*.example.comのワイルドカード証明書とapi.sub.example.comのSAN証明書を混在させることも可能です。

TLSポリシーの選択

TLSポリシーはTLSバージョンと暗号スイートのセットです。ALBの主要なポリシーは以下の通りです。

古いクライアントとの互換性が不要であればELBSecurityPolicy-TLS13-1-2-2021-06を選択してください。TLS1.0/1.1は既に非推奨であり、PCI DSS等のコンプライアンス要件でも無効化が求められます。

NLBのTLSリスナーでも同様にポリシーを指定できます。NLBでTLS終端する場合はバックエンドがHTTPで受信できるため、バックエンド側のTLS処理負荷を軽減できます。

証明書の自動更新

ACM管理の証明書は有効期限の60日前から自動更新が試みられます。ALBへのアタッチが有効な状態では、更新後の証明書は自動的にリスナーへ適用されます。手動での証明書ローテーション作業は不要です。

ただし、インポート証明書(外部CAで発行したもの)は自動更新の対象外です。期限切れ監視をCloudWatchアラームで設定してください。

# ACM証明書期限監視のアラーム(30日前に通知)
aws cloudwatch put-metric-alarm \
  --alarm-name "ACMCertExpiry30Days" \
  --metric-name DaysToExpiry \
  --namespace AWS/CertificateManager \
  --statistic Minimum \
  --period 86400 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=CertificateArn,Value=arn:aws:acm:ap-northeast-1:123456789012:certificate/zzzz

5.3 mutual TLS(mTLS) — ALB 2024 GA

mutual TLSの仕組み

通常のTLSはサーバー証明書によるサーバー認証のみです。mutual TLS(mTLS)はクライアントも証明書を提示し、サーバー側がクライアントを認証する双方向認証です。

認証フローは以下の通りです。

1. クライアントがTLSハンドシェイクを開始します
2. ALBがサーバー証明書を提示し、クライアント証明書を要求します
3. クライアントが自身の証明書と秘密鍵で署名したハンドシェイクデータを送信します
4. ALBがTrust Store(信頼するCA証明書チェーン)を使ってクライアント証明書を検証します
5. 検証成功時のみTLSセッションを確立します
6. ALBがクライアント証明書の情報(Subject/SAN/証明書PEM等)をHTTPヘッダでターゲットへプロキシします

ALBでのmTLS設定手順

mTLSの設定はリスナー単位で行います。設定手順は以下の通りです。

まずTrust Storeを作成します。Trust StoreはクライアントのCA証明書チェーンをS3に配置して作成します。

# CA証明書をS3にアップロード
aws s3 cp ca-cert.pem s3://my-trust-store-bucket/ca-cert.pem

# Trust Store作成
aws elbv2 create-trust-store \
  --name my-trust-store \
  --ca-certificates-bundle-s3-bucket my-trust-store-bucket \
  --ca-certificates-bundle-s3-key ca-cert.pem

次にHTTPSリスナーのmTLS設定を有効にします。

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/xxx \
  --mutual-authentication \
 Mode=verify,TrustStoreArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:truststore/my-trust-store/ttttt,IgnoreClientCertificateExpiry=false

Modeにはverify(厳格な証明書検証)またはpassthrough(証明書をバックエンドへそのまま転送)を指定できます。

ALBはクライアント証明書の情報を以下のHTTPヘッダでターゲットへ渡します。

ターゲット側ではx-amzn-mtls-clientcert-subjectヘッダーを参照してクライアントの識別子を取得できます。

ユースケース

mTLSが特に有効なユースケースは以下の通りです。

• B2B API: 取引先システムを証明書で特定し不正アクセスを排除します
• 金融/医療系サービス: PCI DSS、HIPAAなどコンプライアンス要件でmTLSを求められる場合があります
• IoTデバイス管理: デバイスごとに証明書を発行し、不正デバイスからの接続を拒否します
• 内部マイクロサービス: サービスメッシュ外でもゼロトラスト的な相互認証を実装したい場合に有効です

5.4 WAF統合(AWS WAF)

ALBとAWS WAFの統合

ALBにはAWS WAFのWeb ACLを関連付けることができます。関連付けると、ALBへのリクエストがWeb ACLのルールで評価され、ルールにマッチすると許可/ブロック/カスタムレスポンスのいずれかのアクションが実行されます。

# Web ACLをALBに関連付け
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/my-webacl/xxxx \
  --resource-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-alb/yyyy

注意点として、Web ACLはALBと同じリージョンのものを使用します(CloudFront統合はGlobal、ALB統合はRegionalです)。

WAFルールの設定例

ALB統合でよく使われるマネージドルールグループは以下の通りです。

レートベースルールはDDoSの初段緩和として有効です。ただしCloud NATやCDNなど正規のIPアドレスに対して誤ブロックが起きないよう、除外条件(IPSetでの許可リスト)も設定してください。

GWLBとのセキュリティ多層防御の違い

WAF統合とGWLBは役割が異なります。

両者は排他ではなく、ALB+WAFで高速なL7フィルタを行い、GWLB+FWで詳細な通信制御を行うという多層防御も実践されています。

5.5 セキュリティグループ設計

ALBのセキュリティグループ

ALBにはセキュリティグループを1つ以上アタッチします。インターネット向けALBの推奨設定は以下の通りです。

ALBのセキュリティグループ(インバウンド):

ALBのセキュリティグループ(アウトバウンド):

ターゲットのセキュリティグループ設計

ターゲット(EC2/コンテナ)のセキュリティグループはALBからの通信のみを許可します。CIDRではなくALBのセキュリティグループIDを参照することで、ALBを経由しない直接アクセスを防げます。

# ターゲットSGにALB SGからの許可ルールを追加
aws ec2 authorize-security-group-ingress \
  --group-id sg-target0000xxxx \
  --protocol tcp \
  --port 8080 \
  --source-group sg-alb0000xxxx

これにより、ALBをバイパスしてターゲットに直接アクセスするリクエストはSGで拒否されます。

NLBとセキュリティグループ

NLBにはセキュリティグループをアタッチできます(2023年より対応)。ただしNLBはクライアントIPをそのまま保持する(Client IP preservation)ため、ターゲットのSGではNLBのSGではなくクライアントのIPレンジからの通信を許可する必要があります。

Client IP preservationを無効にすると、NLBのIPアドレスからの通信になるため、SGでNLBのサブネットCIDRを許可する方式も使えます。PrivateLink経由のNLBではClient IP preservationは無効です。

NLBのSGとClient IP保持の関係を整理すると以下の通りです。

6. 高度機能・運用・コスト

flowchart LR
 CW["CloudWatch\nメトリクス監視\n(HTTPCode_Target_5XX / TargetResponseTime)"]
 CW -->|エラー率上昇・レイテンシ増大| EVAL["ターゲット評価\n健全性スコア算出\n(ATWアルゴリズム)"]
 EVAL -->|不健全ターゲット検出| REDUCE["重み削減\n不健全ターゲットへの\nトラフィック比率を下げる"]
 EVAL -->|健全ターゲット確認| INCREASE["重み増加\n健全ターゲットへ\nトラフィックを集中"]
 REDUCE --> ROUTE["ルーティング調整\n重みに基づく\nトラフィック再分散"]
 INCREASE --> ROUTE
 ROUTE -->|継続モニタリング| CW

Automatic Target Weights(ATW) — 自動重み付けによる可用性向上

Automatic Target Weights(ATW)はALBの高度なトラフィック制御機能で、2024年にGAとなりました。ターゲットのエラー率を継続的に分析し、重みを自動調整してトラフィックを適切に分散します。

ATWの仕組み

通常のALBはターゲットグループ内のターゲットへ均等にリクエストを分散します。あるターゲットがハードウェアの劣化・メモリリーク・外部依存サービスの遅延などにより、エラーレートが上昇し始めても、ヘルスチェックが通過する限りはトラフィックが送られ続けます。この状態では、ユーザーの一部がエラーレスポンスを受け取り続けるという部分的な障害が発生します。

ATWはこの問題を解消します。ALBがHTTPステータスコード(5xxエラー率)およびTCP/TLSエラー率を測定し、問題のあるターゲットへの重みを自動的に下げて、正常なターゲットへのトラフィックを増やします。エラー率が改善すると重みは元に戻ります。ヘルスチェックが通過していてもパフォーマンスが低下しているターゲットを検出できる点が、従来のヘルスチェックとの大きな違いです。

ATWの設定

ATWはターゲットグループ単位で有効化します。

# ATWを有効化
aws elbv2 modify-target-group-attributes--target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-tg/xxxx--attributes Key=load_balancing.algorithm.type,Value=weighted_random Key=load_balancing.algorithm.anomaly_mitigation,Value=on

ATWを有効にするにはweighted_randomアルゴリズムを選択し、anomaly_mitigationをオンにします。デフォルトのround_robinアルゴリズムではATWは動作しません。

ATWが動作している場合、CloudWatchのAnomalousHostCountメトリクスで異常と判定されたターゲット数を確認できます。MitigatedHostCountは現在ATWにより重みを下げられているターゲット数を示します。これらのメトリクスをアラームに設定することで、部分障害の発生を即座に検知できます。

ATWの適用場面

ATWが特に有効なのは、ヘルスチェックエンドポイントが正常でもアプリケーションの一部が劣化しているケースです。例えば、データベースのコネクションプールが枯渇しつつあるインスタンスや、特定のAPIパスのみ遅延しているマイクロサービスなど、部分的な障害はヘルスチェックでは検知できないことが多くあります。ATWはアプリケーションレイヤーのエラーレートを直接観測するため、このような微妙な劣化を検出して影響を最小化します。

Target Optimizer — 同時実行数の厳格制御

Target Optimizerは2024年に追加されたALBの機能で、ターゲットへの最大同時リクエスト数(Maximum Inflight Requests)を設定し、バックエンドの過負荷を防ぎます。

Target Optimizerの仕組み

従来のALBはターゲットの処理能力を超えるリクエストを送信し続ける場合がありました。バックエンドがスレッドプールやコネクションプールの上限に達すると、レスポンスタイムが急増してサービス品質が低下します。Target Optimizerはターゲットごとに同時処理リクエスト数の上限を設定し、上限を超えるリクエストは待機キューに保留するか、503を返す挙動を取ります。

最小値は1から設定でき、1に設定するとシリアル処理を強制できます。通常は適切な同時実行数の上限(例えば100〜500)に設定してバックエンドを保護します。

# Target Optimizerの設定
aws elbv2 modify-target-group-attributes--target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-tg/xxxx--attributes Key=target_group_health.unhealthy_state_routing.minimum_healthy_targets.count,Value=1

CloudWatchのTargetTLSNegotiationErrorCountやRequestCountPerTargetメトリクスとTarget Optimizerを組み合わせることで、バックエンドの処理能力に合わせたトラフィック制御が可能です。

クロスゾーン負荷分散

クロスゾーン負荷分散はALBとNLBで既定の動作が異なります。この差異を理解していないと、AZ間でトラフィックが不均一に分散してしまう問題が発生します。

ALBとNLBの既定の違い

ALBはクロスゾーン負荷分散が既定で有効であり、AZ間転送コストは発生しません。すべてのターゲットを均等に扱うため、各AZのターゲット数が異なっていても適切に分散されます。

NLBはクロスゾーン負荷分散が既定で無効です。無効の状態では、各AZのNLBノードは同一AZ内のターゲットへのみトラフィックを送ります。あるAZに3台、別のAZに1台のターゲットが存在する場合、後者のAZのターゲットは前者の3倍のトラフィックを受けることになり、AZごとのターゲット数を均等に保つ必要があります。

NLBでクロスゾーン負荷分散を有効にする場合は、AZ間データ転送コストが発生します。高トラフィックな環境ではこのコストが無視できない規模になることがあるため、ターゲット数をAZ間で均等に保つ方がコスト効率の観点では有利な場合もあります。

クロスゾーン負荷分散の変更

# NLBでクロスゾーン負荷分散を有効化
aws elbv2 modify-load-balancer-attributes--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/net/my-nlb/xxxx--attributes Key=load_balancing.cross_zone.enabled,Value=true

コネクションドレイン(登録解除遅延)

コネクションドレインは、ターゲットをターゲットグループから登録解除する際に、既存の接続を安全に処理し終えるための待機時間です。

デプロイ中にターゲットを更新する場合、古いターゲットを登録解除して新しいターゲットへ切り替えます。コネクションドレインを設定することで、古いターゲットは新規リクエストを受け取らなくなりますが、既に処理中のリクエストは完了するまで継続できます。待機時間(DeregistrationDelay)の既定値は300秒で、1〜3600秒の範囲で設定できます。

短い処理時間のAPIサービスなら30〜60秒、長時間処理するバッチ系ならより長い値が適切です。

# コネクションドレイン時間を60秒に設定
aws elbv2 modify-target-group-attributes--target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-tg/xxxx--attributes Key=deregistration_delay.timeout_seconds,Value=60

アクセスログ — S3出力とAthena分析

ELBのアクセスログはS3バケットへ圧縮ファイルとして出力されます。ロードバランサーが処理したすべてのリクエストの詳細が記録されており、トラブルシューティングや監査に活用できます。

アクセスログの有効化

# ALBアクセスログをS3へ出力
aws elbv2 modify-load-balancer-attributes--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-alb/xxxx--attributes Key=access_logs.s3.enabled,Value=true Key=access_logs.s3.bucket,Value=my-access-logs-bucket Key=access_logs.s3.prefix,Value=my-alb

S3バケットポリシーでELBサービスプリンシパル(elasticloadbalancing.amazonaws.com)からのPutObjectを許可する設定が必要です。

アクセスログのフィールド

ALBのアクセスログには以下のフィールドが含まれます。

Athenaによるアクセスログ分析

S3に出力されたアクセスログをAthenaで分析することで、SQLベースのクエリでパフォーマンス問題・エラーパターン・トラフィック傾向を調査できます。

Athenaのテーブル定義例を示します。

CREATE EXTERNAL TABLE IF NOT EXISTS alb_access_logs (
  type string,
  time string,
  elb string,
  client_ip string,
  client_port int,
  target_ip string,
  target_port int,
  request_processing_time double,
  target_processing_time double,
  response_processing_time double,
  elb_status_code int,
  target_status_code string,
  received_bytes bigint,
  sent_bytes bigint,
  request_verb string,
  request_url string,
  request_proto string,
  user_agent string,
  ssl_cipher string,
  ssl_protocol string,
  target_group_arn string,
  trace_id string,
  domain_name string,
  chosen_cert_arn string,
  matched_rule_priority string,
  request_creation_time string,
  actions_executed string,
  redirect_url string,
  lambda_error_reason string,
  target_port_list string,
  target_status_code_list string,
  classification string,
  classification_reason string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '1',
  'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) "([^ ]*) (.*) (- |[^ ]*)" "([^"]*)" ([A-Z0-9-_]+) ([A-Za-z0-9.-]*) ([^ ]*) "([^"]*)" "([^"]*)" "([^"]*)" ([-.0-9]*) ([^ ]*) "([^"]*)" "([^"]*)" "([^ ]*)" "([^\s]+?)" "([^\s]+)" "([^ ]*)" "([^ ]*)"'
)
LOCATION 's3://my-access-logs-bucket/my-alb/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/';

代表的な分析クエリを示します。

-- 5xxエラーの多いターゲットIPを集計
SELECT target_ip, COUNT(*) AS error_count
FROM alb_access_logs
WHERE elb_status_code >= 500
  AND time LIKE '2026-06-09%'
GROUP BY target_ip
ORDER BY error_count DESC
LIMIT 20;

-- レイテンシが高いリクエストを抽出
SELECT time, request_url, target_processing_time, elb_status_code
FROM alb_access_logs
WHERE target_processing_time > 5.0
  AND time LIKE '2026-06-09%'
ORDER BY target_processing_time DESC
LIMIT 50;

CloudWatch監視 — 主要メトリクス

ALBとNLBのCloudWatchメトリクスを監視することで、ロードバランサーの健全性・パフォーマンス・コストを把握できます。

CloudWatchアラームでUnHealthyHostCount >= 1を設定しておくことが最も重要です。ターゲットが1台でもunhealthyになった時点でSNS通知や自動スケールアウトをトリガーすることで、障害の影響を最小化できます。

コスト構造 — LCU(Load Balancer Capacity Unit)

ELBのコストは時間料金と処理量に基づくLCU料金で構成されます。LCUはELBが処理するトラフィック量を表す独自単位で、コスト最適化の核心です。

LCUの構成要素

ALBのLCUは以下の4つの次元のうち最大値で計算されます。1時間当たりで評価し、最も消費した次元の値が課金対象となります。

計算例: ALBが1時間に以下のトラフィックを処理した場合

• 新規接続: 50/秒 → 50/25 = 2 LCU
• アクティブ接続: 9,000/分 → 9,000/3,000 = 3 LCU
• 処理バイト: 2 GB/時 → 2/1 = 2 LCU
• ルール評価: 500/秒 → 500/1,000 = 0.5 LCU

最大値は3 LCUとなり、3 LCU × 時間単価で課金されます。

ALBとNLBのコスト比較

ALBとNLBはLCUの計算基準が異なります。HTTPリクエスト量が多くルール評価数も増えるワークロードではALBのLCUが上昇しやすい一方、長時間接続の多いワークロード(WebSocket・ゲームサーバー等)ではNLBのアクティブ接続LCUが効率的です。

TCPの大量新規接続が多いワークロードでは、NLBは1LCU=800新規接続/秒とALBの32倍の効率でカウントされます。同じトラフィック量でもNLBの方がLCUコストを低く抑えられる場合があります。

コスト最適化のTips

ATWでターゲットの利用効率を上げる: 問題ターゲットへの無駄なリクエストを減らすことで、エラー再試行によるリクエスト数の増加を抑えられます。

クロスゾーン負荷分散とコスト: ALBはクロスゾーン負荷分散でのAZ間転送コストが発生しません。NLBとGWLBでクロスゾーンを有効にすると、データ転送コストが追加されます。
高トラフィック環境ではAZごとにターゲット数を均等化してクロスゾーンを無効に保つ方が、コスト面で有利な場合もあります。

アイドル接続のタイムアウト調整: ALBのアイドル接続タイムアウト(既定60秒)を短縮することで、長時間保持される接続数を減らしアクティブ接続LCUを抑えられます。ただし短すぎるとクライアントへのコネクションリセットが増えるため、アプリケーションの特性に合わせて調整します。

ルール数の最適化: ALBのルール評価LCUはターゲットグループへ転送されたルール数の総評価回数で計算されます。デフォルトルールのみで処理できるトラフィックを増やし、複雑なルール評価の対象を絞ることでコストを削減できます。

Savings Plansは対象外: ELBのLCU料金は現時点でCompute Savings Plansの対象外です。EC2インスタンスとは異なりLCUの割引予約はないため、コスト最適化はトラフィックパターンの改善(上記Tips)が中心となります。

7. 実戦統合パターン — ALB/NLB/GWLB選定と既存サービス統合

flowchart TD
 START(["ワークロード要件確認"])
 START --> Q1{"L7制御が必要?\n(URL/ホスト/ヘッダ\nルーティング・認証・WAF統合)"}
 Q1 -->|Yes| ALB["Application Load Balancer\n(ALB)\nHTTP/HTTPS/gRPC\nL7コンテンツベースルーティング"]
 Q1 -->|No| Q2{"超低遅延・固定IP\nが必要?\n(ゲーム/IoT/金融/データストリーム)"}
 Q2 -->|Yes| NLB["Network Load Balancer\n(NLB)\nTCP/UDP/TLS L4\n静的IP・PrivateLink対応"]
 Q2 -->|No| Q3{"セキュリティアプライアンス\nをインライン挿入?\n(Firewall/IDS/DPI)"}
 Q3 -->|Yes| GWLB["Gateway Load Balancer\n(GWLB)\nL3 GENEVEカプセル化\n集中インスペクション"]
 Q3 -->|No| NLB2["Network Load Balancer\n(NLB)\nTCP/UDPベースの\n汎用L4負荷分散"]

ここではALB・NLB・GWLBの選定ロジックと、EKS・ECS・CloudFront・Auto Scalingとの統合設計パターンを解説します。各AWSサービスはロードバランサーと連携する際にターゲットグループを仲介点としており、選定したロードバランサーの種類によって統合方法が変わります。

ロードバランサーの選定フロー

最初の判断軸はプロトコルです。HTTP/HTTPSを扱うなら原則ALBを選びます。TCP/UDP/TLSの場合はNLBが候補となり、サードパーティのセキュリティアプライアンスを透過的に挿入する必要があればGWLBとなります。

ステップ1 — プロトコルはHTTP/HTTPSか

HTTP/HTTPSのリクエストを扱い、パス・ホスト・ヘッダ・メソッドによる振り分けや認証連携が必要なら ALB を選びます。WebアプリケーションのフロントエンドAPIやマイクロサービスの内部API、Lambda関数との統合など、HTTP/HTTPSが前提のユースケースはほぼALBで対応できます。

ステップ2 — 超低遅延・静的IPが必要か

TCP/UDP通信でマイクロ秒レベルの低レイテンシが必要、あるいはElastic IPで送信元IPを固定したい場合は NLB を選びます。PrivateLinkのバックエンドとしての利用もNLB必須です。

ステップ3 — サードパーティアプライアンスの挿入が必要か

トラフィックをファイアウォール・IDS/IPS・ディープパケットインスペクションアプライアンスへ透過的に通過させる必要があるなら GWLB を選びます。GENEVEカプセル化でアプライアンスVPCを経由させ、検査後にトラフィックを元の経路へ戻します。

組み合わせパターン:
– CloudFront → ALB: エッジキャッシュとL7ルーティングの組み合わせ
– ALB → NLB(PrivateLink): 外部はALBで受け、内部サービスへPrivateLink経由でルーティング
– GWLB → ALB: セキュリティ検査後にALBで振り分けるインライン構成

EKS統合 — AWS Load Balancer Controller

EKS上でALBやNLBを使うにはAWS Load Balancer Controllerをクラスターにインストールします。このコントローラーはKubernetesのIngressリソースとServiceリソースを監視し、ALBまたはNLBを自動プロビジョニングします。

インストールにはhelmを使います:

helm repo add eks https://aws.github.io/eks-charts
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  --set clusterName=my-cluster \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  -n kube-system

コントローラーにはIAMロール(IRSA: IAM Roles for Service Accounts)が必要です。必要なポリシーはAWSが公式に提供しています。

ALBをIngressとして使う場合のマニフェスト例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
 kubernetes.io/ingress.class: alb
 alb.ingress.kubernetes.io/scheme: internet-facing
 alb.ingress.kubernetes.io/target-type: ip
 alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
 alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
spec:
  rules:
  - http:
paths:
- path: /api
  pathType: Prefix
  backend:
 service:
name: api-service
port:
  number: 8080

target-type: ipを指定するとPodのIPが直接ターゲットグループに登録されます。PodのスケールアウトとスケールインはKubernetesが管理し、コントローラーがターゲットグループへの登録・解除を自動で行います。

NLBをServiceとして使う場合のアノテーション例:

apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  annotations:
 service.beta.kubernetes.io/aws-load-balancer-type: external
 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
 service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  type: LoadBalancer
  ports:
  - port: 443
 targetPort: 8443
 protocol: TCP

EKSとELBの統合で注意すべき点:
– FargateノードのEKS PodはALBのIPターゲットのみ対応し、インスタンスターゲットは使えません
– Podが終了する際はterminationGracePeriodSecondsとターゲットグループのderegistration_delay.timeout_secondsを合わせて設定し、接続のドレインを確実に行います
– マルチAZ配置のターゲットグループではクロスゾーン負荷分散の設定を確認します

ECS/Fargate統合 — タスクのターゲットグループ登録

ECSサービスにロードバランサーを紐付けると、タスクの起動時に自動でターゲットグループへ登録され、タスク停止時に登録解除されます。

ECSサービス定義のロードバランサー設定:

{
  "loadBalancers": [
 {
"targetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/app-tg/...",
"containerName": "app",
"containerPort": 8080
 }
  ]
}

FargateはタスクごとにプライベートIPが割り当てられるため、ターゲットグループのターゲットタイプをipに設定します。スケールアウト時には新しいタスクのIPがターゲットグループに追加され、スケールイン時にはConnection Draining(登録解除遅延)が完了してからタスクが停止します。

ローリングアップデート時の動作:
– ALBのヘルスチェックが成功すると新タスクへのトラフィックが開始されます
– minimumHealthyPercentとmaximumPercentでアップデート中のタスク数を制御します
– deregistrationDelayはアクティブな接続を待機する最大時間で、この時間内に接続が終了しない場合でもタイムアウトでタスクが停止します

ECSのBlue/Greenデプロイ: AWS CodeDeployのECSデプロイタイプとALBを組み合わせます。CodeDeployがALBの本番リスナーとテストリスナーを管理し、BlueとGreenのターゲットグループを切り替えます。テストリスナー(例: 8080番ポート)で新バージョンを事前検証し、問題がなければ本番リスナーを切り替えます。

CloudFront + ALB構成

CloudFrontのオリジンにALBを設定することで、エッジキャッシュとL7ルーティングを組み合わせられます。

主な構成メリット:
– 静的コンテンツはCloudFrontのキャッシュが応答し、ALBへのリクエストが削減されます
– CloudFrontのエッジでWAFやShield Advancedを適用し、オリジンへのDDoSを防ぎます
– CloudFrontが提供するHTTPS(ACM証明書)を使い、ALBとの通信はVPC内部に閉じます

CloudFront経由のみALBにアクセスさせる方法: ALBのリスナールールにカスタムヘッダ条件を追加します。CloudFrontのオリジンリクエストポリシーでカスタムヘッダ(例: X-Origin-Verify: <secret-value>)を追加し、ALBのリスナールールでこのヘッダが存在しないリクエストを403応答に設定します。シークレット値はAWS Secrets Managerで管理し、定期的にローテーションします。

Origin Shieldを有効にすると、CloudFrontのリージョンキャッシュレイヤーが追加され、ALBへのオリジンリクエスト数をさらに削減できます。トラフィック量が多い場合はALBのLCU消費量とAuto Scalingの負荷軽減効果を試算してから設定します。

CloudFront詳細はこちら（Edge/CDN本番運用 Vol1）

Auto Scaling統合

ALBまたはNLBとAuto Scalingグループを組み合わせると、リクエスト数やCPU使用率に応じてEC2インスタンスが自動追加・削除されます。

基本的な接続手順:
1. ターゲットグループを作成(ターゲットタイプ: instance)
2. ALBのリスナーにターゲットグループを紐付け
3. Auto ScalingグループにターゲットグループのARNをアタッチ

スケールアウト時の流れ: Auto Scalingグループが新しいEC2インスタンスを起動 → インスタンスがターゲットグループに登録される → ヘルスチェックが正常と判定したタイミングでトラフィックが流れ始める。

スケールイン時の流れ: Auto ScalingがTerminating状態を選択 → ターゲットグループからインスタンスを登録解除 → Connection Draining(deregistrationDelay秒)の間、進行中の接続を維持 → 設定時間が経過するかすべての接続が終了するとインスタンスが終了。

Connection Drainingの時間設定:

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:...:targetgroup/my-tg/... \
  --attributes Key=deregistration_delay.timeout_seconds,Value=60

デフォルトの300秒はスケールイン速度の低下を招くことがあります。アプリケーションの平均接続保持時間に合わせて60〜120秒に短縮することを検討します。

ALBリクエスト数を指標にしたターゲット追跡スケーリング

Auto Scalingのターゲット追跡ポリシーでALBRequestCountPerTargetを指標に使うと、1インスタンスあたりのリクエスト数が一定値になるようにスケールを自動制御できます。

aws autoscaling put-scaling-policy \
  --policy-name alb-request-tracking \
  --auto-scaling-group-name my-asg \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
 "PredefinedMetricSpecification": {
"PredefinedMetricType": "ALBRequestCountPerTarget",
"ResourceLabel": "app/my-alb/xxxxxxx/targetgroup/my-tg/yyyyyyy"
 },
 "TargetValue": 1000
  }'

ResourceLabelはALBのARNサフィックスとターゲットグループのARNサフィックスを/でつなげた形式です。ALBとターゲットグループが同一アカウント・リージョンに存在する必要があります。

Global Accelerator との組み合わせ

グローバル展開のサービスではALBやNLBの前段にAWS Global Acceleratorを配置します。Global AcceleratorはAnycast IPを2つ提供し、エンドユーザーからの通信をAWSエッジロケーション経由でAWSのプライベートバックボーンを使ってALB/NLBへルーティングします。

組み合わせのメリット:
– エンドユーザーへの低レイテンシ(インターネット経路の最適化)
– 複数リージョンのALB/NLBをひとつのエンドポイントで提供(マルチリージョンフェイルオーバー)
– エンドポイントグループに重みを設定することで、リージョン間トラフィック配分を制御

Global Acceleratorがエンドポイントのヘルスチェック失敗を検知すると、数十秒以内に別リージョンのALB/NLBへトラフィックを切り替えます。DNS変更を待つRoute 53フェイルオーバーとは異なり、IPアドレス変更なしでの切り替えが可能です。

EKSでのALB Ingressはこちら（コンテナ本番運用 Vol3 — EKS）

CloudFrontオリジン統合はこちら（Edge/CDN本番運用 Vol1）

8. つまずきポイント・アンチパターン・まとめ

ELBをプロダクション環境で運用する際の実際のつまずきポイントとアンチパターンを整理します。

8.1 つまずきポイント

① ヘルスチェック設定のミスで正常ターゲットが切り離される

ヘルスチェックパスを/に設定しているケースで、アプリが/に対して301リダイレクトを返すと、成功コードに301を追加していない限りUnhealthyと判定されます。ヘルスチェック専用の軽量エンドポイント(/health)を用意し、成功コードを200に限定するのが安全です。

デプロイ中に一時的にヘルスチェックが失敗するケースも頻発します。デプロイ完了後にアプリが正常化するまでの時間を考慮した異常しきい値の設定が必要です。しきい値を2に設定すると、デプロイ中のごく一時的な失敗でターゲットが急速に切り離されることがあります。

② クロスゾーン負荷分散の既定値の差でAZが偏る

ALBはクロスゾーン負荷分散がデフォルトで有効ですが、NLBはデフォルトで無効です。NLBで有効化していない場合、各AZのノードは同一AZ内のターゲットにのみトラフィックを転送します。AZ間でターゲット数が異なると、ターゲット数の少ないAZへの集中が発生します。

NLBのクロスゾーン負荷分散を有効化する場合は、AZ間データ転送コストが発生することも考慮します。同一AZ内のターゲットを均等に配置するか、コストを許容してクロスゾーンを有効化するかをトレードオフで判断します。

③ LCU課金の理解不足で想定外のコストが発生する

ELBの課金は時間課金に加えてLCU(Load Balancer Capacity Unit)が発生します。LCUは以下の4指標の最大値で計算されます。

WebSocketのような長時間接続を維持するアプリはアクティブ接続数でLCUが高くなります。リスナールール数が多い場合はルール評価数でLCUが増加します。CloudWatchのConsumedLCUsメトリクスで実際の消費量を確認して最適化します。

④ ALBの認証アクションをHTTPリスナーに設定して動作しない

authenticate-oidcとauthenticate-cognitoアクションはHTTPSリスナーにのみ設定できます。HTTPリスナーへ設定しようとするとコンソール・CLIともエラーになります。

認証を導入する場合は、HTTP:80リスナーにHTTPS:443へのリダイレクトルールを設定し、HTTPS:443リスナーに認証アクションを設定する2段階構成が必要です。

⑤ NLBでのクライアントIP保持の挙動を誤認する

NLBはNATを行わずクライアントのIPアドレスをそのまま転送します。バックエンドのEC2インスタンスのセキュリティグループでは、クライアントIPまたはCIDRからの通信を許可する必要があります。

ALBはNATを行うため、バックエンドはALBのセキュリティグループからの通信のみ許可すれば十分です。NLBでALBと同様の設定(ALBからのみ許可)をするとトラフィックがブロックされます。

⑥ ALB mutual TLSで失効チェックを設定せずに本番投入する

ALBのmutual TLS(2024 GA)はクライアント証明書の双方向認証を実現しますが、証明書の失効チェック(CRL/OCSP)を明示的に設定しなければ、秘密鍵が漏洩した証明書でも認証を通過してしまいます。

ACM PCA(Private Certificate Authority)を使う場合は失効設定を有効化します。サードパーティCAの場合はCRLのS3配置とURI設定が必要です。本番投入前に失効チェックの動作を必ず検証します。

⑦ コネクションドレインを未設定でデプロイ時に接続エラーが発生する

ターゲットグループの「登録解除遅延」(コネクションドレイン)を0に設定するか未設定の場合、ローリングデプロイ中にターゲットを急速に切り離すと進行中のリクエストが502エラーになります。

デフォルト値は300秒です。アプリの最大リクエスト処理時間に余裕を加えた値に設定します。例えば最大30秒かかるAPIコールを持つアプリでは60〜90秒を目安とします。

⑧ GWLBのGENEVE戻りトラフィックのルーティングを誤る

GWLBはGENEVE(UDP:6081)でトラフィックをアプライアンスへ転送し、検査後のトラフィックを戻します。この戻りパスのルートテーブル設定を誤ると、インバウンドトラフィックはGWLBE経由で通過するが戻りパスが直接ルーティングされる「非対称ルーティング」になります。

インスペクションVPCのルートテーブルは、すべてのIngress/EgressトラフィックがGWLBEを通過するよう設計します。ルートテーブルの設定ミスは動作確認時には気付きにくく、本番負荷時になって初めて問題が顕在化します。

8.2 アンチパターンと正解

8.3 まとめ — ELBファミリー選定のポイント

Elastic Load BalancingはALB/NLB/GWLBの3種類で、それぞれ異なるレイヤーと用途を担います。

選定の基準:

本番安定のための重要事項:

ヘルスチェックは軽量なエンドポイントで設計し、SLAに合わせた間隔としきい値を設定します。クロスゾーン負荷分散はALBとNLBで既定値が異なる点を必ず確認します。LCUの課金構造を理解してコスト設計に組み込みます。mutual TLSを使用する場合は失効チェックを必ず有効化します。コネクションドレインを適切に設定してゼロダウンタイムデプロイを実現します。

8.4 CloudWatch監視ガイド — 異常を見逃さないメトリクス設計

ELBの健全性と性能を継続的に監視するために、CloudWatchメトリクスのアラームを適切に設定します。

ALB向けの重要メトリクス:

NLB向けの重要メトリクス:

アクセスログ分析 — Athenaを使った障害調査:

ALBのアクセスログはS3に保存でき、Amazon AthenaでSQLクエリ分析が可能です。

-- 5xxエラーのIPとリクエストパスを集計
SELECT
  client_ip,
  request_url,
  COUNT(*) as error_count,
  target_status_code
FROM alb_logs
WHERE elb_status_code LIKE '5%'
  AND day >= '2025/06/01'
GROUP BY client_ip, request_url, target_status_code
ORDER BY error_count DESC
LIMIT 20;

アクセスログの有効化はターゲットグループレベルではなくALBレベルで設定します。ログはS3バケットに5〜15分の遅延で蓄積されるため、リアルタイムの監視にはCloudWatchメトリクスを使います。

複合アラームによる可用性監視:

単一メトリクスではなく複合条件でアラートの精度を上げることができます。例えば「UnHealthyHostCount >= 1 かつ HealthyHostCount <= 2」の複合アラームを設定することで、一部のターゲット障害だけでなく最低健全台数を下回った際にエスカレーションするパターンが効果的です。

8.5 本番チェックリスト

ELBを本番環境へ導入する前に、以下の項目を確認してください。

ALB設定チェック:

• [ ] ヘルスチェックパスは軽量なエンドポイント(/health)を使用しているか
• [ ] ヘルスチェック間隔・しきい値はSLAに合った値か
• [ ] HTTPリスナーにはHTTPSへのリダイレクトルールが設定されているか
• [ ] TLSポリシーはELBSecurityPolicy-TLS13-1-2-2021-06以上か
• [ ] コネクションドレイン(登録解除遅延)が適切に設定されているか
• [ ] CloudWatchアラームがRequestCount・5XX・UnHealthyHostCountに設定されているか
• [ ] アクセスログのS3出力が有効か
• [ ] WAF統合が必要な場合はWeb ACLがアタッチされているか

コスト設計チェック:

• [ ] LCU消費量の見積もりを算出したか
• [ ] クロスゾーン負荷分散の有効/無効とAZ間転送コストを考慮したか
• [ ] ターゲットグループのルール数は最適化されているか

NLB設定チェック:

• [ ] クロスゾーン負荷分散の設定(デフォルトOFF)を意図通りに設定しているか
• [ ] クライアントIPアドレス保持(Client IP preservation)の挙動を理解しているか
• [ ] バックエンドのセキュリティグループにクライアントIPからの通信を許可しているか
• [ ] PrivateLinkサービスとして公開する場合、エンドポイントサービスの設定が正しいか

GWLB設定チェック:

• [ ] GWLBエンドポイント(GLBe)をAZごとに配置しているか
• [ ] ルートテーブルがすべてのトラフィックをGLBe経由に向けているか(非対称ルーティング防止)
• [ ] アプライアンスのコネクションドレインを設定しているか
• [ ] フロースティッキー(5タプル)がアプライアンスのステートフルテーブルと整合しているか

8.6 Vol2以降で扱うトピック

本記事ではELBの基本設計・運用パターンを網羅しました。次のVol2では以下のより高度なトピックを扱います。

• Global Accelerator + ELB統合 — エニーキャストIPによるグローバルレイテンシ最適化
• ELBとService Mesh統合 — App Mesh / Istio連携でのmTLS・トラフィック制御
• マルチリージョンELB設計 — アクティブ-アクティブ / アクティブ-スタンバイの設計パターン
• 高度なLCU最適化 — 接続プーリング・HTTP keepaliveによるLCU削減テクニック
• ELBのコスト分析 — AWS Cost ExplorerによるLCU消費の可視化と削減戦略
• ALB Least Outstanding Requestsアルゴリズム — バックエンドの処理時間が不均等な場合に有効な分散方式
• NLB TLSオフロードの詳細設計 — バックエンドのTLS処理負荷削減とヘルスチェックの組み合わせ
• ELBのアクセスログ高度分析 — Athenaパーティション分割・Glueクローラーを使った大規模ログ管理
• ELBとコンテナオーケストレーション — ECS Service Connect・EKS Gateway API(次世代Ingress)との統合