Start with the word itself, so every later choice makes sense.

Compute is the power that runs your programs: processors, memory, and the software environment around them. Whenever a website answers a request, a report is generated, or a video is converted, some compute is doing the work. A compute service in Azure is a product that gives you that power in a particular form.

Azure compute services differ mainly in how much of the system you manage and how much Microsoft manages for you. Some give you an empty computer and say, “Everything else is yours.” Others say, “Just give us your code, and we will handle the rest.” The difference between these is the heart of every compute decision.

A wrong choice is rarely fatal, but it can be expensive and slow.

Picking the wrong compute service shows up in many ways. A team that chooses virtual machines for a simple website spends months patching servers that App Service would have patched for them. A team that chooses Kubernetes for a tiny application spends more time running the platform than building the product. A team that chooses a simple function for a long, heavy calculation finds that it times out. And a team that runs a steady, busy service on a pay-per-use platform may find the bill larger than expected.

The right choice saves money, reduces risk, speeds up delivery, and makes the system easier to operate. The goal is not the most advanced technology. The goal is the simplest service that safely meets your needs.

Four simple ideas organize almost every Azure compute service.

Infrastructure as a Service (IaaS)

IaaS gives you raw computing resources, mainly virtual machines. You choose the operating system, install the software, apply security updates, and handle most of the setup. Microsoft manages the physical buildings, hardware, and the virtualization layer underneath. You gain maximum control and take on maximum responsibility.

Platform as a Service (PaaS)

PaaS gives you a ready platform for running your application. Microsoft manages the servers and the operating system, and often the runtime and scaling features. You bring your code and settings. App Service is the classic example.

Containers as a Service and orchestration

A container is a lightweight package holding an application and everything it needs to run. Container services run these packages for you. Some are simple, such as Container Instances, some add automatic scaling and traffic handling, such as Container Apps, and some give full control through Kubernetes, an open system that schedules and manages many containers across many machines.

Function as a Service (FaaS) and serverless

Serverless means that you do not manage servers, and you are usually charged only when your code runs. Azure Functions is the best-known example, where you write small pieces of code that run in response to events, such as a message arriving or a file being uploaded.

flowchart LR
    A["More control, more work - Virtual Machines"] --> B["Dedicated Hosts and VM Scale Sets"]
    B --> C["Kubernetes Service - AKS"]
    C --> D["Container Apps and Container Instances"]
    D --> E["App Service"]
    E --> F["Azure Functions - serverless"]
    F --> G["Less control, less work"]
    

A short introduction to each service before we compare them.

Some other specialized options

• Azure Dedicated Host gives you a physical server for your own use, useful for strict compliance or for software licensing rules that require dedicated hardware.
• Azure VMware Solution lets organizations run existing VMware environments in Azure with little change.
• Azure Virtual Desktop runs desktops and apps in the cloud for remote users, which is a different kind of workload from hosting services.
• Azure Static Web Apps hosts static sites and single-page apps with optional serverless back ends.
• Service Fabric is an older microservices platform that is still used by some large systems, though many new projects choose containers instead.

Ask these in order, and the right service usually becomes clear.

The main decision criteria in a table

A visual path from a first question to a likely answer.

flowchart TD
    START["What do you need to run?"] --> Q1{"Moving an existing app with special OS or software needs?"}
    Q1 -- Yes --> VM["Virtual Machines or Scale Sets"]
    Q1 -- No --> Q2{"Is it large parallel or high-performance batch work?"}
    Q2 -- Yes --> BATCH["Azure Batch"]
    Q2 -- No --> Q3{"Is it small code triggered by events?"}
    Q3 -- Yes --> FUNC["Azure Functions"]
    Q3 -- No --> Q4{"Is it a web app or API?"}
    Q4 -- Yes --> Q5{"Is it packaged as many containers or microservices?"}
    Q5 -- Yes --> Q6{"Need full Kubernetes control and ecosystem?"}
    Q6 -- Yes --> AKS["Kubernetes Service - AKS"]
    Q6 -- No --> CA["Container Apps"]
    Q5 -- No --> AS["App Service"]
    Q4 -- No --> Q7{"Short single container job or quick task?"}
    Q7 -- Yes --> ACI["Container Instances"]
    Q7 -- No --> Q8{"Long-running service in a container?"}
    Q8 -- Yes --> CA2["Container Apps or App Service for containers"]
    Q8 -- No --> VM2["Virtual Machines for custom needs"]
    

