Most Azure App Service deployments start simple and stay too simple for too long. The app is public, secrets live in settings, traffic goes straight to the origin, and networking only becomes serious after a security review or a painful incident.

This guide lays out a stronger pattern for production-facing workloads: Azure Front Door Premium at the edge, Azure App Service as the application platform, Private Link for the origin path, VNet integration for outbound private access, managed identity for passwordless access, and Key Vault references for secret hygiene.

This is the kind of architecture that works well in a portfolio because it shows platform thinking, not just resource creation.

Why This Pattern Matters

Security problems in App Service usually come from weak boundaries, not weak code.

If the origin stays publicly reachable, you have two public surfaces instead of one.

If secrets are copied into app settings, rotation becomes sloppy and auditing gets harder.

If outbound networking is not planned, private dependencies turn into emergency refactors later.

The goal here is simple: one controlled public edge, one private origin path, one clean secret model, and one observable platform.

Reference Architecture

The strongest version of this design looks like this:

Azure Front Door Premium receives public traffic, terminates TLS, runs WAF checks, and routes requests.

Azure App Service is the origin, but it is reached through Private Link instead of broad public access.

App Service VNet integration handles outbound traffic so the app can reach Key Vault, storage, databases, or internal APIs through private networking.

Managed identity lets the app authenticate to Azure resources without storing credentials.

Key Vault references let the app read secrets as normal environment variables while the real values stay in Key Vault.

Azure Monitor and Application Insights provide traces, metrics, logs, WAF events, and operational visibility.

The First Design Rule: Separate Inbound And Outbound Networking

Microsoft's networking guidance for App Service is clear about one critical point: private endpoints and VNet integration cannot use the same subnet.

That matters because the two features solve different problems.

Private endpoint protects inbound traffic to the app.

VNet integration controls outbound traffic from the app.

Treating them as separate concerns makes the architecture easier to reason about and easier to troubleshoot.

For a production pattern, create at least:

One subnet for App Service VNet integration

One subnet for private endpoints

Microsoft also notes that subnet sizing matters more than people expect because scale operations and platform upgrades temporarily consume extra IP addresses. A tiny subnet might work in a lab and fail during a real scaling event.

Managed Identity Should Exist Before Secret Wiring

One of the easiest ways to improve an Azure architecture is to stop treating credentials like configuration.

Turn on system-assigned managed identity on the web app as early as possible.

That identity becomes the basis for access to Key Vault and other Azure services.

Instead of pasting secret values into App Service, store them in Azure Key Vault and reference them from app settings.

Microsoft documents the Key Vault reference format like this:

