こんにちは！クララのクロスボーダービジネスチームです！
中国市場でのWeb展開やクラウド構築にAlibaba Cloudを選ぶ企業が増えてきましたが、「WAFはAWSと同じように使えばOKでしょ？」と思っていませんか？

実はこれ、ちょっとした違いが積み重なると意外にハマるポイントが多いんです。
Alibaba Cloud WAFとAWS WAFは、全体の目的は似ていても、細かい部分で設計や運用の前提が異なります。

この記事では、AWSに慣れた皆さん向けに、Alibaba Cloud WAFの特徴や構成の考え方をやさしく解説します。

Alibaba Cloud WAFとは？AWSとどう違う？

Alibaba Cloud WAF（Web Application Firewall）は、Webアプリケーションへのさまざまな攻撃を防ぐためのセキュリティサービスです。SQLインジェクションやクロスサイトスクリプティング（XSS）、DDoS的なCC攻撃、WebShellアップロードなどに対応しています。

AWSのWAFと同様に、Webセキュリティを高めるための重要なパーツですが、その仕組みや運用モデルは大きく異なります。

AWS WAFとどこが違うの？

AWS WAFはCloudFrontやALBなどに”アタッチする”方式で、インライン型なのが特徴。一方、Alibaba WAFはCNAMEを使ってトラフィックを中継するリバースプロキシ型です。つまり、DNSの書き換えが基本になります。

そして最大の違いはこれ：

AWSでは「どのルールを使うか」をMarketplaceで選び、必要に応じてサードパーティ製のルールセットを購入して拡張できますよね。GuardDutyやManaged Rulesといった仕組みに慣れている方なら、WAFも同じ感覚で運用したくなるはず。

でもAlibabaでは、そのアプローチは通用しません。

Alibaba WAFには「ルールを買う」という発想がなく、すべてAlibaba側が用意したプリセットルール（Loose／Medium／Strict）＋自社開発のシグネチャ＋AIベースの自動最適化ロジックが前提になります。

ではどう運用するのか？というと、

• まずは3段階のプリセットから選ぶ（Mediumが標準）

• 誤検知や攻撃傾向に応じて「ホワイトリスト（除外）」や「ブラックリスト（強制遮断）」をGUIで追加

• トラフィックの挙動を見ながらルールのON/OFFを調整 という 「運用しながらチューニングしていく」形が基本です。

ルールは日々Alibaba側で更新されており、重大なゼロデイ攻撃への対応なども迅速。運用者は基本的に「既存のルールをベースに最小限のカスタマイズを重ねる」ことで高精度な防御を維持できます。

つまり、AWSのように「積極的に設計して強化していく」というよりは、 Alibaba WAFは『信頼されたプリセットをベースに安定運用する』という思想でできているんです。

最初は「選べないなんて不便」と思うかもしれませんが、導入から安定稼働までのスピード感や、運用負荷の低さはかなり魅力的ですよ！

【比較】AWS WAFとAlibaba WAFの違いまとめ

項目	AWS WAF	Alibaba Cloud WAF
デプロイ方式	インライン（ALB/CDNにアタッチ）	リバースプロキシ（CNAME/透過モード）
ルール構成	ACLで柔軟に設計＋Marketplace	プリセット＋GUIカスタム、Marketplaceなし
サードパーティ連携	あり	なし（Alibaba公式のみ）
ログ出力	CloudWatch Logs	Simple Log Service（SLS）経由
ICP登録要件	なし	中国本土リージョンで利用時に必須
費用モデル	リソースごとの従量課金（ACL/ルール/リクエスト）	プラン制＋従量課金（ドメイン数・帯域）

Alibaba WAFの構成方法：こんなに違う！

1. CNAMEでトラフィックをWAFに向ける

Alibaba WAFを使うときは、DNS設定でAlibabaが発行したCNAMEに向けるのが基本です。これにより、ユーザーのトラフィックはAlibabaのWAFを経由してWebサーバへ届く構成になります。

• SSL証明書はAlibaba WAFにアップロードが必要

