Azure Container Instance
Does ZopNight manage Azure Container Instance?
Azure Container Instances bill per second for the vCPU and memory a container group requests, from creation until the group stops or is deleted. ZopNight discovers every group with state and sizing via Resource Graph, attributes the per-second spend from Cost Management, and keeps 60 days of utilization for review.
Rules that fire on Azure Container Instance
No active rule family targets Azure Container Instance today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Azure Container Instances run containers on demand without managing servers or orchestrators, billed per second of vCPU and memory. Long-lived container groups that were meant to be ephemeral quietly become always-on compute spend.
Per-second charges that forget to end
ACI meters the vCPU and memory a container group requests (not what the containers inside actually consume) for every second the group runs. The pricing model is built for short bursts: a task that needs 2 vCPUs for ten minutes pays for exactly ten minutes. The trouble begins when the burst never ends. A group whose restart policy is Always will be brought back by the platform after every exit, converting a supposedly one-shot workload into a permanent per-second charge that looks tiny on any single day and substantial across a quarter.
ACI visibility inside ZopNight
Azure Resource Graph discovery captures each container group with its state and sizing. Cost Management attributes the per-second compute spend, and Azure Monitor metrics over a 60-day lookback support utilization review. ACI is not schedulable in ZopNight, because the service’s own model is that ephemeral work should terminate rather than be stopped externally. The platform’s role here is making long-running groups impossible to miss.
How ephemeral containers become permanent spend
Three shapes recur. Restart-policy drift: batch containers created with Always instead of Never or OnFailure, resurrected forever. Demo residue: groups spun up for a proof of concept, working perfectly, billed indefinitely because deleting them was nobody’s job. And request padding: groups asking for several vCPUs and gigabytes of memory as a precaution, where the meter reads the request, not the usage.
Container groups in the portal
Azure portal → Container instances lists every container group with its status. Sorting by creation date surfaces the oldest running groups. For a service designed around ephemerality, age itself is the strongest waste signal, and any group months old deserves a justification.