Handle CloudFormation Concurrent Stack Update Limits (2026)

CloudFormation’s default concurrent stack update limit is a surprisingly low number that can cripple your IaC velocity if you don’t manage it.

Let’s see it in action. Imagine you have a set of common infrastructure components, like VPCs, subnets, and security groups, managed by a "base" CloudFormation stack. You also have application stacks that depend on these base resources.

# base-infrastructure.yaml
Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

# app-service-a.yaml
Resources:
  AppServiceA:
    Type: AWS::ECS::Service
    Properties:
      Cluster: !Ref AppCluster # Assumes AppCluster is defined elsewhere, perhaps in another stack
      TaskDefinition: !Ref AppTaskDefinition
      DesiredCount: 3
      NetworkConfiguration:
        AwsvpcConfiguration:
          Subnets:
            - subnet-0123456789abcdef0 # Reference to a subnet from base-infrastructure.yaml
          SecurityGroups:
            - sg-0abcdef1234567890 # Reference to a security group from base-infrastructure.yaml

# app-service-b.yaml
Resources:
  AppServiceB:
    Type: AWS::ECS::Service
    Properties:
      Cluster: !Ref AppCluster
      TaskDefinition: !Ref AppTaskDefinition
      DesiredCount: 2
      NetworkConfiguration:
        AwsvpcConfiguration:
          Subnets:
            - subnet-0123456789abcdef0
          SecurityGroups:
            - sg-0abcdef1234567890

When you update base-infrastructure.yaml, CloudFormation initiates a stack update. If you then try to update app-service-a.yaml and app-service-b.yaml concurrently, you might hit the limit. CloudFormation treats each stack operation (create, update, delete) as a "change set" that consumes a portion of your available concurrency. The default limit is 10 concurrent stack operations per AWS Region per AWS account. This means if you have 10 ongoing stack updates, your 11th will be throttled.

This limit isn’t arbitrary; it’s a safeguard against accidental, widespread disruption. Imagine a bad configuration change propagating across dozens of stacks simultaneously. By default, AWS wants to give you a buffer. However, for teams practicing GitOps or aiming for high deployment frequency, this buffer can become a bottleneck.

The core problem is that CloudFormation, by default, doesn’t inherently understand inter-stack dependencies when it comes to operation concurrency. It sees each stack update as an independent request against a shared account-wide quota.

The mental model for CloudFormation concurrency revolves around two key concepts:

1. Stack Operations: Any action you take on a CloudFormation stack (create, update, delete) counts as an operation.
2. Account-Wide Quota: The limit is applied at the AWS Region level, but it’s shared across all stacks within that account in that region.

When you issue a aws cloudformation update-stack command, CloudFormation begins a state transition. If you issue another update-stack command for a different stack while the first is still in progress, and the total number of in-progress operations reaches 10, your new request will be rejected with a ThrottlingException or a similar error indicating you’ve hit the limit.

To manage this, you can request an increase to the CloudFormation concurrent stack update limit. This is done through the AWS Support Center.

1. Navigate to AWS Support Center: Log in to the AWS Management Console and go to the "Support" dashboard.
2. Create a Case: Click on "Create case."
3. Select "Service Limit Increase": Choose "Service Limit Increase" as the case type.
4. Specify Details:
   • Region: Select the AWS Region where you need the increase (e.g., us-east-1).
   • Limit Type: Choose "CloudFormation" and then "Concurrent stack operations."
   • New Limit Value: Specify your desired limit. For a busy team, 50 or 100 is common. Start with what you think you’ll need and can justify.
   • Use Case Description: Clearly explain why you need the increase. Mention your deployment frequency, the number of teams or applications managed by CloudFormation, and how the current limit is impacting your velocity. Provide specific examples if possible.

The AWS Support team will review your request. Approvals are typically granted if the use case is valid and doesn’t indicate a potential for widespread misconfiguration. Once approved, the limit is updated for your account in that region.

The actual mechanism behind the limit is that the CloudFormation service endpoint has an internal throttling mechanism. When you make an API call to create or update a stack, the service checks your account’s current active operations against the quota. If the quota is exceeded, the request is immediately rejected. Requesting an increase essentially raises the upper bound of this check for your account.

The most surprising thing about the concurrent stack update limit is that it’s not just about updates; any stack operation (create, update, delete) consumes concurrency. So, if you have 5 stack creations, 3 stack updates, and 2 stack deletions running, you’ve already hit the default limit of 10.

When you successfully get your limit increased, the next obstacle you’ll likely encounter is managing drift detection across a larger number of stacks, or dealing with the increased complexity of visualizing and auditing concurrent operations.