Applying WAF Patterns to Real Architectures

Applying WAF patterns to real architectures is not a theoretical exercise — it requires evaluating each design decision against the five pillars and making informed trade-offs. A common starting point is the architecture diagram: trace the path of a user request through every component and ask, for each hop, what happens if this component fails, what it costs, and how it is secured.

Consider a traditional monolithic web application: a single VM running a web server and database together behind a public IP. Against WAF pillars this scores poorly on all five: no redundancy (reliability), database on same host as web tier (security), always-on VM regardless of traffic (cost), no CI/CD (operational excellence), and vertical scaling only (performance efficiency).

To address the Reliability pillar, spread the web tier across multiple VMs in different availability zones, back the database with geo-replication to a secondary region, and place an Azure Load Balancer in front. This eliminates the single point of failure and allows the application to survive a zone or regional outage without manual intervention.

For the Security pillar, separate the web tier and database into different subnets with NSG rules that only allow the web tier to connect to the database port. Store the database connection string in Azure Key Vault and use a managed identity on the web app to retrieve it at runtime — eliminating hardcoded credentials from application code and configuration files.

For Cost Optimisation, replace always-on VMs with a Virtual Machine Scale Set that scales in during off-peak hours. For the database, evaluate whether a managed PaaS service like Azure SQL Database with an appropriate DTU tier costs less than a full VM with SQL Server. Purchase Reserved Instances for any baseline capacity you can predict 12 months in advance.

Improve Operational Excellence by defining the entire infrastructure as Bicep or ARM templates stored in version control. Build a CI/CD pipeline in Azure Pipelines or GitHub Actions that automatically deploys infrastructure changes and application code. Add deployment gates — automated smoke tests and manual approval — before changes reach production.

For Performance Efficiency, introduce Azure Cache for Redis in front of the database to cache frequently read queries and reduce database load. Deploy static assets (images, CSS, JavaScript) through Azure CDN to serve them from edge nodes close to users worldwide. Load test the application after each change to confirm the improvements are measurable.

Every architectural change involves a trade-off. For example, moving to a multi-zone architecture improves reliability but increases cost (two zones = two VMs). Adding Redis caching improves performance but adds operational complexity (another service to monitor and maintain). Good architecture documentation captures these trade-offs explicitly so future architects understand why decisions were made.

Avoid trying to achieve perfection in a single redesign — that approach is expensive, risky, and slow. Instead, adopt an iterative improvement cycle: run a Well-Architected Review, identify the top three highest-impact issues, fix them, measure improvement, and repeat. This approach aligns architectural improvements with agile delivery and makes progress visible to stakeholders at each sprint.

Microsoft publishes reference architectures for common workload patterns on the Azure Architecture Center. These include web application architectures, microservices on AKS, data analytics pipelines, and many more. Each reference architecture has already been evaluated against WAF pillars and includes notes on the trade-offs made for that specific pattern.

Use Architecture Decision Records (ADRs) to document significant architectural choices, the context in which they were made, the alternatives considered, and the WAF pillar implications. ADRs stored in version control alongside the codebase create an auditable history that helps new team members understand why the architecture looks the way it does.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: WAF patterns are applied by evaluating each architectural decision against all five pillars; improvements can be made iteratively by starting with the highest-impact issues; and trade-offs must be documented so future architects understand the reasoning. Next up we explore Azure SLAs and how to calculate composite SLAs for multi-service architectures.