1. App Service Plan Tiers as Architecture Decisions

Each tier unlocks capabilities that matter to architects. Choosing the wrong tier isn't just a cost issue — it blocks features you'll need later (slots, VNet integration, scale-out limits).

🔑 Tier Unlock Table

Feature Free/Shared Basic Standard Premium v3 Isolated v2
Custom domainsShared only✅✅✅✅
Deployment slots——52020
Autoscale——✅✅✅
VNet integration———RegionalFull (injected)
Max instances—31030100
Zone redundancy———✅✅
SLANone99.95%99.95%99.95%99.95%
Per-app scaling———✅✅
⚠️ Never use Free/Shared for production. No SLA, shared CPU quotas, no custom SSL on Free. If someone says "we'll just use Free for the internal tool" — remind them there's no SLA and daily CPU limits will throttle the app.

2. VNet Integration Options

Two fundamentally different networking models exist for App Service. Choose based on isolation requirements, not just connectivity needs.

Premium v3 + VNet Integration vs ASE v2

Dimension Premium v3 + Regional VNet Integration ASE v2 (Isolated v2)
Network modelOutbound via delegated subnet; inbound still public (use Private Endpoints for inbound)Fully injected into your VNet — both inbound and outbound are private
Inbound accessPublic IP + access restrictions, or Private EndpointInternal Load Balancer (ILB) — no public exposure by default
DNSStandard Azure DNS / custom domainsCustom DNS zone (yourapp.appserviceenvironment.net)
Compute isolationShared multi-tenant stamps (logical isolation)Dedicated single-tenant hardware
Compliance postureGood for most workloads; may not satisfy auditors requiring physical isolationMeets PCI-DSS, HIPAA, FedRAMP requirements for dedicated compute
Deploy timeMinutes2-3 hours (dedicated stamp provisioning)
Cost$$ (pay per instance)$$$$ (flat stamp fee + per instance)
Scale ceiling30 instances per plan100 instances per plan
Zone redundancy✅ (plan-level)✅ (ASE-level)

🔑 Decision Rule

Start with Premium v3 + Private Endpoints. Only escalate to ASE when you need: (1) dedicated/isolated compute for compliance, (2) > 30 instance scale, or (3) custom internal DNS naming for the app itself. Most "we need ASE" conversations end with "Premium v3 + Private Endpoint + Service Endpoints is sufficient."

3. When ASE Is Justified

Compliance Isolation

Auditors for PCI-DSS Level 1 or certain government frameworks require proof that no other tenant's code runs on the same physical hardware. ASE provides single-tenant stamps — you own the entire compute cluster. Premium v3 runs on shared stamps with logical isolation (separate VMs, but shared underlying infrastructure).

Custom Internal DNS

ASE gives you a private DNS zone (e.g., payments.internal.contoso.net) that resolves only within your VNet. Without ASE, you use Private Endpoints and private DNS zones — similar result, but ASE bakes it in natively without managing separate PE resources per app.

Dedicated Compute with High Density

Need 50+ App Service instances for a single app or 100+ across plans? ASE supports up to 100 instances per plan with Isolated v2 SKUs (I1v2 through I6v2 with up to 64 vCPU / 128 GiB RAM per instance). Combined with per-app scaling, this handles extreme multi-tenant SaaS patterns.

📝 Exam Tip

AZ-305 loves "compliance requires network isolation" scenarios. If the question says "no shared infrastructure" or "dedicated hardware" — the answer is ASE (Isolated tier), not Premium + VNet integration. If it just says "private connectivity to backend databases" — Premium + VNet integration or Private Endpoints suffice.

4. Deployment Slots: Blue-Green Pattern

Slots are live app instances with their own hostnames running on the same plan. The swap operation routes traffic atomically — no cold starts, no downtime.

🔑 Slot Settings: Sticky vs Swapped

  • Sticky (slot settings) — stay with the slot, NOT the app code: connection strings marked "slot setting", app settings marked sticky, auth configs, CORS, handler mappings. Use for environment-specific values (e.g., staging DB connection string stays in staging).
  • Swapped — travel with the app code: app settings NOT marked sticky, runtime version, web sockets on/off, managed identity associations. These are your "application configuration."
Warm-Up & Auto-Swap

Warm-Up

Before a swap completes, Azure sends HTTP requests to the staging slot's root (or a custom applicationInitialization path). The swap only finishes when the slot returns HTTP 200. This prevents cold-start latency hitting production users.

<!-- web.config applicationInitialization -->
<applicationInitialization>
    <add initializationPage="/health" />
    <add initializationPage="/api/warmup" />
</applicationInitialization>

Auto-Swap

Configure a slot to auto-swap to production after deployment succeeds. Useful for CI/CD pipelines targeting a staging slot — code lands in staging, warms up, then auto-swaps to production with zero manual intervention.

Traffic Routing (Canary)

Route a percentage of traffic to a non-production slot for canary testing. E.g., send 10% of users to the staging slot to validate before a full swap. Configured per-slot in the Azure portal or via az webapp traffic-routing set.

⚠️ Database migrations must be backward-compatible. Both slots share the same backend. If you deploy breaking schema changes before the swap, the current production code (still running on the old version) will fail. Always use expand-contract migration patterns.

5. Scaling Architecture

🔑 Scale-Up vs Scale-Out

Dimension Scale-Up (vertical) Scale-Out (horizontal)
What changesInstance size (SKU)Number of instances
DowntimeBrief restart during SKU changeNone — new instances added behind LB
LimitLargest SKU in tierTier-dependent (10/30/100)
Use whenSingle-threaded app needs more CPU/RAMStateless app needs more throughput
Autoscale Rules

Autoscale (Standard+) uses rules based on metrics or schedules:

  • Metric-based: CPU%, memory%, HTTP queue length, custom metrics from Application Insights
  • Schedule-based: Scale to 10 instances weekdays 8am-6pm, 2 instances nights/weekends
  • Cool-down: Default 5 minutes between scale actions — prevents flapping

Architecture tip: Always set a minimum instance count ≥ 2 for production. A single instance has no HA — if the underlying node fails, your app is down until a new instance starts.

Per-App Scaling

By default, all apps in a plan run on ALL instances. Per-app scaling (Premium v3+) lets you limit how many instances each app uses. This prevents a noisy-neighbor app from consuming all plan capacity.

Example: A plan with 10 instances hosts 3 apps. App A uses max 5 instances, App B uses max 3, App C uses max 4. The platform distributes across the pool intelligently.

6. Real-World: PCI Compliance — Premium v3 vs ASE

💼 Scenario

A SaaS payment-processing company needs to host their card-data-handling APIs in Azure. Their PCI QSA (Qualified Security Assessor) requires:

  • No shared compute infrastructure with other tenants
  • All traffic to/from the app must traverse private networks only
  • Custom internal DNS for service-to-service communication
  • Ability to scale to 50+ instances during peak processing

❌ Why Premium v3 + VNet Integration Falls Short

  • Compute is on shared multi-tenant stamps — QSA won't accept "logical isolation"
  • Inbound traffic requires Private Endpoints (additional complexity) — not natively private
  • Max 30 instances per plan — below the 50+ requirement

✅ Solution: ASE v2 (ILB mode)

  • Dedicated stamp — single-tenant hardware satisfies QSA's "no shared infrastructure" requirement
  • ILB ASE — no public IP at all; inbound via internal load balancer inside VNet
  • Custom DNS zone — payments.internal.contoso.net resolves only within the VNet
  • 100 instance ceiling — room for 50+ instances with headroom
  • Cost tradeoff — ~$8,000/month stamp fee + per-instance cost. Justified for PCI Level 1 workloads handling millions in card transactions.

Deployment Strategy

Blue-green with slots: deploy to staging slot → run automated PCI compliance scans against staging URL → auto-swap to production after scan passes. Sticky settings hold staging-specific logging levels (verbose) and test connection strings.

Summary

  • Tier = capability gate: Standard unlocks slots; Premium unlocks VNet integration; Isolated unlocks dedicated hardware.
  • VNet integration ≠ ASE: Regional VNet integration (Premium) gives outbound private connectivity. ASE gives full network injection (inbound + outbound).
  • ASE justification: Physical isolation compliance, >30 instances, native internal DNS.
  • Slots = zero-downtime deployments: Swap is atomic. Sticky settings stay with slots. Always warm up before swap.
  • Scale-out > Scale-up for stateless apps. Always min 2 instances in production. Use per-app scaling to prevent noisy neighbors.

Knowledge Check