# Leave address-reuse headroom in an ACI subnet

> Why can a small Azure Container Instances subnet fail during container lifecycle operations?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-429-leave-address-reuse-headroom-in-an-aci-subnet/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:47+00:00
- Modified: 2026-09-10T02:04:57+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Why can a small Azure Container Instances subnet fail during container lifecycle operations?

## Potentially affected

Use this capacity check for ACI groups deployed into an Azure virtual network. Confirm current regional and networking prerequisites. Plan outbound connectivity separately using the documented supported configuration; a subnet-size review is not a complete network design.

## DSE recommendation

Size the delegated subnet for lifecycle behavior, not just the present running-group count.

## Article

## Source facts

Microsoft’s ACI virtual-network deployment guide recommends a subnet of at least /24, or 256 addresses. It warns that smaller subnets can produce subnet-full failures because ACI cannot release address mappings quickly enough for reuse, leaving containers unable to start, restart or stop. The subnet must be explicitly delegated before deployment and can contain only container groups. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-vnet).

## Applicability

Use this capacity check for ACI groups deployed into an Azure virtual network. Confirm current regional and networking prerequisites. Plan outbound connectivity separately using the documented supported configuration; a subnet-size review is not a complete network design.

## DSE recommendation

Size the delegated subnet for lifecycle behavior, not just the present running-group count. Have the network owner reserve an appropriate address range and compare it with Microsoft’s current recommendation before rollout. Include planned creation, restart and replacement activity in the capacity discussion. Do not remove unrelated resources from a shared subnet to force it into the ACI design without a separate authorized migration. Keep subnet delegation and address availability visible in the deployment review.

## Verification

In an approved representative environment, inspect the delegated subnet and observe the intended container creation and restart sequence. Retain subnet-full errors and group-state transitions if they occur. Confirm that lifecycle operations complete with the chosen allocation. Do not interpret a single successful deployment in a small subnet as evidence that repeated replacements will have sufficient address-reuse headroom.

## Official references

[Microsoft Learn: Deploy container group to Azure virtual network](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-vnet).

## Primary reference

- Name: Deploy container group to Azure virtual network - Azure Container Instances | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/container-instances/container-instances-vnet
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Leave address-reuse headroom in an ACI subnet,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-429-leave-address-reuse-headroom-in-an-aci-subnet/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.