Skip to main content

Azure Container Services

Containers have become the standard packaging format for modern applications, but running them in production requires more than a Dockerfile. Azure provides a spectrum of container services—from fully managed Kubernetes to serverless containers and simple on‑demand execution. This category hub helps you navigate the landscape and choose the right platform for your workload, your team’s expertise, and your operational model.

The services described here cover the full lifecycle: storing and securing images (Azure Container Registry), orchestrating microservices (Azure Kubernetes Service), running applications without managing clusters (Azure Container Apps), executing short‑lived tasks (Azure Container Instances), and operating enterprise‑grade Kubernetes with OpenShift (Azure Red Hat OpenShift). The goal is to map your requirements to the service that best balances control, responsibility, and agility.

Workload‑First Container Platform Selection​

Before choosing a service, articulate your workload characteristics and your team’s appetite for platform operations.

Workload Shape​

  • Long‑running HTTP APIs and web applications benefit from platforms that handle ingress, TLS, and rolling updates natively.
  • Event‑driven workers and scheduled jobs need scaling based on queue depth, events, or cron schedules.
  • Batch and one‑off tasks require simple, fast startup and termination.
  • Stateful services demand persistent storage, careful scheduling, and backup strategies.
  • AI/GPU workloads require specific hardware support and driver management.

Control versus Simplicity​

  • Kubernetes (AKS) gives you full access to the Kubernetes API, custom resources, operators, and node configuration. It is the most flexible—and the most operationally demanding.
  • Serverless containers (Container Apps) abstract away the cluster. You bring a container image; the platform handles scaling, revisions, and ingress. Ideal when you don’t need low‑level Kubernetes controls.
  • Simple containers (ACI) run a container or a small group on demand, with no orchestration layer. Perfect for dev/test, build tasks, or burst capacity.

Team Ownership​

Every platform shifts responsibilities between Azure and your team. With AKS, Azure manages the control plane; your team owns nodes, upgrades, scaling, and security. With Container Apps, Azure manages the infrastructure; your team owns the application, its configuration, and its dependencies. Align the service choice with your team’s capacity to operate it.

Container Service Decision Map​

Workload requirementPrimary serviceWhy it may fitImportant boundary
Kubernetes‑native microservices, custom operators, advanced networkingAzure Kubernetes ServiceFull Kubernetes API, node control, ecosystemYou manage nodes, upgrades, and capacity
HTTP APIs, event‑driven workers, or scheduled jobs without cluster managementAzure Container AppsServerless containers, revisions, scale‑to‑zero, DaprNot a full Kubernetes API; limited node access
One‑off container execution (dev/test, migration, burst)Azure Container InstancesFast startup, no orchestrator neededNo scaling, service discovery, or rolling updates
Store, scan, and promote container imagesAzure Container RegistryManaged registry, geo‑replication, image signingNot a runtime; does not run containers
Enterprise Kubernetes with Red Hat OpenShift compliance and ecosystemAzure Red Hat OpenShiftManaged OpenShift, integrated tooling, Red Hat supportAdditional cost; OpenShift‑specific APIs and operations
Manage Kubernetes clusters outside AzureAzure Arc‑enabled KubernetesCentral governance, policy, monitoring across cloudsRequires network connectivity; not a migration to AKS
Fleet‑level management of multiple AKS clustersAzure Kubernetes Fleet Manager (preview)Propagate resources, orchestrate upgrades across clustersNot a substitute for workload configuration

Azure Kubernetes Service (AKS)​

Azure Kubernetes Service is the primary managed Kubernetes offering on Azure. It is the right choice when your applications, your team, or your organization are already invested in the Kubernetes ecosystem and need its API, extensibility, and portability.

What AKS provides​

  • A managed Kubernetes control plane, including API server, etcd, and scheduler.
  • Integration with Azure networking (CNI, network policies, private clusters), storage (CSI drivers for Disks, Files, Blob), and identity (Microsoft Entra ID, workload identity).
  • Node pools for different workload types (system vs. user, Linux vs. Windows, GPU).
  • Cluster autoscaler, horizontal pod autoscaler, and event‑driven scaling with KEDA.
  • Built‑in support for Azure Monitor, Container Insights, and Defender for Cloud.

