Platform Selection Guide
From fully managed web apps to Kubernetes and AI agents — a practical comparison of Azure's compute and hosting options, with the resiliency patterns that keep each one running when things go wrong.
Every Azure hosting option trades control against convenience. The further right you move, the more infrastructure you own — and the more operational capability your team needs to sustain it. Start as far left as your requirements allow.
You deploy code. Azure owns the OS, runtime, patching, load balancing and scale.
You deploy functions or workflows. Azure owns everything else and bills per execution.
You deploy container images. Azure owns the cluster, networking fabric and scaling engine.
You own the cluster configuration, node pools, upgrades and platform add-ons.
The default recommendation — if the workload is an HTTP application and you have no hard Kubernetes requirement, start with App Service or Container Apps. Move to AKS or OpenShift only when you need cluster-level extensibility, a specific operator ecosystem, or you already run Kubernetes at scale.
Four matrices covering capability, resiliency, networking and cost. Scroll each table horizontally on smaller screens.
| Capability | App Service | Azure Functions | Logic Apps | Static Web Apps | Container Apps | AKS | Container Instances | Spring Apps | Red Hat OpenShift | Foundry Agents |
|---|---|---|---|---|---|---|---|---|---|---|
| Windows workloads | ✔ | ✔ | N/A | N/A | — | ✔Windows node pools | ✔ | — | — | N/A |
| Linux workloads | ✔ | ✔ | N/A | N/A | ✔ | ✔ | ✔ | ✔ | ✔ | N/A |
| Single web app or API | ✔ | ✔ | — | ✔ | ✔ | ✔ | —no load balancing | ✔ | ✔ | — |
| Microservices | ✔independent apps / APIs | ✔ | — | — | ✔ | ✔ | — | ✔ | ✔ | — |
| Containers required | —optional | —optional | — | — | ✔ | ✔ | ✔ | —optional | ✔ | —hosted agents only |
| Consumption billing | — | ✔ | ✔ | ✔ | ✔ | — | ✔ | ✔Standard consumption | — | ✔ |
| Auto-scale | ✔ | ✔ | ✔ | ✔edge | ✔ | ✔ | —needs orchestrator | ✔ | ✔ | ✔ |
| Scale to zero | — | ✔ | ✔Consumption | N/A | ✔ | ✔user node pools | ✔per-second billing | ✔consumption plan | — | ✔ |
| Long-running jobs / batch | ✔WebJobs | ✔Durable Functions | ✔ | — | ✔Jobs | ✔ | ✔ | ✔Tasks | ✔ | — |
| Event-driven triggers | — | ✔ | ✔ | — | ✔KEDA | ✔KEDA | — | — | ✔ | ✔ |
| GPU workloads | — | — | — | — | ✔serverless GPU | ✔ | ✔ | — | ✔ | N/Amodel-side |
| Java / Spring optimised | ✔ | ✔ | — | — | ✔ | ✔ | — | ✔purpose-built | ✔ | — |
| OpenShift / RHEL tooling | — | — | — | — | — | — | — | — | ✔ | — |
| Full cluster control | — | — | — | — | — | ✔ | — | — | ✔ | — |
✔ supported · — not supported or not a good fit · N/A not applicable to this abstraction level.
| Resiliency capability | App Service | Azure Functions | Logic Apps | Static Web Apps | Container Apps | AKS | Container Instances | Spring Apps | Red Hat OpenShift | Foundry Agents |
|---|---|---|---|---|---|---|---|---|---|---|
| Availability zone redundancy | ✔Premium / Isolated | ✔Flex & Premium | ✔Standard | ✔global edge | ✔environment level | ✔node pools | ✔pinned to one zone | ✔ | ✔ | ✔platform-managed |
| Multi-region active/active | ✔+ Front Door | ✔+ Front Door | ✔active / passive | ✔built-in | ✔+ Front Door | ✔+ Fleet Manager | ✔manual | ✔+ Front Door | ✔+ Front Door | ✔ |
| Built-in health probes | ✔health check path | N/Aplatform-managed | N/A | N/A | ✔liveness / readiness / startup | ✔ | —restart policy only | ✔ | ✔ | N/A |
| Blue-green / canary deploys | ✔slots | ✔slots | ✔slots (Standard) | ✔preview envs | ✔revisions + split | ✔via controller | — | ✔blue-green | ✔Argo CD | ✔versions |
| Automatic instance healing | ✔auto-heal | ✔ | ✔ | N/A | ✔ | ✔ | ✔restart policy | ✔ | ✔ | ✔ |
| Built-in retry / replay | — | ✔bindings + Durable | ✔per-action policy | — | —app-level | —app-level | — | — | — | ✔runtime-managed |
| Durable state / run history | — | ✔Durable Functions | ✔checkpointed runs | — | — | — | — | — | — | ✔session state |
| Published platform SLA | 99.95% | 99.95% | 99.9% | 99.95% | 99.95% | 99.95%Standard tier | 99.9% | 99.95% | 99.95% | Verifycurrent terms |
SLA figures are indicative; always confirm the current service-level agreement for your tier and region before committing contractually.
| Networking / security | App Service | Azure Functions | Logic Apps | Static Web Apps | Container Apps | AKS | Container Instances | Spring Apps | Red Hat OpenShift | Foundry Agents |
|---|---|---|---|---|---|---|---|---|---|---|
| Built-in HTTPS ingress | ✔ | ✔ | ✔ | ✔ | ✔Envoy | —deploy a controller | —public IP only | ✔ | ✔OpenShift Router | ✔ |
| Custom domain + managed TLS | ✔ | ✔ | ✔ | ✔ | ✔ | ✔via ingress | — | ✔ | ✔ | — |
| VNet integration | ✔ | ✔Flex / Premium | ✔Standard | ✔Standard | ✔ | ✔ | ✔ | ✔ | ✔ | ✔BYO VNet |
| Private endpoint (inbound) | ✔ | ✔ | ✔Standard | ✔Standard | ✔ | ✔private cluster | — | ✔ | ✔ | ✔ |
| Fully isolated tenancy | ✔ASE v3 | ✔ASE v3 | ✔ASE v3 | — | ✔workload profiles | ✔ | — | ✔dedicated plan | ✔ | ✔session sandbox |
| Managed identity | ✔ | ✔ | ✔ | ✔ | ✔ | ✔workload identity | ✔ | ✔ | ✔ | ✔Entra Agent ID |
| WAF (Front Door / App Gateway) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | — | ✔ | ✔ | ✔via API Management |
| Built-in authentication | ✔Easy Auth | ✔Easy Auth | ✔keys / Entra | ✔built-in providers | ✔ | — | — | — | ✔OAuth | ✔Entra + RBAC |
| Cost & operations | App Service | Azure Functions | Logic Apps | Static Web Apps | Container Apps | AKS | Container Instances | Spring Apps | Red Hat OpenShift | Foundry Agents |
|---|---|---|---|---|---|---|---|---|---|---|
| Free tier available | ✔F1 | ✔monthly grant | — | ✔ | ✔monthly grant | ✔Free tier, no SLA | — | — | — | — |
| Dedicated / reserved tier | ✔Premium, Isolated | ✔Premium, Dedicated | ✔Standard WS plans | ✔Standard | ✔workload profiles | ✔ | — | ✔Standard, Enterprise | ✔ | ✔provisioned throughput |
| Cost when idle | Full | None | None | Flatper app | None | Fullnodes keep running | None | Variesby plan | Full | None |
| Primary billing unit | Instance-hour | GB-s + executions | Per action executed | App / month + bandwidth | vCPU-s + GiB-s | Node VMs + control plane | vCPU & GB per second | vCPU & GB per instance | Worker VMs + licence | Tokens + tools (+ compute) |
| Operational overhead | Low | Low | Low | Low | Low | High | Low | Medium | High | Low |
| Team skillset needed | App dev | App dev | Integration | Front-end | Containers | Kubernetes + platform | Containers | Java / Spring | OpenShift + platform | AI / prompt engineering |
Pricing models change. Validate current rates with the Azure Pricing Calculator before producing a business case.
Select a service to see its tiers, scaling behaviour, resiliency levers and a reference architecture. Hover any component in the diagram to learn why it matters.
A fully managed HTTP platform for web apps, REST APIs and mobile back ends. You deploy code or a container; Azure handles the operating system, runtime patching, load balancing, certificates and scale. It remains the fastest route to production for most line-of-business applications.
Choose it when you have a conventional web application or API, you want zero infrastructure ownership, and you do not need container orchestration primitives. If the app already runs on IIS, Tomcat, Node or .NET, this is usually the lowest-friction destination.
Free (F1), Basic (B1–B3)
S1–S3, Premium v3 (P0v3–P5v3), Premium v4
App Service Environment v3 (I1v2–I6v2)
Managed Instance on App Service — a plan-scoped option for legacy or infrastructure-dependent Windows web apps that need more operating-system customization without giving up managed patching, scaling, diagnostics and identity.
On Premium and Isolated v2 plans, instances are spread across physically separate availability zones in the region. A datacentre-level failure removes a fraction of capacity rather than the whole app.
Configure a health check path and the platform removes failing instances from rotation and replaces them. Auto-heal rules can recycle a worker on memory thresholds, slow requests or specific status codes.
Deploy to a staging slot, warm it up, then swap. The swap is an instance-level routing change, so rollback is immediate and failed deployments never reach customers cold.
Cost & sizing note — App Service bills per instance-hour whether or not traffic arrives, so idle environments cost full price. Consolidate non-production apps onto a shared plan, and size on memory and connection count rather than CPU alone.
Event-driven compute that runs a block of code in response to a trigger — an HTTP request, queue message, blob upload, timer or event stream. The platform owns scaling entirely, and you pay for execution time rather than reserved capacity.
Choose it when work arrives as discrete events, traffic is spiky or unpredictable, and each unit of work completes in a bounded time. Functions is also the cheapest way to run infrequent background processing because idle cost is effectively zero.
Trigger from Service Bus or Event Hubs rather than direct HTTP where possible. The broker absorbs bursts, preserves messages during downstream outages, and dead-letters poison messages instead of losing them.
Trigger bindings support configurable retry with exponential back-off. Because retries mean at-least-once delivery, handlers must be idempotent — key writes on a message identifier.
For multi-step processes, Durable Functions checkpoints orchestration state. If an instance fails mid-flow, execution resumes from the last checkpoint rather than restarting the whole workflow.
Cost & sizing note — consumption plans are cheap at low volume but can exceed dedicated pricing under sustained high throughput. Model the crossover point, and watch for runaway scale caused by a poison message loop — always set a maximum scale-out limit.
A low-code workflow engine for connecting systems. Rather than writing integration code, you compose a workflow from triggers and actions drawn from over a thousand connectors — SAP, Salesforce, SQL, Dataverse, SharePoint, Service Bus and more — with retry, error handling and run history built into the platform.
Choose it when the problem is moving and transforming data between systems, orchestrating approvals, or implementing B2B exchanges. If most of your code would be API plumbing and retry logic, a workflow engine will be cheaper to build and far cheaper to operate.
Every action has an independent retry policy — fixed interval, exponential back-off or none. Transient downstream failures are absorbed without any custom code or redeployment.
Group actions into scopes and configure run-after conditions to build try / catch / compensate patterns, so a partial failure triggers cleanup rather than leaving the process half-complete.
Stateful workflows persist the output of every action. Runs survive host restarts, and you can inspect or resubmit any historical run — invaluable when reconciling a failed overnight batch.
Cost & sizing note — Consumption bills every action, so a loop over ten thousand records is ten thousand billable actions. High-volume or chatty workflows are usually dramatically cheaper on a Standard workload plan, where built-in connector actions carry no per-execution connector charge.
A managed hosting service for static HTML and JavaScript front ends, with globally distributed content, integrated authentication, API back ends and automatic preview environments for pull requests. It is purpose-built for frameworks such as React, Angular, Vue, Svelte, Next.js and Blazor WebAssembly.
Choose it when the browser renders the user experience and the server-side surface is a small API. It removes web-server management entirely while giving development teams a branch-based delivery workflow out of the box.
Static assets are served from geographically distributed edge locations. Users continue to receive the front end even if one regional point of presence is unavailable.
Keep the browser shell independently available from the dynamic API. Cache reference data where appropriate and design graceful error states so an API incident does not become a blank page.
Branch environments let teams validate routing, authentication and API compatibility against production-like hosting before merging, reducing deployment-caused outages.
Cost & sizing note — the service is priced per app rather than per server. Bandwidth, linked APIs and enterprise features drive the bill, so it is often substantially cheaper than keeping a general-purpose web host online for a front-end-only workload.
A serverless container platform built on Kubernetes, KEDA, Envoy and optional Dapr — without exposing the Kubernetes cluster. You deploy a container image and define ingress, scale rules and revision traffic; Azure operates the control plane, nodes and platform upgrades.
Choose it when applications already ship as containers, need event-driven scale or microservice traffic splitting, but the team does not need Kubernetes APIs, custom operators or control over node pools. It provides most application-platform capabilities with a fraction of AKS operations.
Enable zone redundancy when the environment is created, then run at least three replicas for critical services. The platform distributes infrastructure and application replicas across availability zones.
Startup, readiness and liveness probes keep unhealthy replicas out of rotation. KEDA can scale on queue depth, event lag or a custom metric instead of waiting for CPU pressure.
Every application version becomes an immutable revision. Split traffic between old and new revisions for canary validation, then shift or roll back instantly without rebuilding.
Cost & sizing note — scale-to-zero makes Consumption economical for intermittent traffic, but sustained workloads can be cheaper on dedicated profiles. Set replica ceilings on every rule and tune per-replica concurrency so a downstream outage cannot trigger unbounded scale.
Managed Kubernetes with an Azure-operated control plane and customer-operated node pools. AKS exposes the Kubernetes API and ecosystem: custom resource definitions, operators, service meshes, policy engines, specialised networking and GPU node pools. That flexibility brings the highest operational responsibility in this guide.
Choose it when Kubernetes itself is a requirement: you need custom operators, privileged workloads, specialised networking, a mature internal platform, portability across clusters, or enough services to justify a common orchestration layer. Do not choose it solely because an application is containerised.
Spread system and user node pools across three availability zones, then use topology-spread constraints and pod anti-affinity so replicas do not collapse back onto one node or zone.
PDBs preserve a minimum number of replicas during voluntary disruptions such as node upgrades. Combine them with readiness probes and surge capacity to upgrade without taking the service offline.
HPA or KEDA scales pods, while Cluster Autoscaler or Node Autoprovisioning adds nodes. Both layers need tested limits; otherwise a constrained node pool can leave newly requested pods pending.
Operational warning — the managed control plane does not make the application platform managed. Your team still owns Kubernetes version upgrades, node-image upgrades, ingress, DNS, certificate automation, policy, observability, capacity, pod security and incident response. Budget for a platform engineering capability, not just the VM bill.
The fastest way to run a container in Azure without creating a server or cluster. A container group receives CPU, memory, networking and optional persistent storage, starts in seconds, and is billed per second until it stops. ACI is a compute primitive rather than a complete application platform.
Choose it when one or more tightly coupled containers need to run as a finite task, build agent, data-processing step or emergency burst worker. Use an external orchestrator such as Logic Apps, Functions or Azure Batch when work must be retried, scheduled or scaled.
ACI does not provide application autoscaling, rolling deployments or service-level load balancing. Place a durable orchestrator in front to create, monitor, retry and clean up each container group.
A container group can be pinned to an availability zone, but it does not span zones. For higher availability, launch independent groups in multiple zones and route or partition work externally.
Keep work items in Service Bus or Queue Storage and write results to durable storage. A failed group can then be replaced without losing its input or relying on ephemeral container files.
Cost & sizing note — billing stops with the container group, which makes ACI attractive for short jobs. For continuously running services, Container Apps or App Service usually provides better resiliency features and a clearer operational model at comparable cost.
A managed application platform designed for Spring Boot and Spring Cloud workloads. Azure operates the runtime, service discovery, configuration, routing, certificates, patching and application instances so Java teams can focus on services rather than building a platform around them.
Choose it when an organisation has a meaningful Spring portfolio and wants consistent discovery, configuration, blue-green deployment and observability without operating Kubernetes. Confirm current regional availability, tier options and lifecycle guidance in Microsoft Learn before making a long-term platform decision.
Where supported, zone-redundant deployment spreads platform infrastructure and application instances across availability zones. Run multiple application instances so a zone loss leaves serving capacity.
Centralised service registration and configuration reduce hard-coded dependencies. Services can discover healthy peers dynamically, while configuration changes are governed independently from application binaries.
Deploy a new version beside the current version, validate it, then switch production traffic. The old deployment remains available for rapid rollback if a regression appears.
Cost & sizing note — dedicated plans bill for provisioned application vCPU and memory, while Enterprise also carries a commercial component licence per vCPU. Consolidating many Spring services can justify that platform premium; a single small service is often cheaper on App Service or Container Apps.
A fully managed OpenShift service jointly engineered and operated by Microsoft and Red Hat. It combines Kubernetes orchestration with the opinionated OpenShift platform: integrated routing, OAuth, operators, an internal registry, developer workflows and Red Hat's enterprise support model.
Choose it when OpenShift is an enterprise standard, workloads depend on certified Red Hat operators or RHEL tooling, or a hybrid estate needs a consistent OpenShift operating model across Azure and on-premises. For a greenfield Azure-only Kubernetes platform, compare the licence and operating model carefully with AKS.
Control-plane and worker capacity is distributed across availability zones in supported regions. Applications still need multiple replicas, topology constraints and disruption budgets to benefit from that infrastructure.
MachineSets define repeatable worker pools and the cluster autoscaler adds capacity when pods cannot be scheduled. Separate critical, general and specialised workloads into appropriately sized pools.
OpenShift GitOps continuously reconciles cluster and application state from source control. Configuration drift is visible and recoverable, while versioned manifests support repeatable regional recovery.
Operational and cost warning — ARO reduces control-plane operations but remains a full container platform. Worker VMs, OpenShift licences, network services, logging and platform engineering all contribute to total cost. It is strongest where OpenShift standardisation produces value across a sizeable application estate.
A managed platform for building, deploying and scaling AI agents. Foundry supports configuration-only prompt agents, managed real-time voice agents, code-based hosted agents, and ephemeral agents that call the Responses API directly. A common runtime brings model access, tools, identity, networking, tracing, evaluation and publishing together.
Choose it when the application needs an agent that reasons across models and tools, maintains conversations, or acts through enterprise systems — and those behaviours require central identity, content safety, tracing, evaluation and lifecycle governance. It is an agent platform, not a replacement for general web hosting.
| Dimension | Prompt agent | Voice-based prompt agent | Hosted agent |
|---|---|---|---|
| Authoring surface | Foundry portal, SDK or REST | Agent definition through portal, SDK or REST | Agent Framework, LangGraph, OpenAI Agents SDK, Anthropic Agent SDK, GitHub Copilot SDK or custom code |
| Runtime code to maintain | None — configure instructions, model and tools | None for managed voice orchestration | Your agent logic, supplied as a container image or source-code ZIP |
| Compute | Fully managed | Fully managed with Voice Live | Foundry-managed container compute with session isolation |
| Managed endpoint | Yes | Yes — real-time WebSocket | Yes |
| Autoscale | Automatic by request volume | Managed by Foundry and Voice Live | Automatic by session and request volume |
| Microsoft Entra identity | Supported | Supported | Automatic dedicated identity per agent |
| Cost model | Model inference plus tool usage | Voice Live, speech and model usage | Model inference, tools and container compute |
| Best for | Fast delivery where custom orchestration is unnecessary | Low-latency spoken experiences without hosting the voice stack | Custom orchestration, multi-agent systems and framework-specific logic |
Voice-based prompt agents and some related voice capabilities are preview features. Review current support, availability and SLA boundaries before production use.
Hosts and scales agents, manages conversations and tool calls, and exposes managed endpoints. Hosted-agent sessions run in isolated compute and can connect to a bring-your-own virtual network.
Curate web search, file search, code interpreter, memory, functions, OpenAPI and remote MCP servers behind one versioned, governed MCP-compatible endpoint with central authentication.
Version agents, publish stable endpoints and distribute through Microsoft Copilot, Teams and the Entra Agent Registry. Supported patterns include OpenResponses, Activity, Invocations and A2A protocols.
Use Microsoft Entra identity and Azure RBAC to govern who can create, invoke and manage agents. Prompt agents support private networking; hosted-agent sessions can run in VM-isolated sandboxes attached to a customer virtual network.
Integrated content filters and guardrails help mitigate unsafe output and prompt-injection risks, including cross-prompt injection. Tool connections support keys, managed identity, OAuth on-behalf-of and unauthenticated access where appropriate.
Application Insights integration provides end-to-end traces and metrics. Evaluate quality before publishing, monitor production behaviour, and use Agent Optimizer preview to improve instructions, skills, tool descriptions and model choices.
Ephemeral-agent option — an application can call the Foundry Responses API directly and keep its instructions, tools and model choice in application code. This avoids a persistent agent resource while retaining catalog models, platform tools, project data, on-behalf-of authentication and project-level observability.
Cost & reliability note — prompt-agent cost is primarily model inference and tool usage; hosted agents add container compute, and voice agents add speech and Voice Live charges. Set token and tool-call budgets, choose an appropriate model for each step, trace failures end to end, and design tools to be idempotent before allowing an agent to take consequential actions.
Start with the workload shape and the operating model the team can sustain. The simplest platform that satisfies the non-negotiable requirements is usually the most resilient choice.
| Workload or requirement | Recommended starting point | Why |
|---|---|---|
| Traditional .NET, Java, Node or Python web app | Azure App Service | Fast migration path, managed runtime, deployment slots, autoscale and strong private-networking options. |
| Bursty event processing or small HTTP functions | Azure Functions on Flex Consumption | Scale to zero, always-ready capacity, VNet integration and event-native bindings. |
| SaaS, ERP or B2B system integration | Azure Logic Apps | Connector ecosystem, durable run history, retries and low-code exception handling reduce bespoke plumbing. |
| React, Angular, Vue or static content front end | Azure Static Web Apps | Global edge delivery, managed TLS and authentication, plus automatic pull-request environments. |
| Containerised API or worker without Kubernetes needs | Azure Container Apps | Serverless scale, revisions, health probes, KEDA and managed ingress without cluster operations. |
| Custom operators, service mesh, GPU pools or platform APIs | Azure Kubernetes Service | Full Kubernetes extensibility and control, provided a platform engineering team owns the lifecycle. |
| Short-lived isolated container task | Azure Container Instances | Starts quickly, bills per second and requires no persistent server or cluster. |
| Large Spring Boot portfolio | Azure Spring Apps | Purpose-built runtime, discovery, configuration, blue-green deployment and Tanzu capabilities. |
| Enterprise standard is Red Hat OpenShift | Azure Red Hat OpenShift | Joint Microsoft and Red Hat operations with the full supported OpenShift application platform. |
| AI agent using models, tools and enterprise data | Microsoft Foundry Agent Service | Managed agent runtime, identity, toolboxes, tracing, evaluation, guardrails and publishing lifecycle. |
Architecture principle — high availability is not a product checkbox. Pair the selected platform with zone-aware capacity, a resilient data tier, queue-based load levelling where appropriate, tested deployment rollback, end-to-end observability and a rehearsed regional recovery procedure.