[2024/08/06 追記] AWS ALB の Private Link のサポートに対する解釈を誤っていましたので、機能面の比較の Private Link の欄を × に修正しました
L7 ロードバランサーは、ざっくりいうと、HTTP の内容(URL や HTTP ヘッダーなど)を利用した高度な負荷分散をできる仕組みです。
Azure の場合は Application Gateway V2(以降、Azure AGW と表記)、AWS の場合は Application Load Balancer(以降、AWS ALB と表記)が該当します。
Azure Application Gateway V1 は廃止されるため、Application Gateway V2 の方を検討することになります。
Azure AGW に Basic SKU が登場(2024/7/25 時点で Public Preview)したことで、改めて気になったので確認してみました。
機能面の比較
項目 | Azure AGW(Standard/WAF) | Azure AGW(Basic) | AWS ALB |
---|---|---|---|
SLA | 99.95%1 | 99.9%1 | 99.99%2 |
SSL 終端 | ○3 | ○ | ○4 |
自動スケーリング | ○3 | ×1 | ○4 |
ゾーン冗長 | ○3 | ○1 | ○4 |
URL ベースのルーティング | ○3 | ○ (構築画面に表示された) | ○5 |
1 つのリスナーで複数サイトのホスティング | ○3 | ○1 | ○6 |
セッションアフィニティ(スティッキーセッション) | ○3 | ○1 | ○4 |
Web ソケットのサポート | ○3 | ○1 | ○4 |
HTTP ヘッダーの書き換え | ○3 | ○1 | ×7 |
URL の書き換え | ○3 | ×1 | × (公式資料が見つからず) |
Private Link | ○3 | ×1 |
|
Private 通信のみの構成 | ○1 | ×1 | ○8 |
Azure AGW Basic の SSL 終端については明確な資料が見つかりませんでしたが、Azure AGW の役割として自明な上、構築画面で「フロントエンド IP の種類」に「パブリック」のみを指定できるので「○」としました。
機能面の Azure AGW の強みとしては、HTTP ヘッダーや URL の書き換えができることです。
GUI を用いて分かりやすく様々な条件で動作するよう設定できるので、柔軟な構成が可能です。
[2024/08/06 追記] また、Azure AGW の場合は Private Link もサポートしています。
ただこの辺りを使用しない場合は、AWS ALB の高い SLA と基本的な機能を持っている面が非常に魅力的ですね。
性能面の比較
項目 | Azure AGW(Standard/WAF) | Azure AGW(Basic) | AWS ALB |
---|---|---|---|
秒間最大接続数 | 62,5001 | 2001 | (数百万の同時接続)4 |
バックエンドプール / ターゲットグループ最大数 | 1001 | 51 | 1009 |
バックエンドプール / ターゲットグループあたりのサーバー最大数 | 1,2001 | 51 | 1,0009 |
CU / LCU あたりの秒間接続数 | 501 | 101 | 2510 |
CU / LCU あたりのスループット | 2.22 Mbps / CU1 | 2.22 Mbps / CU1 | 1 時間あたり 1 GB / LCU11 |
CU / LCU あたりのアクティブな接続 | 2,500 / CU1 | 2,500 / CU1 | 3,000 / LCU(相互 TLS 使用時は 1,500 / LCU)10 |
CU (Capacity Unit, Azure AGW の場合) / LCU (Load Balancer Capacity Units, AWS ALB の場合) あたりのスループットの単位はドキュメントの表記に合わせましたが、ほぼ同じ値と考えて良さそうです。
ただし、AWS ALB で AWS Lambda ターゲットを使用した場合は、1 時間あたり 0.4 GB のスループットになるようです。
秒間接続数に関して Azure AGW Standard は50
なのに対して AWS ALB は25
なので、倍の差がありますね。
その他の個人的に気になるところ
スケーリングの調整可否
Azure AGW の場合、スケーリングについてインスタンスの上限値を設定したり、手動スケールで固定値にすることが可能です。
ちなみにスケール設定の際は「インスタンス」という単位で調整し、1 インスタンス ≒ 10 CU となります。
https://learn.microsoft.com/ja-jp/azure/application-gateway/understanding-pricing#capacity-unit-related-to-instance-count
各インスタンスでは、処理能力の観点から最低 10 容量ユニットが保証されます。 同じインスタンスが、容量ユニットのパラメーターに応じて、トラフィック パターンごとに 10 を超える容量ユニットをサポートする可能性があります。
これに対して AWS ALB の場合は常に自動スケーリングになる認識です。
この観点でいうと、Azure の方がコストコントロールしやすい可能性があります。
料金の違い
料金は変動する可能性があるので注意が必要ですが重要な要素です。
Azure AGW の料金は下記から確認できます。
東日本リージョンの場合、Standard だと固定料金が 1 時間あたり $0.29
、CU あたり 1 時間につき $0.008
ということで、なかなかのお値段です。
HTTP ヘッダーや URL の書き換えもできる機能のリッチさを踏まえると、仕方ない面があるのかもしれません。
この機能に関して Azure ポータルから確認変更する GUI は分かりやすく、個人的に気に入っています。
https://learn.microsoft.com/ja-jp/azure/application-gateway/rewrite-http-headers-portal
https://learn.microsoft.com/ja-jp/azure/application-gateway/rewrite-url-portal
また、現在プレビュー中の Basic は固定料金が 1 時間あたり $0.0326
、CU あたり 1 時間につき $0.0116
ということで、要件に合えばリーズナブルに使えそうです。
こちらに対して AWS ALB の料金は下記から確認できます。
東京リージョンの場合、固定料金が 1 時間あたり $0.0243
、LCU あたり 1 時間につき $0.008
ということで、非常に安いですね!
ただし前述の通り、秒間接続数に差があることと、スケール上限を指定できないので大規模アクセス時のコストコントロールに関して注意が必要です。
-
https://learn.microsoft.com/en-us/azure/application-gateway/overview-v2#sku-types ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24
-
https://learn.microsoft.com/ja-jp/azure/application-gateway/features ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10
-
https://aws.amazon.com/jp/elasticloadbalancing/features/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#http-header-conditions ↩
-
https://aws.amazon.com/jp/blogs/news/new-application-load-balancer-sni/ ↩
-
https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.html ↩
-
https://aws.amazon.com/jp/blogs/news/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/ ↩
-
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-limits.html ↩ ↩2
-
https://aws.amazon.com/jp/elasticloadbalancing/pricing/ ↩ ↩2