Skip to main content
HashnodeDiving DevOps

Command Palette

Search for a command to run...

Migrate from CloudFormation to Terraform

Updated
•3 min read
J
Jan Tymiński

I started my professional career in 2012 as Systems Administrator and continued it until 2018 to become DevOps Engineer. I work with AWS since 2016 and I am 5 times certified AWS Specialist.

The Tale of the CloudFormation

A long time ago, in a land far, far away, there was a DevOps dojo.
The dojo trained young padawans in DevOps craftsmanship.
Many of them were ambitious and wanted to use their skills in practice as soon as possible.
They were given quests.

Quests varied in their toughness, but many of them had a common ground - the fate of the young padawans.
They were sent to accomplish missions and fight evil creatures in the lands of the AWS CloudFormation.

AWS CloudFormation is one of the toughest lands in the Clouds universe.
Many adventurers have failed to accomplish quests in these lands.
Many have lost their lives fighting the creatures called Stacks.
Many have lost their minds to the riddles of Change Sets.
New DevOpses were coming, they were moving further, but with all the burden they couldn't conquer the lands of the Cloudformation.

One day the dojo sent two of their most experienced DevOpses.
They have seen the scenes nobody wants to see.
They have seen the defeat of their mentees.
They have seen a disaster.

With a plan, they started picking up battles, tackling them with a balance between efforts and benefits.
It took months, but the strategy paid off.
The Team of Two DevOpses visited hundreds of villages of the CloudFormation lands.
Although they didn't conquer the kingdom, they have secured peace in the Clouds universe.

One day a team of three DevOps Ninjas arrived at the CloudFormation lands.
They came from the kingdom of the Terraform.
They were not pleased with what they found.

The DevOps Ninjas have tightly cooperated with the Dojo Masters.
They needed to understand all the situation and politics of the CloudFormation lands.
Months passed by...
The Dojo Masters left the CloudFormation lands, leaving them in the hands of the brave DevOps Ninjas to continue on the journey.
And months passed by...

The DevOps Ninjas were already sure that only with the powers of the Terraform Kingdom they can bring everlasting peace to these lands.
The authority of the CloudFormation Kingdom must come to an end.

And so the biggest war in the universe began!

Migrating the infrastructure

I hope you enjoyed this little introduction, now let's get to the technical part.

The process is pretty simple, I have made a simple PoC with a CloudFormation template provided by AWS.
I have chosen WordPress scalable and durable template to ensure the behaviour around the RDS database that was crucial for me.
I recommend you to try it on your own to ensure what will happen, test for a scenario you have - you might want to seek for another template to better simulate your case.

The process is pretty simple and consists of two separate processes described by AWS and I will list it with links to AWS articles so you can easily ensure the steps:

  1. Set up DeletionPolicy: Retain to all resources you want to retain when CloudFormation Stack is removed (link)

  2. Upload new CloudFormation Stack definition

  3. Import these resources to your Terraform code

  4. Delete the CloudFormation Stack (link)

And that's it!

Deleting CloudFormation Stack might fail if there are resources in it that miss the DeletionPolicy: Retain and they are connected with resources retained, e.g. there's a subnet without this attribute that is related to an RDS which is retained - AWS will try to remove this subnet and fail as it cannot be removed as long as RDS uses it - this situation is good for us, we will not accidentally remove resources that we need for other resources to work.
The CloudFormation Stack can then be forcibly removed, ignoring the fact it cannot delete some resources.

I hope you find this post useful and that you enjoyed the little story in the beginning - the fairy tale is based on a real life situation.

#terraform#aws#cloudformation#devops#infrastructure

Comments (1)

Join the discussion
A
Adam Brodziak2y ago

I wonder why go with Terraform? You loose some traits CloudFormation gives you, e.g. rollbacks on failed deploy, no need to keep external state. Since CF was used I guess it was AWS-only, so Terraform's questionable universality does not matter. Then why?

J
Jan Tymiński2y ago

Thank you for the question!

The Tale of the CloudFormation is there to explain it a little - the CF code was built through years by many people that were more or less experienced with the CloudFormation and eventually it became really hard to maintain - unmaintained, not up to date, tons of drifts, etc... Then there was an internal team built for taking care of all the infrastructure, with expertise in Terraform and inability to dive into existing CloudFormation stacks in any reasonable time. Terraform has just some little inconveniences that the team is aware of and we decided it's easier for us to get rid of CloudFormation as it was easier to achieve than fixing all the stacks - especially when not being experts in them. To make things more complicated, there were parts of the infrastructure in Terraform too - but in a similar state as CF stacks and we decided to not reanimate them but build new code from scratch on what we actually see in the infrastructure.

1
A
Adam Brodziak2y ago

Thanks Jan Tymiński for explaining. I was wondering why not use CDK and import existing CF stacks.

1
J
Jan Tymiński2y ago

I hope it's more clear now and I'm glad you asked!

More from this blog

Diving DevOps

11 posts

DevOps specialist in AWS, Terraform, Docker. Holder of five AWS certs, on the journey to becoming a Kubernetes pro. Navigating the ever-evolving tech landscape with precision.