Containers Serverless containers premium top250-pre130-priority field-manual-complete

Container group

Container group means the Azure Container Instances deployment unit that runs one or more containers together on the same host. Teams use it to model simple serverless container workloads, sidecars, one-off jobs, and shared volumes without managing a Kubernetes cluster. In Azure operations, it appears in Azure Container Instances resources, YAML definitions, ARM templates, public IP settings, DNS labels, volume mounts, container logs, and short-lived job runbooks. The practical question is which app, revision, image, identity, network path, or cost boundary it changes, and what live evidence proves the setting is healthy.

Back to glossary browser Open Microsoft Learn source
Aliases
No aliases mapped yet
Difficulty
fundamentals
CLI mappings
3
Last verified
2026-05-12

Microsoft Learn

A container group is the top-level Azure Container Instances resource where one or more containers share lifecycle, resources, network, and volumes on the same host.

Microsoft Learn: Container groups in Azure Container Instances2026-05-12

Technical context

Technically, Container group is the top-level Azure Container Instances resource that schedules containers together with shared lifecycle, local network, resources, and storage volumes. Engineers verify it through container group state, container logs, restart policy, exposed ports, IP address, DNS label, mounted volumes, image references, and events. Important configuration includes containers, images, CPU and memory, restart policy, environment variables, ports, DNS label, virtual network, registry credentials, and volume mounts. Production reviews should capture owner, resource group, region, environment, resource IDs, deployment version, diagnostics, limits, and rollback notes before changing it.

Why it matters

Container group matters because container groups provide fast container execution, but shared lifecycle and host placement make design choices visible in reliability and recovery. The business impact is practical: users may see failed requests, delayed processing, leaked traffic, stale credentials, slow starts, or unexpected charges when teams misunderstand it. A strong glossary entry gives architects, developers, security reviewers, and operators the same language for design reviews and incident handoffs. It connects the Azure setting to ownership, measurable objectives, dashboards, rollback paths, and audit evidence. That shared understanding helps teams make safer production changes under pressure instead of treating the setting as a portal detail.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

You see Container group in Container Instances groups, container definitions, networking, and restart logs when confirming containers, resource requests, volumes, IP settings, and restart policy for release, audit, or incident evidence.

Signal 02

You see Container group during troubleshooting when short-lived containers fail or cannot share expected volumes and operators must connect portal state, CLI output, logs, metrics, owners, and rollback notes.

Signal 03

You see Container group in architecture reviews when teams decide how multiple containers run together as one ACI unit, how evidence is gathered, and how it affects security, reliability, operations, cost, and performance.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Run short-lived ACI jobs where containers share lifecycle, network, and mounted volumes without needing Kubernetes.
  • Package sidecar logging, helper containers, or initialization work with the primary container in one deployment unit.
  • Troubleshoot image pulls, exit codes, restart policy, ports, DNS labels, and volume mounts for a failed container group.
  • Use container groups for demos, batch processing, conversion jobs, and maintenance tasks that need quick isolated execution.
  • Document CPU, memory, networking, secrets, cleanup, and ownership so temporary container groups do not become unmanaged infrastructure.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Data converter container group with sidecar logging

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Graphic Design Institute, a public-sector training provider, needed a temporary converter that processed uploaded design files and shipped logs to a central endpoint.

Business/Technical Objectives
  • Run converter and log-forwarder containers together
  • Avoid managing a Kubernetes cluster for a small workload
  • Complete each conversion job within 12 minutes
  • Keep uploaded files on approved storage volumes
Solution Using Container group

The team deployed an Azure Container Instances container group with two Linux containers scheduled together: the converter and a log-forwarding sidecar. Both shared lifecycle and local network, while Azure Files volumes provided approved input and output paths. The YAML definition captured image names, CPU, memory, restart policy, ports, and volume mounts. Operators used CLI commands to inspect container states, exit codes, and logs after each job. The design avoided public IP exposure because users interacted through a separate upload service. The runbook also recorded owner, scope, resource IDs, monitoring window, rollback trigger, and review date so support, security, and finance could make decisions from the same evidence. Operators attached before-and-after metrics to the change record and reviewed them with the service owner before closing the release.

