Practical Azure web app architecture for production: Front Door, PostgreSQL, Blob Storage, Managed Identity and WAF.
Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
No spam. Unsubscribe anytime.
I recently had to design a web application for an organization where Microsoft Azure was the natural infrastructure environment.
Choosing where the application process runs was only one part of the problem.
Once you move beyond a small application, the more important architecture questions become:
This article focuses on those surrounding layers.
I will treat the application runtime as interchangeable. It could be Azure App Service, Azure Container Apps, AKS, or another approved Azure compute service. I covered the runtime decision separately in Hosting Next.js 16 on Azure: Container Apps, App Service, AKS, or Static Web Apps, because it deserves its own discussion.
The goal here is to arrive at a practical production architecture for a modern web application without automatically adding every Azure service available.
For many production applications, I would start with something conceptually this simple:
Internet
|
v
Azure Front Door
|
v
Web App
App Service / Container
|
+-------------+-------------+
| | |
v v v
PostgreSQL Blob Storage Optional Cache
|
v
Persistent Data
Managed Identity
|
Key Vault
Azure Monitor
Application Insights
This already creates useful separation between five concerns:
The architecture can then become more sophisticated only where the application's requirements justify it.
That last point matters. Azure makes it easy to create architectures that are technically impressive but operationally expensive. Every private endpoint, subnet, firewall policy, replica, additional region and monitoring pipeline becomes something that needs to be understood and maintained.
I prefer starting with the workload requirements and adding infrastructure deliberately.
A small web application can expose its application runtime directly to the internet.
That is a perfectly legitimate starting architecture.
As requirements increase, I would evaluate Azure Front Door as a separate edge layer.
Azure currently positions Front Door as its global application delivery and CDN service. It provides global routing, acceleration, origin protection and integration with Azure Web Application Firewall.
The architecture becomes:
Browser
|
v
Azure Front Door
|
v
Application Origin
This layer becomes useful when you need capabilities such as:
For applications with stricter security requirements, Front Door Premium can use Private Link to reach supported Azure origins without requiring those origins to remain directly exposed to the public internet. Microsoft documents this topology for both App Service and Azure Container Apps.
That gives you:
Internet
|
v
Azure Front Door Premium
|
| Private Link
|
v
Private Application Origin
This is a useful enterprise architecture because Front Door becomes the controlled public boundary.
The application itself can remain private.
No.
I would add it when there is a concrete requirement for edge delivery, WAF, origin isolation, global routing or centralized traffic control.
A regional internal business application may not need it.
A public customer platform handling sensitive flows probably deserves a much closer look.
For public applications, a Web Application Firewall often becomes part of the edge architecture.
Azure Front Door Premium supports Microsoft's managed WAF rule sets, which are designed to protect against common web vulnerabilities and incorporate Microsoft threat intelligence.
Azure Front Door also provides network and application-layer DDoS protections at its global edge, while WAF policies can add controls such as rate limiting, IP filtering, geo-filtering and bot protection.
The important operational detail is that I would not switch a new WAF policy into blocking mode and assume the job is finished.
Microsoft itself recommends initially tuning WAF policies against real application traffic, reviewing false positives, and then moving production policies into prevention mode.
A WAF policy carries an operational lifecycle that a simple "Internet → WAF → App" diagram doesn't show:
Deploy rules
|
Detection
|
Review logs
|
Tune exclusions
|
Prevention
That is particularly important for applications with large forms, APIs, CMS interfaces or unusual request payloads.
Application compute should generally be replaceable.
If one replica disappears and another starts, persistent application data should still exist.
That leads to a simple rule for most web platforms:
Application process
!=
Persistent storage
The application runtime handles requests.
Persistent services hold the state.
For a common web application, that could mean:
Application
|
+---- PostgreSQL
|
+---- Blob Storage
|
+---- Redis, if genuinely needed
This separation becomes increasingly important as the application scales horizontally.
Two web replicas can easily share the same managed database and object storage. Sharing files written to the local application filesystem is considerably more awkward.
For PostgreSQL applications, the Azure-native starting point I would evaluate is Azure Database for PostgreSQL Flexible Server.
It is Microsoft's managed PostgreSQL offering and includes automated patching, backups, monitoring, scaling controls and built-in PgBouncer support.
For a basic architecture:
Web App
|
v
Azure Database for PostgreSQL
For higher availability requirements, PostgreSQL Flexible Server can provision a physically separate standby.
Azure currently supports both zonal and zone-redundant high availability. In zone-redundant HA, the primary and standby are placed across availability zones, and transactions are synchronously committed to both.
Conceptually:
Application
|
v
PostgreSQL
/ \
Primary Standby
Zone A Zone B
If the primary becomes unavailable, Azure can fail over to the standby while keeping the database endpoint consistent for the application.
Whether you actually need zone-redundant HA should follow from the availability requirements.
It roughly doubles the database compute involved, so it is not something I would enable automatically on every small project.
This distinction matters.
A standby covers infrastructure failure — the primary going down, a zone outage, hardware issues.
Data corruption is a separate failure mode. If an application incorrectly deletes 10,000 rows, that deletion replicates to the standby along with everything else, which is where backups and point-in-time recovery come in.
Azure Database for PostgreSQL automatically creates backups and supports point-in-time recovery. The default retention is seven days and can currently be configured up to 35 days.
So I think of the two controls separately:
High availability
|
v
"Can we continue operating?"
Backups / PITR
|
v
"Can we recover earlier data?"
A proper production architecture needs requirements for both.
Before implementation, I would define at least:
Those decisions are much more useful than simply writing "backups enabled" in an architecture document.
User uploads, documents, images and generated files generally should not live permanently inside the application container or web-server filesystem.
In Azure, Blob Storage is the natural destination.
Web App
|
+---------+---------+
| |
v v
PostgreSQL Blob Storage
structured files/media
data
This keeps application replicas disposable and avoids synchronization problems between them.
For important files, the storage architecture should also consider data protection.
Azure Blob Storage supports mechanisms including soft delete, versioning, lifecycle policies and different storage-redundancy options. Microsoft recommends combining blob soft delete, container soft delete and versioning where appropriate for stronger protection against accidental deletion or modification.
Versioning has a cost implication because previous versions consume storage, so lifecycle policies are useful for automatically removing or moving older objects according to retention requirements.
Again, the right configuration follows the data.
A temporary generated thumbnail and a signed customer document should probably not have the same retention policy.
Architecture diagrams have a tendency to acquire Redis automatically.
I would avoid that.
A distributed cache is useful when there is a real need for:
If there is no concrete workload requiring it, PostgreSQL plus application-level caching may already be enough.
There is also an important 2026 Azure-specific detail here.
For new architectures, Azure Managed Redis is the service I'd design around. Microsoft has announced retirement of the Azure Cache for Redis SKUs and recommends migration to Azure Managed Redis, so a new design built on the older service would already need a migration plan on day one.
So a modern architecture that actually needs shared Redis state becomes:
Application replicas
/ \
/ \
+-----------------+
|
v
Azure Managed Redis
|
PostgreSQL
Azure Managed Redis is Microsoft's current managed Redis service and can be used alongside App Service, Container Apps, Functions and other Azure compute services.
One of the Azure patterns I like most is Managed Identity.
Without it, cloud applications often end up with a growing collection of credentials:
DATABASE_PASSWORD
STORAGE_KEY
AZURE_CLIENT_SECRET
SOME_SERVICE_PASSWORD
...
Managed Identity allows supported Azure compute resources to receive an identity from Microsoft Entra ID.
The Azure platform manages that identity, meaning the application does not need to provision or rotate a traditional client secret just to authenticate to another Entra-protected Azure resource.
Conceptually:
Application
|
| Managed Identity
|
+------> Key Vault
|
+------> Storage
|
+------> Other Azure services
Managed Identity covers authentication between Azure resources. External API keys, third-party credentials, and some database authentication scenarios still need secret values, and those belong in a controlled secret store such as Azure Key Vault rather than source code or casually distributed configuration files.
Microsoft's current Key Vault guidance recommends separating vaults by application, environment and region where appropriate, while applying least-privilege access and monitoring.
For me, the hierarchy is:
Can we authenticate using Managed Identity?
|
Yes
|
v
Use Managed Identity
No
|
v
Store secret in Key Vault
That is much cleaner than treating .env files as the security architecture.
Azure can make almost every service private. Deciding which services actually need to sit behind Private Link is a separate, deliberate decision for each application.
For example, Azure Database for PostgreSQL can operate with controlled public access or through private networking. Private endpoints allow applications to reach PostgreSQL over Azure's private network rather than traversing the public internet.
Similarly, Front Door Premium can privately reach an application origin.
A hardened topology might therefore become:
Internet
|
v
Azure Front Door Premium
|
Private Link
|
v
Private Application
|
Private network
|
+---------+---------+
| |
v v
PostgreSQL Blob Storage
private access private access
This is a very reasonable architecture for some regulated or enterprise systems, and it comes with real complexity worth naming up front.
You now need to think about:
Microsoft's own architecture guidance treats networking as a significant design decision because it can be difficult to change later.
I would therefore decide based on the actual security model.
Questions I would ask include:
A bank, SaaS startup and internal administrative tool can all use Azure while needing very different answers.
A production application is not finished when it responds successfully to HTTP requests.
You need to know:
Azure Monitor provides the broader observability platform, while Application Insights focuses on application performance monitoring and telemetry for live applications.
At a minimum, I would think about:
Application
|
+---- Logs
|
+---- Metrics
|
+---- Traces
|
+---- Exceptions
|
+---- Health checks
|
v
Azure Monitor
Application Insights
The exact amount of telemetry depends on the application.
More logs do not automatically produce better observability.
The useful question is whether the telemetry allows you to reconstruct the user and system flows that matter when something breaks.
For a transaction-oriented application, that might mean being able to trace:
Request
|
Frontend
|
API
|
Database
|
External service
|
Response
as one correlated operation.
It is easy to declare an application "highly available" because the web layer has two replicas.
Consider:
Front Door
|
+------+------+
| |
App A App B
\ /
\ /
Database
The application layer is redundant here. The database sitting underneath both replicas needs the same check, and so does everything else in the request path:
High availability is a characteristic of the whole user journey, rather than an isolated resource.
A stronger single-region architecture could therefore be:
Azure Front Door
|
Application
/ \
Replica A Replica B
\ /
\ /
PostgreSQL
Primary + Standby
Zone A/B
|
Blob Storage
redundant storage
PostgreSQL Flexible Server can provide zone-redundant HA, and Azure Storage provides multiple redundancy models including zone and geo-redundant configurations depending on the recovery requirements.
Whether the next step should be multi-region architecture is a separate decision.
For many applications, a well-designed zone-resilient single-region deployment provides a much better complexity-to-reliability tradeoff than immediately introducing active-active regional architecture.
Instead of building one enormous "best practice" architecture, I find it more useful to maintain a few reference shapes.
This is where I would start for many normal business applications.
Internet
|
v
Web App
|
+-----------+-----------+
| |
v v
PostgreSQL Blob Storage
|
Managed backups
Managed Identity
|
Key Vault
Application Insights
Potential compute:
Characteristics:
This architecture is relatively easy to understand and operate.
If the application does not have specific edge or private-network requirements, I would resist adding them preemptively.
For an internet-facing platform where traffic control and application security matter more:
Internet
|
v
Azure Front Door
CDN + WAF
|
v
Web App
/ \
Replica A Replica B
\ /
\ /
PostgreSQL
|
Blob Storage
|
Optional Redis
Managed Identity
|
Key Vault
Azure Monitor / Insights
I would use this shape when I need:
This is probably the architecture I would expect for many public SaaS and marketplace platforms.
When the organization has stronger security, compliance or networking requirements:
Internet
|
v
Azure Front Door Premium
CDN + WAF
|
Private Link
|
v
Private Application
/ \
Replica A Replica B
\ /
\ /
Private VNet
/ | \
/ | \
v v v
PostgreSQL Storage Redis
Private Private Private
\ | /
\ | /
Key Vault
|
Azure Monitor / SIEM
Microsoft directly documents the Front Door Premium to private Container Apps and App Service patterns, so this is a supported Azure architecture rather than a custom networking trick.
I would expect this architecture to be shaped further by the organization's own Azure landing zone, networking rules, security operations and identity standards.
That is important.
For enterprise systems, the application team should rarely invent the organization's Azure governance architecture from scratch.
The application should fit into it.
Before committing to the production architecture, I would want answers to a small set of questions.
What uptime does the application actually require?
Does it need zone resilience?
Is regional disaster recovery required?
What is the acceptable recovery time?
How much data could be lost in the worst acceptable incident?
How long should backups be retained?
Does the application need a WAF?
Can the application origin be public?
Can the database be publicly addressable?
Which flows require private connectivity?
What belongs in PostgreSQL?
What belongs in object storage?
Is Redis genuinely required?
Does the application need to connect to internal Azure or on-premise systems?
Are there external services with fixed IP requirements?
Can Managed Identity replace credentials for Azure service access?
Which secrets genuinely need Key Vault?
Who receives alerts?
Who handles infrastructure incidents?
Who can deploy?
Who can access production data?
Who performs restores?
These questions usually change the architecture more than the choice between two Azure product SKUs.
For a new public web platform in Azure, with no unusual organizational restrictions, my baseline would currently be approximately:
Azure Front Door + WAF where justified
|
Application runtime
|
+--------+---------+
| | |
PostgreSQL Blob Managed Redis
HA Storage if needed
|
Managed Identity
|
Key Vault
|
Azure Monitor
Application Insights
From there I would make the architecture either simpler or stricter.
For a small application, remove Front Door, HA and Redis if they solve no immediate requirement.
For an enterprise application, add private origins, Private Link, network integration, additional security telemetry and the organization's established Azure governance controls.
The key is to keep each component tied to an actual requirement.
Azure makes sophisticated architecture available surprisingly quickly.
The difficult part is deciding which sophistication the application genuinely needs.
For me, a good production Azure architecture is one where the application runtime can remain relatively boring while Azure handles the infrastructure concerns around it through clearly separated services.
That separation also makes future changes easier.
You can replace the application runtime without redesigning storage.
You can introduce Front Door without replacing PostgreSQL.
You can add a cache without changing where files are stored.
You can tighten network access without fundamentally rebuilding the application.
That is the characteristic I would optimize for.
Keep the application portable, keep persistent state external, and let each Azure service solve one clearly defined infrastructure problem.
Thanks, Matija