Azure Container Instances and Container Groups
Azure Container Instances is the smallest useful unit of container hosting in Azure: a container, an IP address, and no orchestrator. That simplicity is the whole product, and it makes ACI excellent for a narrow set of jobs and a poor fit for everything else. Sitting just above it, Azure Container Apps offers the microservice features people usually want — revisions, ingress, event-driven scaling — without a cluster to operate. This note covers what each is for, how container groups colocate containers that need to share a lifecycle, and the ACI limits that are easier to know in advance than to discover.
Containerisation, briefly
Containerisation packages an application with all its dependencies — libraries, frameworks, configuration — into a single portable image, so it executes consistently across development, testing, and production. Container-based virtualisation virtualises the operating system rather than the hardware, letting multiple applications run within one OS instance while staying isolated from each other. Containers inside a VM provide functionality similar to VMs inside a physical server.
A container image is a lightweight, standalone, executable package containing everything needed to run the software: the application code, the runtime that executes it, the system tools and shared libraries it depends on, and its configuration settings. Once built, the image is a portable unit that runs consistently across computing environments. Images are the building blocks; containers are instances of images running at runtime. ACI deploys directly from an image in a registry.
Azure Container Instances
ACI is a serverless, fully managed container service for running containers on demand without managing any underlying infrastructure. It's designed for simple, single-container workloads that need fast deployment and minimal overhead, and it supports both Windows and Linux containers through the same API.
The benefits that define its niche:
- Fast startup: containers launch in seconds.
- Per-second billing: you're charged only while the container runs.
- Custom sizes: specify exact CPU core and memory values, avoiding payment for unused capacity.
- Persistent storage: azure Files shares can be mounted directly to retrieve and persist state.
- Direct internet exposure: containers can be given a public IP address and a fully qualified domain name, and can also be deployed into a virtual network.
Course material commonly presents ACI as a good option for lift-and-shift migration. That framing doesn't hold up. Lift-and-shift normally means an application that hasn't been containerised, which is precisely the case for VMs — you can't lift-and-shift into a container service without first doing the containerisation work that lift-and-shift is defined by avoiding. ACI's genuine strengths are short-lived and bursty work: simple applications, task automation, build jobs, batch processing.
Where ACI stops
The limits are real and worth knowing before you build on it.
No built-in scaling: ACI is designed for single container instances and offers no scaling capability of its own. It can be paired with AKS for burst capacity, but it can't scale up or out independently.
Specs are immutable after deployment: you can't modify a container instance's specification once it's running. There's an option to change CPU and memory, but doing so launches a new instance and destroys the old one. Which means it isn't really an edit, it's a replacement, and any in-flight work is lost.
Limited configuration: compared with Kubernetes, ACI exposes few options, you get minimal control over the underlying infrastructure and container settings.
Taken together these mean ACI is a poor destination for anything long-running that you expect to tune, and a good one for work that starts, does a job, and exits.
Container groups
The top-level resource in ACI is the container group: a collection of containers scheduled on the same host machine, sharing a lifecycle, resources, local network, and storage volumes. Groups are how you deploy and manage several containers as a single unit.
Multi-container groups make sense when a single functional task divides into several images, often built by different teams. Typical shapes:
- A container serving a web application, alongside a container pulling the latest content from source control.
- An application container and a logging container, where the logging container collects the main application's output from a shared volume and writes it to long-term storage.
- An application container and a monitoring container, where the monitor periodically probes the application and raises alerts.
- A front-end container serving a web application, and a back-end container running a service that retrieves data.
The general pattern here is the sidecar: an auxiliary container running alongside the main application container, providing supporting functionality such as logging, monitoring, caching, or data synchronisation without being part of the application's core logic. The same pattern applies in Azure Container Apps, where you can define multiple containers in a single container app — an agent reading logs from the primary container via a shared volume and forwarding them to a logging service, for example.
Deploying and exposing a group
There are two common ways to deploy a multi-container group:
1) An ARM template, recommended when you're deploying other Azure resources alongside the container instances: an Azure Files share, for instance. For the template mechanics themselves, see the companion note on Azure Resource Manager. 2) A YAML file, recommended when the deployment contains only container instances, since YAML is more concise for that case.
Container groups can share an external-facing IP address, one or more ports on that address, and a DNS label with an FQDN. Three rules govern this:
- External client access: requires exposing the port both on the IP address and from the container.
- Port mapping isn't supported: because containers in a group share a port namespace. Two containers in the same group therefore can't both listen on the same port. A constraint that decides how you split an application across containers.
- Deleted groups release their IP address and FQDN. Anything holding a reference to either will break.
Azure Container Apps
Container Apps is the managed service that sits between ACI's simplicity and AKS's power. It combines the flexibility of web apps with the simplicity of container instances and features drawn from Kubernetes, and it manages the details of Kubernetes and container orchestration for you. Containers in Container Apps can use any runtime, language, or development stack.
Its notable capabilities:
- Ingress control over how external traffic reaches your containers: enabling or disabling ingress, restricting traffic sources (for example allowing only traffic from other container apps), and configuring ports.
- Auto-scaling based on metrics, and support for managing multiple versions of an application, which is what makes deployments and rollbacks straightforward.
- Dapr: an open-source API providing building blocks such as state management and publish/subscribe, which is how Container Apps supports a microservices architecture without you assembling that infrastructure yourself. Dapr's building blocks are covered in more depth in the note on scaling and extending AKS.
Container Apps jobs run containerised tasks that execute for a finite duration and then exit — data processing, machine learning, or any on-demand work. Jobs and container apps run in the same environment and share capabilities such as networking and logging. A job's trigger type determines how it starts: manual jobs run on demand, schedule jobs run at specified times and can repeat, and event jobs are triggered by events such as a message arriving on a queue.
One constraint to plan around: Container Apps supports Linux-based containers only (linux/amd64). Windows containers need ACI or AKS.
There's also Azure Web Apps with container support, which deploys custom container images into the familiar App Service environment, bringing along scaling, deployment slots, and autoscaling. That option is covered from the App Service side in the note on what App Service hosts.
Common issues
Deployment takes a long time. Verify the selected region has capacity; try another region if necessary.
Container not accessible. Ensure public access is enabled and the DNS label is correctly configured. Check firewall rules if applicable.
Limited configuration options. ACI isn't designed for complex configurations — if you need real control over the container environment, that's an AKS case.
No scaling options. ACI doesn't scale. If scaling is required, integrate with AKS to use its scaling capabilities.
Deployment failure. Verify the image name and tag are correct, and check the Azure Activity Log for detailed error messages.
Ingress not working. Ensure ingress is enabled and the port is correctly configured; check NSG rules if applicable.
Image pull errors. Verify the image is accessible from Azure Container Registry or Docker Hub, and check authentication settings if the image is private. Registry authentication is covered in the note on Azure Container Registry.
Application not responding. Check the container logs, and verify the application is listening on the expected port and handling incoming requests.