• DNSを変えるタイミングに注意！

※HTTPSを使用する場合、Alibaba WAFにSSL証明書をアップロードする必要があります。

WAFがユーザーからのリクエストをSSL終端するためで、証明書が未設定だとHTTPS通信は確立されません。

また、WAFからオリジンサーバ（ECSなど）への接続もHTTPSにする場合は、Webサーバ側にも別途証明書が必要になります。

このように、WAF導入時は証明書の二重管理が発生する点にご注意ください。

2. Transparent Proxyモード（Cloud-Native WAF）って何？

Alibaba WAFには、CNAMEを書き換えなくても使える構成もあります。それが “Transparent Proxyモード”、正式には Cloud-Native WAF（WAF 3.0） と呼ばれる方式です。

このモードでは以下のような特徴があります：

• ECSやALB、Kubernetes Ingressなどと内部連携して使う

• DNSを書き換える必要がなく、透過的にトラフィックをWAF経由にできる

• AWS的な「WAFをシステムにアタッチする」構成に近い使い方ができる
  

ただし、このモードはAlibaba Cloud内のリソースに限定されるため、
他社CDNやAlibaba CDNとは連携できません（CDNに使いたい場合はCNAMEモードを選ぶ必要があります）。

AWS的な「透過的に使えるWAF」に近い使い方ができますが、あくまでAlibaba内部の連携が前提です。

3. CDNやロードバランサと一緒に使いたいときは？

Alibaba公式が推奨しているパターンがあります：

CDN + WAF の構成例

[ユーザー] → [CDN] → [WAF (CNAME)] → [ECS/SLB]

CNAMEベースでWAFにリクエストを転送する構成です。ドメインの名前解決をWAFが担う形になるため、DNSまわりの設計やCDNとの整合性に注意が必要です。

 

ALB + WAF（Service Integration モード）

[ユーザー] → [ALB] → [WAF (Transparent)] → [ECS]

リバースプロキシ型ではなく、トラフィックを透過的に通過させる構成です。既存のインフラに組み込みやすく、複数サービスを統合運用する環境では柔軟性が高い方式です。

 

Alibaba Cloudの場合、WAFはCDNより“後段”に配置する構成が前提になります。

一般的なCDNサービス（Cloudflareなど）では「WAF → CDN → Origin」といった構成が可能ですが、Alibaba WAFはCNAME方式のため、「CDN → WAF → Origin」構成が基本です。

「WAF → CDN」のような逆順構成は現在の仕様では非対応ですので、個別要件がある際などは構成設計時にご注意ください。

また、AlibabaのCloud-Native WAF（WAF 3.0）は、ALBやIngressには対応していますが、CDNサービスとは統合できません。

Alibaba WAFを使うときの注意点

中国リージョンで使うならICP登録はマスト！

中国国内でWAFやCDNを使うには、ドメインがICP登録済みである必要があります。
未登録のドメインをWAFに追加しようとすると、設定できないか、自動的に削除されてしまいます。

証明書の二重管理に注意！

WAFにも証明書を登録しないとHTTPS通信ができません。
しかも、WebサーバとWAFの両方に証明書が必要になるため、証明書管理が煩雑になることがあります。

ログはSLS経由。CloudWatchじゃないよ！

WAFの検知ログは、Alibaba CloudのSimple Log Service（SLS）に連携して出力します。
初期状態ではログ出力は無効なので、忘れずに有効化しましょう。

まとめ：中国向けWAFは”設計ごと”見直そう！

Alibaba Cloud WAFは、AWS WAFとは基本的な機能は似ていても、構成や導入の考え方には細かな違いがたくさんあります。

AWSで慣れた構成で考えると、DNSの切り替えや証明書の扱い、ICP登録などでつまずきやすいですが、
逆に言えばそれらを理解して設計すれば、中国国内に強いWAF基盤が構築できるのがAlibaba Cloudの強みです。

クララでは、中国向けWebサイトやクラウドサービスの構成・導入支援も行っています。Alibaba WAFの構成にお悩みの方は、ぜひお気軽にご相談ください！