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. .NET Framework apps run unchanged on App Service on Windows; Azure Container Apps runs Linux containers only, so a .NET Framework app cannot move there without porting.
- 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. Every app in a plan runs on the same VM instances and shares their CPU and memory, so one resource-hungry app degrades the rest — move it to its own plan.
- 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.
Slots also take a traffic percentage: route, say, 10% of production traffic to the staging slot as a canary and raise it before swapping. Autoscale rules can be metric-based (CPU, queue length) or schedule-based — for peaks at known hours, raise the minimum instance count just before the window and lower it after, so capacity is ready instead of trailing the spike.
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.
The integrated app uses the virtual network's DNS settings, so reaching an on-premises server by name also needs DNS that can resolve it from the VNet (for example a DNS Private Resolver outbound endpoint with a forwarding rule). App Service Environment v3 (Isolated v2) goes further and places the whole platform in your subnet: with an internal virtual IP the apps are reachable only from the VNet and connected networks and reach private endpoints directly — the single-tenant answer when isolation is a compliance requirement.
Reaching data without credentials: give the app a managed identity and grant it access on the target — Azure SQL with Microsoft Entra authentication, Key Vault, Storage — so there is nothing to store or rotate. A Key Vault reference is the fallback for secrets the target cannot replace; it protects a password, but a password still exists.
⚠️ 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?
