Azure Container Instances represents the smallest compute primitive in Azure for running containerized workloads. It is positioned as the fastest path to execute a Docker container in Azure without provisioning or managing virtual machines or an orchestrator. The service accepts a container image, a set of resource requirements, and networking intent and starts the container within seconds. This immediacy makes it suitable for burst workloads, batch jobs, CI/CD runners, and any scenario where containers are needed on demand without the overhead of a control plane.
Terraform translates that immediacy into repeatable infrastructure. Instead of relying on CLI commands that are easy to forget or drift over time, the entire container configuration is declared in code. The declaration captures images, resource allocations, networking, volumes, and probes in a versioned artifact that can be reviewed, peer-reviewed, and applied consistently across environments. The impact of that shift is operational: teams gain reproducibility for ephemeral workloads and an audit trail for every container deployment. The contextual layer is that ACI fits alongside other Azure container services. It is the simplest option for isolated containers, while persistent multi-service deployments may require evaluation against Azure Kubernetes Service.
Terraform itself enables definition, preview, and deployment of cloud infrastructure. Configuration files are authored in HCL syntax. HCL allows explicit specification of the cloud provider, such as Azure, and the elements that compose the cloud infrastructure. After configuration files are created, an execution plan is created to preview infrastructure changes before they are deployed. That preview step is the core safety mechanism for ACI deployments where public IP exposure and resource allocation have cost implications.
Azure Container Instances Core Characteristics
Azure Container Instances provides the fastest way to run a Docker container in Azure without managing any virtual machines or orchestrators. You specify the container image, resource requirements, and networking, and ACI starts the container within seconds. It is ideal for burst workloads, batch jobs, CI/CD runners, and any scenario where you need containers on demand.
The real-world consequence for users is reduced time to value for short-lived workloads. Developers can ship a container image and have it running in seconds without waiting for node provisioning or cluster upgrades. The contextual connection is to Terraform. Because ACI starts quickly, Terraform apply cycles remain short and feedback loops stay tight. The same speed also means cost exposure is per-second, which makes plan preview and tagging important before apply.
Use Azure Container Instances to run serverless Docker containers in Azure with simplicity and speed. Deploy an application to a container instance on-demand when you don't need a full container orchestration platform like Azure Kubernetes Service. In this article, you use Terraform to deploy an isolated Docker container and make its web application available with a public IP address.
The isolation model means each container group can be addressed directly via a public IP address. That model simplifies debugging and monitoring because endpoints are directly reachable. The trade-off is that security boundaries must be defined explicitly through network policies, DNS labels, and Azure Monitor integration.
Prerequisites and Local Tooling
Prerequisites for Terraform ACI work are minimal.
- You need Terraform CLI on your local machine, if you’re new to using Terraform to deploy Microsoft Azure resources, then I recommend you check out this link.
- A text editor or IDE of your choice (Visual Studio Code with terraform extension is my recommendation)
The presence of Terraform CLI establishes the execution environment. The CLI handles provider plugin download, state management, and plan/apply. The text editor choice impacts authoring speed for HCL files and for editing variables and outputs. Visual Studio Code with the Terraform extension provides syntax highlighting and validation for Azure provider resources.
The provider configuration file is the entry point for Azure interactions.
The provider.tf file in Terraform is used to specify and configure the providers used in your Terraform configuration. A provider is a service or platform where the resources will be managed
Declaring the Azure provider with authentication settings ensures that all subsequent resources are interpreted in the correct subscription and tenant context. The provider block is the anchor for resource naming conventions, default tags, and feature toggles.
Terraform Module for Azure Container Instances
This Terraform module deploys a Linux or Windows container in Azure using Azure Container Instances.
The module demonstrates the fastest and simplest way to run a container in Azure, without having to manage any virtual machines and without having to adopt a higher-level service.
The module source referenced in the reference material is:
source = "Azure/aci/azurerm"
A representative module invocation is:
module "aci" {
source = "Azure/aci/azurerm"
resource_group_name = "MyContGroup-RG01"
location = "westus"
container_group_name = "myContGroup"
dns_name_label = "cont01-example"
os_type = "linux"
image_name = "microsoft/aci-helloworld"
container_name = "mycont01"
cpu_core_number = "0.5"
memory_size = "1.5"
port_number = "80"
}
The module encapsulates the resource group, container group, and container instance definitions. Using a module reduces duplication and centralizes defaults for tagging and networking.
Variable defaults can be declared to simplify reuse:
variable "resource_group_name" {
default = "test-aci-rg01"
}
A second example invocation shows partial parameters with variable interpolation:
module "aci" {
source = "Azure/aci/azurerm"
dns_name_label = "cont01-example"
os_type = "linux"
image_name = "microsoft/aci-helloworld"
resource_group_name = "${var.resource_group_name}"
}
Outputs expose runtime information for downstream automation and monitoring.
output "fqdn" {
value = "${module.aci.containergroup_fqdn}"
}
output "ip" {
value = "${module.aci.containergroup_ip_address}"
}
output "id" {
value = "${module.aci.containergroup_id}"
}
The outputs provide the fully qualified domain name, public IP address, and resource ID of the container group. These values enable integration with monitoring tools and CI pipelines that need to know where the container is reachable.
The module was originally created by Alexander Shapoval. This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution
The table below summarizes the module parameters observed in the reference facts.
| Parameter | Example Value | Context |
|---|---|---|
| resourcegroupname | MyContGroup-RG01 | Container group placement scope |
| location | westus | Azure region for deployment |
| containergroupname | myContGroup | Logical group name for ACI |
| dnsnamelabel | cont01-example | Public DNS label for container group |
| os_type | linux | Container operating system |
| image_name | microsoft/aci-helloworld | Container image reference |
| container_name | mycont01 | Name of container within group |
| cpucorenumber | 0.5 | CPU allocation |
| memory_size | 1.5 | Memory allocation |
| port_number | 80 | Exposed port |
Resource Group and Container Group Declaration
The guide covers all the basic and essential aspects, from setting up a resource group and virtual network to deploying container instances. In a future post, we will delve deeper into incorporating additional features and more advanced configurations. However, for a simple and functional deployment, this guide covers everything you need.
Resource groups provide a container for ACI resources and allow tagging for cost allocation. Terraform manages the lifecycle of the resource group alongside the container group, ensuring that deletion order respects dependencies.
The container group declaration binds the image, CPU, memory, and port. The port number defines the listening endpoint. When a dnsnamelabel is provided, Azure allocates a public IP and assigns a DNS name that resolves to the container group.
The impact of declaring resource groups in Terraform is consistent naming and automated cleanup. The contextual link is to networking. A container group with a public IP can be reached from the internet, which makes monitoring and alerting essential from day one.
Networking, Public IP and DNS
Use Azure Container Instances to run serverless Docker containers in Azure with simplicity and speed. Deploy an application to a container instance on-demand when you don't need a full container orchestration platform like Azure Kubernetes Service. In this article, you use Terraform to deploy an isolated Docker container and make its web application available with a public IP address.
Public IP exposure enables direct access for web applications and APIs. The DNS label creates a stable hostname that remains constant across container restarts within the same container group. Terraform captures the public IP address and FQDN as outputs for validation.
Terraform enables the definition, preview, and deployment of cloud infrastructure. Using Terraform, you create configuration files using HCL syntax. The HCL syntax allows you to specify the cloud provider - such as Azure - and the elements that make up your cloud infrastructure. After you create your configuration files, you create an execution plan that allows you to preview your infrastructure changes before they're deployed
The plan step is critical for ACI because public IP allocation and DNS label changes are immediate. Previewing changes prevents accidental exposure of new endpoints or removal of existing ones.
Operational Workflow with Terraform
This downloads the Azure provider plugin and initializes the backend.
Always review the plan before applying. Check that only the expected resources will be created.
Terraform will create all resources in the correct order, handling dependencies automatically.
After applying, verify your resources are running correctly:
The workflow described is initialize, plan, apply, verify.
terraform init
The init command downloads provider plugins and prepares the working directory. The plan command generates a preview of changes. The apply command executes the plan.
The impact of reviewing the plan is prevention of unintended resource creation. The contextual layer is that Terraform handles dependencies automatically, so resource group creation precedes container group creation without explicit depends_on in most cases.
Set up monitoring from day one:
Learn by doing with interactive courses on CopyPasteLearn:
Managing Azure resources with Terraform brings consistency, version control, and automation to your infrastructure. The configurations in this guide follow production best practices and can be extended to match your specific requirements. Start with these foundations and iterate as your infrastructure needs evolve.
Operational best practices derived from the reference facts include:
- Tag resources consistently for cost tracking
- Use outputs for FQDN and IP to feed monitoring systems
- Review plan output before apply to avoid unexpected public exposure
- Keep Terraform state secure and versioned
Use OneUptime to monitor the endpoints exposed by your containers and get alerted on failures. For containers running batch jobs, track completion status and duration to detect processing delays before they affect downstream systems.
Monitoring bridges the gap between declarative deployment and runtime health. Container instances are ephemeral by design, so external monitoring must be configured to detect restarts, crashes, and latency spikes.
For storing container images, see our guide on Azure Container Registry at https://oneuptime.com/blog/post/2026-02-23-how-to-create-azure-container-registry-in-terraform/view.
The reference to Azure Container Registry shows the ecosystem connection. ACI can pull images from ACR, and Terraform can manage both services together. This linkage is relevant for private image scenarios and for enforcing image immutability.
Quickstart Metadata and Documentation
| title | Quickstart: Create an Azure Container Instance with a public IP address using Terraform | |
|---|---|---|
| description | In this article, you create an Azure Container Instance with a public IP address using Terraform | |
| ms.topic | quickstart | |
| ms.service | azure-container-instances | |
| ms.date | 11/17/2025 | |
| ms.update-cycle | 180-days | |
| ms.custom | devx-track-terraform, linux-related-content | |
| author | TomArcherMsft | |
| ms.author | tarcher |
The sample code for this article is located in the Azure Terraform GitHub repo
The metadata indicates the official quickstart nature of the content, the service scope, and the update cycle. The date 11/17/2025 provides temporal context for the documentation version.
Summary and Production Considerations
Summary
Azure Container Instances provide the simplest way to run containers in Azure. Terraform captures the full deployment configuration - images, resources, networking, volumes, and probes - in code that can be versioned and reviewed. Use ACI for burst workloads and batch jobs where you want container simplicity without Kubernetes complexity. For persistent, multi-service deployments, consider whether ACI or AKS better fits your needs.
Nawaz Dhandala
Author@nawazdhandala • Feb 23, 2026 •
The summary reinforces the core value proposition. Terraform captures the full deployment configuration in code that can be versioned and reviewed. That versioning enables change control for container images, resource sizes, and networking.
Azure Monitor and Log Analytics with Terraform
Configure Azure Monitor, Log Analytics, and alerts with Terraform for comprehensive cloud observability. Step-by-step guide with code examples and best pract...
Deploy Azure Container Registry and Container Instances with Terraform for lightweight container workloads. This tutorial provides production-ready Terraform code you can adapt for your own infrastructure.
The following Terraform configuration creates the resources described above. Each resource includes proper tagging, security settings, and follows Azure best practices.
The reference to production-ready code with tagging and security settings indicates that Terraform configurations for ACI should include resource locks, network restrictions, and diagnostic settings where appropriate.
Conclusion
The intersection of Terraform and Azure Container Instances creates a narrow but powerful path for container workloads that do not require orchestration. Terraform provides the repeatable, versioned, and previewable layer that converts ad-hoc container launches into managed infrastructure. The module pattern demonstrated with source = "Azure/aci/azurerm" abstracts the complexity of container group and container resource definitions while exposing parameters for resource group, location, OS type, image, CPU, memory, and port. Outputs for FQDN, IP, and resource ID close the loop between deployment and observability.
The operational impact is measurable. Deployment time collapses to seconds, cost aligns with per-second billing, and the entire lifecycle is captured in HCL. The contextual impact is that teams can standardize burst workloads, batch jobs, and CI/CD runners under a single IaC workflow without introducing Kubernetes overhead. Monitoring endpoints exposed by containers with tools such as OneUptime and integrating Azure Monitor and Log Analytics via Terraform completes the production posture.
The choice between ACI and AKS remains workload dependent. ACI excels when container isolation, rapid start, and simple networking are sufficient. Terraform makes that choice reversible because infrastructure is code. As requirements evolve, the same declarative principles apply whether the target is a single container instance or a larger container registry and instance topology.