Serverless vs PaaS vs IaaS decision in Azure - CLI Comparison

Introduction

Azure offers three main service models — IaaS, PaaS, and Serverless — each giving you a different level of control and responsibility. Choosing the wrong model means either managing too much infrastructure or paying for idle capacity you don't need.

When you need full OS control and custom networking — use IaaS (Azure VMs).

When you want to deploy an app without managing servers or OS updates — use PaaS (Azure App Service).

When you have event-driven workloads that run occasionally and scale to zero — use Serverless (Azure Functions).

When you migrate a legacy app that requires specific OS configuration — use IaaS.

When you build APIs or microservices that need automatic scaling without managing infrastructure — use PaaS or Serverless.

Commands

Creates a Serverless Azure Function App with a consumption plan — you pay only when the function runs. Scale to zero when idle.

Terminal

az functionapp create --resource-group myResourceGroup --consumption-plan-location eastus --runtime python --runtime-version 3.9 --functions-version 4 --name myFunctionApp --storage-account mystorage123

Expected Output

{

  "availabilityState": "Normal",

  "defaultHostName": "myfunctionapp.azurewebsites.net",

  "kind": "functionapp",

  "name": "myFunctionApp",

  "resourceGroup": "myResourceGroup",

  "state": "Running",

  "type": "Microsoft.Web/sites"

}

→

--consumption-plan-location - Uses serverless consumption pricing — pay per execution

→

--runtime python - Sets the function runtime language

Creates a PaaS web app on Azure App Service. You manage the app code, Azure manages the OS, runtime, and scaling.

Terminal

az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name myWebApp --runtime "PYTHON:3.9"

Expected Output

{

  "defaultHostName": "mywebapp.azurewebsites.net",

  "kind": "app",

  "name": "myWebApp",

  "resourceGroup": "myResourceGroup",

  "state": "Running",

  "type": "Microsoft.Web/sites"

}

→

--plan - Specifies the App Service plan (defines compute tier)

→

--runtime - Sets the language runtime for the web app

Creates an IaaS virtual machine. You control the OS, install software, and manage patches — full control, full responsibility.

Terminal

az vm create --resource-group myResourceGroup --name myVM --image UbuntuLTS --admin-username azureuser --generate-ssh-keys

Expected Output

{

  "fqdns": "",

  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",

  "location": "eastus",

  "name": "myVM",

  "powerState": "VM running",

  "resourceGroup": "myResourceGroup"

}

→

--image UbuntuLTS - Specifies the OS image for the VM

→

--generate-ssh-keys - Creates SSH keys for secure access

Key Concept

If you remember nothing else from this pattern, remember: IaaS = you manage OS and above, PaaS = you manage code only, Serverless = you manage functions only and pay per execution.

Common Mistakes

Choosing IaaS for a simple web app because it feels more familiar

You end up managing OS updates, security patches, and scaling manually when PaaS handles all of that automatically.

Use Azure App Service (PaaS) for web apps — deploy code and let Azure manage the infrastructure.

Using Serverless for long-running or stateful workloads

Azure Functions have execution time limits and are stateless — long jobs will time out.

Use PaaS (App Service) or IaaS (VM) for workloads that run longer than a few minutes or need persistent state.

Forgetting that IaaS VMs cost money even when idle

A stopped VM still incurs storage costs. A running VM costs per hour regardless of load.

Use Serverless or PaaS for variable workloads — they scale to zero or scale automatically based on demand.

Summary

Use Azure Functions (Serverless) for event-driven, short-lived workloads — pay only per execution.

Use Azure App Service (PaaS) for web apps and APIs — manage code only, Azure handles infrastructure.

Use Azure VMs (IaaS) when you need full OS control, custom networking, or legacy app support.