Curious what the community thinks about using Terraform to manage cloudformation stacks? I deployed the AWS innovation sandbox this week but their deployment options were limited, so went with Terraform orchestrating the CF

We use it to manage cloudformation stacksets in the organizations aws account

Terraform is a great way to manage CloudFormation stacks — and multi-account, multi-region StackSets, as @RB mentioned. Even when the goal is as simple as packaging a template and a known set of parameter values, I'd probably vote for Terraform over a nested CloudFormation stack. Gotchas for managing CloudFormation from Terraform: • List data types: The Terraform AWS provider does not convert an HCL list or set to a CloudFormation list type such as

List<String>

. Use

join(",", <http://local.my|local.my>_list)

to pass a single string of comma-delimited values. Implicit type conversion, a recommended practice in HCL, is a really bad idea. • Other data types: Unexpected semantics are possible with other data types, including confusion between not setting a member of

aws_cloudformation_stack.parameters

, setting it to HCL

null

, or setting it to

""

(the empty string). • Template source changes: Modules I've seen that stash a long CloudFormation template in S3 don't enable versioning for the S3 bucket or don't append

?versionId=

to the value of

aws_cloudformation_stack.template_url

. Without these steps, Terraform won't notice updates to the CloudFormation template. Most of my AWS utilities can be installed as a CloudFormation stack, a CloudFormation StackSet, or a Terraform module that wraps one or the other, so I have a lot of experience in this area. Here is a model you can use (GPLv3) that correctly recognizes CloudFormation template changes: github.com/sqlxpert/lights-off-aws/blob/c86306c/terraform/main.tf#L213 People deploying the same Terraform module in multiple regions but within one AWS account might be fine with enhanced multi-region support, introduced mid-2025 in Terraform AWS provider v6. Deploying a module in multiple AWS accounts, even in just one region, still requires some sort of multi-account framework, so CloudFormation StackSets can be a simple alternative. Enhanced multi-region example: github.com/sqlxpert/lights-off-aws#installation-with-terraform Hope this helps! I'm glad to answer questions here or if we happen to attend CloudPosse office hours on Zoom in the same week.

This is all great stuff. Thank you for this. I didn’t know if it was considered bad practice to orchestrate the cloud formation with terraform, but I was able to get up and running with the innovation sandbox in about five minutes and thought it was too easy.

fwiw this is super dependent on how well maintained the cloudformation is. questions to ask: • what cadence do you follow at? • what blast radius will updates typically have? • could you accept/tolerate using yaml transforms in terraform? just pay attention to the history of the cfn and also double-check your lifecycle on it, and you ought to be gouda

Sweet, those are what have been running through my head so glad to see I'm on that track

I like using TF with CloudFormation but also take a look at rain. It's great if you want simple workflows that are CloudFormation only. https://github.com/aws-cloudformation/rain

Thanks for sharing that tool, @managedkaos ! Looks interesting.