App Service vs Container Apps vs Functions: Azure Compute Selection Guide

App Service is the traditional PaaS focused on web apps and APIs, supports Windows/Linux, uses plan-based fixed scaling, and offers a fully managed OS — the most mature option with the deepest operational know-how. Container Apps (GA 2022) is a serverless Kubernetes-based PaaS that deploys directly from container images and supports Scale to Zero plus KEDA event-driven scaling — the go-to choice when you want containers without the AKS operational burden. Functions is an event-driven serverless runtime triggered by HTTP, Timer, Queue, Blob, Event Hub, Service Bus, or Cosmos DB, with a per-function limit of 10 minutes (Consumption) or 60 minutes (Premium), ideal for short event processing. Rule of thumb: traditional web app → App Service, container-based greenfield → Container Apps, event-driven short tasks → Functions, full-control Kubernetes → AKS.

Main App Service Plan tiers: Free / Shared / Basic (B1-B3) for dev and test, no Always On. Standard (S1-S3) is the minimum for production, with Auto Scale (10-instance cap), custom domains, and SSL. Premium v3 (P0v3-P5v3) is the recommended production tier, with Auto Scale up to 30 instances, VNet Integration, Premium Storage, and the latest-generation CPUs. Isolated v2 (I1v2-I6v2) runs on App Service Environment v3 (ASEv3) with a dedicated VNet for compliance workloads, starting from hundreds of thousands of yen per month. For typical production web apps, start at Premium v3 P1v3; reserve ASEv3 for compliance scenarios (PCI DSS, GDPR data residency, financial institutions). Linux and Windows have nearly identical tier structures, with small feature differences (e.g., Docker-supported features).

Key Container Apps features: 1) Scale to Zero (zero instances when idle for zero cost), 2) KEDA event-driven scaling (50+ scalers including HTTP, Queue, Event Hub, Service Bus, Kafka, and Cron), 3) Dapr integration (Distributed Application Runtime providing a common API for inter-service communication, pub/sub, and state stores), 4) Revisions (blue-green and canary deployments), 5) Traffic Splitting across multiple revisions for A/B testing, 6) built-in Managed Identity support, and 7) VNet Integration with Internal/External Endpoint and Private Endpoint support. Under the hood it runs on AKS, but you configure it declaratively with ARM/Bicep without touching Kubernetes YAML. It is the go-to service when you want to run containers without taking on AKS operations.

Main Functions plans: Consumption Plan — fully serverless, pay-per-execution (free up to 1M executions + 400K GB-seconds per month), 10-minute execution cap, and Cold Starts of a few seconds. Premium Plan — VNet Integration, Always On (no Cold Start), 60-minute execution cap, dedicated instances, monthly base fee plus usage. App Service Plan — share an existing plan to cut costs by co-locating Functions with other apps, with some scaling constraints. Flex Consumption Plan (GA 2024, the new recommended default) — an evolution of Consumption with VNet Integration, instance-count control, and configurable Always Ready Instances. Pick Consumption for simple lightweight workloads, Premium or Flex Consumption when you need low latency, and an App Service Plan for cost optimization through co-location. Flex Consumption is increasingly the default for new projects.

Monthly cost estimates for representative production setups in the Tokyo region. App Service: P1v3 (210 ACU, 3.5 GB RAM) x 2 instances for HA = JPY 40,000-50,000/month. Container Apps: 1 container (0.5 vCPU, 1 GiB RAM) x 1 replica always-on plus on-demand scaling = JPY 10,000-30,000/month (drops sharply with Scale to Zero). Functions: Consumption (5M executions + 1M GB-seconds/month) = JPY 2,000-5,000/month; Premium EP1 = JPY 16,000/month base plus usage. AKS: free Standard control plane + D4s_v5 x 3 nodes = JPY 60,000-90,000/month plus load balancer. Cost order: Functions Consumption << Container Apps (Scale to Zero) <= Functions Premium <= App Service <= AKS. The simpler the app, the more dramatic the savings from Scale to Zero on Functions or Container Apps.

Pick AKS only when you genuinely need a full Kubernetes environment. Specifically: 1) running on vendor-neutral OSS Kubernetes (multi-cloud strategy), 2) significant existing Helm Chart / Kustomize assets, 3) advanced K8s features like Service Mesh (Istio), 4) custom node pools such as GPU nodes or Spot nodes, or 5) complex stateful workloads using StatefulSet. If you just want to run containers, Container Apps is enough and lets you skip the AKS operational burden (upgrades, networking, storage design, security patching). Microsoft itself recommends "start with Container Apps, choose AKS only when you need Kubernetes-specific features" for new projects.

Recommendations by scenario: 1) Simple CRUD web app (Node.js / Python / .NET) → App Service Premium v3 (deep operational know-how, PaaS reliability). 2) Microservices or container-based greenfield → Container Apps (Scale to Zero + KEDA + Dapr). 3) Serverless API with low traffic → Functions Consumption (a few thousand yen per month). 4) Serverless API with low-latency requirements → Functions Flex Consumption. 5) Full Kubernetes required → AKS. The industry pattern for new web development is converging on three pillars: App Service for stateful or complex requirements, Container Apps for stateless microservices, and Functions for short event-driven processing.

AZ-204 (Developer Associate, scheduled for retirement in July 2026) tests the choice between App Service, Functions, and Container Apps in depth in Domain 1 (Compute, 25-30%). AZ-104 (Administrator) Domain 3 covers operational selection, AZ-305 (Solutions Architect Expert) Domain 4 covers architect-level selection, and AZ-400 (DevOps Engineer Expert) covers CI/CD pipeline construction. Pairing these with non-Microsoft certifications like AWS Solutions Architect Professional and GCP Professional Cloud Architect demonstrates multi-cloud capability that is highly valued in the job market.