Azure Container Instances capacity/provisioning failure across multiple tenants and regions

Question

Hello Azure Support,

We are experiencing a critical production outage affecting Azure Container Instances (ACI) across multiple tenants/subscriptions.

Impact

• All workloads running on Azure Container Instances are currently stopped or unable to start.

This is affecting production services across multiple tenants.

Unable to restore service by redeploying or scaling down resource requests.

Scope

We tested multiple regions including:

Australia East

Australia Southeast

Multiple Asia regions

The issue appears widespread and not isolated to a single subscription or tenant.

Symptoms

Even the smallest Linux container groups fail to provision.

Example deployment:

1 vCPU

1.5 GB RAM

Linux OS

Error Received

Failed to start the container group

Error:
Subscription deployment didn't reach a successful provisioning state after '00:30:00'.

The requested resource is not available in the location 'australiaeast' at this moment.
Please retry with a different resource request or in another location.

Resource requested:
'1' CPU
'1.5' GB memory
'Linux' OS

This same error repeats across multiple attempts and regions.

Troubleshooting Already Performed

Retried deployments multiple times

Tested smaller container sizes

Tested multiple regions

Tested across multiple tenants/subscriptions

Confirmed issue is not limited to one workload

Business Impact

This is a full service outage impacting containerized workloads and customer-facing systems. Immediate assistance is required.

Request

Please investigate urgently:

Confirm if there is an active Azure Container Instances capacity/platform incident

Provide ETA for mitigation

Advise temporary workaround or healthy regions

Confirm whether this is regional capacity exhaustion or control plane issue

Contact

Please treat this as Severity A / Critical.

Thank you.

Answer 1

The error message indicates an ACI capacity issue in the target regions rather than a problem with the specific container configuration or subscription quotas.

Key points from documented behavior and guidance:

1. ACI has hard per-container-group limits, but the configuration described (1 vCPU, 1.5 GB RAM, Linux) is well within the documented maximums, so the failure is not due to exceeding standard resource limits.
   • Standard ACI container groups can use up to 31 vCPUs and 240 GB memory per group in supported regions.
2. When deployments fail with messages such as:

   "The requested resource is not available in the location '<region>' at this moment. Please retry with a different resource request or in another location." this typically indicates a regional capacity or platform-side issue rather than a misconfiguration on the customer side.

3. Official guidance for capacity-related or quota-like deployment failures in ACI includes:
   • Verify that requested CPU and memory are within the documented [Resource availability & quota limits for Azure Container Instances].
   • If deployments fail even with small CPU/memory values and across multiple retries, consider deploying to a different Azure region where capacity may be available.
   • For spot containers specifically, guidance is to:
     • Lower CPU/memory requests.
     • Try different regions.
     • Deploy during off-peak hours if the issue is related to capacity adjustments. The same mitigation patterns apply to standard ACI when the platform reports that requested resources are not available in a region.
4. For production reliability, ACI guidance is to:
   • Run workloads across multiple availability zones where supported.
   • Consider running separate container groups in multiple regions and front them with a global load-balancing service (for example, Azure Traffic Manager or Azure Front Door) so that if one region experiences capacity or platform issues, traffic can fail over to another region.
   • Overprovision container groups to tolerate capacity loss in one zone or region.
5. ACI is a single-region service for each container group. If a region is unavailable or experiencing platform issues, container groups in that region will be unavailable. Multi-region deployment and failover are customer responsibilities.
6. For issues that appear to be widespread, cross-region, and service-side (as in this case), the documented escalation path is:
   • Check Azure Status and Service Health in the Azure portal for any active incidents affecting Azure Container Instances in the impacted regions.
   • If no incident is visible but the behavior persists across regions and subscriptions, open an Azure Support request so the engineering team can investigate as a potential platform incident.

Actionable steps based on the documented guidance:

1. Confirm capacity and limits
   • Ensure the container group definitions are within the documented ACI limits (they are, based on the example provided).
2. Try alternate regions
   • Attempt deployments in other ACI-supported regions outside the currently affected geographies (for example, regions in another continent) to identify any region that still has available capacity.
3. Implement multi-region resiliency pattern
   • For critical workloads, deploy ACI-based services in at least two regions and front them with a global load-balancing service so that traffic can be routed away from an impacted region.
4. Open a critical Azure Support request
   • Use the Azure portal to create a Severity A support ticket for Azure Container Instances, referencing the error text and regions tested, so the platform team can confirm whether there is an active capacity/platform incident and provide an ETA.

The documentation does not provide real-time incident status or ETAs; those are only available through Azure Status, Service Health, and direct Azure Support engagement.

---

References:

• Resource availability & quota limits for ACI
• Reliability in Azure Container Instances
• Spot containers remain in the Waiting state
• Support and troubleshooting for Azure Container Instances