Choosing the Right Compute Service

Azure offers multiple compute services — each designed for a different type of workload, level of control, and operational model. Choosing the wrong compute service leads to unnecessary complexity (too low-level) or insufficient control (too abstracted). The key question is: how much of the underlying infrastructure do you need to manage? This lesson walks through the major compute options and the criteria that guide you to the right choice for each scenario.

Azure Virtual Machines give you full control over the OS, runtime, and application stack. Use VMs when you need to: run legacy applications that require a specific OS version or kernel setting, perform a lift-and-shift migration of an on-premises workload without modification, install custom software at the system level, or need persistent compute that runs 24/7 with a predictable, fixed configuration. The trade-off is the highest operational burden — you are responsible for OS patching, security hardening, and monitoring the OS layer.

Virtual Machine Scale Sets are the right choice when you need VMs but also need to scale automatically based on demand. If your workload is stateless (web servers, API backends, batch workers), runs identically on every instance, and experiences variable demand, VMSS is the natural fit. It combines VM-level control with automated horizontal scaling. When choosing between a standalone VM and VMSS, the deciding factor is usually whether the workload needs to scale beyond a single instance.

Azure App Service is a PaaS platform for hosting web applications, REST APIs, and mobile backends. You deploy your code (in Node.js, Python, Java, .NET, PHP, Ruby, or a container) and Azure manages the runtime, OS, patching, load balancing, and scaling. Use App Service when you want to ship code quickly without managing infrastructure, when your application follows standard web app patterns, and when you do not need OS-level customisation. App Service is one of the most popular Azure services due to its balance of power and simplicity.

Azure Container Instances (ACI) let you run a Docker container in the cloud without managing any infrastructure — no VMs, no orchestrator. ACI is ideal for short-lived, on-demand container workloads: scheduled batch jobs, CI/CD pipeline tasks, data processing scripts, or development environments. Containers start in seconds and you pay per second of CPU and memory consumed. ACI does not provide features like service discovery, rolling deployments, or health-based restart that Kubernetes offers — it is a single-container or container-group execution environment.

Azure Kubernetes Service (AKS) is a managed Kubernetes environment for orchestrating containerised applications at scale. Use AKS when you have multiple microservices that need service discovery, rolling deployments, auto-healing, and sophisticated scaling. AKS manages the Kubernetes control plane (API server, etcd, scheduler) as a free PaaS component, while you manage the worker node VMs. AKS is the most operationally demanding container option but offers the most power and flexibility for production microservices architectures.

Azure Functions is an event-driven, serverless compute option where you write individual functions that execute in response to triggers — HTTP requests, timer schedules, messages arriving on a queue, or events from other Azure services. You pay per execution (the first 1 million executions per month are free), and the platform scales from zero to thousands of concurrent executions automatically. Use Functions for event-driven automation, webhooks, data transformation pipelines, and any workload that is naturally short-lived and trigger-based.

Use this simplified decision tree: Need full OS control? → VM or VMSS. Containerised workload at scale? → AKS. Single container, short-lived? → ACI. Web app or API without OS management? → App Service. Event-driven, short-duration code? → Azure Functions. The further down this list you go, the less infrastructure you manage and the faster you can deploy — but also the less control you have over the execution environment. Choose the highest level of abstraction that meets your requirements.

Real-world architectures often use multiple compute options together. For example: a company might use App Service for its customer-facing web application, Azure Functions for event-driven order processing, AKS for its internal microservices platform, and VMs for a legacy ERP system that cannot be refactored. Azure's unified management tools — the portal, CLI, ARM templates, and Azure Monitor — work consistently across all compute services, making multi-compute architectures manageable from a single control plane.

Cost varies significantly across compute options. VMs — charged per hour for the VM size, even when idle (unless deallocated). App Service — charged per App Service Plan SKU per hour, but multiple apps share one plan at no extra cost. ACI — charged per second of actual CPU and memory used, with no idle cost. Azure Functions (Consumption Plan) — charged per execution and per second of execution time, with a very generous free tier. For bursty workloads, serverless options are almost always the most cost-efficient; for steady, always-on workloads, reserved VMs or App Service plans may be cheaper.

Different compute services offer different SLA guarantees: Single VM (Premium SSD): 99.9%. VM in Availability Set: 99.95%. VM across Availability Zones: 99.99%. App Service (Standard tier and above): 99.95%. Azure Functions (Consumption Plan): 99.95%. AKS: 99.95% uptime for the API server (with paid tier). Composite SLA for a multi-component architecture is calculated by multiplying the individual SLAs — for example, App Service (99.95%) connected to Azure SQL (99.99%) gives a composite SLA of approximately 99.94%.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure offers multiple compute options — VMs, VMSS, App Service, ACI, AKS, and Functions — each suited to different workload profiles and control requirements, the general rule is to choose the highest abstraction level that satisfies your requirements to minimise operational burden, and real architectures often combine multiple compute services orchestrated through Azure's unified management layer. Next up we begin exploring Azure storage services, starting with Storage Accounts.