AWS ALBとNLBの使い分け設計｜aws elbv2コマンドでマルチAZ構成を実装する方法

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWS ALBとNLBの使い分け設計｜aws elbv2コマンドでマルチAZ構成を実装する方法
「AWSのロードバランサー、ALBとNLBのどちらを選べばいいかわからない」
「設定の違いは分かるけど、本番でどう使い分けるのか判断できない」

AWSには複数種類のロードバランサーがあり、構成設計の段階で選択を誤るとパフォーマンス問題やセキュリティリスク、余計なコストにつながります。特にマルチAZ冗長構成を前提にした設計では、レイヤーごとの特性を理解した上でロードバランサーを選ぶことが、システムの安定稼働に直結します。

この記事では、Application Load Balancer（ALB）とNetwork Load Balancer（NLB）の設計上の違いと使い分け基準を、aws elbv2コマンドの実装例を交えて解説します。マルチAZ構成の設定方法、ヘルスチェック設計のベストプラクティス、503エラーなどトラブルシュートの切り分け手順まで実務視点でカバーします。

この記事のポイント

・ALBはL7（HTTP/HTTPS）、NLBはL4（TCP/UDP）で動作する
・パスベースルーティング・WAF連携が必要ならALB一択
・固定IP・低レイテンシ・DB/MQ接続ならNLBが適切
・マルチAZ設定はaws elbv2コマンドで複数サブネットを指定する


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

AWSのロードバランサーは3種類ある

AWSが提供するELB（Elastic Load Balancing）には、現在3種類のロードバランサーがあります。

・ALB（Application Load Balancer）：L7（アプリケーション層）で動作。HTTP/HTTPS/WebSocket/gRPCに対応
・NLB（Network Load Balancer）：L4（トランスポート層）で動作。TCP/UDP/TLSに対応
・GLB（Gateway Load Balancer）：L3（ネットワーク層）で動作。ファイアウォールやIDSなどのネットワークアプライアンスを挿入するための特殊用途

WebアプリケーションやAPIサーバーの設計で主に選択肢になるのはALBとNLBの2種類です。本記事もこの2つに絞って解説します。

AWSコンソールやCLIでロードバランサーを操作する際は、すべてaws elbv2コマンドを使います（旧世代のClassic Load Balancerはaws elbコマンドですが、新規設計では利用しない方がよいです）。

Application Load Balancer（ALB）の設計と適用場面

ALBはHTTPヘッダー・URLパス・ホスト名などのL7情報を見てルーティングを判断できます。Webアプリケーション、REST API、マイクロサービスの振り分けに最も多く使われるロードバランサーです。

ALBが適する典型的な場面を挙げます。

・パスベースルーティング：/api/*はAPIサーバーへ、/static/*はS3やCloudFrontへ振り分ける
・ホストベースルーティング：app.example.comとadmin.example.comを同一ALBで別々のターゲットへ振り分ける
・SSL/TLS終端：ALBでHTTPS終端を行い、バックエンドEC2にはHTTPで転送する（証明書管理をACMに一元化できる）
・AWS WAF統合：WAFルールをALBに適用してSQLインジェクションやXSS攻撃をブロックする
・Amazon Cognito統合：ログインページへのリダイレクトやJWT検証をALBにオフロードする

1. ALBを作成してマルチAZに設定する

ALBのマルチAZ設定は、作成時に--subnetsオプションで複数のアベイラビリティゾーン（AZ）にある各サブネットを指定するだけで完了します。

# ALBを作成（ap-northeast-1a / ap-northeast-1c のマルチAZ構成）
# --subnets に異なるAZのサブネットIDを列挙する
aws elbv2 create-load-balancer \
  --name my-web-alb \
  --type application \
  --subnets subnet-aaa1b2c3 subnet-xxx4y5z6 \
  --security-groups sg-0abcdef0123456789 \
  --scheme internet-facing \
  --ip-address-type ipv4

# 出力例（抜粋）
# LoadBalancers:
#   - DNSName: my-web-alb-1234567890.ap-northeast-1.elb.amazonaws.com
#     State:
#       Code: active
#     AvailabilityZones:
#       - ZoneName: ap-northeast-1a
#         SubnetId: subnet-aaa1b2c3
#       - ZoneName: ap-northeast-1c
#         SubnetId: subnet-xxx4y5z6
ALBにはセキュリティグループ（--security-groups）が必須です。通常、80/tcp（HTTP）と443/tcp（HTTPS）のインバウンドを許可するセキュリティグループを事前に作成しておきます。

2. ターゲットグループとリスナーを設定する

ロードバランサー本体を作成した後、トラフィックの転送先となるターゲットグループと、受け付けるプロトコル・ポートを定義するリスナーを設定します。

# ターゲットグループを作成（ヘルスチェックも同時に設定）
aws elbv2 create-target-group \
  --name my-web-tg \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-01234567abcdef890 \
  --health-check-protocol HTTP \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --target-type instance

# EC2インスタンスをターゲットグループに登録する
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-tg/abcdef1234567890 \
  --targets Id=i-0123456789abcdef0 Id=i-0abcdef1234567890

# HTTPSリスナーを作成（ACM証明書を使用）
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-web-alb/abcdef1234567890 \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/abcd1234-5678-90ab-cdef-example11111 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-tg/abcdef1234567890
ヘルスチェックパスには専用のエンドポイント（例：/health）を設けることを推奨します。ルートパス（/）をヘルスチェックに使うと、アプリの一部だけ壊れた場合に正常と誤判定するリスクがあります。

Network Load Balancer（NLB）の設計と適用場面

NLBはL4で動作するため、HTTPの中身は関知せず、TCPコネクションをそのままターゲットに転送します。HTTPアプリには不向きに見えますが、以下の場面ではNLBが適切な選択になります。

・固定IPが必要な場合：NLBにはEIP（Elastic IP）を割り当てられるため、IPホワイトリストで管理する外部システムとの連携が可能です
・DB・MQへのTCP接続を負荷分散したい場合：PostgreSQL（5432/tcp）やRabbitMQ（5672/tcp）など、HTTPではないプロトコルの負荷分散に使います
・クライアントIPをバックエンドで直接参照したい場合：NLBはX-Forwarded-Forヘッダーを付与しないため、ソースIPがそのまま届きます（ALBはXFFヘッダーで転送するためバックエンドには直接届かない）
・超低レイテンシが必要なケース：NLBはL4のパケット転送なのでALBより処理オーバーヘッドが少ない。ゲームサーバーやIoTデバイスの接続に向いています

1. NLBを作成してマルチAZに設定する


# NLBを作成（マルチAZ構成）
aws elbv2 create-load-balancer \
  --name my-app-nlb \
  --type network \
  --subnets subnet-aaa1b2c3 subnet-xxx4y5z6 \
  --scheme internet-facing

# TCPターゲットグループを作成（例：PostgreSQL 5432/tcp）
aws elbv2 create-target-group \
  --name my-db-tg \
  --protocol TCP \
  --port 5432 \
  --vpc-id vpc-01234567abcdef890 \
  --health-check-protocol TCP \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --target-type instance

# TCPリスナーを作成
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/net/my-app-nlb/abcdef1234567890 \
  --protocol TCP \
  --port 5432 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-db-tg/abcdef1234567890
NLBにはセキュリティグループの設定が不要です（NLBはVPCのセキュリティグループとは独立して動作し、ターゲットEC2のセキュリティグループ側で制御します）。

2. NLBのゾーナルアイソレーションに注意する

NLBにはALBと異なる「ゾーナルアイソレーション（Zonal Isolation）」という特性があります。クライアントが特定のAZのNLBエンドポイントに接続した場合、そのAZのターゲットだけに転送されます。

この挙動はクロスゾーン負荷分散（後述）を有効化することで変更できますが、有効化するとAZをまたぐデータ転送に追加料金が発生します。設計段階で意識しておくポイントです。
ロードバランサーとVPC設計を体系的に習得したい方は、AWSマスターセミナー上級編も合わせてご確認ください。現役エンジニアが設計判断の根拠も含めてハンズオンで解説しています。

ALBとNLBの選定基準まとめ

実務での選定は次の観点で判断します。
比較項目 ALB NLB
動作レイヤー L7（HTTP/HTTPS） L4（TCP/UDP/TLS）
対応プロトコル HTTP・HTTPS・WebSocket・gRPC TCP・UDP・TLS
固定IP なし（DNS名のみ） あり（EIP割り当て可）
パスベースルーティング あり なし
AWS WAF統合 あり なし
Cognito認証 あり なし
セキュリティグループ 必須 不要
クライアントIP保持 X-Forwarded-Forヘッダーで取得 ソースIPが直接届く
主なユースケース WebアプリAPI・マイクロサービス DB・MQ・ゲーム・IoT
「HTTPSのWebアプリを作る→ALB」「DBやMQをL4で負荷分散する→NLB」が基本判断軸です。

ヘルスチェック設計のベストプラクティス

ロードバランサーが「このターゲットは生きているか」を判断するのがヘルスチェックです。設定が甘いと不正確な判定が起こり、障害時に正常サーバーへの切り替えが遅れます。

1. ヘルスチェック間隔と閾値の設計


# 現在のターゲットグループのヘルスチェック設定を確認する
aws elbv2 describe-target-groups \
  --target-group-arns arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-tg/abcdef1234567890

# ヘルスチェック設定を変更する
aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-tg/abcdef1234567890 \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --health-check-timeout-seconds 5

# ターゲットの現在のヘルス状態を確認する
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-tg/abcdef1234567890

# 出力例（正常）
# TargetHealthDescriptions:
#   - Target:
#       Id: i-0123456789abcdef0
#       Port: 80
#     TargetHealth:
#       State: healthy
#   - Target:
#       Id: i-0abcdef1234567890
#       Port: 80
#     TargetHealth:
#       State: healthy
設計の目安としては以下の値を採用します。

・interval（チェック間隔）：30秒。5秒にすると障害検知は速くなるが、バックエンドへのリクエスト頻度が増す
・healthy_threshold：2回連続正常でHealthy判定。デフォルト5から下げると障害回復後の復帰が速くなる
・unhealthy_threshold：3回連続失敗でUnhealthy判定。2回だと一時的なレスポンス遅延でも外れてしまうリスクがある
・health-check-path：/healthなどの専用エンドポイントを用意し、ステータスコード200を返すように実装する。DBへの疎通確認を含めると精度が上がる

クロスゾーン負荷分散の設計と料金への影響

クロスゾーン負荷分散（Cross-Zone Load Balancing）は、リクエストをすべてのAZのターゲットに均等に分散する機能です。

1. ALBとNLBの挙動の違い

ALBはデフォルトでクロスゾーン負荷分散が有効です（追加料金なし）。
NLBはデフォルトで無効です（有効化するとAZをまたぐデータ転送に料金が発生します）。

# ロードバランサーのクロスゾーン設定を確認する
aws elbv2 describe-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/net/my-app-nlb/abcdef1234567890

# 出力例（NLBのデフォルト）
# Attributes:
#   - Key: load_balancing.cross_zone.enabled
#     Value: "false"

# NLBのクロスゾーン負荷分散を有効化する
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/net/my-app-nlb/abcdef1234567890 \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true
各AZのEC2台数が均等でない場合（1aに2台・1cに1台など）、クロスゾーンを有効にするとリクエストが均等になり、台数が少ないAZのEC2が過負荷になるリスクを回避できます。ただし各AZを同台数で運用するのが前提であれば、クロスゾーンなしでも問題ありません。

トラブルシュート｜503・502・504エラーの切り分け手順

ロードバランサー経由でエラーが返る場合の切り分け手順をまとめます。

1. 503 Service Unavailable の対処

利用可能なターゲットが1台もない状態です。すべてのEC2がUnhealthyになっている可能性があります。

# ターゲットのヘルス状態を確認する
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-tg/abcdef1234567890

# 出力例（Unhealthy）
# TargetHealthDescriptions:
#   - Target:
#       Id: i-0123456789abcdef0
#     TargetHealth:
#       State: unhealthy
#       Reason: Target.FailedHealthChecks
#       Description: Health checks failed with these codes: [404]

# PC（検証機）からターゲットEC2のヘルスチェックエンドポイントを直接確認する
curl -v http://10.0.1.10/health
対処は以下の順序で確認します。

・EC2側のアプリが起動しているか確認する（systemctl status アプリ名）
・セキュリティグループがALB/NLBからのインバウンドを許可しているか確認する
・ヘルスチェックパスが正しいステータスコード（200）を返しているか確認する
・ss・lsofコマンドでLinuxのポート確認を行い、ターゲットが指定ポートでLISTENしているか確認する

2. 502 Bad Gateway の対処

ターゲットEC2はHealthyだが、HTTPレスポンスが不正な場合に発生します。アプリのクラッシュ、タイムアウト、不正なHTTPレスポンス（ヘッダーなし等）が原因です。ALBのアクセスログをS3に出力する設定を事前に行っておくと、502発生時の原因究明が格段に速くなります。

# ALBアクセスログを有効化する（S3バケットを事前に作成しておく）
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-web-alb/abcdef1234567890 \
  --attributes \
    Key=access_logs.s3.enabled,Value=true \
    Key=access_logs.s3.bucket,Value=my-alb-access-logs \
    Key=access_logs.s3.prefix,Value=alb

# アクセスログから502エラーの詳細を確認する
# ログフォーマット例（抜粋・502エラー行）
# https 2026-08-14T10:30:01.123456Z app/my-web-alb/xxxx 203.0.113.1:54321 10.0.1.10:80 0.001 0.005 - 502 502 0 0 "GET https://example.com/api/user HTTP/1.1" ...

3. 504 Gateway Timeout の対処

ターゲットが規定時間内にレスポンスを返せなかった場合に発生します。ALBのデフォルトのアイドルタイムアウトは60秒です。バッチ処理など時間がかかる処理をALBの後段に置く場合は値を引き上げます。

# ALBのアイドルタイムアウトを変更する（秒単位・最大4000秒）
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-web-alb/abcdef1234567890 \
  --attributes Key=idle_timeout.timeout_seconds,Value=120

# 変更結果を確認する
aws elbv2 describe-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-web-alb/abcdef1234567890 \
  | grep idle_timeout

ALBとNLBの選定判断は、AWSの「設計の型」を知っていれば迷わない

ロードバランサーの種類は調べれば分かります。でも「なぜこのシステムにALBを選ぶのか」「NLBのゾーナルアイソレーションをどう設計に織り込むか」を説明できますか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、AWSを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

本記事のまとめ

ALBとNLBの使い分けとマルチAZ実装のポイントをまとめます。
やりたいこと コマンド
ALBを作成してマルチAZに設定する aws elbv2 create-load-balancer --type application --subnets サブネットA サブネットB --security-groups SG_ID
NLBを作成してマルチAZに設定する aws elbv2 create-load-balancer --type network --subnets サブネットA サブネットB
ターゲットグループを作成する aws elbv2 create-target-group --protocol HTTP --port 80 --vpc-id VPC_ID
ターゲットのヘルス状態を確認する aws elbv2 describe-target-health --target-group-arn ARN
クロスゾーン負荷分散の設定を確認・変更する aws elbv2 modify-load-balancer-attributes --attributes Key=load_balancing.cross_zone.enabled,Value=true
ALBのアイドルタイムアウトを変更する aws elbv2 modify-load-balancer-attributes --attributes Key=idle_timeout.timeout_seconds,Value=120
「HTTPSのWebアプリ・マイクロサービス→ALB」「DB・MQ・固定IP要件→NLB」が基本の選定軸です。マルチAZ設定は作成時に異なるAZのサブネットIDを--subnetsに列挙するだけで完了します。503エラーが出たらまずヘルスチェック設定とセキュリティグループを確認し、504が出たらアイドルタイムアウトの値を見直す、という切り分け手順を覚えておくと、障害対応が格段に速くなります。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。