--- title: "Azure Web App Architecture: Practical Production Guide" slug: "azure-web-app-architecture-production-reference" published: "2026-08-05" updated: "2026-08-11" validated: "2026-08-11" categories: - "Next.js" tags: - "Azure web app architecture" - "Azure Front Door" - "Azure Database for PostgreSQL" - "Azure Blob Storage" - "Managed Identity" - "Azure Key Vault" - "Application Insights" - "Azure Monitor" - "Azure Managed Redis" - "Private Link" - "WAF policies" llm-intent: "reference" audience-level: "intermediate" framework-versions: - "next.js@16" status: "stable" llm-purpose: "Azure web app architecture: practical production reference showing Front Door, PostgreSQL, Blob Storage, Managed Identity and monitoring—read design…" llm-prereqs: - "Access to Azure Front Door" - "Access to Azure App Service" - "Access to Azure Container Apps" - "Access to AKS" - "Access to Azure Database for PostgreSQL Flexible Server" llm-outputs: - "Completed outcome: Azure web app architecture: practical production reference showing Front Door, PostgreSQL, Blob Storage, Managed Identity and monitoring—read design…" --- **Summary Triples** - (Azure Web App Architecture: Practical Production Guide, focuses-on, Azure web app architecture: practical production reference showing Front Door, PostgreSQL, Blob Storage, Managed Identity and monitoring—read design…) - (Azure Web App Architecture: Practical Production Guide, category, general) ### {GOAL} Azure web app architecture: practical production reference showing Front Door, PostgreSQL, Blob Storage, Managed Identity and monitoring—read design… ### {PREREQS} - Access to Azure Front Door - Access to Azure App Service - Access to Azure Container Apps - Access to AKS - Access to Azure Database for PostgreSQL Flexible Server ### {STEPS} 1. Choose the edge layer 2. Treat WAF as security control 3. Separate persistent state 4. Start with managed PostgreSQL 5. Define backups vs high availability 6. Use Blob Storage for files 7. Add Redis only if needed 8. Prefer managed identity over secrets 9. Decide public vs private networking 10. Bake in observability early 11. Assess availability across the path 12. Select a reference architecture # Azure Web App Architecture: Practical Production Guide > Azure web app architecture: practical production reference showing Front Door, PostgreSQL, Blob Storage, Managed Identity and monitoring—read design… Matija Žiberna · 2026-08-05 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: * Where does public traffic enter? * Should the application origin be public or private? * Where does persistent data live? * How are uploaded files stored? * How does the application authenticate to Azure services? * Where do secrets live? * What happens when one application replica fails? * What happens when a database node fails? * How do you detect problems? * How do you recover from an accidental deletion or regional incident? 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. ## A useful starting architecture For many production applications, I would start with something conceptually this simple: ```text 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: 1. **Edge and public traffic** 2. **Application compute** 3. **Persistent state** 4. **Identity and secrets** 5. **Observability** 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. ## 1. Decide what sits in front of the application 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: ```text Browser | v Azure Front Door | v Application Origin ``` This layer becomes useful when you need capabilities such as: * centralized TLS * CDN behavior * global edge routing * Web Application Firewall * rate limiting * bot protection * origin protection * multiple application origins * failover between origins 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: ```text 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. ### Do you always need Front Door? 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. ## 2. Treat the WAF as an application security control 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: ```text Deploy rules | Detection | Review logs | Tune exclusions | Prevention ``` That is particularly important for applications with large forms, APIs, CMS interfaces or unusual request payloads. ## 3. Keep persistent state outside the application 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: ```text Application process != Persistent storage ``` The application runtime handles requests. Persistent services hold the state. For a common web application, that could mean: ```text 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. ## 4. PostgreSQL: start with the managed service 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: ```text 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: ```text 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. ## 5. Backups and high availability solve different problems 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: ```text 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: * expected uptime * acceptable recovery time * acceptable data loss * backup retention * restore procedure * who can trigger a restore Those decisions are much more useful than simply writing "backups enabled" in an architecture document. ## 6. Use Blob Storage for files and media 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. ```text 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. ## 7. Add Redis only when the application needs Redis 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: * cross-instance caching * session state * expensive data caching * rate-limit state * queues or messaging patterns * other low-latency shared state 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: ```text 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. ## 8. Prefer identity over credentials between Azure 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: ```text 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: ```text 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: ```text 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. ## 9. Public versus private networking should be a deliberate decision 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: ```text 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: * subnets * DNS * private DNS zones * routing * address ranges * integration with existing VNets * developer access * CI/CD access * monitoring access * incident troubleshooting 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: * Does the database have any reason to accept public traffic? * Does the application need access to internal corporate systems? * Is private connectivity required by policy? * Will an enterprise hub-and-spoke network be used? * Does outbound traffic need inspection? * Are fixed outbound IPs required? * Who is responsible for DNS and networking? A bank, SaaS startup and internal administrative tool can all use Azure while needing very different answers. ## 10. Observability belongs in the architecture from the start A production application is not finished when it responds successfully to HTTP requests. You need to know: * whether it is healthy * whether it is slowing down * whether error rates are increasing * which downstream dependency is failing * what happened before an incident * whether a deployment changed behavior 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: ```text 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: ```text Request | Frontend | API | Database | External service | Response ``` as one correlated operation. ## 11. Availability has to be considered across the entire request path It is easy to declare an application "highly available" because the web layer has two replicas. Consider: ```text 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: * storage * external APIs * DNS * authentication providers * network paths * caches * queues High availability is a characteristic of the **whole user journey**, rather than an isolated resource. A stronger single-region architecture could therefore be: ```text 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. ## 12. Three production architectures I would actually consider Instead of building one enormous "best practice" architecture, I find it more useful to maintain a few reference shapes. ### Reference architecture 1: Lean production application This is where I would start for many normal business applications. ```text Internet | v Web App | +-----------+-----------+ | | v v PostgreSQL Blob Storage | Managed backups Managed Identity | Key Vault Application Insights ``` Potential compute: * App Service * Container Apps Characteristics: * one Azure region * public application endpoint * controlled database access * managed database * external object storage * proper secret handling * application monitoring * backups 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. ### Reference architecture 2: Public customer platform For an internet-facing platform where traffic control and application security matter more: ```text 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: * WAF * rate limiting * edge routing * CDN * multiple application replicas * more deliberate availability * shared cache where justified This is probably the architecture I would expect for many public SaaS and marketplace platforms. ### Reference architecture 3: Enterprise private-origin platform When the organization has stronger security, compliance or networking requirements: ```text 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. ## 13. What I would define before drawing the final Azure diagram Before committing to the production architecture, I would want answers to a small set of questions. ### Availability What uptime does the application actually require? Does it need zone resilience? Is regional disaster recovery required? ### Recovery What is the acceptable recovery time? How much data could be lost in the worst acceptable incident? How long should backups be retained? ### Security Does the application need a WAF? Can the application origin be public? Can the database be publicly addressable? Which flows require private connectivity? ### Data What belongs in PostgreSQL? What belongs in object storage? Is Redis genuinely required? ### Integration Does the application need to connect to internal Azure or on-premise systems? Are there external services with fixed IP requirements? ### Identity Can Managed Identity replace credentials for Azure service access? Which secrets genuinely need Key Vault? ### Operations 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. ## My practical production baseline For a new public web platform in Azure, with no unusual organizational restrictions, my baseline would currently be approximately: ```text 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 ## LLM Response Snippet ```json { "goal": "Azure web app architecture: practical production reference showing Front Door, PostgreSQL, Blob Storage, Managed Identity and monitoring—read design…", "responses": [ { "question": "What does the article \"Azure Web App Architecture: Practical Production Guide\" cover?", "answer": "Azure web app architecture: practical production reference showing Front Door, PostgreSQL, Blob Storage, Managed Identity and monitoring—read design…" } ] } ```