Single service comparison

Azure Front Door couples routing, WAF, and acceleration under a single managed resource, while Huawei CDN is a content-acceleration service whose edge security and certificate needs must be composed with WAF and Cloud Certificate Manager (CCM) as separate products. Huawei CDN exposes domain-name configurations, cache rules, and origin settings rather than a backend-pool/routing-rule data model, so Front Door constructs like multiple backend pools with weighted failover and per-rule path matching do not map one-to-one and require manual decomposition across CDN plus ELB and DNS steering.

Front Door's health probes, session affinity, and priority-based global failover are intrinsic to its routing engine; Huawei CDN sits in front of origins and relies on origin pull behavior, cache refresh, and external ELB for backend health and failover. WAF integration is not unified: Huawei WAF is deployed in front of or alongside CDN as a separately purchased and configured service, with its own QPS-tiered editions, whereas Front Door's WAF policy is attached directly to the Front Door resource. Confirm parity for TLS policy, custom rules, bot protection, and geographic controls before cutover.

Operationally, Front Door is configured as one control-plane object via Azure Resource Manager with rule sets for header/query rewrites; Huawei CDN offers its own rule engine and APIs but with different supported conditions and actions, and the global anycast routing behavior is managed by Huawei rather than per-routing-rule. Treat CDN as the closest edge component, not a drop-in equivalent, and validate feature-by-feature parity for control plane, data plane, observability (Cloud Eye versus metrics emitted by Front Door), and certificate lifecycle via CCM.

Start with assessment: inventory every Front Door frontend, routing rule, backend pool, health probe, WAF policy, and TLS certificate, plus expected RPS, bandwidth, and regional origin distribution. Confirm Huawei CDN service-area coverage, supported scenarios (website, file download, on-demand, whole site), and PoP presence for your user geographies, then decide whether CDN alone or a CDN + WAF + CCM (+ ELB for backend health) composition is required for each workload variant.

Recreate configuration in Huawei: add accelerated domains in CDN with matching origin server addresses, replicate cache TTLs and the subset of Front Door rule-set actions that CDN's rule engine supports, and front the same hostnames with WAF policies mirroring managed and custom rules. Import certificates into CCM for the CDN/WAF listeners and re-plan DNS TTLs and CNAME chains, since Front Door's single anycast hostname becomes a CDN CNAME to Huawei's edge. Where Front Door routed to multiple weighted backend pools, model equivalent behavior with ELB listener weights or DNS steering rather than assuming native parity.

Validate before cutover: run the new stack in shadow with representative traffic, compare cache hit ratios, origin pull rates, TLS handshake behavior, WAF block/action logs, and response headers; exercise failover by taking down a primary origin and observing customer-visible behavior. Re-check any Front Door features that lack a documented Huawei equivalent (for example certain bot-protection or rate-limit dimensions, or specific rule engine actions) and either implement workarounds or flag them as accepted gaps to stakeholders.

Account for cost-model changes: Azure Front Door typically bills outbound data transfer, request volume, and WAF/inbound rule processing; Huawei CDN bills processed traffic with traffic-package and peak/off-peak options, WAF is billed as tiered monthly editions by QPS and domain count, and CCM, ELB, and EIP may add resource-hourly charges. Recalculate total cost using your peak RPS, monthly egress, retained certificate count, and WAF edition needed before production cutover, and confirm the support plan and SLA differences between the two stacks.