"Exceeded attempts to wait" when updating VPC via CloudFormation

The "Exceeded attempts to wait" error you're experiencing with your CloudFormation stack is related to a timeout issue where CloudFormation is waiting for the VPC Gateway Attachment resource to reach a stable state, but it's not happening within the expected timeframe.

This issue can occur for several reasons:

1. Resource stabilization delay: When you're making significant changes to your VPC infrastructure (like changing the CIDR block from 10.0.0.0 to 10.4.0.0), the underlying AWS services may take longer than expected to complete the operation.

2. Dependencies: The VPC Gateway Attachment might be dependent on other resources that are still being processed or are in an unstable state.

3. Resource quotas: You might be hitting service quotas during the update process, especially if you're creating new subnets while keeping old ones temporarily.

To resolve this issue, you could try:

1. Adding a DependsOn attribute to ensure proper resource creation order.

2. Increasing the timeout period for your CloudFormation stack operation.

3. Breaking down your update into smaller, incremental changes rather than changing the entire CIDR block at once.

4. If you're using VPC endpoints, ensure that resources in the VPC have proper access to CloudFormation and the required S3 buckets.

5. Check if you have any resources that might be causing conflicts during the update process.

In some cases, it might be easier to create a new VPC with the desired configuration and migrate resources gradually rather than attempting to modify the existing VPC's fundamental attributes like its CIDR block.
Sources
CloudFormation stack is stuck on CREATE_IN_PROGRESS due to an EC2 instance | AWS re:Post
Troubleshooting CloudFormation - AWS CloudFormation
AWS::CloudFormation::WaitCondition - AWS CloudFormation

Hi There

You can't change or modify the IP address range of an existing virtual private cloud (VPC) or subnet.

There are several alternative options, see this article: https://repost.aws/knowledge-center/vpc-ip-address-range

The solution I found was to completely replace the VPC in the CDK resource (by changing its logical name and CIDR blocks). That resulted in the new VPC being created, all the resources flipped over to it, and the old one torn down successfully. When I relied on Cloudformation to 'modify' the VPC, it didn't work reliably.