A customer vended a new account through Landing Zone last week and noticed the VPC StackSet failed silently. The account had all the baseline guardrails but no VPC—meaning application teams couldn’t deploy anything. After checking CIDR conflicts and service quotas, we discovered the issue was an incorrect CIDR range in the manifest that overlapped with an existing VPC in their Transit Gateway network. In this post, I’ll walk through exactly what causes VPC deployment failures and how to fix them.

The Problem

You vend a new AWS account through Landing Zone Account Vending Machine. The account is created and moved to the correct OU. However, the VPC StackSet fails to deploy, leaving the account without network infrastructure. You see one of these errors:

  • The CIDR range 10.0.0.0/16 is already in use
  • VPCLimitExceeded: You have reached the limit of 5 VPCs per region
  • EIPAddressLimitExceeded: Address limit exceeded
  • Invalid manifest parameter: Subnet count exceeds AZ count
Error Type Root Cause
CIDR already in use Overlaps with existing VPC or peered network
VPC limit exceeded Account has max VPCs in region
EIP limit exceeded Account has max Elastic IPs allocated
Invalid subnet config More subnets than availability zones

Why Does This Happen?

Landing Zone uses a StackSet to deploy VPCs to new accounts. The StackSet pulls configuration from your manifest.yaml file. Several things can break this process:

  • CIDR range conflicts: If your manifest specifies a CIDR range that already exists in the target account or in a peered network (via VPC peering or Transit Gateway), CloudFormation fails. This is especially common in organizations using Transit Gateway for network segmentation.
  • VPC limit exceeded: AWS limits accounts to 5 VPCs per region by default. If the new account already has VPCs (from a previous provisioning attempt or manual setup), you hit this limit.
  • NAT Gateway or EIP limit exceeded: If the new account is being deployed with NAT Gateways, AWS limits to 5 Elastic IPs per region by default.
  • Invalid subnet count: If your manifest specifies more subnets than the number of availability zones in the region (usually 3), the StackSet fails.
  • Incorrect manifest.yaml syntax: Typos in CIDR notation (e.g., 10.0.0.0/33 is invalid) or missing required fields cause CloudFormation to reject the template.

The Fix

Step 1: Check the StackSet Operation

List all StackSet operations to find failures:

aws cloudformation list-stack-set-operations \
  --stack-set-name AWS-Landing-Zone-VPC \
  --region us-east-1 \
  --query 'Summaries[?Status==`FAILED`]'

Get details on a specific operation:

aws cloudformation describe-stack-set-operation \
  --stack-set-name AWS-Landing-Zone-VPC \
  --operation-id abc12345-1234-1234-1234-123456789012 \
  --region us-east-1

This will show if the operation failed and why.

Step 2: Check Stack Instances in the Target Account

List stack instances for the new account:

aws cloudformation describe-stack-instances \
  --stack-set-name AWS-Landing-Zone-VPC \
  --stack-instance-account 123456789012 \
  --stack-instance-region us-east-1 \
  --region us-east-1

If status is “OUTDATED” or “FAILED”, the stack wasn’t successfully deployed. If status is “CURRENT”, the stack exists and should have a VPC.

Step 3: Check for CIDR Conflicts

In the target account, list existing VPCs:

# Assume role into target account first
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/OrganizationAccountAccessRole \
  --role-session-name vpc-check

# Then list VPCs
aws ec2 describe-vpcs \
  --region us-east-1 \
  --query 'Vpcs[].{CidrBlock: CidrBlock, VpcId: VpcId}'

If you see a VPC with the same CIDR as your manifest, that’s your problem. Edit manifest.yaml and choose a non-overlapping CIDR. For example:

# Old (conflicts with 10.0.0.0/16)
cidr: 10.0.0.0/16

# New (no conflict)
cidr: 10.1.0.0/16

Also check for VPCs in peered networks or in your Transit Gateway:

aws ec2 describe-transit-gateway-attachments \
  --region us-east-1 \
  --query 'TransitGatewayAttachments[*].ResourceId'

For each VPC attachment, check its CIDR range and ensure it doesn’t overlap with your manifest CIDR.

Step 4: Check Service Quotas

Check your VPC quota:

aws service-quotas get-service-quota \
  --service-code vpc \
  --quota-code L-F678F1CE \
  --region us-east-1

If the quota usage is at or near the limit, request an increase:

aws service-quotas request-service-quota-increase \
  --service-code vpc \
  --quota-code L-F678F1CE \
  --desired-value 20 \
  --region us-east-1

Also check EIP quota:

aws service-quotas get-service-quota \
  --service-code ec2 \
  --quota-code L-0287A674 \
  --region us-east-1

If you need EIPs, request an increase.

Step 5: Validate manifest.yaml

Check your manifest for syntax errors and invalid CIDR notation:

# CIDR must be valid notation (X.X.X.X/Y where Y is 0-32)
# Each subnet CIDR must fall within the VPC CIDR

# Example valid manifest section:
subnets:
  - name: private-a
    cidr: 10.0.1.0/24  # Falls within 10.0.0.0/16
  - name: private-b
    cidr: 10.0.2.0/24  # Falls within 10.0.0.0/16
  - name: public-a
    cidr: 10.0.128.0/25  # Falls within 10.0.0.0/16

Count the subnets and make sure it doesn’t exceed your region’s AZ count. For us-east-1 (3 AZs), don’t define more than 3-4 subnets per AZ.

Step 6: Delete the Failed Stack and Retry

If the stack instance is in “OUTDATED” or “FAILED” state, delete it and re-create it:

# Delete the stack instance
aws cloudformation delete-stack-instances \
  --stack-set-name AWS-Landing-Zone-VPC \
  --accounts 123456789012 \
  --regions us-east-1 \
  --operation-preferences FailureToleranceCount=0,MaxConcurrentCount=1 \
  --region us-east-1

# Wait for deletion to complete
sleep 60

# Re-create the stack instance
aws cloudformation create-stack-instances \
  --stack-set-name AWS-Landing-Zone-VPC \
  --accounts 123456789012 \
  --regions us-east-1 \
  --operation-preferences FailureToleranceCount=0,MaxConcurrentCount=1 \
  --region us-east-1

Monitor the operation:

aws cloudformation describe-stack-instances \
  --stack-set-name AWS-Landing-Zone-VPC \
  --stack-instance-account 123456789012 \
  --stack-instance-region us-east-1 \
  --region us-east-1 \
  --query 'Summaries[0].Status'

Wait for status to change to “CURRENT”.

Is This Safe?

Yes, deleting a StackSet instance and recreating it is safe. If the new account doesn’t have data yet, there’s zero risk. Just ensure you’ve fixed the underlying issue before recreating.

Key Takeaway

VPC deployment failures in Landing Zone usually come down to CIDR conflicts, service quota limits, or invalid manifest configuration. Always check for overlapping CIDR ranges, verify service quotas, and validate your manifest syntax before provisioning new accounts.

Have questions or ran into a different Landing Zone issue? Connect with me on LinkedIn or X.