Study notes for managing AWS resources through OpenTofu and Cloudformation.
Not long ago there was Terraform.
And then Terraform switched to a BUSL license and scared everyone in the ecosystem away.
So, the ecosystem forked Terraform and created OpenTofu.
At one point, Terraform/OpenTofu was the de-facto standard for AWS IaC. AWS had a similar service named AWS Cloudformation, but it lacked the features to compete with Terraform. At the time, Terraform supported more resources and services that Cloudformation. Additionally, Terraform could import existing resources into the configuration state, but Cloudformation could not. Cloudformation also lacked the ability to detect configuration drift, but Terraform could detect and correct (some) configuration drift.
However, this has begun to change in recent years. It seems that Amazon has begun investing more into Cloudformation beginning in 2018 by adding the ability to import existing resources into a stack. In 2019 Cloudformation could now detect configuration drift. Finally in 2021, Amazon created the AWS Cloud Control API in an effort to unify the API under a common service. The Cloud Control API expands Cloudformation’s coverage of services and resources, and helps ensure that new service offerings are available in Cloudformation.
At one point (pre-2020’s), Terraform was the go-to for IaC, but today I view Terraform and Cloudformation equally. If my development team knows OpenTofu, then we’ll use OpenTofu. If they know Cloudformation, then we’ll use Cloudformation. I don’t see any deal breakers in either approach.
The OpenTofu Language
I recommend reading Open Tofu’s extensive documentation to learn the language.
There are 3 elements to the OpenTofu language:
- Blocks:
block-type "name" { ... }
- Arguments:
a = "hello world"
- Expressions:
1+2
Expressions go on the right-hand side of Arguments.
Arguments go inside of Blocks.
Blocks can also be nested inside of each other.
Here are the types of top-level blocks available:
terraform
- Special block that configures OpenTofu settingsprovider
- Configures an OpenTofu provider (such as AWS)resource
- Block that represents a managed resourcedata
- Block that represents a request to get data from a data source and export the results into a variablemodule
- Creates an instance of a module based off of code from another locationvariable
- Declares a variable
The Backend Problem of OpenTofu
While using Terraform OpenTofu, the state of the resources in the cloud must be tracked. By default, OpenTofu tracks this state with the local backend, which means it writes the state to a text file in your working directory. This is a huge problem because this state file is not encrypted, and can contain sensitive information (i.e. credentials)!
To solve this, select a different backend, such as the S3 backend which stores your state in an S3 bucket.
Additionally, you can enable encryption of the state file and use AWS KMS to encrypt/decrypt the state and manage its keys.
On the other hand, Cloudformation already manages configuration state on AWS for you. There is no need to set up additional backend configurations like OpenTofu has.
Recommended Reading
Bookmarks to Keep
Here are some links that I recommend adding to your bookmarks list for quickly looking up information: