Cloud Knowledge

Your Go-To Hub for Cloud Solutions & Insights

Advertisement
Azure Cloud

Azure App Service PaaS: scalable hosting for web apps, APIs, and mobile backends with CI/CD, autoscale, and enterprise security.

Shivam Tiwari 0
Azure App Service PaaS: scalable hosting for web apps, APIs, and mobile backends with CI/CD, autoscale, and enterprise security.
Azure App Service (PaaS): Build & Run Web Apps, REST APIs, and Mobile Backends

Azure App Service (PaaS): Build & Run Web Apps, REST APIs, and Mobile Backends

A complete, production-grade guide to Azure App Service for developers and platform engineers: architecture, CI/CD, autoscale, networking, security, diagnostics, and hands-on troubleshooting with PowerShell, Azure CLI, Kudu, and Microsoft Graph.

Why Azure App Service?

Azure App Service is a fully managed PaaS that abstracts servers, OS patching, capacity planning, and load balancing, so teams can focus on features. You can host modern web apps, REST APIs, and mobile backends using .NET, Java, Python, Node.js, PHP, and Ruby—with built-in CI/CD, autoscaling, diagnostics, and Microsoft Entra ID (Azure AD) authentication.

Zero server admin—patching, OS upgrades, and fleet ops handled for you.
Scale in minutes—increase instances or scale up pricing tiers seamlessly.
Enterprise-ready—SLA, compliance, VNet integration, private access, and App Service Environment.
Observability built-in—Azure Monitor and Application Insights.

1) Fully Managed Platform

App Service is a true PaaS: Microsoft manages compute hosts, OS patching, runtime updates, and load balancers. You select an App Service Plan, deploy code or containers, and the platform handles the rest.

Key Points

  • Managed OS and runtime images for Linux and Windows.
  • Automatic platform maintenance keeps environments secure.
  • Built-in load balancing with health probes and instance healing.
  • Production-grade SLA with Premium/Isolated tiers.

Troubleshooting: Quick Wins

  • Verify platform-level incidents in Azure Service Health.
  • Compare app logs vs. platform events in Log Analytics.
  • Use App Service Diagnostics (“Diagnose and solve problems” blade) for guided checks.

PowerShell: Create Plan + Web App

# Requires Az.Resources, Az.Websites modules
$rg = "rg-appsvc-demo"
$loc = "EastUS"
$plan = "asp-prod-p1v3"
$app  = "webapp-prod-001"

New-AzResourceGroup -Name $rg -Location $loc
New-AzAppServicePlan -Name $plan -ResourceGroupName $rg -Location $loc -Tier "PremiumV3" -WorkerSize "P1v3" -NumberofWorkers 2 -Linux
New-AzWebApp -Name $app -ResourceGroupName $rg -Location $loc -AppServicePlan $plan -Runtime "DOTNET:8"

Tip: Size up or down the plan without redeploying the app code.

Quick FAQ (10)

  1. Is the OS patched automatically? Yes, App Service handles OS/runtime patching.
  2. Do I manage load balancers? No, built-in L4/L7 load balancing is included.
  3. Can I deploy containers? Yes, both single container and multi-container (compose) on Linux.
  4. Does the plan isolate apps? Apps share the plan’s VMs; ASE offers full isolation.
  5. How to check platform issues? Service Health + Resource Health + Diagnostics.
  6. How to scale? Scale up (SKU) or out (instances) in the plan’s Scale blade.
  7. What runtimes are supported? .NET, Java, Node, Python, PHP, Ruby (on Linux).
  8. Can I pin runtimes? Yes—choose major/minor stack versions per app.
  9. How to automate creation? ARM/Bicep, Terraform, Az PowerShell, Azure CLI.
  10. Does PaaS support WebSockets? Yes—enable it in Configuration > General Settings.

2) Multi-language Support (.NET, Java, Python, Node, PHP, Ruby)

Choose a language/runtime and deploy without changing your architecture. Platform images are tuned for .NET, Java, Python, Node.js, PHP, and Ruby (Linux).

Key Points

  • Pick a runtime stack + version in Configuration.
  • Use custom container if you need system dependencies.
  • Node/Java apps can specify startup commands or scripts.

Azure CLI: Create Node.js App

rg=rg-appsvc-demo
loc=eastus
plan=asp-web-prod
app=web-node-001

az group create -n $rg -l $loc
az appservice plan create -n $plan -g $rg --sku P1v3 --is-linux
az webapp create -g $rg -p $plan -n $app --runtime "NODE|20-lts"
az webapp config appsettings set -g $rg -n $app --settings NODE_ENV=production ENABLE_ORYX_BUILD=true

Quick FAQ (10)

  1. How do I set Python version? Choose stack in Configuration > General settings.
  2. Does Java need an app server? Linux App Service supports Java SE or Tomcat images.
  3. Can I bring system libs? Yes with custom Docker images.
  4. Is PHP supported on Windows? Use Linux for current PHP runtime support.
  5. Can I run .NET 8? Yes, select .NET 8 stack.
  6. Start script for Node? Set Startup Command or use package.json scripts.
  7. JVM tuning? Use JAVA_OPTS in app settings.
  8. pip/npm restore? Oryx builder handles dependencies at build/deploy.
  9. Ruby supported? Yes on Linux containers or bring your own image.
  10. Localization? Configure culture/timezone via settings and code.

3) Host Web Apps, REST APIs, and Mobile Backends

App Service specializes in stateless HTTP workloads—web front-ends, JSON APIs, GraphQL, and mobile gateway backends. Add persistence via Azure SQL Database, Azure Storage, or Cosmos DB.

Key Points

  • Enable ARR Affinity only when sticky sessions are required.
  • Use Azure API Management in front of APIs for throttling, auth, and versioning.
  • Cache layer: Azure Cache for Redis to reduce load.

Kudu Zip Deploy (PowerShell)

$user = "$(Get-AzWebAppPublishingProfile -Name webapi-001 -ResourceGroupName rg-appsvc | Select-Object -ExpandProperty PublishingUserName)"
$pass = "$(Get-AzWebAppPublishingProfile -Name webapi-001 -ResourceGroupName rg-appsvc | Select-Object -ExpandProperty PublishingPassword)"
$pair = "$($user):$($pass)"
$base64 = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes($pair))
$hdr = @{ Authorization = "Basic $base64" }
Invoke-RestMethod -Uri "https://webapi-001.scm.azurewebsites.net/api/zipdeploy" -Method POST -Headers $hdr -InFile ".\drop.zip" -ContentType "application/zip"

Quick FAQ (10)

  1. Should I use APIM? Yes for API security, throttling, and developer portal.
  2. GraphQL OK? Yes—host it like any Node/.NET API.
  3. Mobile push? Use Notification Hubs; App Service hosts the backend.
  4. File uploads? Send to Blob Storage; keep apps stateless.
  5. gRPC? Use HTTP/2 support and appropriate runtime.
  6. Rate limiting? APIM or NGINX in container; app logic where needed.
  7. Long running jobs? Offload to WebJobs, Functions, or Queues.
  8. Static web? Prefer Static Web Apps; or cache at CDN.
  9. Multipart forms? Stream to storage to avoid memory spikes.
  10. JSON size limits? Tune server and client; paginate responses.

4) Integrated DevOps & CI/CD

App Service plugs into Azure DevOps, GitHub, Bitbucket, and other providers for continuous delivery. Use GitHub Actions or Azure Pipelines to build with Oryx and deploy across slots.

Key Points

  • Zero-downtime deployment using slots + health checks.
  • Oryx builds auto-detect language & lock dependency versions.
  • Use staged rollouts with slot traffic (% based).

PowerShell: Create Slots + Swap

$rg="rg-appsvc-demo"; $app="webapp-prod-001"
New-AzWebAppSlot -Name $app -ResourceGroupName $rg -Slot "staging"
# Deploy to 'staging' (via your pipeline), then swap:
Switch-AzWebAppSlot -Name $app -ResourceGroupName $rg -SourceSlotName "staging" -DestinationSlotName "production"

Azure CLI: Set Up Deployment from GitHub

az webapp deployment source config \
  --name webapp-prod-001 --resource-group rg-appsvc-demo \
  --repo-url https://github.com/yourorg/yourrepo --branch main --manual-integration

Quick FAQ (10)

  1. Can I use GitHub Actions? Yes—use the Azure Web Apps deploy action.
  2. Blue/green? Use slots and Swap with traffic ramp-up.
  3. Infra as code? ARM/Bicep/Terraform are all supported.
  4. Monorepos? Build matrix or path filters in pipelines.
  5. Secrets? Store in Key Vault and reference via managed identity.
  6. Rollback? Swap back or redeploy previous artifact.
  7. Pre-prod testing? Staging slot + smoke tests + warmup.
  8. Package types? Zip deploy, container images, or Run-From-Package.
  9. Build cache? Oryx caches package restore to speed builds.
  10. Approvals? Use pipelines’ environments & checks.

5) Built-in Auto Scaling

Scale out based on CPU, memory, HTTP queue length, or custom metrics via Azure Monitor. Scale up to larger SKUs for more CPU/RAM/IOPS.

PowerShell: Autoscale Rules

$rg="rg-appsvc-demo"; $plan="asp-prod-p1v3"
$profile = New-AzAutoscaleProfile -Name "default" -DefaultCapacity 2 -MinimumCapacity 2 -MaximumCapacity 10
$scaleOut = New-AzAutoscaleRule -MetricName "CpuPercentage" -MetricResourceId (Get-AzAppServicePlan -Name $plan -ResourceGroup $rg).Id `
  -Operator GreaterThan -MetricStatistic Average -Threshold 70 -TimeGrain 00:01:00 -TimeWindow 00:05:00 -ScaleActionDirection Increase -ScaleActionValue 1 -ScaleActionCooldown 00:05:00
$scaleIn = New-AzAutoscaleRule -MetricName "CpuPercentage" -MetricResourceId (Get-AzAppServicePlan -Name $plan -ResourceGroup $rg).Id `
  -Operator LessThan -MetricStatistic Average -Threshold 35 -TimeGrain 00:01:00 -TimeWindow 00:10:00 -ScaleActionDirection Decrease -ScaleActionValue 1 -ScaleActionCooldown 00:10:00
Add-AzAutoscaleSetting -Name "asp-autoscale" -ResourceGroup $rg -Location "EastUS" -TargetResourceId (Get-AzAppServicePlan -Name $plan -ResourceGroup $rg).Id -AutoscaleProfile $profile -AutoscaleRule $scaleOut,$scaleIn

Key Points

  • Warmup settings reduce cold starts after scale out.
  • Set Health Check Path to route around bad instances.
  • Use Min instance floor to absorb traffic spikes.

Quick FAQ (10)

  1. Horizontal vs. vertical? Out = more instances; up = bigger SKU.
  2. Custom metrics? Yes via Azure Monitor metric alerts.
  3. Schedule-based scaling? Define time windows in autoscale profiles.
  4. Pre-warming? Use Always On + warmup requests.
  5. Health probe path? Configure under Health check.
  6. Autoscale cooldown? Avoid oscillation; 5–10 min works well.
  7. Per app scaling? Scaling is at plan level; isolate critical apps in their own plan.
  8. Cost guardrails? Set max instances + budget alerts.
  9. Queue length metric? Use HttpQueueLength for backpressure.
  10. Memory rules? Use MemoryWorkingSet metric on Windows plans.

6) Global Availability

Deploy apps close to your users across global regions for low latency and failover. Use slot swaps and geo-redundant deployment patterns with Traffic Manager or Front Door.

Key Points

  • Active/active with Front Door + health probes.
  • Blue/green per region with independent slots.
  • Geo-replicate state (database/storage) appropriately.

CLI: Deploy Same App Name in Multiple Regions

for r in "eastus" "westeurope"; do
  az group create -n rg-$r -l $r
  az appservice plan create -g rg-$r -n asp-$r --is-linux --sku P1v3
  az webapp create -g rg-$r -p asp-$r -n myapp-$r --runtime "NODE|20-lts"
done

Quick FAQ (10)

  1. How do I fail over? Front Door routes around unhealthy backends.
  2. DNS vs. Front Door? Front Door adds WAF, TLS, and anycast edge.
  3. Data replication? Choose geo-replicated DB/storage strategy.
  4. Latency testing? Use Front Door metrics + RUM in App Insights.
  5. Certs per region? Manage centrally in Front Door, or per app.
  6. Deployment per region? Pipeline stages per environment/region.
  7. Same name globally? App names are DNS global; use suffix by region.
  8. Edge caching? Use CDN/Front Door caching for static assets.
  9. DR drills? Practice region evacuation with scripts.
  10. RPO/RTO? Define based on data tier (SQL/Storage) not App Service.

7) Custom Domains & SSL/TLS

Map vanity domains and secure with free App Service Managed Certificates or bring certs from Key Vault.

PowerShell: Bind Certificate

$rg="rg-appsvc-demo"; $app="webapp-prod-001"
# Upload PFX (if not using Key Vault)
$bytes = [IO.File]::ReadAllBytes(".\tls.pfx")
$enc = [Convert]::ToBase64String($bytes)
New-AzWebAppSSLBinding -WebAppName $app -ResourceGroupName $rg -CertificateFilePath ".\tls.pfx" -CertificatePassword (Read-Host "PFX Password" -AsSecureString) -Name "www.contoso.com"

Key Points

  • Use free managed certs for basic TLS; rotate automatically.
  • Prefer Key Vault references for enterprise key management.
  • Redirect HTTP to HTTPS in app or via rewrite rules.

Quick FAQ (10)

  1. Wildcard certs? Supported—upload PFX or use Key Vault.
  2. Auto renew? Managed certs renew automatically.
  3. ACME? Use Key Vault + automation or external ACME clients.
  4. Mutual TLS? App Service supports mTLS at app level.
  5. HSTS? Add headers via web.config or middleware.
  6. Non-www to www? Rewrite rules or app logic.
  7. Multiple domains? Bind multiple hostnames per app.
  8. IP-based SSL? SNI is default; IP SSL only if required.
  9. Key rotation? Automate via Key Vault versioned secrets.
  10. TLS 1.0/1.1? Disable; prefer TLS 1.2+ in config.

8) High Availability & Load Balancing

Built-in L7 LB distributes traffic across instances; health checks avoid unhealthy nodes. Premium/Isolated tiers provide higher SLAs for production.

CLI: Health Check Path

az webapp config set -g rg-appsvc-demo -n webapp-prod-001 --health-check-path "/health"

Key Points

  • Instrument /health to verify DB/cache connectivity.
  • Use Always On to prevent idle unloads.
  • Warmup slots before swapping to reduce cold starts.

Quick FAQ (10)

  1. LB sticky sessions? Enable ARR Affinity if needed.
  2. Zero-downtime? Use staging slot + swap with warmup.
  3. Circuit breakers? Implement in app or API gateway.
  4. Slow start? Health check + warmup scripts.
  5. Graceful shutdown? Handle SIGTERM; reduce timeouts.
  6. Scaling LB? Plan capacity at App Service Plan level.
  7. HTTP/2? Supported; enable if required.
  8. WebSockets? Turn on under General Settings.
  9. gRPC over HTTP/2? Supported on Linux with proper config.
  10. Timeouts? Tune client/server; default gateway limits apply.

9) Deployment Slots (Staging, Testing, Production)

Slots let you deploy and test without touching production. Swap when ready; swap-settings control which app settings/connection strings stay in each slot.

PowerShell: Slot Settings

$rg="rg-appsvc-demo"; $app="webapp-prod-001"
$settings = @{ "ASPNETCORE_ENVIRONMENT"="Staging"; "FeatureFlag__NewUI"="true" }
Set-AzWebAppSlot -Name $app -ResourceGroupName $rg -Slot "staging" -AppSettings $settings -ConnectionStrings @()

Key Points

  • Mark secrets as slot-specific where values differ.
  • Use Swap with Preview to validate after warmup.
  • Rollback instantly by swapping back.

Quick FAQ (10)

  1. Can I have many slots? Yes—limits depend on SKU.
  2. Share storage? Each slot has its own content root.
  3. Traffic splitting? Route % traffic to a slot.
  4. DB migrations? Run pre-swap scripts before promote.
  5. Secrets? Use Key Vault refs; mark as slot settings.
  6. Logs per slot? Yes—diagnostics are slot-scoped.
  7. Custom domains? Bind to production slot.
  8. APM keys? Different per slot for isolation.
  9. Swap conflicts? Review Swap diff in portal.
  10. Blue/green? Production and staging = blue/green.

10) Integrated Monitoring & Logging

Stream application logs, request telemetry, and metrics to Application Insights and Log Analytics. Use Kudu to inspect files and processes.

Enable Logs (CLI)

az webapp log config -g rg-appsvc-demo -n webapp-prod-001 --application-logging filesystem --level Information --docker-container-logging filesystem
az webapp log tail -g rg-appsvc-demo -n webapp-prod-001

KQL: Slow Requests in the Last 1h

requests
| where timestamp > ago(1h)
| where duration > 1000ms
| project timestamp, name, url, duration, resultCode, operation_Id
| order by duration desc

Key Points

  • Use Failed request tracing to debug 4xx/5xx.
  • Collect app logs to Log Analytics for long-term retention.
  • Alert on error rate, latency, and CPU with action groups.

Quick FAQ (10)

  1. Live log tail? Yes via CLI or Kudu log stream.
  2. Log retention? Configure in Log Analytics workspace.
  3. PII in logs? Mask/redact before emitting.
  4. Distributed tracing? Ensure correlation headers flow.
  5. Sampling? Tune App Insights sampling to control cost.
  6. Custom metrics? Track via SDK and query in KQL.
  7. Crash dumps? Use Procdump via Kudu on Windows.
  8. Structured logs? JSON logging makes KQL easier.
  9. Alert fatigue? Use dynamic thresholds and suppression.
  10. Log shipping? Diagnostic settings route to multiple sinks.

11) Authentication & Authorization (EasyAuth)

Enable built-in auth against Microsoft Entra ID, GitHub, Google, Facebook, and Twitter—no code required. For advanced flows, use your own middleware.

CLI: Enable Entra ID Auth (EasyAuth)

az webapp auth set -g rg-appsvc-demo -n webapp-prod-001 \
  --enabled true \
  --action LoginWithAzureActiveDirectory \
  --aad-allowed-token-audiences https://webapp-prod-001.azurewebsites.net/.auth/login/aad/callback

Graph API: Sanity-check the Enterprise App (Service Principal)

# Using Microsoft Graph CLI (mgc). Ensure you've consented Directory.Read.All as needed.
mgc login
mgc beta service-principals list --filter "displayName eq 'webapp-prod-001'"

Key Points

  • Use EasyAuth for quick SSO; bring middleware for custom policies.
  • Protect APIs with tokens—validate audience/issuer in code.
  • Use App Roles or Groups for authorization.

Quick FAQ (10)

  1. Is EasyAuth production-ready? Yes; many teams ship with it.
  2. Token forwarding to API? Configure Unauthenticated requests + Allowed token audiences.
  3. Roles in tokens? Define app roles in Entra app registration.
  4. Custom policy? Use your own middleware or APIM policies.
  5. B2C? Use Azure AD B2C as identity provider to EasyAuth.
  6. Logout? Call /.auth/logout endpoint.
  7. Token refresh? Rely on provider; use MSAL on client.
  8. Impersonation? Use On-behalf-of flow in your API.
  9. Anonymous pages? Configure Allow unauthenticated for those routes.
  10. WAF? Put Front Door WAF in front of the app if needed.

12) App Service Environment (ASE)

For high security and isolation, use ASE to host apps in a dedicated subnet with private IPs and scale capabilities.

Key Points

  • Private networking only—no public endpoints if desired.
  • Best for regulated workloads needing isolation.
  • Higher cost but stronger boundaries and capacity.

Quick FAQ (10)

  1. When to choose ASE? Isolation, private networking, and high scale.
  2. Public access? Optional—can be disabled.
  3. Cost? Higher than shared plans; plan accordingly.
  4. VNet address space? Plan subnets carefully for growth.
  5. Private DNS? Configure split-horizon where needed.
  6. Ingress? Private endpoints or internal load balancers.
  7. Hybrid? Combine with ExpressRoute for on-prem access.
  8. Migration? Redeploy via IaC + data migration.
  9. Monitoring? Same App Insights/Monitor patterns apply.
  10. WAF? Use Application Gateway WAF or Front Door.

13) VNet Integration

Securely reach private resources via VNet integration or expose your app privately via Private Endpoints. Combine with ExpressRoute or VPN for on-prem.

PowerShell: Add VNet Integration

$rg="rg-appsvc-demo"; $app="webapp-prod-001"
Add-AzWebAppVnetConnection -ResourceGroupName $rg -Name $app -VnetResourceGroupName "rg-network" -VnetName "vnet-apps" -SubnetName "snet-integration"

Key Points

  • Integration subnet must have enough free IPs; disable subnet delegation conflicts.
  • Use private DNS zones for name resolution of private endpoints.
  • NSGs and UDRs can control outbound traffic from the integration subnet.

Quick FAQ (10)

  1. Inbound private? Use Private Endpoint for inbound.
  2. Outbound private? VNet integration for egress to private resources.
  3. Static outbound IP? Use NAT Gateway on the integration subnet.
  4. DNS? Use Azure Private DNS or custom DNS servers.
  5. Firewall? Use Azure Firewall with UDRs for egress policies.
  6. SNAT exhaustion? NAT Gateway helps expand SNAT ports.
  7. Hybrid? Integrate with VPN/ExpressRoute to on-prem.
  8. Multiple VNets? One integration at a time; use peering to reach others.
  9. Latency? Prefer same-region VNets where possible.
  10. Diagnostics? Use Connection Troubleshoot in Network Watcher.

14) Managed Identities (MSI)

Avoid secrets—use System-assigned or User-assigned Managed Identities to access Key Vault, Storage, SQL, and other Azure services.

PowerShell: Assign MSI + Grant Key Vault Access

$rg="rg-appsvc-demo"; $app="webapp-prod-001"; $kv="kv-prod-001"
# Assign MSI
$web = Get-AzWebApp -Name $app -ResourceGroupName $rg
$web = Set-AzWebApp -Name $app -ResourceGroupName $rg -AssignIdentity
$principalId = $web.Identity.PrincipalId

# Grant Vault access via RBAC role (recommended)
New-AzRoleAssignment -ObjectId $principalId -RoleDefinitionName "Key Vault Secrets User" -Scope (Get-AzKeyVault -VaultName $kv -ResourceGroupName $rg).ResourceId

Code Snippet: Read Secret (C#)

var client = new SecretClient(new Uri("https://kv-prod-001.vault.azure.net/"),
    new DefaultAzureCredential());
var secret = await client.GetSecretAsync("DbPassword");

Quick FAQ (10)

  1. System vs. user-assigned? System tied to app; user-assigned reusable.
  2. Key Vault references? Use @Microsoft.KeyVault(SecretUri=...) in app settings.
  3. Rotate secrets? No app changes—identity stays constant.
  4. Graph access? Grant roles on Graph as needed.
  5. SQL access? Use Entra auth for SQL with MSI.
  6. Storage SAS? Prefer role-based access, not keys.
  7. Least privilege? Grant minimal roles at specific scopes.
  8. Diagnostics? Check token acquisition failures in logs.
  9. Local dev? Use developer credentials via DefaultAzureCredential chain.
  10. Multi-tenant? Ensure correct tenant is targeted.

15) Container Support (Docker & Custom Images)

Run custom Linux/Windows containers for full control over runtime and dependencies. Pull from ACR or public registries.

CLI: Configure Container Deploy

az webapp create -g rg-appsvc-demo -p asp-linux -n web-cnt-001 \
  --deployment-container-image-name contoso.azurecr.io/app:1.0.0

az webapp config container set -g rg-appsvc-demo -n web-cnt-001 \
  --docker-custom-image-name contoso.azurecr.io/app:1.0.1 \
  --docker-registry-server-url https://contoso.azurecr.io

Key Points

  • Use WEBSITES_PORT app setting to expose container port.
  • Health check path should hit container liveness endpoint.
  • Prefer minimal bases (Alpine/Distroless) for smaller attack surface.

Quick FAQ (10)

  1. Multi-container? Use docker-compose on Linux.
  2. Private registry? Use admin creds or ACR with Managed Identity.
  3. Startup cmd? Set in Startup Command or Dockerfile CMD.
  4. Logs? Container STDOUT/ERR captured by platform.
  5. Persistent volumes? Limited; design stateless apps.
  6. Sidecars? Use multi-container; or move to AKS if complex.
  7. GPU? Not available; use AKS for GPU workloads.
  8. Privileged? Not supported; containers run restricted.
  9. Inbound TLS? Platform handles TLS; container can be HTTP.
  10. Port conflicts? Expose only a single HTTP port.

16) Hybrid Connectivity

Access on-prem databases/APIs using Hybrid Connections or ExpressRoute. For HTTP/S, consider APIM or reverse proxies to simplify routing.

Key Points

  • Hybrid Connections are TCP-based; ensure ports are open on-prem.
  • For strict security, use VNet Integration + ER/VPN + private endpoints.
  • Monitor relay status to detect connectivity issues.

Quick FAQ (10)

  1. Is it encrypted? Yes—over Azure Relay.
  2. DB latency? Keep regions close to on-prem for best RTT.
  3. Firewall? Allow outbound to Relay endpoints.
  4. DNS names? Use hostnames or IPs reachable via hybrid link.
  5. High throughput? Prefer VNet + ER for heavy data flows.
  6. Failover? Secondary link or region for resiliency.
  7. HA DB? Implement DB-side clustering/replication.
  8. Monitoring? Azure Monitor metrics for connections.
  9. Costs? Relay usage charges apply.
  10. Protocol? TCP only; not UDP.

17) Backup & Restore

Automate app and content backups to Blob Storage; capture DB backups at the database tier (SQL, Cosmos, etc.).

PowerShell: Create Backup

$rg="rg-appsvc-demo"; $app="webapp-prod-001"; $storage="stbackups001"
New-AzWebAppBackup -ResourceGroupName $rg -Name $app -StorageAccountUrl "https://$storage.blob.core.windows.net/backups?<SAS>" -BackupName "on-demand-$(Get-Date -Format yyyyMMddHHmm)"

PowerShell: Restore Backup

Restore-AzWebAppBackup -ResourceGroupName $rg -Name $app -StorageAccountUrl "https://$storage.blob.core.windows.net/backups?<SAS>" -BlobName "on-demand-20251102.zip" -Overwrite

Key Points

  • Test restores quarterly; document RTO/RPO.
  • Store DB backups natively; app backup ≠ DB backup.
  • Encrypt backup containers; manage SAS rotation.

Quick FAQ (10)

  1. What gets backed up? Site content + settings; not external DBs.
  2. Frequency? Schedule daily or as compliance requires.
  3. Retention? Use lifecycle rules on the backups container.
  4. Point-in-time? Use DB native PITR features.
  5. Cross-region? Copy backups to paired region storage.
  6. Encrypted? Use storage encryption + private endpoints.
  7. Cost? Storage + transactions; modest for typical apps.
  8. Restore to slot? Yes—restore into staging to verify.
  9. Permissions? SAS with write/list for backup; read for restore.
  10. Automation? Runbook or pipeline to trigger on demand.

18) App Service Plans & Pricing Tiers

Choose capacity: Free/Shared for experiments; Basic/Standard for dev/test; PremiumV3/Isolated for production; ASE for isolation.

CLI: Resize Plan

az appservice plan update -g rg-appsvc-demo -n asp-prod-p1v3 --sku P2v3

Key Points

  • Apps in same plan share compute—watch noisy neighbor effects.
  • Isolate critical apps in dedicated plans.
  • Use budgets and cost alerts.

Quick FAQ (10)

  1. Per-app scaling? Plan-level; split apps across plans.
  2. Burst loads? Use autoscale with min instance floor.
  3. Dev/test savings? Auto-stop in off hours.
  4. Premium vs. Standard? Premium adds v3 hardware, better perf, features.
  5. Isolated? Dedicated environment with network isolation.
  6. Function Apps? Can share a plan; or use Consumption.
  7. Multiple regions? Separate plans per region.
  8. Scale to zero? Not on Web Apps; use Functions for serverless.
  9. Capacity limits? Check SKU limits per region.
  10. SLA tiers? Premium/Isolated for higher SLA targets.

19) Continuous Integration with Git

Connect a repo directly for automatic builds; or use pipelines for controlled deployments and approvals.

CLI: Local Git Deployment

az webapp deployment source config-local-git -g rg-appsvc-demo -n webapp-prod-001
# Then push to the provided Git remote URL

Key Points

  • Prefer CI pipelines for secrets scanning and quality gates.
  • Enforce branch protections and PR checks.
  • Use Workload identity for GitHub to avoid publish profiles.

Quick FAQ (10)

  1. SSH deploy? Use Git deploy over HTTPS; for containers, push to ACR.
  2. Publish profiles? Short-term; prefer OIDC federation.
  3. Artifacts? Use zip/run-from-package for repeatability.
  4. Pre/post scripts? Add to pipeline stages.
  5. Infra validation? Validate via IaC lints/tests.
  6. Secrets scanning? Enable CodeQL/secret scanners.
  7. Rollback via Git? Redeploy previous artifact or slot swap back.
  8. Tagging? Tag builds for traceability.
  9. SBOM? Generate during build for compliance.
  10. SLSA? Harden supply chain with signed artifacts.

20) Deployment Options: FTP/S, GitHub Actions, DevOps, ZIP, ARM/Bicep, CLI

Choose the right path for your team maturity and compliance needs. For enterprises, prefer pipelines with approvals and artifact retention.

ZIP Run-From-Package (CLI)

az webapp deployment source config-zip -g rg-appsvc-demo -n webapp-prod-001 --src "./drop/app.zip"

Key Points

  • Run-From-Package mounts the ZIP read-only for consistency.
  • Use slots to validate before promote.
  • Prefer CI/CD over manual FTP.

Quick FAQ (10)

  1. FTP allowed? Yes but restrict; prefer pipeline deploys.
  2. Storage mapping? Avoid writing to local file system.
  3. Oryx? Auto build detects language and runs install.
  4. Package lock? Commit lockfiles for deterministic builds.
  5. Node pm2? Use startup command or ecosystem file.
  6. Java WAR? Deploy to Tomcat image slots.
  7. Python WSGI? Configure gunicorn/uvicorn appropriately.
  8. App offline? Use app_offline.htm for maintenance windows.
  9. Long deploys? Use SCM site and monitor logs.
  10. Compression? Optimize ZIP to reduce upload time.

21) Serverless Integration with Azure Functions

Offload event-driven workloads to Azure Functions. Use queues, Event Grid, or Service Bus to decouple and smooth bursts.

Key Points

  • Web app handles sync requests; Functions handle async work.
  • Share libraries via artifacts or private feeds.
  • Use Durable Functions for orchestrations.

Quick FAQ (10)

  1. Same plan? Functions can run on a dedicated plan or Consumption.
  2. Cold starts? Mitigate with Premium plans.
  3. Auth? Same Entra ID/EasyAuth patterns apply.
  4. Queues? Storage Queues or Service Bus.
  5. At-least-once? Enable poison queues and retries.
  6. Idempotency? Design handlers to be idempotent.
  7. Fan-out? Use Durable orchestrations.
  8. Observability? App Insights with distributed tracing.
  9. Scale? Functions scale automatically with triggers.
  10. Cost? Pay per execution on Consumption tier.

22) Custom Startup Scripts

Configure startup commands on Linux apps to run migrations, seed caches, or start custom processes.

CLI: Set Startup Command

az webapp config set -g rg-appsvc-demo -n webapp-prod-001 --startup-file "python /home/site/wwwroot/start.py"

Key Points

  • Keep startup under ~60–90s to avoid health failures.
  • Log progress to STDOUT for troubleshooting.
  • Use slots to run migrations before swap.

Quick FAQ (10)

  1. Where to put scripts? In the site content directory.
  2. Environment vars? Configure in App Settings.
  3. Multiple commands? Use a shell wrapper.
  4. Permissions? Ensure executable bit for scripts.
  5. Long migrations? Run offline in job/Function.
  6. Logs not visible? Use Kudu process console.
  7. Timeouts? Keep startup under health probe intervals.
  8. Secrets? Pull via Managed Identity and Key Vault.
  9. Crash on start? Check docker logs or app logs.
  10. Node build? Move builds to CI—don’t compile at startup.

23) Diagnostic Tools (Kudu, App Service Diagnostics, Advanced Tools)

Use Kudu for filesystem/process analysis; App Service Diagnostics for guided checks and insights.

PowerShell: Process Dump (Windows)

# Via Kudu PowerShell console run procdump when process spikes:
procdump -ma w3wp -accepteula

Key Points

  • Kudu: https://<app>.scm.azurewebsites.net for tools and APIs.
  • Diagnose blade highlights common issues: memory leaks, 5xx spikes, cold starts.
  • Download event logs and HTTP logs for offline analysis.

Quick FAQ (10)

  1. Where are logs? D:\home\LogFiles (Windows) or /home/LogFiles (Linux).
  2. Remote Console? Available via Kudu (CMD/PowerShell/Bash).
  3. Site extensions? Install APM/utility extensions.
  4. Thread dumps? Use jstack for Java containers.
  5. Node inspector? Attach inspector to running process.
  6. Memory leak? Enable memory dumps at thresholds.
  7. High CPU? Capture CPU profile via Diagnostics.
  8. 404 spikes? Check rewrite rules and static asset paths.
  9. Cold starts? Turn on Always On; pre-warm slots.
  10. Port conflicts? Ensure only a single exposed port.

24) Scaling Rules & Autoscale Settings

Fine-tune autoscale using multiple metrics and schedules.

CLI: Queue Length Scale

az monitor autoscale rule create \
  --resource /subscriptions/<subId>/resourceGroups/rg-appsvc-demo/providers/Microsoft.Web/serverfarms/asp-prod-p1v3 \
  --condition "HttpQueueLength > 200 avg 5m" --scale out 1

Key Points

  • Separate rules for business hours vs. off-hours.
  • Use dynamic thresholds to reduce alert noise.
  • Always define a max instance cap.

Quick FAQ (10)

  1. Instance warmup? Add cooldown to allow startup.
  2. Custom logic? Push custom metrics to Monitor.
  3. Can I pin min=0? Keep at ≥1 to avoid cold starts; Web Apps don’t scale to zero.
  4. Per slot? Scaling is at plan level, not slot level.
  5. Budget safety? Set budget alerts and max instances.
  6. Weekend profile? Use schedule profiles.
  7. Throttle storms? Combine with APIM rate limiting.
  8. Backoff? Use longer time windows for stability.
  9. Traffic draining? Health check + slot warmup.
  10. Chaos testing? Validate behavior under failover.

25) Application Settings & Configuration Management

Manage environment variables, connection strings, and feature flags from the portal, CLI, or templates.

CLI: Bulk Apply Settings

az webapp config appsettings set -g rg-appsvc-demo -n webapp-prod-001 --settings \
  ASPNETCORE_ENVIRONMENT=Production FeatureFlag__NewUI=false Logging__Level__Default=Information

Key Points

  • Use slot settings where values differ by environment.
  • Centralize secrets in Key Vault; reference via app settings.
  • Use feature flags to decouple releases from launches.

Quick FAQ (10)

  1. Config drift? Enforce via IaC and pipeline checks.
  2. Per-env values? Maintain env-specific parameter files.
  3. Hot reload? Some stacks support dynamic reload; otherwise restart.
  4. Secrets in code? Avoid; use MSI + Key Vault.
  5. Audit changes? Activity Log + deployment logs.
  6. App restart? Some changes restart the app—deploy via slots.
  7. Configuration backup? Export ARM template or use backups.
  8. Feature management? Use App Configuration service for flags.
  9. Per-slot settings? Mark as slot setting.
  10. Rollback configs? Keep versioned config artefacts.

26) API Management (APIM) Integration

Put APIM in front of apps for API gateway features—security, quotas, versioning, and developer portal.

Key Points

  • Offload JWT validation and transformations to APIM policies.
  • Use products/subscriptions for external partners.
  • Protect backend with private endpoints and VNet.

Quick FAQ (10)

  1. Self-hosted gateway? For hybrid/on-prem scenarios.
  2. Rate limits? Set in policies per product/API.
  3. Versioning? Header or path-based versioning.
  4. OpenAPI? Import from OpenAPI specs.
  5. Caching? Use APIM response cache.
  6. mTLS? Configure client certs policy.
  7. Debug policies? Use trace mode.
  8. Gateway private? Use VNet injected tier.
  9. Dev portal? Publish API docs to partners.
  10. Latency? Keep gateways regional to backends.

27) WebJobs & Background Tasks

Run scheduled or continuous jobs alongside your web app for maintenance, batch work, and integrations.

Key Points

  • Prefer Functions for scalable event-driven work; WebJobs for simple co-deployment.
  • Schedule via CRON expressions in settings.
  • Monitor job logs in Kudu/LogFiles.

Quick FAQ (10)

  1. Continuous vs. triggered? Continuous runs always; triggered by schedule or on demand.
  2. Language? C#, Node, Python supported.
  3. Isolation? Jobs share the plan with the web app.
  4. Long tasks? Use Functions or separate worker plan.
  5. Retry? Implement retry logic in the job code.
  6. Job secrets? Use Key Vault/MSI.
  7. Scale? Follows the plan scaling.
  8. Debug? Kudu console + logs.
  9. Deploy? Zip deploy with App_Data/jobs structure.
  10. Timers? CRON format in settings.

28) Compliance & Security Standards

App Service supports enterprise compliance needs (ISO, SOC, HIPAA, GDPR, PCI DSS). Combine with secure network patterns and identity controls.

Security Controls Checklist

  • Private endpoints + VNet egress.
  • Managed Identity + Key Vault.
  • WAF at edge (Front Door or AppGW).
  • Threat detection with Defender for Cloud.
  • Code scanning (SAST/DAST) in CI.

Quick FAQ (10)

  1. Pen tests? Follow Microsoft cloud pen guidance.
  2. Data residency? Choose regions that meet policy.
  3. PII? Classify and encrypt at rest/in transit.
  4. Keys? Store only in Key Vault.
  5. Access reviews? Use Entra access reviews and PIM.
  6. Audit? Enable diagnostic logs to Log Analytics.
  7. WAF mode? Start in detection, move to prevention.
  8. Least privilege? Adopt RBAC at resource scopes.
  9. Dependency risks? SBOM + vulnerability scans.
  10. Secrets sprawl? Managed Identity first; no keys.

29) Cost Optimization

Keep performance high and bills low with right-sizing, autoscale, and off-hours shutdown.

PowerShell: Stop Dev Plan Overnight

Stop-AzAppServicePlan -Name asp-dev -ResourceGroupName rg-dev
# In an Automation Account, schedule nightly stop and morning start.

Key Points

  • Consolidate low-traffic apps on a shared plan.
  • Split noisy apps into dedicated plans.
  • Use App Insights sampling to control telemetry cost.

Quick FAQ (10)

  1. Budget alerts? Yes via Cost Management.
  2. Right-size? Review CPU/mem 95th percentiles.
  3. Off-hours? Stop non-prod plans automatically.
  4. Logs cost? Set retention and sampling.
  5. Front Door egress? Cache to reduce origin egress.
  6. Containers size? Use small base images.
  7. Dev/test offers? Leverage dev/test pricing.
  8. Autoscale caps? Set max to prevent bill shock.
  9. SQL cost? Choose serverless or scale down.
  10. Storage tiers? Lifecycle older blobs to cool/archive.

30) Deep Integration with Azure Services

App Service natively connects with Azure SQL Database, Azure Storage, Key Vault, Service Bus, Event Grid, and Logic Apps—compose reliable, event-driven architectures.

Key Points

  • Use Event Grid for webhooks and reactive patterns.
  • Service Bus for reliable, ordered, transactional messaging.
  • Logic Apps for no-code/low-code integrations and workflows.

Quick FAQ (10)

  1. Queue choice? Service Bus for enterprise messaging; Storage Queues for simple use cases.
  2. Triggers? Event Grid for push; Functions for handlers.
  3. Key rotation? Use Key Vault and Managed Identity.
  4. File handling? Store in Blob; process via Functions.
  5. Webhooks? Secure with validation tokens/signatures.
  6. Saga pattern? Durable Functions or orchestrators.
  7. Retries? Use policies/queues with DLQs.
  8. Observability? Centralize logs/metrics/traces.
  9. Governance? Tags, policies, blueprints.
  10. SBOM/legal? Track third-party licenses.

Bonus: Typical Use Cases

  • Corporate websites and content portals with global reach.
  • REST APIs for mobile/web clients with APIM fronting.
  • Microservices using containers and event-driven backends.
  • Multi-tenant SaaS with Azure SQL, Storage, and Key Vault.

Pro Tip: Start with PremiumV3 for production, enable Health Check, use slots, and wire App Insights before your first deploy.

© Your Site — Azure App Service guide. Internal links provided to cloudknowledge.in.

Related Story

Leave a Reply

Your email address will not be published. Required fields are marked *