Frequently asked questions about Azure Container Instances

The maximum size for a deployable container image on Azure Container Instances is 15 GB. You might be able to deploy larger images depending on the exact availability at the moment you deploy, but larger image size isn't guaranteed.

The size of your container image impacts how long it takes to deploy, so generally you want to keep your container images as small as possible.

Because one of the main determinants of deployment times is the image size, look for ways to reduce the size. Remove layers you don't need, or reduce the size of layers in the image (by picking a lighter base OS image). For example, if you're running Linux containers, consider using Alpine as your base image rather than a full Ubuntu Server. Similarly, for Windows containers, use a Nano Server base image if possible.

You should also check the list of precached images in Azure Container Images, available via the List Cached Images API. You might be able to switch out an image layer for one of the precached images.

See more detailed guidance on reducing container startup time.

• Nano Server: sac2016, 10.0.14393.3568 or newer
• Windows Server Core: ltsc2016, 10.0.14393.3568 or newer

• Nano Server: 1809, 10.0.17763.1040 or newer
• Windows Server Core: ltsc2019, 1809, 10.0.17763.1040 or newer
• Windows: 1809, 10.0.17763.1040 or newer

Use the smallest image that satisfies your requirements. For Linux, you could use a runtime-alpine .NET Core image, which has been supported since the release of .NET Core 2.1. For Windows, if you're using the full .NET Framework, then you need to use a Windows Server Core image (runtime-only image, such as 4.7.2-windowsservercore-ltsc2016). Runtime-only images are smaller but don't support workloads that require the .NET SDK.

ACI supports image pulls from ACR and other non-Microsoft container registries such as DockerHub. ACI supports image pulls from ACR and other non-Microsoft OCI compatible container registries such as DockerHub with an endpoint that is publicly exposed to the internet.

1. Identify what Windows base image you're currently using.

   If you're pulling directly from Microsoft Container Registry (MCR), then that image name is your base image.

   If you're working with a private registry, you'll need to look at your Dockerfile to identify the base image, which will be stated after the 'FROM' line.

2. Select the new base image you want to use from Windows Server 2019. The following examples show commonly used Windows Server 2016 images on Azure Container Instances and our recommendations for replacement Windows Server 2019 images.

   Windows Server 2016 Image	Recommended Windows Server 2019 Images
   mcr.microsoft.com/windows/servercore/iis	mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
   mcr.microsoft.com/windows/servercore:ltsc2016	mcr.microsoft.com/windows/servercore:ltsc2019

   To learn more, read about image discovery.

   Note

   If you would like assistance selecting your new base image, create an Azure Support Ticket.

3. Follow the Update containers in Azure Container Instances how-to guide to update your ACI container group to use your new base image.

   If you're using MCR for your container registry, you can pass the MCR image name directly into the container group image parameter.

   If you're using a private container registry, follow the steps in Upgrade containers to a new version of the Windows operating system. Make sure the container group's image registry parameters are updated if you've changed them.

This really depends on your workload. Start small and test performance to see how your containers do. Monitor CPU and memory resource usage, and then add cores or memory based on the kind of processes that you deploy in the container.

Make sure also to check the resource availability for the region you're deploying in for the upper bounds on CPU cores and memory available per container group.

Azure Container Instances aims to be a serverless containers-on-demand service, so we want you to be focused on developing your containers, and not worry about the infrastructure! For those that are curious or wanting to do comparisons on performance, ACI runs on sets of Azure VMs of various SKUs, primarily from the F and the D series. We expect this to change in the future as we continue to develop and optimize the service.

Yes (sometimes). See the quotas and limits article for current quotas and which limits can be increased by request.

Not yet. Currently, these values are the maximums for a container group. Contact Azure Support with specific requirements or requests.

Current region availability is published here. If you have a requirement for a specific region, contact Azure Support.

Currently, scaling isn't available for containers or container groups. If you need to run more instances, use our API to automate and create more requests for container group creation to the service.

You can deploy container groups in an Azure virtual network of your choice, and delegate private IPs to the container groups to route traffic within the virtual network across your Azure resources. For networking scenarios and limitations with Azure Container Instances, see Virtual network scenarios and resources.

Yes, the ACI service does reserve the following ports for service functionality: 22, 1025-1027, 3389-3399, 9999, 19000, 19080, 19390, 19100, 20000-30000, 49152-65534. Avoid using these ports in your container group definition.

Container group IP addresses are subject to change after being created or deleted. We recommend that your application code doesn't take a dependency on the container group's IP address. We also suggest using NAT Gateway or Application Gateway if you would like to maintain a static IP address.

Container group duration is calculated from the time that we start to pull your first container's image (for a new deployment) or your container group is restarted (if already deployed), until the container group is stopped. See details at Container Instances pricing.

Meters stop running once your entire container group is stopped. As long as a container in your container group is running, we hold the resources in case you want to start the containers up again.

Confidential computing is an industry term defined by the Confidential Computing Consortium (CCC) - a foundation dedicated to defining and accelerating the adoption of confidential computing. The CCC defines confidential computing as: The protection of data in use by performing computations in a hardware-based Trusted Execution Environment (TEE). ACI Confidential Containers introduce hardware-based protection, code integrity, and verification of the Trusted Execution Environment (TEE). Confidential containers apply the latest in confidential computing hardware enabling customers to deploy their existing applications without any modifications while taking advantage of the hardware-based data protection. Code integrity, and verification of the TEE are achieved through the attestation of a confidential computing enforcement policy, which is attached to the container group at deployment time. If any of the properties of the container group differ from those of the confidential computing enforcement policy, the environment fails to launch ensuring that the TEE isn't compromised.

Confidential containers can be used for a wide variety of elastic workloads but are especially a great fit for workloads that require strong data protection guarantees. Some examples of these workloads include machine learning workloads that utilize data sets that include personal data or with algorithms that are considered intellectual property. Healthcare customers can use it for analyzing patient data and researching. Financial services customers may use it for credit analysis risk calculation, and portfolio balancing.

Confidential computing enforcement policies can be generated using the confcom extension with the Azure CLI. For more information, see confcom extension.

GPU based ACI container deployments and Windows containers aren't supported with confidential containers.

Current region availability for confidential containers is published here.

Confidential containers on Azure Container Instances do have an additional cost compared to standard SKU container groups. For more information, see pricing page.

ACI Spot containers are a new feature that allows customers to run interruptible, containerized workloads on unused Azure capacity at up to 70% discounted prices vs regular-priority ACI containers.

ACI Spot containers may be preempted when Azure has insufficient surplus capacity and customers are billed for per-second memory/core usage. With ACI Spot Containers, you can now run your containerized workloads such as batch processing, Monte Carlo simulations, dev/test workloads and parallelizable offline workloads that can tolerate interruptions on Azure at a fraction of the cost of traditional ACI pricing. This offering is targeted at customers who wants to run interruptible workloads with no strict availability requirement.

GPU based ACI container deployments, availability zones, support for ACI deployments with Public IP and ACI deployments behind custom virtual network with Private IP aren't supported with Spot containers.

All customers get a default quota of 10 vCPU cores and 10 container groups.

Customers can file support request to increase capacity for Spot containers by selecting the issue type as "Services and Subscription limits(quotas)" and new quota type as "StandardSpotCores" added for ACI Spot containers offering when you're requested to fill in the requested details.

Azure Container Instances(ACI) Spot containers are only available in select regions during Public Preview. See Resource and region availability for more information.

ACI Spot containers are offered at discounted price and offer up to a 70% discount on top of regular priority ACI containers. The discounts would vary per month in each region. For more information, see the pricing page.

Next steps

• Learn more about Azure Container Instances.
• Troubleshoot common issues in Azure Container Instances.