ostebovik.net / resources AZ-104 · Compute Reference

Azure Compute — When to choose each

VM vs App Service
vs Container Instances

Every Azure compute decision starts with the same question: how much of the stack do you want to manage? The three options represent a trade-off between control and operational overhead. Think of it as owning a house, renting an apartment, or booking a hotel — most control in the house, least hassle in the hotel, but you can't repaint the hotel walls.

At a glance
Microsoft.Compute/virtualMachines
Virtual Machine
Full OS control. You own everything above the hypervisor.
ControlFull OS access
StartupMinutes
ScalingManual or VMSS
BillingPer hour, always on
PatchingYou own it
Best forLegacy, lift-and-shift, domain join, custom OS
Microsoft.Web/sites
App Service
Managed platform. Deploy code or a container — Azure handles the rest.
ControlApp layer only
StartupSeconds
ScalingBuilt-in autoscale
BillingPer plan, always on
PatchingMicrosoft managed
Best forWeb apps, APIs, slots, CI/CD, managed TLS
Microsoft.ContainerInstance
Container Instances
Simplest way to run a container. No cluster, no plan, no overhead.
ControlContainer layer
StartupSeconds
ScalingManual only
BillingPer second, stops when idle
PatchingImage-based
Best forBatch jobs, CI runners, event-driven, testing
Decision flow
Need full OS control, custom drivers, domain join, or kernel requirements? YES NO Virtual Machine IaaS — full OS control Is it a web app, API, or continuously running service? YES NO App Service PaaS — managed platform Short-lived task, batch job, or intermittent workload? YES NO Container Instances CaaS — per second billing Multiple containers needing orchestration or scaling? YES NO AKS outside project scope Consider AKS, Service Fabric, or other orchestrators
Side-by-side comparison
Dimension Virtual Machine App Service Container Instances
Abstraction IaaS PaaS CaaS
OS management You Azure N/A — image-based
Startup time 1–5 minutes Seconds Seconds
Scaling Manual or VMSS Built-in autoscale Manual only
Cost model Per hour — always on Per plan — always on Per second — stops billing when stopped
Deployment slots No Yes (Standard+) No
Managed TLS No Yes No
Persistent storage Managed disks Limited Azure Files mount
Domain join Yes No No
Custom OS Yes No Via image
⚠ The exam trap
The most common AZ-104 trick question pairs App Service with Container Instances. A containerized web application — which service? The answer depends on one thing: does it run continuously? The word "container" is a distraction. The decision driver is the workload pattern, not the packaging format.
Containerized web app serving users continuously
→ App Service (container deployment mode)
Containerized job that processes a queue and exits
→ Container Instances
App Service + containers

App Service can run container images instead of code — this is not the same as Container Instances. The platform remains App Service (slots, autoscale, auth, TLS all still work) but the delivery mechanism is a container image rather than a zip deploy. Use this when your team already has a container build pipeline and wants App Service's operational features without rewriting deployment tooling.

ACI lacks deployment slots, autoscaling, built-in TLS termination, and built-in auth. If you need any of those, App Service is the right answer regardless of whether the app is containerized.

Exam signals — what to listen for
If you hear... Reach for...
"Domain join", "custom OS", "lift and shift", "specific software version", "IaaS" Virtual Machine
"Web app", "API", "PaaS", "deployment slots", "autoscale", "managed TLS", "GitHub integration" App Service
"Serverless containers", "batch job", "short-lived", "event-driven", "no cluster", "per-second billing" Container Instances