Your responsibilities​

AKS reduces, but does not eliminate, operational toil. You still own:

  • Node pool sizing, scaling, and OS/kernel version upgrades.
  • Resource requests, limits, and pod disruption budgets.
  • Workload deployment, health probes, and release strategies.
  • Ingress controllers, TLS certificates, and network policies.
  • Identity and secret management (though integration with Key Vault and managed identities simplifies it).
  • Backup and disaster recovery of application state.

Key architectural decisions​

  • Cluster isolation: Production clusters should be dedicated per environment and per critical workload boundary. Use separate node pools for different applications.
  • Networking: Prefer Azure CNI with private clusters for enterprise workloads. Use network policies for east‑west segmentation.
  • Identity: Use workload identity to give pods individual managed identities. Avoid long‑lived Kubernetes secrets for Azure resource access.
  • Scaling: Combine cluster autoscaler with horizontal pod autoscaler. Set appropriate resource requests/limits to enable bin packing and prevent starvation.

Learn more about Azure Kubernetes Service (AKS) →

Azure Container Apps​

Azure Container Apps is a serverless container platform built on Kubernetes but abstracted away. You deploy container images, and Azure handles the rest: scaling (including to zero), traffic splitting, revisions, and managed ingress.

When Container Apps fits​

  • You are building HTTP APIs or microservices and don’t need Kubernetes primitives like DaemonSets, custom schedulers, or privileged containers.
  • You need event‑driven scaling (e.g., based on Azure Service Bus queue length) using built‑in KEDA scalers.
  • You want blue‑green deployments, canary releases, and easy rollbacks via revisions and traffic splitting.
  • You want to leverage Dapr for service‑to‑service invocation, state management, or pub/sub without managing Dapr yourself.

When it may not fit​

  • You require custom Kubernetes operators, admission webhooks, or deep node‑level access.
  • Your application depends on a specific CNI plugin or storage driver not supported by the platform.
  • You need to run stateful workloads with persistent volumes (Container Apps currently supports only ephemeral storage).

Operational model​

Container Apps abstracts nodes, control planes, and cluster upgrades. You configure an environment (a boundary for networking, logging, and scale), deploy revisions of your app, and define scale rules. Updates create new revisions; traffic can be split between them for gradual rollouts. Monitoring is via Azure Monitor and Log Analytics.

Learn more about Azure Container Apps →

Azure Container Instances (ACI)​

ACI provides the simplest path to running a container in Azure. No cluster, no orchestrator, no long‑term commitment.

Common use cases​

  • Dev/test environments: Spin up a container quickly to test an image or configuration.
  • CI/CD build agents: Run a build step in an isolated container.
  • Burst capacity from AKS: Use virtual nodes to extend your AKS cluster with ACI when you need instant, ephemeral compute.
  • Data processing tasks: A batch job that transforms data and exits.

Limitations to consider​

  • ACI does not offer autoscaling, service discovery, or persistent storage on its own. For long‑running services, prefer AKS or Container Apps.
  • Cold start latency can be higher than pre‑warmed pods in a Kubernetes cluster.
  • Networking is more constrained; advanced topologies require careful planning.

Azure Container Registry (ACR)​

Every container workflow starts with an image, and ACR is the private, managed registry for Azure. It should be the single source of truth for all container images and OCI artifacts in your organization.

Image lifecycle and security​

  • Use immutability: Pin deployments to image digests, not tags like latest. This guarantees reproducibility.
  • Scan for vulnerabilities: Enable Defender for Cloud integration to automatically scan images for known CVEs.
  • Sign your images: Use notation (Notary v2) to sign images and verify signatures at deployment.
  • Promote across environments: Use separate registries or repositories for development, staging, and production, promoting images via CI/CD rather than rebuilding.
  • Geo‑replicate: Place copies of your registry in each region where you run workloads to reduce pull latency and avoid cross‑region egress costs.

