Stage 3 — Scale / Edge¶

Trigger: "Traffic is growing and internet exposure is a concern."

Stage 2 made the app safe to operate. Stage 3 makes it safe to expose and ready to grow: Azure Front Door becomes the global entry point, a Web Application Firewall blocks common attacks at the edge before they reach application code, and an autoscale rule adds and removes instances as CPU demand changes.

This stage carries forward the Stage 2 architecture and redeploys the full cumulative stack, then composes additional foundation Bicep modules through stages/stage-03-scale-edge/main.bicep.

Before you start¶

Read these foundations first — Stage 3 applies the decisions they describe:

• Network edge and identity — why edge protection belongs outside the app.
• Zero trust at the workload level — filtering requests before they reach code.
• Well-Architected — Performance Efficiency — why scaling out on a signal beats over-provisioning.

What you'll build¶

flowchart TD
    User[Public user] -->|HTTPS 443| AFD[Azure Front Door<br/>Standard, global edge]
    AFD --> WAF[WAF policy<br/>Prevention, DRS 2.1]
    WAF -->|Route /*, probe /healthz| OG[Origin group<br/>health-probed]
    OG -->|HTTPS origin| WebApp[App Service Web App<br/>Linux S1, DOTNETCORE 8.0]
    Autoscale[Autoscale rule<br/>CPU, min 1 / max 2] -.->|Scales| Plan[App Service plan S1]
    WebApp --> Plan
    WebApp -->|Managed identity| KV[Key Vault<br/>SqlConnectionString]
    WebApp -->|SQL 1433, TLS 1.2| SQL[(Azure SQL Database)]
    WebApp -->|Telemetry| AI[Application Insights]
    AI --> LA[Log Analytics workspace]
    AI --> Alerts[Metric alerts]
    Alerts --> AG[Action Group]
    subgraph RG[Single resource group]
        WebApp
        Plan
        KV
        SQL
        AI
        LA
        Alerts
        AG
        Autoscale
    end

Cost: ~$0.20–$0.30/hour. Time: 35–50 minutes.

Prerequisites¶

• Azure CLI logged in (az login) with rights to create resource groups and role assignments.
• A strong SQL administrator password exported as SQL_ADMIN_PASSWORD (never commit it).
• An Entra principal for the SQL admin, exported as SQL_ENTRA_ADMIN_LOGIN and SQL_ENTRA_ADMIN_OBJECT_ID.
• An operations notification email exported as ALERT_EMAIL_ADDRESS.

Deploy¶

The generic driver scripts under scripts/practical/ wrap the Bicep deployment:

export SQL_ADMIN_PASSWORD='<choose-a-strong-password>'
export SQL_ENTRA_ADMIN_LOGIN='<entra-user-or-group-display-name>'
export SQL_ENTRA_ADMIN_OBJECT_ID='<entra-object-id>'
export ALERT_EMAIL_ADDRESS='<ops-notification-email>'

scripts/practical/deploy-stage.sh stage-03

To deploy the Bicep directly instead:

az group create --resource-group rg-practical-storefront-stage03 --location koreacentral

az deployment group create \
  --resource-group rg-practical-storefront-stage03 \
  --template-file infra/bicep/stages/stage-03-scale-edge/main.bicep \
  --parameters infra/bicep/stages/stage-03-scale-edge/main.bicepparam \
  --parameters sqlAdministratorLoginPassword="$SQL_ADMIN_PASSWORD"

Verify¶

scripts/practical/verify-stage.sh stage-03

This runs four smoke tests:

1. HTTP smoke — GET / on the origin returns 200, GET /healthz returns {"status":"Healthy"}, GET /ops/info returns JSON with a version field.
2. SQL smoke — confirms the database is reachable on TCP 1433.
3. Identity smoke — confirms managed identity, Key Vault custody, SQL Entra admin, staging slot, and metric alerts.
4. Front Door smoke — confirms the endpoint is enabled, a WAF policy is associated, the origin group probes /healthz, and the autoscale maximum is 2. A non-200 edge response is reported as a warning because Front Door endpoints propagate globally over several minutes.

Spot-check individual controls:

az afd endpoint show --profile-name <afdProfile> --endpoint-name <afdEndpoint> --resource-group rg-practical-storefront-stage03 --query enabledState
az afd security-policy list --profile-name <afdProfile> --resource-group rg-practical-storefront-stage03 --query "length(@)"
az afd origin-group show --profile-name <afdProfile> --origin-group-name og-storefront --resource-group rg-practical-storefront-stage03 --query healthProbeSettings.probePath
az monitor autoscale show --name <autoscaleName> --resource-group rg-practical-storefront-stage03 --query "profiles[0].capacity.maximum"

See labs/trunk/stage-03-scale-edge/ for the full checklist, sample requests, and expected results.

Best practices embedded in this stage¶

• Edge protection outside the app — Front Door and its WAF filter traffic globally before it reaches the origin, so application code never sees the blocked requests.
• Stateless for scale-out — the app holds no session state locally, so adding a second instance is safe and requests can land on either one.
• Health probes drive routing — the origin group probes /healthz, so an unhealthy instance is taken out of rotation automatically.
• WAF before custom code — request inspection happens at the edge with the Microsoft Default Rule Set, not in hand-written application filters.

Front Door reaches the web app over its public hostname at this stage. Locking the origin so it only accepts traffic from this Front Door instance (via the X-Azure-FDID header and the AzureFrontDoor.Backend service tag), and moving the origin behind a private endpoint, happen in a later stage.

Clean up¶

scripts/practical/destroy-stage.sh stage-03

This deletes the resource group and everything in it.

Go deeper¶

• Health endpoints, graceful degradation, and backpressure
• Operations and reliability for a public web API
• Well-Architected — Cost Optimization
• Network topology cheatsheet

See Also¶

• Stage 2 — Production Baseline
• Network edge and identity
• Zero trust at the workload level
• Well-Architected — Performance Efficiency

Sources¶

• Azure Front Door overview
• Web Application Firewall on Azure Front Door
• Azure Front Door origins and origin groups
• Health probes in Azure Front Door
• Get started with autoscale in Azure