My team has invested a sizable amount of code to manage CloudFormation. At this point, we have a rather mature interface for dealing with CloudFormation, includ

My team has invested a sizable amount of code to manage CloudFormation. At this point, we have a rather mature interface for dealing with CloudFormation, including: - defining dependencies between stacks - taking outputs from stacks and feeding them in as parameters to other stacks (not using that awful Import/Export Value crap they implemented) - deploying as many stacks in parallel as possible and waiting for them to complete before deploying dependent stacks - dealing with common failures and rollbacks, including handling known "continue update rollback" steps with predefined resources to skip - pre/post stack create/update/delete actions to make API calls and perform other actions outside of CloudFormation We basically built the missing pieces of CloudFormation ourselves and have managed to keep CloudFormation holding the definitive state rather than managing it ourselves (or paying Terraform to do it). We have about 500 stacks for a single deployment of our product. We also implemented a large number of Transform Macro lambdas to composable templates _much_ easier. There's a lot you can do with CloudFormation, but it takes some investment. A few things about it that really drive me nuts, though: - Lagging support for new features/resources - Parameter count and parameter size limits - Certain bugs with some resource types that are slow to get fixed. (Redshift cluster password management and issues with elasticsearch resizing triggering blue/green deployment come to mind. - No ability to modify timeouts for some actions. For example, the timeout for a CustomResource is fixed and cannot be tuned -- if your Lambda never responds, CloudFormation will hang up to 2 hours. We wrote our own Lambda wrapper just to guarantee a response if an unexpected failure occurs