Using Azure Front Door Custom Routing and WAF to Run A/B Tests Without DNS Changes

Problem: How to Split Traffic for A/B Testing Without DNS Changes

When you roll out a new feature you often want to expose it to a subset of users. Traditional approaches rely on DNS or application‑level routing, both of which introduce latency, require code changes, or cause DNS cache problems. Azure Front Door (AFD) offers a network‑level solution: custom routing rules that map URL paths or host headers to backend pools, optionally weighted, and a Web Application Firewall (WAF) that protects the entire edge.

Thesis: Custom routing + WAF = Zero‑DNS‑Change A/B Testing with Built‑in Security

By configuring a path‑based routing rule that forwards /beta/* requests to a new backend pool with a weight of 20 % and leaving the default pool at 80 %, you can serve 20 % of users from the new version. The same rule can be reused for region‑specific routing or gradual roll‑outs. Attaching a WAF policy to the profile or individual rule adds rate‑limiting, SQL injection protection, and custom logic without touching your application.

1. Create the Front Door Profile and Backend Pools

# Create the Front Door profile
az network front-door create \
  --name myFrontDoor \
  --resource-group  \
  --host-name myapp.azurefd.net \
  --sku Standard_AzureFrontDoor

# Create backend pool for the current production App Service
az network front-door backend-pool create \
  --name poolA \
  --front-door-name myFrontDoor \
  --resource-group  \
  --backend-address myapp1.azurewebsites.net \
  --load-balancing-settings-name default \
  --health-probe-settings-name default

# Create backend pool for the new beta App Service
az network front-door backend-pool create \
  --name poolB \
  --front-door-name myFrontDoor \
  --resource-group  \
  --backend-address myapp2.azurewebsites.net \
  --load-balancing-settings-name default \
  --health-probe-settings-name default

Requirements: az network front-door commands need the Owner or Contributor role on the subscription. Replace <resource-group> with your actual RG name. The two backend-address values should match the fully‑qualified domain names of your App Service instances; the host header sent by AFD will default to the pool’s name unless overridden.

2. Define Routing Rules for A/B Testing

Front Door supports two rule types that are relevant here: ForwardingRule (simple path‑based or host‑based routing) and WeightedRule (traffic splitting). The following example uses ForwardingRule with a weight, which is supported in the Premium SKU but can be simulated with two rules in Standard.

# Default rule: 80% traffic to poolA
az network front-door routing-rule create \
  --name ruleDefault \
  --front-door-name myFrontDoor \
  --resource-group  \
  --accepted-protocols Http Https \
  --frontend-endpoints myFrontDoorEndpoint \
  --patterns-to-match /* \
  --backend-pool-name poolA \
  --rule-type ForwardingRule \
  --weight 80

# Beta rule: 20% traffic to poolB
az network front-door routing-rule create \
  --name ruleBeta \
  --front-door-name myFrontDoor \
  --resource-group  \
  --accepted-protocols Http Https \
  --frontend-endpoints myFrontDoorEndpoint \
  --patterns-to-match /beta/* \
  --backend-pool-name poolB \
  --rule-type ForwardingRule \
  --weight 20

Key points:

• Weights are only respected if the Front Door SKU supports weighted routing; otherwise the rules execute in the order they are defined.
• The /beta/* pattern is case‑insensitive and will match any path that starts with /beta/.
• If you need more granular control, use a WeightedRule with FrontDoorRoutingRuleType=WeightedRule (Premium only).

3. Attach a WAF Policy to the Profile

WAF can be applied globally to the profile or per rule. Global attachment gives the same protection to every request, while per‑rule allows different rule sets for beta traffic.

# Create a WAF policy
az network front-door waf-policy create \
  --name myWAFPolicy \
  --resource-group  \
  --sku WAF_Medium \
  --mode Prevention \
  --custom-rules '[{"name":"RateLimit","ruleType":"RateLimitRule","priority":1,"enabledState":"Enabled","matchConditions":[{"variable":"RequestHeaders","operator":"Contains","negateCondition":false,"matchValues":["User-Agent"]}]}]'

# Associate the policy with the Front Door profile
az network front-door waf-policy association create \
  --front-door-name myFrontDoor \
  --resource-group  \
  --waf-policy-name myWAFPolicy

Replace the custom-rules JSON with your own logic; the example above adds a simple rate‑limit rule. The mode can be Detection or Prevention. In Prevention mode, matching requests are blocked outright.

4. Verify the Configuration

1. Health Probes: In the Azure portal or via CLI, confirm that both backend pools report Healthy. A probe path of /health is recommended.
2. Traffic Split: Use curl -I https://myapp.azurefd.net/beta/test repeatedly. The Server header should show the IP of the beta backend for ~20 % of requests. In the portal’s Front Door diagnostics you can view traffic distribution.
3. WAF Logs: Navigate to Front Door WAF logs in Azure Monitor. Verify that requests to both pools hit the policy and that no legitimate traffic is blocked.
4. Run az network front-door show --name myFrontDoor --resource-group to confirm the rule weights and backend pool assignments.

Risks to watch for:

• 502 Bad Gateway if the host header sent by AFD does not match the backend’s expected hostname. Set OverrideBackendHostHeader in the backend pool if needed.
• Cost: Premium SKU and per‑rule charges apply. Keep the number of rules minimal.
• WAF false positives: test in a staging environment before enabling Prevention mode.

Trade‑Offs and Limitations

While custom routing removes DNS churn, it introduces a few constraints:

• Weighted routing is only available in the Premium SKU. The Standard SKU requires separate rules and manual traffic balancing.
• Each additional routing rule adds a small per‑rule charge. A large number of A/B tests can become expensive.
• Health probe paths must be valid for every backend; misconfiguration can cause a pool to be marked unhealthy prematurely.

Nevertheless, the benefits—zero DNS changes, instant traffic split, and built‑in WAF—often outweigh these costs for controlled roll‑outs.

Actionable Checklist

• Plan your routing rules: decide path or host header, weight percentages, and whether to use global or per‑rule WAF.
• Provision the Front Door profile in the appropriate region; verify that Premium WAF is supported.
• Deploy backend pools with correct host headers and health probes.
• Create routing rules and attach WAF policy; keep the ARM template or CLI script version‑controlled.
• Run the verification steps above before promoting to production.
• Monitor traffic distribution and WAF logs; adjust weights or rules as needed.
• When the beta is fully validated, delete the beta rule or set its weight to 0 to free the backend.

By following this pattern, you can safely experiment with new features, perform region‑specific roll‑outs, or even run canary deployments—all while keeping your DNS stable and your traffic protected by WAF.