Access control​

Authenticate to ACR using Microsoft Entra ID. Grant least‑privilege access: developers need pull and push; AKS and Container Apps need only pull. Use dedicated service principals or managed identities; avoid admin account keys.

Learn more about Azure Container Registry (ACR) →

Azure Red Hat OpenShift (ARO)​

For organizations that have standardized on Red Hat OpenShift, ARO provides a jointly managed OpenShift experience on Azure. It includes the full OpenShift ecosystem—integrated CI/CD (OpenShift Pipelines), built‑in monitoring (Prometheus/Grafana), and strict security defaults (Security Context Constraints).

Use ARO when your team is already proficient with OpenShift, or when you need the compliance and operational consistency that OpenShift offers across cloud and on‑premises environments. It is not a default choice for teams new to Kubernetes; the additional cost and complexity should be justified by existing OpenShift investments.

Hybrid and Multi‑cloud Operations​

Azure Arc‑enabled Kubernetes​

Arc extends Azure management to Kubernetes clusters running outside Azure—in other clouds, on‑premises, or at the edge. With Arc, you can:

  • Organize all clusters in Azure Resource Manager.
  • Apply Azure Policy for governance.
  • Deploy configurations via GitOps (Flux).
  • Monitor clusters with Container Insights and Defender for Cloud.

Arc does not migrate workloads; it provides a single pane of glass for multi‑cluster governance.

Azure Kubernetes Fleet Manager (Preview)​

Fleet Manager is designed for platform teams that manage tens or hundreds of AKS clusters. It allows you to propagate Kubernetes resources and orchestrate upgrades across a fleet. It is a management tool, not a replacement for configuring individual clusters.

Cross‑Cutting Container Architecture Concerns​

Image Supply Chain Security​

Secure images are the foundation. Build from trusted base images, pin dependencies, and generate SBOMs. Scan at every stage—during CI, in the registry, and at runtime. Sign images and verify signatures in admission controllers (e.g., Azure Policy for AKS). Never run images with known critical vulnerabilities.

Identity and Secrets​

Use workload identity in AKS to map a Kubernetes service account to a managed identity. In Container Apps, use the built‑in managed identity. Inject secrets at runtime via Key Vault references; never embed them in images or environment variable plaintext.

Networking and Ingress​

  • In AKS, deploy an ingress controller (e.g., Application Gateway Ingress Controller or NGINX) to route external traffic. Use Azure Firewall or NSGs for egress control.
  • In Container Apps, managed ingress handles TLS termination and can restrict traffic to your VNet.
  • For all services, place sensitive backends behind private endpoints and restrict public exposure.

Storage and State​

Stateless containers are ideal—replicas can be destroyed and recreated without data loss. When state is necessary, use persistent volumes (AKS) or external databases (Container Apps). Configure backup schedules, and regularly test restores. A pod restart does not equal a data backup.

Scaling and Resilience​

Define resource requests and limits for every container. Use liveness probes to restart stuck processes and readiness probes to remove unhealthy instances from service. Set pod disruption budgets to maintain quorum during voluntary disruptions. Autoscale based on metrics that reflect actual load (e.g., requests per second, queue length).

Deployment and Release​

Adopt immutable deployments: build a new image, deploy it, and cut over. Use rolling updates or blue‑green deployments. With Container Apps, use revisions and traffic splitting for canary releases. Automate via CI/CD or GitOps (Flux). Always test rollback procedures.

Observability​

Ship container logs to Log Analytics. Use Container Insights (AKS) or the built‑in Azure Monitor integration (Container Apps) for cluster and application metrics. Enable distributed tracing. Create alerts on key golden signals: request latency, error rate, and resource saturation.

Choosing a Container Service by Workload​