Results & Business Impact
  • Average conversion job completed in 7 minutes
  • No Kubernetes cluster was required for the temporary service
  • Central logging captured both containers in the group
  • Private storage volume access satisfied data-handling review
Key Takeaway for Glossary Readers

A container group is useful when containers truly need shared lifecycle and simple serverless execution.

Case study 02

Election report generation with Azure Container Instances

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CivicCount Analytics prepared nightly election-readiness reports for county officials and needed isolated runs before each public test.

Business/Technical Objectives
  • Run report generation on demand without persistent servers
  • Expose no public endpoint for internal processing
  • Capture output files and logs for audit review
  • Finish each county report before the nightly deadline
Solution Using Container group

Engineers packaged the report generator as a container group deployed from an ARM template. The group used a private container image, environment variables from secure parameters, an Azure Files mount for generated reports, and a restart policy appropriate for batch work. Operators checked container group state, events, logs, and exit code after each run. Because the workload was not a long-lived app, ACI provided the right operational model. The runbook included the exact image tag and storage mount for audit traceability. The runbook also recorded owner, scope, resource IDs, monitoring window, rollback trigger, and review date so support, security, and finance could make decisions from the same evidence.

Results & Business Impact
  • Nightly report generation completed 42 percent faster than the VM script
  • Public network exposure was removed from the workflow
  • Audit staff received logs, exit codes, and output file locations
  • The team retired two underused reporting VMs
Key Takeaway for Glossary Readers

Container groups give simple batch workloads a clear deployment unit with auditable runtime evidence.

Case study 03

Media rendering job with shared volume

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Fourth Wall Studios, a media production company, needed short bursts of rendering capacity for preview clips after editors uploaded project files.

Business/Technical Objectives
  • Start rendering jobs without waiting for VM provisioning
  • Share scratch storage between renderer and compressor containers
  • Track failures by container exit code
  • Stop paying once preview jobs completed
Solution Using Container group

The engineering team created a container group with a renderer container and a compressor container that shared an Azure Files volume. The group used a private registry image and a restart policy that exposed failed jobs for review instead of looping forever. The workflow API submitted the container group, then collected logs, output files, and exit codes. Operators sized CPU and memory from previous render duration data. For long production renders, the team still used a different platform, but ACI solved preview bursts cleanly. The runbook also recorded owner, scope, resource IDs, monitoring window, rollback trigger, and review date so support, security, and finance could make decisions from the same evidence.

Results & Business Impact
  • Preview job startup time fell from 20 minutes to under 2 minutes
  • Shared volume handling eliminated manual file copies
  • Failed renders were triaged by container exit code
  • Compute charges stopped when each group finished
Key Takeaway for Glossary Readers

Container groups shine for short-lived coordinated containers when shared lifecycle is intentional.

Why use Azure CLI for this?

Use CLI checks to inspect container group state, logs, networking, and image references for short-lived Azure Container Instances workloads.

CLI use cases

  • Show container group properties before troubleshooting a failed job.
  • Collect container logs and exit codes after an ACI run.
  • Verify IP address, ports, image, restart policy, and volumes.

Before you run CLI

  • Confirm tenant, subscription, resource group, environment, region, and app name before collecting or changing production Container Apps evidence.
  • Use least-privileged access and avoid exposing tokens, registry credentials, connection strings, or customer data in CLI output.
  • Know whether the command is read-only, mutating, cost-impacting, traffic-impacting, or security-impacting before running it in production.

What output tells you

  • Output confirms whether live Azure configuration exists at the expected scope and matches the approved deployment design.
  • Returned names, IDs, revision states, traffic weights, replica counts, or image references help separate drift from application behavior.
  • Differences between expected and actual state create evidence for rollback, owner follow-up, audit review, or support escalation.

Mapped Azure CLI commands

Container commands

