What is Azure Container Instances?
Containers are becoming the preferred way to package, deploy, and manage cloud applications. Azure Container Instances offers the fastest and simplest way to run Linux or Windows containers in Azure, without having to manage any virtual machines and without having to adopt a higher-level service.
ACI supports regular containers.
Fast startup times
Containers offer significant startup benefits over virtual machines (VMs). Azure Container Instances can start containers in Azure in seconds, without the need to provision and manage VMs.
Bring Linux or Windows container images from Docker Hub, a private Azure container registry, or another cloud-based Docker registry. Visit the FAQ to learn which registries ACI supports. Azure Container Instances caches several common base OS images, helping speed deployment of your custom application images.
Container access
Azure Container Instances enables exposing your container groups directly to the internet with an IP address and a fully qualified domain name (FQDN). When you create a container instance, you can specify a custom DNS name label so your application is reachable at customlabel.azureregion.azurecontainer.console.azure.cn.
Azure Container Instances also supports executing a command in a running container by providing an interactive shell to help with application development and troubleshooting. Access takes places over HTTPS, using TLS to secure client connections.
Important
Azure Container Instances requires all secure connections from servers and applications to use TLS 1.2. Support for TLS 1.0 and 1.1 has been retired.
Compliant deployments
Hypervisor-level security
Historically, containers offered application dependency isolation and resource governance but were insufficiently hardened for hostile multitenant usage. Azure Container Instances guarantees your application is as isolated in a container as it would be in a VM.
Customer data
The Azure Container Instances service doesn't store customer data. It does, however, store the subscription IDs of the Azure subscription used to create resources. Storing subscription IDs is required to ensure your container groups continue running as expected.
Custom sizes
Containers are typically optimized to run just a single application, but the exact needs of those applications can differ greatly. Azure Container Instances provides optimum utilization by allowing exact specifications of CPU cores and memory. You pay based on what you need and get billed by the second, so you can fine-tune your spending based on actual need.
For compute-intensive jobs such as machine learning, Azure Container Instances can schedule Linux containers to use NVIDIA Tesla GPU resources (preview).
Persistent storage
To retrieve and persist state with Azure Container Instances, we offer direct mounting of Azure Files shares backed by Azure Storage.
Linux and Windows containers
Azure Container Instances can schedule Linux containers with the same API. You can specify your OS type preference when you create your container groups.
Some features are currently restricted to Linux containers:
- Multiple containers per container group
- Volume mounting (Azure Files, emptyDir, GitRepo, secret)
- Resource usage metrics with Azure Monitor
- GPU resources (preview)
For Windows container deployments, use images based on common Windows base images.
Run multiple containers in a single container group
Azure Container Instances supports scheduling of multiple containers within a single container group that share the same container host, local network, storage, and lifecycle. This enables you to combine your main application container with other supporting role containers, such as logging sidecars.
Virtual network deployment
Azure Container Instances enables deployment of container instances into an Azure virtual network. When deployed into a subnet within your virtual network, container instances can communicate securely with other resources in the virtual network, including those that are on premises (through VPN gateway or ExpressRoute).
Managed identity
Azure Container Instances supports using managed identity with your container group, which enables your container group to authenticate to any service that supports Microsoft Entra authentication without managing credentials in your container code.
Considerations
User's credentials passed via command line interface (CLI) are stored as plain text in the backend. Storing credentials in plain text is a security risk; Azure advises customers to store user credentials in CLI environment variables to ensure they're encrypted/transformed when stored in the backend.
If your container group stops working, we suggest trying to restart your container, checking your application code, or your local network configuration before opening a support request.
Container Images can't be larger than 15 GB, any images above this size may cause unexpected behavior: How large can my container image be?
Some Windows Server base images are no longer compatible with Azure Container Instances:
What Windows base OS images are supported?
If a container group restarts, the container group's IP may change. We advise against using a hard coded IP address in your scenario. If you need a static public IP address, use Application Gateway: Static IP address for container group - Azure Container Instances | Azure Learn
There are ports that are reserved for service functionality. We advise you not to use these ports because using them leads to unexpected behavior: Does the ACI service reserve ports for service functionality?
If you're having trouble deploying or running your container, first check the Troubleshooting Guide for common mistakes and issues
Your container groups may restart due to platform maintenance events. These maintenance events are done to ensure the continuous improvement of the underlying infrastructure: Container had an isolated restart without explicit user input
ACI doesn't allow privileged container operations. We advise you to not depend on using the root directory for your scenario.
Next steps
Try deploying a container to Azure with a single command using our quickstart guide: