Pitfall 1: Challenges with Stateful Resource Management

Updating stateful resources like DynamoDB, S3, RDS, and Route 53 through AWS CloudFormation can lead to unintended modifications that necessitate resource replacement. This may result in resource deletion and the creation of new instances, which can be problematic in production environments.

To prevent accidental deletions, the retain deletion policy can be employed. However, this necessitates managing the resource outside of CloudFormation or importing it back into the stack. Additionally, complex infrastructure management can lead to edge cases that break the stack. When such issues arise, AWS typically recommends deleting and recreating the stack, a process that can be intricate and risky in production scenarios. For stateful resources like DynamoDB, RDS, Route 53, EBS Volumes, and S3 Buckets, I advise using APIs directly rather than relying on CloudFormation.

Pitfall 2: Region-Specific Stacks

AWS CloudFormation templates are confined to specific regions. This can create confusion when managing global resources, making it unclear where to locate the stack.

Moreover, cross-region connectivity can complicate matters when utilizing CloudFormation. The sequencing of changes is restricted to a single stack. When resources across various regions (such as security groups and peering connections) need to connect, additional effort is necessary beyond what CloudFormation offers. While code can be developed to manage these stacks, my experience suggests that direct API management is typically simpler.

Pitfall 3: Complications with Nested Stacks

Nested stacks in AWS CloudFormation allow for template reuse within a stack, but they often introduce more challenges than solutions. The deployment speed of AWS CloudFormation is already slow, and nesting exacerbates this issue due to the added overhead.

Failure recovery also becomes problematic as stacks grow larger and more complex. When AWS CloudFormation encounters a failure, it usually results in a complete teardown and rebuild, which can lead to manual intervention and potential outages.

Pitfall 4: Limitations of Exported Output Values

CloudFormation stacks can output resource values for consumption by other stacks, which seems beneficial. However, relying on these values can restrict modifications or deletions of the originating stack, increasing complexity in managing stack dependencies.

Pitfall 5: Sluggish Deployment Times

AWS CloudFormation is notorious for slow deployments, particularly when multiple stacks need to be deployed in sequence or when IAM resources are involved.

Pitfall 6: Code Dependency for Stack Management

Most environments necessitate multiple CloudFormation stacks to manage risks, reuse templates, or address stack limits. This often requires coding to automate the deployment of these stacks. Although CloudFormation is designed to be straightforward, the need for coding can diminish this advantage.

Pitfall 7: Risks in Secret Management

AWS CloudFormation cannot manage certain resources like EC2 SSH keys due to the risk of exposing sensitive values in the resource state. Including secrets within a stack—such as AWS Lambda environment variables or EC2 instance userdata—poses additional risks since the CloudFormation API retains all parameters and templates, accessible through the AWS console and API.