direct
az container list --resource-group <resource-group> --output table
az containerdiscoverContainers
read-only Microsoft docs
az container show --name <container-group> --resource-group <resource-group>
az containerdiscoverContainers
read-only Microsoft docs
az container create --name <container-group> --resource-group <resource-group> --image mcr.microsoft.com/azuredocs/aci-helloworld
az containerprovisionContainers
mutating Microsoft docs

Architecture context

A container group in Azure Container Instances is the small deployment boundary that shares lifecycle, networking, volumes, and placement for one or more containers. I use it when the architecture calls for a short-lived job, sidecar-style helper, build task, or simple service that does not justify an orchestrator. The important design choice is what must start, stop, and fail together. Containers in the group share an IP address and can use shared volumes, so dependency order, ports, secrets, restart policy, and logs need review. Operators should know whether the group is disposable, how output is collected, and what retries exist. It is useful, but it should not be stretched into a hidden platform.

Security

Security for Container group focuses on image trust, registry credentials, network exposure, environment variables, volume mounts, managed identity, and public IP or private network choices. Review managed identity, RBAC, registry permissions, secrets, ingress, network rules, image provenance, audit logs, and who can change the resource. Prefer private endpoints or internal ingress where appropriate, Key Vault backed secrets, least privilege, and explicit approval for public exposure. Watch for broad contributor access, plaintext environment variables, untrusted images, stale revisions, and logs that reveal tokens or customer data. Production use should include owner, rotation path, emergency rollback, and evidence that security controls apply to every active revision.

Cost

Cost for Container group comes from CPU and memory allocation, runtime duration, idle groups, failed restarts, log retention, mounted storage, and repeated ad hoc jobs. Direct charges may be visible in billing, but indirect costs appear as incident response, excessive telemetry, duplicate capacity, failed retries, slow deployments, or support time. Review budgets, tags, workload profile placement, replica limits, retention policies, build frequency, and log ingestion before scaling or automating it. Tie every cost increase to an owner, business reason, expected duration, and measurement window. This helps finance distinguish intentional capacity from waste and helps engineers avoid small configuration choices becoming monthly variance.

Reliability

Reliability for Container group depends on restart policy, image pull success, container exit codes, shared lifecycle, volume availability, DNS/IP assignment, and job completion behavior. Operators should know expected scale behavior, startup path, dependencies, probes, retry rules, image pull path, and the rollback target. Monitor replica state, revision health, ingress errors, dependency failures, queue depth, latency, and quota. Test the failure path before production change, including image pull failure, secret rotation, downstream outage, and traffic rollback. Keep a known-good revision or image available when possible. This prevents a small configuration mistake from becoming a user-visible outage during a busy release window. Review the evidence after every release.

Performance

Performance for Container group is about startup time, image size, CPU and memory allocation, shared local networking, volume performance, and dependency latency. Measure signals that reflect workload experience, such as latency, throughput, queue depth, replica readiness, image pull duration, CPU, memory, connection counts, or dependency response time. Avoid tuning one setting in isolation when identity, network path, registry location, cache state, partitioning, image size, or downstream services also influence results. Keep baseline measurements before and after changes so regressions are visible. That evidence helps teams optimize the actual bottleneck instead of the most obvious Container Apps setting. Use the same measurement window across stable and candidate versions.

Operations

Operationally, Container group needs clear ownership, naming, tagging, change records, and repeatable verification. Teams should know which portal blade, CLI command, metric, log query, deployment file, and runbook prove current state. Capture before-and-after evidence for production changes, including resource IDs, revision names, image digests, traffic weights, replica counts, secrets, region, and monitoring window. Keep rollback steps near the change record, not in personal notes. For support, define who can approve changes, who monitors impact, and when old revisions, images, or sessions should be cleaned up. Also document alert recipients, emergency approvers, evidence owners, and the post-rollout review date for audits.

Common mistakes

  • Expecting independent lifecycle for containers inside the same group.
  • Leaving public IP exposure enabled for internal processing jobs.
  • Undersizing CPU or memory and blaming the application for exits.