16 · Azure & managed endpoints
AWS isn't the only cloud. Azure offers the same managed-vs-control spectrum: Container Instances (one container, fast), Container Apps (serverless, scale-to-zero, autoscaling), and managed ML endpoints. The pattern is portable — match the service to the requirement, not the cloud.
The deploy pattern is the same on every cloud — pick a service by how managed and how scalable you need it — only the names change. On Azure: **Container Instances (ACI)** runs a single container fast (`az container create`) with no orchestration — great for a quick job or a simple always-on service. **Container Apps** is serverless containers with autoscaling and **scale-to-zero** (pay nothing when idle) — the modern default for a web/model service with variable traffic. **Managed ML endpoints** (Azure ML, mirroring AWS SageMaker and GCP Vertex AI) give a fully-managed, autoscaling, monitored model-serving endpoint. The skill is portable: match the requirement to the right rung of the spectrum, regardless of which cloud's logo is on it.
Without this:
Without seeing the cross-cloud pattern, you'd treat each provider as a brand-new system to relearn — and you'd reach for whatever service you happen to know rather than the one that actually fits the requirement (e.g. an always-on instance for a bursty, mostly-idle service that scale-to-zero would have run for a fraction of the cost).
AWS (lesson 15) isn't the whole world — Azure and GCP host just as much production ML. The good news: the deploy decision is the same everywhere. Every major cloud offers the same managed-vs-control spectrum you learned for AWS; only the product names differ. Learn the shape once and you can deploy on any of them.
On Azure, the containerized rungs are:
-
Azure Container Instances (ACI) — the simplest: run a single container, fast, with no orchestration layer. One command,
az container create, points at your image (in Azure Container Registry, Azure's ECR equivalent) and you get a running container with a public IP/FQDN. It's the analog of "just run this container" — perfect for a quick batch job or a simple always-on service, but there's no built-in autoscaling or scale-to-zero. -
Azure Container Apps — serverless containers with real orchestration: autoscaling based on traffic and, crucially, scale-to-zero — when no requests arrive, it scales down to zero replicas and you pay nothing, then spins back up on the next request. This is the modern default for a model API with variable or bursty traffic: you get autoscaling and load balancing without managing servers, and you don't pay for idle capacity. It's roughly Azure's answer to AWS Fargate / Google Cloud Run.
-
Azure ML managed endpoints — like AWS SageMaker endpoints: deploy a model and get a fully-managed, autoscaling, monitored HTTPS serving endpoint, ML-native (built-in versioning, blue-green rollout, data capture for monitoring). The choice when managed model serving is what you want.
The same three tiers exist on every cloud. It's worth seeing them side by side:
| Need | AWS | Azure | GCP | |---|---|---|---| | Run one container, fast | (ECS task) | Container Instances | Cloud Run job | | Serverless autoscaling container, scale-to-zero | Fargate / App Runner | Container Apps | Cloud Run | | Managed PaaS for a container | Elastic Beanstalk | App Service | App Engine | | Fully-managed ML serving endpoint | SageMaker | Azure ML endpoint | Vertex AI endpoint | | Raw VM (full control) | EC2 | Azure VM | Compute Engine | | Container registry | ECR | Azure Container Registry | Artifact Registry |
The takeaway is the portable skill: match the requirement to the rung, not the cloud. A bursty, mostly-idle model API → a scale-to-zero serverless container (Container Apps / Cloud Run / Fargate). A steady high-traffic service needing ML-native monitoring and A/B → a managed ML endpoint (Azure ML / SageMaker / Vertex). A one-off container → the run-a-container service. Pick the cloud for the reasons that actually differ between them — existing accounts, pricing, the rest of your stack — but the deployment shape you already know.
Azure deploy commands: `az container create` runs a single container on Container Instances (no autoscaling), while `az containerapp create` with `--min-replicas 0` gives a serverless, autoscaling, scale-to-zero Container App — pay nothing when idle.
Your model API gets bursty, unpredictable traffic and is idle most of the night. You want autoscaling and to pay nothing when no requests arrive. On Azure, which service fits?
- The deploy decision is the same on every cloud — pick by how managed and how scalable you need it — only the product names change, so the skill is portable.
- On Azure: Container Instances (`az container create`) runs one container fast with no autoscaling; Container Apps adds serverless autoscaling and scale-to-zero; Azure ML endpoints give managed ML serving.
- The tiers map across providers: scale-to-zero serverless = Container Apps / Fargate / Cloud Run; managed ML endpoint = Azure ML / SageMaker / Vertex AI — match the requirement to the rung, not the cloud.
Teams deploy the same containerized model on whatever cloud they already use — a scale-to-zero serverless container for bursty traffic, a managed ML endpoint for steady high-traffic serving — applying the one portable managed-vs-control decision regardless of vendor.
If you remove it: You'd relearn each cloud as a new system and reach for whatever service you know rather than the right rung — running an always-on instance for a mostly-idle service that scale-to-zero would have run for a fraction of the cost.