クラウドを複数使っているチームや、AWSからAzureへ移行を検討している場合、Azure Application GatewayとAWS ALB(Application Load Balancer)の違いに迷う場面があります。
この記事では、Azure Application GatewayとAWS ALBをazコマンドとaws elbv2コマンドで構築する手順を並べて比較し、機能ごとの違いと選定の判断軸を解説します。想定環境はAzure CLI 2.x系とAWS CLI v2です。
この記事のポイント
・Azure Application GatewayはVNet内に配置するL7ロードバランサーでWAF統合が標準で選べる
・AWS ALBはターゲットグループとリスナーの組み合わせでルーティングを制御する
・azとaws elbv2コマンドで構築手順を並べると概念の対応関係が分かりやすくなる
・選定の軸はクラウドの主軸・WAF要否・コンテナ連携の3点で判断できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜL7ロードバランサーが必要なのか
Webアプリケーションを公開するとき、L4ロードバランサー(TCPレベル)では対処できない場面があります。URLのパスに基づいてバックエンドを切り替えたい、特定のホスト名だけ別サーバーへ転送したい、SSLの終端を一か所に集めたい。こうした要件には、HTTPを理解できるL7ロードバランサーが必要です。
AzureにはApplication Gateway(AG)、AWSにはApplication Load Balancer(ALB)という専用のL7サービスがあります。
どちらもHTTPS終端、パスベースルーティング、ヘルスチェックを持ちますが、設定の単位と考え方が異なります。
典型的なつまずきとして、AWSで「ターゲットグループ→ロードバランサー→リスナー」の順で作成していた担当者が、Azureに移行したときに「バックエンドプール・リスナー・ルーティングルールをGateway内で一括設定する」設計に戸惑うケースがあります。
Azure Application Gatewayの構築手順
Azure Application GatewayはVNet内のサブネットに配置します。サブネットはApplication Gateway専用にする必要があります。1. リソースグループとVNetを準備する
まずリソースグループとVNetを作成します。# リソースグループを作成する az group create \ --name rg-agw-demo \ --location japaneast # VNetとApplication Gateway用サブネットを作成する az network vnet create \ --resource-group rg-agw-demo \ --name vnet-agw-demo \ --address-prefix 10.0.0.0/16 \ --subnet-name snet-agw \ --subnet-prefix 10.0.1.0/24 # バックエンド用サブネットを追加する az network vnet subnet create \ --resource-group rg-agw-demo \ --vnet-name vnet-agw-demo \ --name snet-backend \ --address-prefix 10.0.2.0/24
2. Application Gatewayを作成する
Application GatewayにはStandard_v2 SKUを使います。パブリックIPを用意してからGatewayを作成します。# パブリックIPを作成する az network public-ip create \ --resource-group rg-agw-demo \ --name pip-agw-demo \ --sku Standard \ --allocation-method Static # Application Gatewayを作成する az network application-gateway create \ --resource-group rg-agw-demo \ --name agw-demo \ --location japaneast \ --sku Standard_v2 \ --capacity 1 \ --vnet-name vnet-agw-demo \ --subnet snet-agw \ --public-ip-address pip-agw-demo \ --http-settings-port 80 \ --http-settings-protocol Http \ --frontend-port 80 # 出力例(環境により異なります) # { # "applicationGateway": { # "name": "agw-demo", # "provisioningState": "Succeeded", # "sku": {"name": "Standard_v2", "tier": "Standard_v2"} # } # }
作成後はprovisioningStateが「Succeeded」になるまでaz network application-gateway showで状態を確認します。
3. バックエンドプールとルーティングルールを設定する
Application Gatewayのバックエンドはバックエンドプールに登録します。# バックエンドプールにサーバーのIPを登録する az network application-gateway address-pool create \ --resource-group rg-agw-demo \ --gateway-name agw-demo \ --name pool-webservers \ --servers 10.0.2.10 10.0.2.11 # 出力例(環境により異なります) # { # "backendAddresses": [ # {"ipAddress": "10.0.2.10"}, # {"ipAddress": "10.0.2.11"} # ], # "name": "pool-webservers", # "provisioningState": "Succeeded" # }
カスタムドメインを設定するときは、DNSのCNAMEレコードをApplication GatewayのパブリックIPに向ける必要があります(Linux DNS 設定の基本)。
AWS ALBの構築手順
AWS ALBはターゲットグループ、ロードバランサー、リスナーの3つを個別に作成して組み合わせます。1. ターゲットグループを作成する
ALBのバックエンドはターゲットグループで管理します。ヘルスチェックの設定もここで行います。# ターゲットグループを作成する aws elbv2 create-target-group \ --name tg-webservers \ --protocol HTTP \ --port 80 \ --vpc-id vpc-xxxxxxxx \ --health-check-protocol HTTP \ --health-check-path /health \ --health-check-interval-seconds 30 # 出力例(環境により異なります) # { # "TargetGroups": [{ # "TargetGroupName": "tg-webservers", # "Protocol": "HTTP", # "Port": 80, # "HealthCheckPath": "/health", # "TargetType": "instance" # }] # }
2. ALBを作成する
ALBはマルチAZ構成にするため、サブネットを2つ以上指定します。# ALBを作成する(マルチAZ構成にするためサブネットを2つ指定する) aws elbv2 create-load-balancer \ --name alb-demo \ --subnets subnet-aaa111 subnet-bbb222 \ --security-groups sg-xxxxxxxx \ --scheme internet-facing \ --type application # 出力例(環境により異なります) # { # "LoadBalancers": [{ # "LoadBalancerName": "alb-demo", # "DNSName": "alb-demo-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com", # "State": {"Code": "provisioning"} # }] # }
3. HTTPSリスナーを設定する
AWSではSSL証明書をACM(AWS Certificate Manager)で管理します。# HTTPSリスナーを作成する(証明書はACMのARNを指定する) aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT:loadbalancer/app/alb-demo/xxx \ --protocol HTTPS \ --port 443 \ --certificates CertificateArn=arn:aws:acm:REGION:ACCOUNT:certificate/xxx \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:REGION:ACCOUNT:targetgroup/tg-webservers/xxx # HTTPをHTTPSへリダイレクトするリスナーを追加する aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT:loadbalancer/app/alb-demo/xxx \ --protocol HTTP \ --port 80 \ --default-actions Type=redirect,RedirectConfig="{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}"
Azureでは証明書をKey Vaultに保管してApplication Gatewayと連携させるか、PFX形式で直接アップロードする方法があります。
Azureを中心にクラウドインフラを運用するチームは、Azure Linux実践講座でAzureのネットワーク設計を体系的に学ぶ方法もあります。
機能別比較:ルーティング・SSL・WAF・ヘルスチェック
| 機能 | Azure Application Gateway | AWS ALB |
|---|---|---|
| パスベースルーティング | URLパスマップで設定。正規表現も可(v2) | リスナールールのcondition/actionで設定 |
| ホストベースルーティング | マルチサイトリスナーで対応 | リスナールールのhost-headerで対応 |
| SSL終端 | Key VaultまたはPFX証明書を使用 | ACMの証明書を使用(自動更新) |
| WAF統合 | WAF_v2 SKUを選択するだけで有効化できる | AWS WAFを別途アタッチする |
| ヘルスチェック | HTTPプローブ(カスタムパス設定可) | HTTPヘルスチェック(カスタムパス・コード設定可) |
| コンテナ連携 | AKSのIngress Controllerとして利用可(AGIC) | ECSサービスのターゲットグループに直接登録可 |
| 課金モデル | 固定時間料金+処理データ量 | 固定時間料金+LCU(処理容量単位) |
どちらを選ぶべきか:判断の軸
迷ったときは次の3点で判断するのが確実です。・メインのクラウドがAzureかAWSか:VNetやVPCとの統合を考えると、メインのクラウドに合わせる方が運用が楽になります
・WAFが必要かどうか:AzureはWAF_v2 SKUを選ぶだけで統合WAFが使えます。AWSではWAFを別途有効化する手順が増えます
・コンテナ(AKS・ECS)との連携:AKSを使うならApplication Gateway Ingress Controller(AGIC)が選択肢に入ります。ECSを使うならALBのターゲットグループ直接登録が標準設計です
マルチクラウドでL7ロードバランサーを使い分ける場合、各クラウド内でCNAMEとAレコードの扱いが異なる点を事前に整理しておくと、後から困らなくなります。
よくあるつまずきと対処法
1. Application Gatewayのプロビジョニングに時間がかかる
Application Gatewayは作成完了まで5~10分かかります。az network application-gateway showでprovisioningStateを確認し、「Succeeded」になるまで待ちます。
# プロビジョニング状態を確認する az network application-gateway show \ --resource-group rg-agw-demo \ --name agw-demo \ --query provisioningState \ --output tsv # 出力例(環境により異なります) # Succeeded
2. ALBのヘルスチェックがUnhealthyになる
ヘルスチェックのパスやポートが間違っているケースが多くあります。aws elbv2 describe-target-healthでターゲットの状態を確認します。
# ターゲットのヘルス状態を確認する aws elbv2 describe-target-health \ --target-group-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT:targetgroup/tg-webservers/xxx # 出力例(環境により異なります) # { # "TargetHealthDescriptions": [{ # "Target": {"Id": "i-xxxxxxxxx", "Port": 80}, # "TargetHealth": { # "State": "healthy" # } # }] # }
3. パスベースルーティングが意図どおりに動かない
Application Gatewayのパスマップでは、より具体的なパスのルールが優先されます。「/api/*」と「/*」を両方設定したとき、「/api/users」は「/api/*」のルールで処理されます。
ALBでも同様に、より具体的な条件のルールに高い優先度を設定する必要があります。
本記事のまとめ
| 項目 | Azure Application Gateway | AWS ALB |
|---|---|---|
| 作成コマンド | az network application-gateway create |
aws elbv2 create-load-balancer |
| バックエンド登録 | az network application-gateway address-pool create |
aws elbv2 create-target-group |
| ルーティング設定 | URLパスマップとルーティングルール | リスナーのcondition/action |
| WAF統合 | WAF_v2 SKU選択で即時有効 | AWS WAFを別途アタッチ |
| SSL証明書 | Key Vault連携またはPFXアップロード | ACMで発行・自動更新 |
| 向いている場面 | Azure中心の構成・WAF統合が必要な場合 | AWS中心の構成・ECS連携が多い場合 |
>>Azure Linux実践講座の詳細はこちら
LinuxとAzureの基礎から体系的に学びたい方は、
>>【初心者向けLinuxセミナー(2日間ハンズオン)】
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Azure仮想ネットワーク作成のCIDRとサブネット割り当てをBicepで構成する手順|アドレス空間の設計手順
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます