India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Azure App Service, Container Apps & Static Web Apps Services
Azure's web and application platform is a set of managed hosting services: App Service for code or container web apps with deployment slots, Container Apps for serverless containers, and Static Web Apps for globally served front ends, usually behind Azure Front Door. NTSPL moves Indian customer portals, donor platforms and ticketing sites onto them for downtime-free releases and surge-ready scaling.
Microsoft Azure services in scope
The Problem Azure App Service and App Service deployment slots Solve
Customer-facing web applications in India face a specific load shape: quiet for weeks, then 20x traffic in minutes when a project launches, a campaign goes viral on WhatsApp or tickets go on sale. Most are still hosted on two IIS or Nginx VMs where releases mean a maintenance page at midnight, scaling means a ticket to the infrastructure team, and TLS certificates expire unnoticed. The application platform problem is giving developers a release path with no downtime, compute that scales before users see errors, and an edge layer that absorbs bots and caches what it can before traffic reaches the origin.
NTSPL chooses the hosting model per component rather than per application. Server-rendered .NET, Java, PHP or Node.js apps go to App Service with staging slots and swap-with-preview. Containerized APIs and background workers that need scale-to-zero or event-driven scaling go to Container Apps. Marketing and campaign front ends become Static Web Apps with preview environments per pull request. Front Door sits in front of all of them with WAF and caching, and the origins accept traffic only from Front Door.
When to Host on Azure App Service, Container Apps or Static Web Apps (and When to Choose AKS)
Signals that point to web & application platform on Microsoft Azure
- Releases happen after 11 pm behind a maintenance page because there is no way to deploy without interrupting users.
- Web VMs run under 15 percent CPU most of the month but hit 100 percent during launches, campaigns or on-sales.
- TLS certificates, OS patches and runtime upgrades on web servers are tracked manually and have lapsed at least once in the last year.
- A campaign or microsite needs to go live in days and marketing waits on infrastructure tickets for every new one.
- Bots and scrapers make up a visible share of requests, inflating server load and distorting conversion analytics.
When a different approach is better
- Platforms with dozens of microservices needing custom networking, service mesh or node-level control: Azure Kubernetes Service gives that control.
- Legacy apps that depend on COM components, registry settings or installed Windows services: run them on Azure Virtual Machines or Windows containers in AKS.
- Short event-triggered functions like file processing or webhook handlers: Azure Functions on the Flex Consumption plan is cheaper than an always-on web plan.
Azure Web Hosting Building Blocks: App Service Plans, Slots, Container Apps, Static Web Apps and Front Door
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Azure App Service | Hosts web apps and APIs from code or containers on a shared App Service plan, with built-in TLS, autoscale, VNet integration, health checks and managed identity. | A web application written in .NET, Java, Node.js, Python or PHP needs managed hosting without the team operating VMs or Kubernetes. |
| App Service deployment slots | Provide live staging environments with their own hostnames; a swap warms the new version on production settings and exchanges routing without dropping requests. | Releases currently need a maintenance window, or rollback takes longer than a few minutes. |
| Azure Container Apps | Runs containers on a serverless platform built on Kubernetes, with KEDA-based scaling (including to zero), revisions with traffic splitting, Dapr and jobs. | Services are already containerized, load is bursty or event-driven, and the team does not want to manage a Kubernetes cluster. |
| Azure Static Web Apps | Serves static front ends (React, Angular, Next.js static export, Hugo) from globally distributed content with built-in authentication, staging environments per pull request and integrated APIs. | A campaign site, landing page or single-page app front end needs fast global delivery and no server management. |
| Azure Front Door (Standard, Premium) | Acts as a global layer-7 entry point with anycast routing, TLS offload, caching, rules engine and Web Application Firewall, with Premium adding bot protection and Private Link origins. | Public traffic needs WAF, caching and origin failover, or origins must have no public exposure. |
| Azure Load Testing | Generates large-scale HTTP load from JMeter or Locust scripts against staging environments and correlates results with server-side metrics. | A known surge event such as a launch or on-sale is coming and capacity has never been proven at that level. |
Front Door-fronted App Service with slots and Container Apps backends
Front Door-fronted App Service with slots and Container Apps backends
Users reach Azure Front Door Premium, which serves cached static content and Static Web Apps assets at the edge and forwards dynamic requests through Private Link to App Service in Central India. App Service calls containerized APIs and workers on Container Apps inside a VNet, which in turn use Azure SQL and Azure Managed Redis through private endpoints.
Select any component
Front Door-fronted App Service with slots and Container Apps backends: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 5-step primary path.
Azure Web Platform Engineering Decisions: Plan Tier, Slot Strategy, Scaling Rules and Edge Caching
App Service plan tier and density
Use Premium v3 for production: it gives more memory per core, faster scale-out, zone redundancy and is covered by the Savings Plan for compute. Standard gives up to five deployment slots and Premium up to 20. Several apps can share one plan, so group apps with similar load profiles and keep noisy ones separate. Isolated v2 in an App Service Environment is justified only when a dedicated single-tenant network boundary is mandated.
Slot strategy and swap safety
Deploy to a staging slot, run smoke tests against its hostname, then swap with preview so the target slot's settings are applied and the app warms before traffic moves. Mark database connection strings and feature flags as deployment slot settings so they stay with the slot. Configure applicationInitialization with the key warm-up URLs. For risky releases, route 5-10 percent of production traffic to staging with testing in production before the full swap.
App Service or Container Apps per component
Keep server-rendered web front ends and monolithic APIs on App Service, where slots, built-in authentication and runtime stacks reduce effort. Move components that are already containers, that must scale to zero, or that scale on queue depth or events rather than HTTP to Container Apps. Container Apps workload profiles allow dedicated, larger instances for memory-heavy services while keeping consumption billing for light ones in the same environment.
Autoscale rules for surge events
Reactive CPU autoscale is too slow for an on-sale that goes from 500 to 15,000 concurrent users in two minutes. Pre-scale on a schedule 30 minutes before known events, set scale-out rules on HTTP queue length rather than CPU alone, and use short cool-downs on scale-out with long ones on scale-in. In Container Apps, set minimum replicas above zero for latency-sensitive APIs during event windows.
Front Door caching and origin lockdown
Cache static assets, images and public listing pages at Front Door with query-string handling set explicitly per route; bypass cache for authenticated and checkout paths. Lock App Service origins with an access restriction allowing only the AzureFrontDoor.Backend service tag plus a check on the X-Azure-FDID header for your profile, or use Premium with Private Link so origins have no public endpoint at all.
How NTSPL Moves a Customer Portal onto App Service Slots and Front Door
App Service migration assessment
Scan IIS or Linux web servers for blockers such as local file writes, GAC assemblies and Windows-integrated auth, and assign each component to App Service, Container Apps or Static Web Apps.
Plan, slots and VNet integration
Create zone-redundant Premium v3 plans, a staging slot per app with slot-specific settings, and VNet integration to reach private endpoints for SQL and Redis.
Pipeline to slot and revision
Build GitHub Actions or Azure Pipelines workflows that deploy to staging, run smoke tests, then swap with preview or shift Container Apps revision weights.
Front Door, WAF and origin lockdown
Configure routes, caching and WAF policies, then restrict origins to Front Door before switching public DNS.
Load test and pre-scale calendar
Run Azure Load Testing at 1.5x expected peak, tune autoscale rules, and publish a pre-scale schedule tied to launch and sale dates.
What you receive
Securing Azure Web Apps: Front Door WAF, Origin Lockdown, Managed Identity and Easy Auth
Public web apps face credential stuffing, bot scraping, injection attacks and origin bypass, where attackers hit the App Service hostname directly to skip the WAF. NTSPL applies Front Door WAF managed and bot rules, restricts origins to Front Door only, uses managed identity for every downstream call so no secrets live in app settings, and enforces TLS 1.2 or higher and HTTPS-only on every app.
- Front Door WAF managed rule set plus rate-limit rules on login and OTP endpoints
- App Service access restrictions or Private Link origins so traffic cannot bypass Front Door
- Managed identity for SQL, Storage and Key Vault access, removing stored credentials
- App Service Authentication (Easy Auth) with Microsoft Entra ID or Entra External ID for staff and customer sign-in
- Defender for App Service to detect attacks against apps and dangling DNS on custom domains
Azure Web Platform Pricing Levers: App Service Plan Density, Container Apps Consumption and CDN Offload
App Service bills per instance-hour of the App Service plan regardless of how many apps share it, and slots run on the same instances at no extra charge. Container Apps consumption billing charges per vCPU-second and GiB-second plus requests, with scale-to-zero, while dedicated workload profiles bill per node. Static Web Apps has free and standard plans. Front Door bills base fee, requests and data transfer.
- Consolidating low-traffic apps onto shared Premium v3 plans, covered by a Savings Plan for compute
- Scheduled scale-in to the minimum instance count overnight and on weekends
- Container Apps consumption profile with scale-to-zero for workers and admin APIs
- Front Door caching of images and static pages to cut origin instance needs
- Static Web Apps free plan for short-lived campaign microsites
Azure App Service vs Azure Container Apps vs AKS: where should my web application run?
Decide on four criteria. Packaging: App Service runs code directly on built-in stacks or a container; Container Apps and AKS require containers. Scaling: App Service scales instances by rules and keeps at least one running; Container Apps scales on HTTP, events or queues and can go to zero; AKS scales anything but you configure it. Release model: App Service slots give swap-based zero-downtime releases; Container Apps revisions give weighted traffic splitting; AKS needs your own rollout tooling. Operations: App Service and Container Apps hide the cluster; AKS exposes it. NTSPL rule: web front ends and monoliths on App Service, containerized APIs and event workers on Container Apps, AKS only when you need node control, service mesh or more than 20-30 services.
Key facts about web & application platform on Microsoft Azure
Web & Application Platform on Microsoft Azure in Practice
3 web & application platform scenarios from Real estate, Non-profit, Event ticketing: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Real-estate developer handles 40x launch-day traffic on its booking portal
Non-profit runs donor CRM on App Service and launches campaign sites in 2 days
Ticketing platform holds 95,000 users in a fair queue during concert on-sales
Container terminal links TOS, gate automation and Azure over dual ExpressRoute
School group connects 14 campuses through Virtual WAN with filtered student internet
Hospital network moves HL7 and appointments to event-driven FHIR integration
Electronics distributor onboards retail EDI partners in 2 weeks with Logic Apps B2B
Web & Application Platform on Microsoft Azure: Frequently Asked Questions
Do App Service deployment slots cost extra?
No. Deployment slots run on the same App Service plan instances as the production app, so there is no separate charge for the slot itself, though a slot consumes some of the plan's CPU and memory while running. The Standard tier supports up to five slots and Premium up to 20. NTSPL usually keeps one staging slot per production app.
How do we move our website from IIS VMs to App Service?
Run the App Service migration assessment against the IIS server to flag blockers such as GAC dependencies, local file writes or Windows authentication, fix those, then deploy to a staging slot and test. Static files written to local disk usually move to Blob Storage. DNS is switched through Front Door once the slot passes tests, so rollback is a routing change.
Can App Service and Container Apps host data in India only?
Yes. Both can be deployed in Central India, South India and West India, and Azure SQL and Redis caches can be placed in the same region. Front Door is a global service that caches content at edge locations, so for pages carrying personal data under the DPDP Act, NTSPL disables caching on those routes so responses are not stored at the edge.
Can App Service handle a sudden 20x traffic spike?
It can if prepared. Reactive autoscale adds instances in minutes, which is too slow for an instant spike, so NTSPL pre-scales on a schedule before known events, caches heavily at Front Door, and moves sessions to Redis so new instances serve traffic immediately. For unannounced spikes, HTTP queue-length rules react faster than CPU rules.
When are Static Web Apps better than App Service for a website?
When the site is mostly static content or a single-page app calling APIs. Static Web Apps serves files from global points of presence, provides free managed TLS for custom domains and creates a preview environment for each pull request. Anything requiring server-side rendering with heavy logic, or long-running back ends, belongs on App Service or Container Apps.
How does Container Apps billing work?
On the consumption profile, you pay per second for vCPU and memory while replicas run, plus a per-million request charge, with a monthly free grant. Scaling to zero stops compute charges. Dedicated workload profiles bill per node instead and suit steady, larger services. Many environments mix both: consumption for spiky APIs and dedicated profiles for always-on services.