Introduction to Azure Container Instances

Microsoft today released a public preview of a new service, Azure Container Instances. This may seem confusing initially, Azure already has a container service called Azure Container Services (ACS), but this is a somewhat different offering. ACS is a full container hosting solution, including orchestrators, deployed on top of multiple IaaS based Azure Virtual machines. Azure Container Instances (ACI) is not an orchestrator, it is a platform for deploying containers quickly and  simply. The exciting difference with ACI is that containers are now a first class object in Azure, using ACI you can just deploy a container object, there is no need to deploy and manage VMs to host your containers, you simply specify the size of the container your require without having to care about the underlying VMs or storage.
This simple container as service offering should be useful to those looking to quickly spin up a container without having to worry about infrastructure behind it, but what is even more exiting is the potential to provide a platform as a service offering  to be used by orchestrators for providing containers (see later in this article).
In this article we’ll take a look at some of the basics of this service, how it can be used and it’s limitations.
ACI is in preview, so there are some limitations on what you can do with the service:

Only Linux containers are supported at the moment, Windows containers to come in the future
It’s not currently possible to attach a container to a virtual network
Use of ACS is currently only through the Azure Cloud Shell or using Azure Resource Manager templates, there is no GUI in the portal and no PowerShell or Command line option to run locally. We’ll focus on using the cloud shell in this article
There are some limitations both on region availiblity, and the size of containers in a region

Containers are run on the host machine using HyperV isolation, so that container instances are as isolated as virtual machines in Azure. This should mean containers offer the same level of security and performance isolation from other users sharing the same host,
Creating a container
Creating a container is a single line command in  cloud shell, with various option. At a minimum you need to specify the name to use for the container, the image you want to use (can come from Dockerhub or a private registry), the resource group to store this in, and if you want a public IP the ip-address option. Note that your container name needs to be lower case, otherwise you’ll see an error.


az container create --name helloworld --image microsoft/aci-helloworld --resource-group containertesting --ip-address public


az container create --name --image microsoft/aci-helloworld --resource-group --ip-address public

This creates a new container with the default size of 1 CPU and 1.5GB memory. It adds a public IP and exposes port 80.

As mentioned, there’s no interface in the portal for containers, so if you look in your resource group you will see the object you created, but there is very little you can do with it in the GUI.

Once your done with container you can delete it with the container delete command


az container delete --name helloworldcontainer --resource-group containertest


az container delete --name helloworldcontainer --resource-group containertest

As mentioned containers can also be deployed using ARM templates, you can find some examples here.
Container Sizes
Unlike virtual machines, containers aren’t restricted to pre-set sizes, you can choose at deployment time the amount of CPU cores and Memory. To specify these ammend your command to include the cpu and memory commands:


az container create --name helloworld --image microsoft/aci-helloworld --resource-group containertest --cpu 2 --memory 4 --ip-address (public


az container create --name --image microsoft/aci-helloworld --resource-group containertest --cpu 2 --memory 4 --ip-address (public

I have seen some errors when deploying larger size containers in certain regions (mainly West Europe), so I suspect there are some limits in place for the preview. Larger sizes in East US seemed to work fine. I’ve not yet been able to find documentation of how big your containers can get.

Data and Persistence
As mentioned, it’s not currently possible to connect an container to an Azure virtual network so using local network resources for persisting data is not possible. Container instances do offer the ability to mount Azure file shares for persistent data, with plans to add Azure disks in the future.
I’ve not yet been able to get hold of the documentation for how to attach file shares, I will update this article when I have that.
Alternatively, if your data can be stored in a database you can  make use of public services like Azure SQL, Cosmos DB or Table storage.
Container Groups
ACI has the concept of container groups, these are multiple containers which  are deployed to the same host and share the same network and any mounted volumes, the concept is similar to Kubernetes pods. Container groups need to be deployed using an ARM template rather than through the cloud shell, you can see an example of this here.
As already mention, ACI is not an orchestator, it’s a tool for providing easy deployment of indvidual VM’s. However, ACI is intended to be used with orchestrators, theorchestrator can utilise ACI as the method of provisioning VMs and not have to care about managing hosts. ACI comes ready with an example (experimental) connector for Kubernetes and I am sure further down the line we will see these for other orchestrators.
Container pricing is a bit more complex than VM’s, your charged on 3 metrics

Create request – a one of fee for each creation of a container, currently $0.0025 in the East US region
Memory Usage – The amount of memory used by each container per second. Billed at $0.0000125 per GB per second
CPU Usage – The amount of CPU cores used by each container per second. Billed at $0.000013 per core per second

so a container created once with 2 cores and 2GB memory, running for an hour would cost
0.0025 +((0.0000125 * 3600)*2) + ((0.000013 * 3600)*2)=$0.1861

Azure Resource Policies Part 1 – Built in Policies

As your Azure usage increased you will inevitably need to grant rights to other users to create and manage resources. Often you need to apply limits to what these user can do with their Azure subscription. Role Based Access Control allows you to put users into roles which grant them access to specific top level resources (virtual machines, storage, SQL etc.), what RBAC doesn’t do however is...

Setup Storage Replica in Azure

In my last article we discussed the various different options for providing SMB shares in Azure given the lack of shared storage. One of the options we discussed for this was using a new feature of Server 2016 – Storage Replica, and in this article we will take a deep dive into how to setup this up in Azure. This Windows Server feature allows you to replicate data between two servers (or...

SMB File Sharing in Azure

In an ideal world, all our cloud applications would be designed from the ground up to work with the cloud, they would be designed to work with cloud principals, make use of PaaS services and provide high availability. Unfortunately, this is often not the case. We are regularly tasked with moving existing on-premises applications into the cloud as a “lift and shift” type operation, until they can...

Azure Resource Manger Snippets for VSCode

I previously wrote about using VS Code for authoring Azure Resource Manger templates, in particular about using the snippets from the cross platform toolkit to create skeletons for many ARM resources. In this post I documented the manual installation process for these snippets, as there was not a VS Code extension to install these automatically. This is no longer the case, I have recently...

Completing your automated VM deployments with the DSC VM extension

Azure Resource Manager (ARM) templates are a great resource for deploying Azure infrastructure, including virtual machines, in a declarative manner. However, using an ARM template to deploy a VM will only get you as far as having a VM deployed and the operating system installed and running. The next step is to get any applications and supporting software installed on those machines. Of course you...

Disaster Recovery for Azure VMS with Site Recovery

Disaster recovery is, or should be, a must for for many production applications. Having the ability to recover your application in a separate geographic location should a major incident occur is vital to the continued availability of your service. Microsoft have offered a DR service called Azure Site Recovery (ASR) for some time now, but this has been focused on taking on-premises applications...

Conditions in ARM Templates – The Right Way!

At this months Build conference there where lot’s of new Azure announcements and in particular lots of new features for Azure Resource Manager (ARM) templates. Ryan Jones. PM on ARM templates, did a breakout session talking about all this new functionality which is available now on channel 9. I want to focus on one of the big improvements, at least from perspective, and that is we now have...

ARM Template Deployments for MYSQL and PostgreSQl

Last week at build Microsoft announced a preview of MYSQL and PostgreSQL databases as a PaaS service running in Azure. Since then, we’ve not yet seen full documentation of the ARM templates required to deploy these, however some example templates did appear on Github a few days ago that provide enough information to begin creating templates that use these two database services. Both...

Azure App for iOS and Android

Today at the Build Conference, Microsoft announced the Azure Mobile app for iOS and Android (with a UWP app to come soon). I’ve had access to this app for a while during the preview and whilst it’s never going to replace the web portal for the majority of Azure work and has fairly limited functionality at the minute, it does provide a handy tool for times you need to make a change on...

Follow Me

Follow me on Twitter