Azure Container Instances let you run Docker containers in Azure without managing a full orchestration platform like Kubernetes. These are serverless containers that start quickly and are billed by the second, making them ideal for isolated workloads, testing, or applications that need to scale on demand. The service handles the underlying infrastructure, so you focus on the container itself rather than the virtual machines running it.
When you create a container instance, you must decide how much compute power it needs. CPU cores determine how many processing tasks the container can handle at once, while memory in gigabytes controls how much data the container can hold while running. You set these limits when you deploy, and Azure allocates the necessary resources from its infrastructure. If you allocate too little, the container may run slowly or fail; if you allocate too much, you pay for resources you do not use.
Each container instance can be configured with a public or private IP address, which determines whether traffic from the internet can reach it. When you need the container to respond to users, you open a specific port and choose the protocol (usually TCP). The public IP makes the container reachable from anywhere, while a private IP restricts access to within your virtual network. This choice matters because public containers face the internet and need security measures, while private containers are safer but require other resources in the same network to reach them.
You control what happens when a container stops by setting a restart policy. The Always policy keeps the container running and restarts it if it ever stops, which works for web services that must stay available. The OnFailure policy restarts the container only when it exits with an error, useful for batch jobs that should retry on failure. The Never policy leaves the container stopped after it finishes, which fits one-time tasks. Choosing the right policy prevents unnecessary restarts and ensures your application behaves as expected.
A decision tree that starts with whether a container must stay running, then branches on failure retry needs to choose the Always, OnFailure, or Never restart policy.
Bicep is a language that lets you describe Azure resources in code rather than clicking through the portal. A Bicep file defines the container name, image, CPU, memory, ports, and restart policy in one place, then Azure deploys everything exactly as specified. This approach makes deployments repeatable and version-controlled, so you can recreate the same container environment across different environments or share the configuration with your team. The file also outputs useful information like the container's IP address after deployment, which you can use in other scripts or automation.
You deploy the Bicep file using either Azure CLI or Azure PowerShell, depending on which command-line tool you prefer. Both commands first create a resource group to hold the container, then run the deployment to create the container instance from your Bicep file. After deployment, you can manage the container through the Azure portal or continue using CLI and PowerShell commands. The deployment process is the same regardless of which tool you choose; the difference is only the syntax of the commands you type.
Eager to master hybrid server management? Discover how to administer Windows Server Hybrid Core Infrastructure on Azure, setting your path towards the Microsoft Certified: Azure Hybrid Infrastructure Administrator Associate certification!
Prepare and test your skills
Prepare and test your skills
Azure Container Instances supports Always, OnFailure, and Never restart policies. The Always policy keeps containers running and restarts them whenever they stop, which is suited for web services that must remain available. The OnFailure policy restarts containers only upon exiting with an error for batch job retries, while the Never policy leaves containers stopped after completion for one-time tasks.
A public IP address makes an Azure Container Instance reachable from anywhere across the internet on configured ports, whereas a private IP address restricts network access strictly to resources within the same virtual network. Public containers face the internet and require security measures, while private containers provide greater security by preventing external internet access.
You can deploy a Bicep file to create an Azure Container Instance using either Azure CLI or Azure PowerShell. Both tools use the same deployment process of creating a resource group first and then deploying the container instance according to the configuration in the Bicep file.
StudyCerts
StudyCerts