5.1.1.2. Design for Azure App Service
5.1.1.2. Design for Azure App Service
💡 First Principle: A fully managed Platform as a Service (PaaS) for web applications abstracts away underlying infrastructure, enabling developers to focus on writing code and accelerate delivery while benefiting from built-in scalability, security, and CI/CD integration.
Scenario: You are designing a new customer-facing web application that needs to support .NET Core. The development team wants to focus solely on writing application code and leverage a fully managed service that provides automatic scaling and built-in SSL for a custom domain.
Azure App Service is a fully managed Platform as a Service (PaaS) for hosting web applications and APIs.
Key Design Considerations:
- Managed Platform: App Service handles OS patching, capacity provisioning, and load balancing, reducing operational overhead.
- Scalability: Supports both vertical scaling (changing pricing tier) and horizontal scaling (scaling out instances) manually or automatically.
- Deployment Options: Integrates with CI/CD tools, Git repositories, Docker containers, and provides deployment slots for staging.
- Supported Languages and Frameworks: Natively supports .NET, Java, Node.js, PHP, Python, and Ruby.
- Security: Built-in features include SSL certificates, Microsoft Entra ID integration, and network isolation (VNet integration, Private Endpoints).
- Cost: Pricing is based on the App Service Plan (compute resources). Consider different pricing tiers based on performance and feature needs.
- Use Cases: Ideal for web applications, REST APIs, and mobile backends where rapid deployment and reduced management are priorities.
Design decisions in practice — the plan tier is the design:
| Tier | Deployment slots | Autoscale | Zone redundancy | Typical use |
|---|---|---|---|---|
| Free / Shared | No | No | No | Experiments only — shared compute, quotas |
| Basic | No | No | No | Dev/test, or production that never needs a zero-downtime release |
| Standard | Yes (5) | Yes | No | The realistic production floor |
| Premium v3 | Yes (20) | Yes | Yes | Production needing zone redundancy or higher density |
| Isolated v2 | Yes (20) | Yes | Yes | App Service Environment — full network isolation, compliance |
Two properties decide most scenarios. Deployment slots start at Standard, so any requirement mentioning zero-downtime release, staged validation or instant rollback rules Basic and below out — a slot swap warms the new version and exchanges it with production, and swapping back is the rollback. Zone redundancy starts at Premium v3 and needs more than one instance, so any in-region availability target above a single datacenter means Premium.
Reaching private resources: regional VNet integration governs outbound traffic from the app into a virtual network, which is what lets an app reach a private endpoint, an on-premises database over ExpressRoute, or a Key Vault behind a firewall. Private Endpoint on the app governs the opposite direction — inbound, making the app itself reachable only privately. Scenarios frequently need both, and they are separate settings.
⚠️ Exam Trap: "scale down to save cost between releases" is not a reason to choose Basic. Losing slots and autoscale costs more in outage risk than the tier saves.
⚠️ Common Pitfall: Choosing an undersized App Service Plan for a production workload. This can lead to performance throttling and a poor user experience. Analyze performance requirements to select an appropriate pricing tier.
Key Trade-Offs:
- Simplicity vs. Control: App Service is incredibly simple to use but offers less control over the underlying OS and server configuration compared to VMs or AKS.
Reflection Question: How does designing for Azure App Service, leveraging its fully managed platform, built-in scalability, and support for various programming languages, fundamentally enable developers to focus on application logic and achieve rapid deployment with minimal infrastructure management?
