AzureアプリケーションゲートウェイとAWS ALBを比較構築|選定基準と設定の違い

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Azure > AzureアプリケーションゲートウェイとAWS ALBを比較構築|選定基準と設定の違い
「AzureとAWSのどちらでL7ロードバランサーを使えばいいのか。」
クラウドを複数使っているチームや、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点で判断できる


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

Application Gatewayはプロビジョニングに5~10分かかります。
作成後は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" # }

リスナーとルーティングルールはaz network application-gateway http-listenerおよびrule createコマンドで追加します。
カスタムドメインを設定するときは、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" # }] # }

バックエンドサーバーのポートが正しく開いているかは、事前にss -tlnpコマンドで確認しておきます(Linux ポート確認の全コマンド)。

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}"

AWSのACMは証明書の発行から自動更新まで無料で行えます。
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連携が多い場合
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
>>Azure Linux実践講座の詳細はこちら

LinuxとAzureの基礎から体系的に学びたい方は、
>>【初心者向けLinuxセミナー(2日間ハンズオン)】

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

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

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

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

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

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

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

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。