Use this map as a guide, not a law. Real decisions may involve exceptions, such as a web app that must run on a very special runtime, which pushes you to containers or virtual machines even though it is a web app. Always test your assumptions with a small trial before committing.

The foundation, with the most freedom and the most responsibility.

A virtual machine behaves like a complete computer. You pick the operating system, the size, the disks, and the network. You then install and maintain everything that runs on it. This is why virtual machines are the right answer when you must run older applications that need a specific environment, special drivers, unusual software, or licensed products that cannot move to a platform service.

A Virtual Machine Scale Set manages a group of identical virtual machines. It can add or remove machines automatically based on load, and can spread them across availability zones, which are separate physical sites inside a region. This gives you scaling and resilience for workloads that must stay on virtual machines.

Price options for virtual machines

Virtual machines can be paid for in several ways: pay-as-you-go by the second, reserved instances or savings plans that give a discount in exchange for a one- or three-year commitment, Spot virtual machines that use spare capacity at a deep discount but can be taken away at short notice, and Azure Hybrid Benefit, which lets you reuse eligible Windows Server or SQL Server licenses. These options can make virtual machines very economical for steady, predictable work.

The comfortable default for many web applications.

Azure App Service hosts web applications and web APIs on a managed platform. You choose a plan, which defines the size and number of machines, and place your apps in it. Microsoft handles operating system updates, load balancing, and many security tasks. You gain features such as deployment slots, which are live staging copies for safe releases, managed certificates, built-in sign-in support, autoscale, and easy integration with pipelines.

Small pieces of code that run when something happens.

Azure Functions lets you write a small piece of code, called a function, that runs in response to a trigger. A trigger is an event, such as an incoming web request, a message in a queue, a new file in storage, or a timer. The platform starts your code, runs it, and scales out automatically when many events arrive. On suitable plans, you pay only for the time your code runs, and nothing when it is idle.

Functions come with different hosting plans. Some are purely pay-per-use and scale to zero, some keep pre-warmed instances to reduce start delays, and some run on a plan you control, such as an App Service plan. Names and details of these plans have changed over time, so check the current documentation.

Three ways to run containers, from simple to powerful.

Azure Container Instances

Container Instances run a single container or a small group with almost no setup, billed per second. They suit short jobs, quick tests, build agents, and simple small tools. They have no built-in automatic scaling or load balancing, so they are not meant for large, busy systems.

Azure Container Apps

Container Apps is a serverless platform for running containers, microservices, and background jobs. It adds automatic scaling based on traffic or events, including scaling to zero, built-in traffic management, versions called revisions, and support for common microservice tools. You do not manage a Kubernetes cluster, even though Container Apps is built on Kubernetes technology underneath.

Azure Kubernetes Service

AKS provides managed Kubernetes. Microsoft manages the control plane, which is the brain of the cluster, while you manage the worker machines, called nodes, and the workloads on them, though newer automatic modes shift more of this work to Microsoft. You gain full access to the Kubernetes ecosystem, with fine control over networking, scheduling, and extensions. You also take on more complexity, so teams need the skills to run it.

For work that needs many machines for a short time.

Azure Batch is built for large-scale parallel and high-performance computing. You describe a set of tasks, and Batch creates a pool of virtual machines, spreads the tasks across them, retries failures, and removes the machines when the work is finished. You pay for the virtual machines while they run, and there is no extra charge for the Batch service itself in most cases.

Typical uses include video rendering, financial risk simulations, scientific modeling, and large data conversions. For such work, using many cheap Spot machines can cut cost greatly, because the job scheduler can restart tasks if a machine is taken away.

sequenceDiagram
    participant U as You or Pipeline
    participant B as Azure Batch Service
    participant P as Pool of Virtual Machines
    participant S as Storage
    U->>B: Submit job with thousands of tasks
    B->>P: Create or resize pool of machines
    B->>P: Spread tasks across machines
    P->>S: Read input files
    P->>S: Write results
    P-->>B: Report task success or failure
    B->>P: Retry failed tasks
    B-->>U: Job completed
    B->>P: Remove machines when idle
    

One table to hold the whole picture.

The cheapest service depends on how busy your workload is.

Utilization means how much of your paid capacity you actually use. A pay-per-use service costs little when your work is rare, and more as your work becomes constant. A reserved or always-on service costs the same whether busy or idle, so it wins when it is nearly always busy.

flowchart LR
    LOW["Rare or spiky workload"] --> PAY["Pay-per-use options - Functions, Container Apps, Container Instances"]
    MID["Moderate steady workload"] --> PLAN["Plan-based options - App Service and small VM groups"]
    HIGH["Constant heavy workload"] --> RES["Reserved capacity - VMs, scale sets, AKS nodes with commitments"]
    

Ways to lower the bill

Remember hidden costs as well. These include time spent on patching and operations, data leaving Azure, storage, logging, load balancers, and support plans. A virtual machine may look cheaper per hour than a platform service, yet cost more once you count the people needed to run it.

Every compute choice changes who is responsible for what.

The shared responsibility model

Microsoft always protects the physical data centers and underlying hardware. As you move toward more managed services, Microsoft also takes over more of the software layers. With virtual machines you patch the operating system. With App Service Microsoft patches the platform, and you secure your code and settings. With functions, even more is handled for you. In every case, you still own your data, your identities, and your configuration.

Common security practices across all options

• Use managed identities. These let a compute resource prove who it is to other services without stored passwords.
• Keep secrets in Azure Key Vault instead of in code or settings.
• Use private networking with virtual networks and private endpoints for internal workloads.
• Apply least privilege with role-based access control, giving only needed permissions.
• Put a web application firewall in front of public applications.
• Use Microsoft Defender for Cloud to find weaknesses and respond to threats.
• Use Azure Policy to require approved regions, encryption, and private access.

Each service offers different ways to survive failure.

No matter which service you choose, the basic rules of reliability are the same. Run more than one copy, spread across availability zones where supported, put a load balancer or global entry point in front, keep data outside the compute layer, and watch everything with monitoring and alerts. Each service has its own settings for these.

flowchart TD
    USERS["Users"] --> FD["Azure Front Door - global entry and firewall"]
    FD --> WEB["App Service - zone-redundant web front end"]
    WEB --> API["Container Apps - scalable API and microservices"]
    API --> Q["Service Bus queue - smooths bursts"]
    Q --> FN["Azure Functions - event-driven workers"]
    API --> DB["Azure SQL Database - zone-redundant"]
    FN --> DB
    FN --> BLOB["Blob Storage - files and results"]
    JOB["Azure Batch - nightly heavy processing"] --> BLOB
    WEB --> MON["Azure Monitor and Application Insights"]
    API --> MON
    FN --> MON
    

Scaling styles

• Scale up means using a bigger machine, which is simple but has a ceiling.
• Scale out means adding more copies, which is usually better for resilience and growth.
• Scale to zero means running nothing when idle, which only some serverless services offer.
• Event-driven scaling adds capacity based on queue length or event rate, not only processor use.

How much effort you spend running things depends on the choice.

All Azure compute services connect to Azure Monitor, which collects metrics, meaning numbers over time such as processor use or request counts, and logs, meaning written records of events. Application Insights looks inside your running application and tracks slow calls, errors, and dependencies. Alerts notify people when limits are crossed.

The level of operations work, however, differs. With virtual machines you must also monitor disk space, security updates, and agent health. With platform and serverless services, Microsoft handles much of that, and you focus on application-level signals. When comparing options, include the cost of this operational effort, because it often decides the true winner.

Your first choice is not your last.

Many companies move through stages. They start by moving old systems to virtual machines, which is called rehosting or lift and shift. Later they replatform, moving the same app to a managed platform such as App Service with small changes. Finally they may refactor the app into smaller services running on containers or functions. Each step reduces operations effort and often cost, though it needs time and engineering work.

Common mistakes in choosing compute.

See the thinking applied to realistic situations.

A short list to use on your next project.

• Start from requirements. Write down what the workload does, how it scales, what rules apply, and what the team can support.
• Prefer the most managed service that fits. Move left on the spectrum only for real reasons.
• Prototype before committing. Run a small trial of your top two choices with realistic data.
• Compare total cost. Include operations effort, licensing, networking, and monitoring.
• Design for failure. Use zones, multiple instances, and health checks regardless of the service.
• Keep apps stateless and store data in managed storage and databases.
• Secure by default. Managed identities, Key Vault, private networking, and least privilege.
• Automate infrastructure. Use templates and pipelines so any choice can be rebuilt or changed.
• Monitor consistently. Send logs and metrics to a shared workspace and alert on user-facing symptoms.
• Review regularly. Workloads change, and so do services, prices, and team skills.
• Document the decision. Record why you chose a service, so future teams understand and can revisit it.