
Azure gives you over 20 ways to run your code. Most workloads only need one of four: Virtual Machines, App Service, Azure Functions, or Container Apps. Picking the right one saves you time, money, and headaches. Picking the wrong one means you're either managing infrastructure you don't need or fighting limitations that don't fit your workload.
This guide breaks down the four main options so you can make the right call on your next deployment.
The Four Services in Plain Terms
Think of Azure compute like housing options:
- Virtual Machines are like buying a house. Full control, full responsibility — you fix the roof when it leaks.
- App Service is like renting an apartment. You move in and live there. The building manager handles plumbing and electricity.
- Azure Functions are like booking a hotel room. You only pay for the nights you stay. No room sits empty waiting for you.
- Container Apps is like hiring a property manager for your rental portfolio. You own the properties (your container images), but someone else handles the day-to-day.
Side-by-Side Comparison
| Virtual Machines | App Service | Azure Functions | Container Apps | |
|---|---|---|---|---|
| You manage | OS, patches, security, scaling, networking | Your code and configuration | Your function code | Your container images and config |
| Azure manages | Physical hardware | OS, runtime, scaling, patching | Everything except your code | Container orchestration, scaling, load balancing |
| Pricing | Pay for VM size + uptime (even idle) — from ~$3.80/mo | Tier-based plan — from $9.49/mo | Pay per execution — $0.40 per million executions | Per resource consumption or dedicated plan |
| Scaling | Manual or auto-scale rules you define | Auto-scale built in (you configure rules) | Automatic — scales to zero when idle | Automatic — scales on HTTP traffic or events |
| Best for | Legacy apps, custom OS, full control | Web apps, REST APIs, simple deployments | Background tasks, scheduled jobs, event-driven work | Microservices, containerized apps, multi-container |
| Skip it when | You don't need server-level control | You need OS-level customization | Your process runs longer than 10 minutes | App Service would be simpler |
Full Control Comes with Full Responsibility
VMs give you a complete computer in the cloud. You choose the operating system, install your own software, and configure everything from networking to security. That control comes with a trade-off — you're responsible for OS updates, security patches, and scaling.
Use VMs when:
- You're migrating a legacy application that requires a specific OS configuration or custom software that won't run in a managed environment
- You need full control over networking and security — firewall rules, custom routing, specific port configurations
- You're running database servers or infrastructure services that require persistent storage and predictable performance
The downside is real. Unpatched vulnerabilities remain one of the most common attack vectors in cloud environments. When you run VMs, patching is your job.
Practice this yourself — build your first VM in a real Azure environment with the Creating Your First Virtual Machine lab. Want to automate VM deployment? The Deploy a VM Using Bicep lab walks you through infrastructure as code.
Deploy Code, Skip the Server Management
App Service is a managed platform for web applications. You deploy your code, Azure handles the server underneath. No OS patching, no runtime management, no manual scaling.
It supports .NET, Java, Node.js, Python, and PHP out of the box. Custom domains, SSL certificates, and authentication come built in — things that would take hours to configure on a VM.
Use App Service when:
- You're building a web application or REST API and want the simplest path from code to cloud
- You want deployment slots for staging and production swaps with zero downtime
- Your app fits within supported runtimes — if it runs on .NET, Node, Python, Java, or PHP, start here
The limitation is flexibility. You can't install custom system software or modify the underlying OS. If your app needs a specific Linux package or custom runtime, you'll need containers or a VM.
Starting at $9.49/month for a basic plan, it's one of the most cost-effective ways to host a web app in Azure.
Practice this yourself — deploy a web app from scratch in the Creating a Web App on Azure App Service lab. Want the infrastructure as code approach? Try Deploy a Web App Using ARM Templates.
Your Code Runs Only When It Needs To
Azure Functions is serverless. You write a function, define what triggers it — an HTTP request, a new file in storage, a queue message, a timer — and it runs only when that trigger fires. When nothing's happening, you pay nothing.
On the Consumption plan, pricing is $0.40 per million executions plus $0.000016 per GB-second of memory. For most small workloads, that's pennies.
Use Functions when:
- You're processing background tasks like resizing images, sending emails, or handling file uploads
- You're running scheduled jobs — daily reports, cleanup routines, data sync tasks
- You're building event-driven workflows where one action triggers the next
The hard constraint is time. Functions on the Consumption plan have a 5-minute default timeout and a 10-minute maximum. HTTP-triggered functions hit a hard ceiling of 230 seconds due to Azure Load Balancer limits. If your process takes longer, use App Service, Container Apps, or a VM.
For stateful workflows that coordinate multiple steps, Durable Functions chain function calls together while Azure manages the state between them.
Practice this yourself — build a stateful serverless workflow with the Python Durable Functions lab.
Containers Without the Cluster Management
Container Apps is managed container hosting. You package your application in a Docker container, push it to a registry, and Azure runs it. You get the benefits of containers — consistent environments, multi-service deployments, custom runtimes — without managing a Kubernetes cluster.
It scales automatically based on HTTP traffic, event triggers, or custom rules. It can also scale to zero, meaning you don't pay when nothing's running.
Use Container Apps when:
- You're building microservices and need multiple containers communicating with each other
- Your app is already containerized and you want a simple deployment target
- You need custom runtimes or system-level packages that App Service doesn't support
- You want event-driven scaling with containers — queue-based processing, background workers
The trade-off is complexity. You need to understand container concepts — building images, managing registries, writing Dockerfiles. If your app fits within App Service's supported runtimes, that's a simpler starting point.
Practice this yourself — start with container fundamentals in the Azure Container Registry lab. Learn how to build and store container images before deploying them.
The Three Mistakes Everyone Makes
Using VMs for everything. VMs are powerful, but they come with management overhead. If you're running a standard web app, App Service removes that burden. Only reach for VMs when you genuinely need OS-level control or custom software that can't run anywhere else.
Choosing Functions for long-running processes. Functions are designed for short, event-driven tasks. If your process takes more than a few minutes, you'll hit timeout limits. Check whether App Service or Container Apps would be a better fit before you build around a 10-minute ceiling.
Jumping to containers before considering App Service. Containers are not automatically better. Building images, managing registries, and writing Dockerfiles add complexity. If your app uses a supported runtime and doesn't need multiple services, App Service gets you to production faster.
Picking the Right One
Start with the simplest question — what are you building?
- A web app or API? Start with App Service.
- Short tasks triggered by events? Start with Functions.
- Multiple services or custom runtimes? Start with Container Apps.
- Need full OS control or specific software? Use a VM.
If you're unsure, start with App Service. It has the shortest path from code to running application, and you can always move to containers or VMs later if you hit a limitation.
Now that you understand the four options:
- Deploy something small on your chosen service and see how it feels
- Read the official compute decision tree on Microsoft Learn for edge cases beyond these four
- If you're studying for AZ-104, these services map to the "Deploy and Manage Azure Compute Resources" exam objective
Ready to Master Cloud Engineering?
Get access to hands-on labs, expert-led courses, and a supportive community.
Practice it hands-on
Labs where you can apply what this article covers, in a real environment.
Creating a Web App on Azure App Service using Azure Portal
Learn how to create, configure, and deploy a web application using Azure App Service through the Azure Portal's interface.
cloudlearn.ioStart labBuilding a 3-Tier Web Application on Azure with App Service, Functions, and Cosmos DB
Build a 3-tier restaurant menu app using Azure App Service, Functions, and Cosmos DB. Learn serverless APIs, NoSQL databases, and full-stack deployment.
cloudlearn.ioStart labContainerize and Deploy a Multi-Container Application to Azure Container Apps
Build Docker images for a restaurant menu app, push to ACR, and deploy frontend and backend containers to Azure Container Apps.
cloudlearn.ioStart lab

