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.

   Expand table

   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.

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