@Microsoft.KeyVault(SecretUri=https://your-vault.vault.azure.net/secrets/your-secret)

Your code still reads a normal app setting.

The difference is that the secret is centrally governed, audited, and rotated in Key Vault rather than scattered across environments.

Key Vault References Are Better, But They Have Operational Rules

There are two practical behaviors every serious guide should call out.

First, if you do not specify a secret version, the app will use the latest version automatically.

Second, App Service caches Key Vault reference values and refreshes them within 24 hours unless you trigger a configuration restart or explicitly refresh the references.

That means secret rotation is cleaner, but it is not magic. Teams still need an operational playbook for validation and refresh timing.

Microsoft also warns against relying on public outbound IPs when the vault is network-restricted. If the vault is locked down, the app should reach it through a virtual network path instead.

VNet Integration Is The Outbound Story

Private endpoint only solves inbound access to the app. It does not give the app a private route to the services it depends on.

That is where VNet integration matters.

With VNet integration, outbound calls from the app can reach private endpoints or resources reachable through the virtual network.

Microsoft also notes that when you apply NSGs or UDRs, you must still account for runtime dependencies such as identity endpoints and certificate validation endpoints. If teams forget that, they create a secure-looking network that breaks startup, authentication, or dependency calls.

If the workload is Linux-based and must route private traffic consistently, Microsoft specifically documents using vnetRouteAllEnabled so outbound traffic flows through the virtual network path.

DNS Is A Core Part Of The Architecture

A lot of Azure networking designs look correct in a diagram and fail in practice because DNS was not treated as first-class infrastructure.

For App Service private endpoint scenarios, Microsoft documents that the app hostname maps through privatelink.azurewebsites.net.

For Key Vault private endpoint scenarios, teams normally work with the privatelink.vaultcore.azure.net zone.

The real validation step is not just whether the resources deployed.

The real validation step is whether the client path and app path resolve the expected private targets from the networks that matter.

If DNS is wrong, the platform is not secure and it is not stable.

Front Door Premium Should Be The Public Edge

If you want one public edge with serious security controls, Azure Front Door Premium is the right service to place in front of App Service for this pattern.

It gives you:

Global entry point

TLS termination

WAF capabilities

Health probes

Origin routing

Private Link support to App Service

Microsoft's documented flow is straightforward: create the Front Door Premium profile, add the App Service origin, enable Private Link with the sites subresource, and then approve the pending private endpoint connection from the App Service side.

Two details are easy to miss.

You cannot mix public and private origins in the same origin group.

And the private endpoint request from Front Door must actually be approved before the traffic path is usable.

Public Access Strategy

The cleanest end state is to disable public network access on the app after Front Door Private Link is working.

That leaves Front Door as the public edge and App Service as the private origin.

If you cannot make that change immediately, Microsoft's App Service access restriction guidance gives you a transition pattern:

Allow only the AzureFrontDoor.Backend service tag and further scope traffic with the X-Azure-FDID header so the app only accepts traffic from your specific Front Door instance.

That is still a compromise compared to a private-only origin, but it is far better than leaving the default endpoint broadly open.

There is one subtle rule that matters here: access restrictions do not apply to traffic that enters through a private endpoint. Once you move to a private origin model, subnet design, DNS, and private connectivity governance become central.

WAF Is Not Optional Decoration

Too many architectures mention WAF without saying what it is supposed to do.

Microsoft's Front Door WAF guidance calls out practical capabilities that belong in a real production design:

OWASP-based managed rules

Microsoft threat intelligence rules

Bot protection

Rate limiting

Geo-filtering

Logging through Azure Monitor

A pragmatic rollout is to start in Detection mode, tune exclusions and custom rules, then move to Prevention mode after you understand normal traffic behavior.

That sequence sounds operationally mature because it is.

Observability Has To Be Part Of The Story

A good Azure guide should not stop at provisioning.

The platform should show how teams prove that it is healthy.

Use Application Insights for request traces, dependency calls, failures, and latency.

Use Azure Front Door and WAF logs to understand edge behavior and attack patterns.

Use App Service diagnostics and access restriction audit logs where relevant.

Create a simple health endpoint such as /healthz and use it for probes and release validation.

Health checks should confirm readiness, not execute expensive business logic.

Common Mistakes To Avoid

There are a few mistakes that waste a lot of time in this pattern.

Using the same subnet for private endpoints and VNet integration.

Under-sizing the integration subnet.

Forgetting to approve the Front Door private endpoint connection.

Mixing public and private origins in the same origin group.

Assuming access restrictions protect private endpoint traffic.

Treating DNS like a deployment detail instead of core infrastructure.

Final Take

This architecture is strong because it solves the right problem. It does not chase complexity for its own sake. It gives you a controlled public edge, a private origin path, cleaner secret handling, and a better operational model for real applications.

If you want portfolio content that reads like credible Azure engineering and not recycled marketing, this is the level to aim for.

Supporting diagrams for this guide are included in the portfolio package in this repository under portfolio_guides/azure_app_service_zero_trust.

---

*Stay radical, stay curious, and keep pushing the boundaries of what's possible in the cloud.*

Chriz *Beyond Cloud with Chriz*