ScenarioCandidate servicePrimary design questionRisk to mitigate
Large microservices platform, custom operatorsAKSDo you have the team to manage upgrades and node pools?Operational toil without automation
Public API with scale‑to‑zeroContainer AppsDoes your app need Kubernetes‑specific features?Over‑provisioning without autoscale
Nightly batch processing jobContainer Apps Jobs or ACIHow long does the job run?Cost if left running; ACI timeout limits
Lift‑and‑shift legacy app into containersAKS or AROWhat are the storage and networking requirements?Stateful complexity if not designed
Secure, private app with WAFAKS + Application Gateway Ingress ControllerHow will you manage ingress and TLS?Exposed endpoints without WAF
GPU‑based inferenceAKS with GPU node poolsIs the GPU SKU available in your region?Cost and limited availability

Common Container Anti‑Patterns​

  • Defaulting to Kubernetes for everything. The learning curve and operational overhead are real. For simple APIs, Container Apps is faster and cheaper.
  • Using latest tags in production. This defeats reproducibility and makes rollbacks dangerous. Always deploy by digest.
  • Running containers as root. This expands the attack surface. Use a non‑root user in your Dockerfile and enforce pod security standards.
  • Embedding secrets in images or config files. Use Key Vault and managed identities. Secrets should never be in source control or image layers.
  • Skipping resource requests/limits. This leads to node overcommitment, noisy neighbors, and unpredictable scaling.
  • Disabling health probes. Without readiness and liveness probes, the platform cannot remove unhealthy instances from traffic.
  • Ignoring image scanning. A critical vulnerability in a base image compromises the entire workload. Scan continuously.
  • Manually editing production clusters. Use GitOps. Manual changes drift, are undocumented, and hinder disaster recovery.
  • Treating containers as immortal. Design for failure. All containers must be replaceable without data loss.

Representative Architecture: A Multi‑Tier SaaS Platform​

A SaaS provider uses a blend of container services for different tiers:

  • Public API: Deployed as Azure Container Apps, with scale‑to‑zero during low usage. Ingress uses managed TLS and is integrated with Azure Front Door for global distribution and WAF.
  • Core backend services: Hosted on AKS in a private cluster. These require custom scheduling, mTLS via a service mesh, and horizontal pod autoscaling.
  • Background workers: Event‑driven Container Apps jobs process messages from Azure Service Bus, scaling based on queue depth.
  • Legacy .NET monolith: Containerized and run on AKS with Windows node pools until a phased modernization is complete.
  • Image pipeline: GitHub Actions builds images, scans them, and pushes to ACR. AKS uses image digests, and Azure Policy enforces that only signed images can be deployed.
  • Identity: Workload identity in AKS maps each microservice to a dedicated managed identity, granting least‑privilege access to Azure SQL Database, Key Vault, and Storage.

Why this mix? AKS provides the control needed for the complex core services and legacy Windows workloads. Container Apps reduces operational overhead for simpler, event‑driven components. ACI is used during CI/CD for integration testing, as it is cheaper and faster than maintaining a separate test cluster.

Container Platform Operations and Lifecycle​

Operating containers is a continuous process. Establish these operational habits:

  • Upgrade cadence: AKS clusters should be upgraded to supported Kubernetes versions within the support window. Use Planned Maintenance and staggered node pool upgrades.
  • Capacity review: Monthly, review cluster utilization, right‑size node pools, and clean up unused images and registries.
  • Security audit: Integrate Defender for Cloud to continuously assess cluster and container posture. Address critical recommendations promptly.
  • Disaster recovery test: Periodically restore from backup, not just data but also cluster configuration (infra‑as‑code) and test the full application recovery.
  • Cost governance: Use AKS cost analysis, reservation for stable workloads, and auto‑scaling to avoid idle resources. Container Apps’ consumption model helps for bursty workloads.

Azure’s container ecosystem provides a right‑sized platform for every stage of your cloud‑native journey, from a single container instance to a global, multi‑cluster Kubernetes fleet. The key is to start with your workload requirements and your team’s willingness to own infrastructure, then let those decisions guide your service selection.

Explore Further​