How to Use AWS for Infrastructure as Code (IaC)

In 2004, Amazon Web Services (AWS) launched its first publicly available cloud service, the Simple Queue Service (SQS). Today, AWS has the largest market share for public cloud services, ahead of Microsoft Azure and Google Cloud Platform (GCP). Given its position as the oldest and current leading public cloud provider, what does the infrastructure-as-code (IaC) landscape look like in the context of AWS?

CloudFormation is AWS’s native service for IaC. It was released in 2011, and much has happened since then, both with CloudFormation and the surrounding IaC landscape.

In this blog post, we will discuss five popular options for infrastructure as code on AWS:

• AWS CloudFormation
• AWS Cloud Development Kit (CDK)
• HashiCorp Terraform
• OpenTofu
• Pulumi

If you want to follow along the examples on your own system you must have AWS credentials available in your terminal. The simplest way is to download and configure the AWS CLI. The details are outside the scope of this blog post, but you can read up on how to do this in the AWS documentation. 

All the tools we will discuss can automatically pick up the AWS credentials from the AWS CLI configuration file.

All the sample commands in this post have been tested on a MacBook in a Z Shell (ssh) environment.

IaC can be classified into two broad categories:

• In declarative IaC, you define the desired state of your infrastructure, and it is up to the tools you use to create it to match that state. You define the destination, and the tool takes care of the journey. 

Examples include Terraform, OpenTofu, and AWS CloudFormation. The distinctive feature of declarative IaC is that the order of code statements does not matter. What is important is how the infrastructure is configured and how resources are related to each other.

• In imperative IaC, you define the steps to take your infrastructure to the desired state. 

Examples include AWS CDK and Pulumi, as well as custom Bash or Powershell scripts. The distinctive feature of imperative IaC is that the order of code statements does matter. Switching the place of two commands or code statements results in a different result or even an error.

The tools we will explore in this blog post can broadly be classified into one of these two categories of IaC. However, both AWS CDK and Pulumi have elements of both declarative and imperative IaC. 

The same is true for Terraform and OpenTofu, which both can include elements of imperative IaC as well as declarative IaC. CDK is special in the sense that it is imperative in nature, but it produces CloudFormation templates that are inherently declarative in nature.

Treating your infrastructure as code means storing the code in a source code repository, making changes to the code through peer review processes, and building CI/CD pipelines to move a change from commit to production.

To compare the different tools, we must have a sample cloud architecture to work with. A good example contains a few different types of resources with dependencies between them.

With that in mind, the architecture we will be working with consists of a virtual private cloud (VPC) with a single subnet, a security group, an internet gateway, a route table, and an EC2 instance with an SSH public and private key pair.

The goal is to set up an EC2 instance that we can reach via SSH from our local system. It is not a production-ready system, but it is an example with just enough complexity to get a feel for the different options for infrastructure as code.

An overview of the architecture is given in the following figure:

If you are not familiar with the AWS ecosystem of cloud resources that are part of this architecture, a short description of the important pieces follows below:

1. A Virtual Private Cloud (VPC) is a virtual network. Think of this as the digital equivalent of your private home or office network.
2. A VPC can be split into multiple smaller networks called sub networks or subnets. Splitting a VPC into smaller parts is a best practice from a security and management standpoint.
3. An internet gateway allows network resources in a VPC to talk to the internet.
4. How traffic is routed inside of your subnets is configured in a route table. This is a table of IP address ranges and their destination. In our case we will route all traffic to go through the internet gateway.
5. A security group is a firewall you can attach to network resources to configure what traffic is allowed in or out.
6. You specify what is allowed or denied through security group rules. In our case we will have one rule to allow incoming traffic on port 22 (SSH) from the public internet.
7. An Elastic Compute Cloud (EC2) instance is a virtual machine. In this architecture we will create an EC2 instance running Amazon Linux 2023.
8. To access the EC2 instance via SSH, we will also need to set up an SSH public and private key pair and add the public key to the EC2 instance.

Resources in AWS are created in a geographical region. Each region is split into multiple availability zones. AWS has many regions around the globe. In this blog post, we will be using the region in Ireland, known as eu-west-1, in AWS terminology.

That was a high-level overview of what we will be creating. This architecture will allow us to get an understanding of the process of using each of the five tools for infrastructure as code on AWS.

AWS CloudFormation was launched in 2011 and was a game-changer for creating cloud infrastructure on AWS. Instead of clicking in the AWS console to create resources manually or writing complicated shell scripts, you could suddenly declaratively describe the infrastructure you wanted in a configuration language and have CloudFormation bring it to life.

CloudFormation uses a declarative approach to infrastructure as code, with templates written in either JSON or YAML. 

A deployed instance of a CloudFormation template is known as a CloudFormation stack. The stack is an important concept because it represents the current state of the world as far as CloudFormation is concerned. 

The CloudFormation template you use to create a stack is your desired state. To make changes to your infrastructure, you update your template and apply the new template to the stack. This, in turn, makes CloudFormation update the current state of the world to match your desired state.

CloudFormation is executed on the server side. There is no option to execute It locally, which is a major difference from how Terraform works.

Step 1. Install and configure the AWS CLI

To get started with CloudFormation, you must install and configure the AWS CLI on your local system. The details of this are beyond the scope of this blog post, but you can find instructions for how to do this in the AWS documentation.

Once you have the AWS CLI installed, verify that it is working:

We need to decide whether to write the CloudFormation templates using JSON or YAML. In almost all situations, it is easier to work with YAML files, so we will use them. However, in some automation scenarios, where you are programmatically working with your CloudFormation templates, it can make sense to use JSON.

Create a new working directory and cd into it:

Create a new file named awstemplate.yaml in your favorite text editor to get started. Add the following boilerplate YAML code to indicate that we are creating a CloudFormation template:

This is currently not a valid CloudFormation template. We have added some metadata along with headers for parameters, mappings, resources, and outputs. We will fill in the details in the following subsections.

Step 2. Create the network architecture

We begin by creating the network architecture, which consists of a VPC, a subnet, an internet gateway, a security group, and a route table. 

In the Parameters section, add a parameter named VpcCidrBlock for the VPC CIDR block (the range of IP addresses that this network contains):

Next, under the Resources keyword in the root of the document, add the VPC and subnet resources:

Each resource has a logical name in the template. In this case, the resources are named simply VPC and Subnet. A resource has a Type and a number of Properties, which vary depending on the type of resource you are creating.

If this is the first CloudFormation template you see, you will have many questions. One thing that quickly gets confusing in CloudFormation is the use of intrinsic functions (e.g.,!Select, !Ref, Fn::GetAZs, etc.).

So far, we have an empty virtual network so we should keep adding the various network components that are required for us to be able to reach the EC2 virtual machine via SSH. The internet gateway requires two resources. 

Add the following resources below the other resources in the template:

The internet gateway itself does not require any configuration. However, we must add a specific resource that represents the attachment of the internet gateway to the VPC. Without this connection we would have an orphaned internet gateway that we can’t use for anything.

We control the routing in our VPC through a route table. A route table can have one or many routes. As with the internet gateway, we must use additional resources to specify in what subnet the route table should be in effect. Add the following resources below the other resources in the template:

The important part is that we have created a route that sends all traffic (DestinationCidrBlock: 0.0.0.0/0) to the internet gateway.

The final network resource we must add is the security group. The security group specifies what traffic is allowed in (ingress traffic) and what traffic is allowed out (egress traffic) from an EC2 instance or other network connected resource. 

Add the security group resource under the rest of the resources in the template:

The security group is configured with one ingress rule allowing traffic on port 22 (SSH) from anywhere in the world (0.0.0.0/0).

Note that, in general, you should avoid opening port 22 to the world, but since this is a demo, we will allow it. If you want to, you can change the value of the CidrIp property to <your public IP>/32 to pin it to your exact IP address and nothing else.

Step 3. Create the EC2 instance

To create the EC2 instance, we must have an Amazon Machine Image (AMI) to base it on.

Apart from this, we will need an SSH key. There is no way to create a new SSH keypair with CloudFormation and obtain the private key so that you can connect to the EC2 instance from your local system. This means we must first create a local SSH keypair and provide CloudFormation with the public key during deployment.

Create a new keypair in your working directory:

The details of the ssh-keygen command is outside the scope of this blog post. It is sufficient to know this command creates a public and private keypair (named ec2-key.pub and ec2-key, respectively) we can use to connect to the virtual machine via SSH.

Next, add a new parameter in the Parameters section of your CloudFormation template:

As mentioned, an EC2 instance is created from an AMI. Unfortunately, we must know the ID of the AMI we intend to use. The ID is different depending on what AWS region you are creating the EC2 instance in. You can add support for multiple regions to your CloudFormation template by adding a mapping from the AWS region to the AMI ID. 

In the Mappings section of the template, add the following content:

This maps from a given AWS region to a supported AMI ID for that specific region. These particular AMI IDs correspond to an Amazon Linux 2023 machine image. You should add each region that you want your template to support. The AMI IDs can be obtained from the AWS console or by using the AWS CLI.

With all the prerequisites for the EC2 instance out of the way, we can add resources for the keypair and the EC2 instance to the Resources section of our template:

The KeyPair resources reference the input parameter PublicKeyMaterial. A value for this parameter will be provided at deployment time.

The Instance resource uses the correct AMI ID in the ImageId property by retrieving the value from the Region map using the !FindInMap function.

Finally, to simplify connecting to the EC2 instance we add an output to the Outputs section of our CloudFormation template. The value for the output is the SSH connection command needed to connect to the instance:

The default user for an Amazon Linux 2023 instance is ec2-user.

Step 4. Deploy the demo infrastructure

As mentioned, a deployed instance of a CloudFormation template is called a CloudFormation stack. There are two different AWS CLI commands you can run to create a stack. 

The most convenient command is:

The aws cloudformation deploy command creates a stack if it does not exist and updates a stack if it does exist. This command is idempotent, which is why it is the preferred command. 

The alternative command is:

The downside of the aws cloudformation create-stack command is that it is not idempotent, so rerunning the same command will result in a failure. You can update a stack using the aws cloudformation update-stack command or just use the aws cloudformation deploy command described above.

Run an additional command to obtain the value of the output that we added to the template:

Run the SSH command to verify that the connection works:

Once you are done, exit from the EC2 instance (using the exit command) and delete the CloudFormation stack to avoid unnecessary costs:

The command returns immediately, and the stack deletion happens asynchronously on AWS.

The AWS Cloud Development Kit, or AWS CDK for short, was introduced in 2018. CDK was another game-changer in the landscape of infrastructure as code. CDK is imperative in nature, and you write CDK code using a high-level programming language (e.g., Python, TypeScript, C#, and more).

The source code you write is eventually converted (or synthesized) into CloudFormation templates for you, and a CDK application could consist of one or many CloudFormation stacks. However, CDK is an abstraction on top of CloudFormation, and in a sense, it is not necessary to even be aware that CloudFormation is part of the process under the hood.

CDK has a concept of constructs. A construct can represent a single AWS resource or a larger piece of infrastructure consisting of multiple underlying resources. This is similar in spirit to a module in Terraform.

It allows users to create powerful abstractions. Imagine packaging the architecture we set up with CloudFormation above into a construct named LinuxEnvironment. There is no need for users of this LinuxEnvironment to know all the pieces of underlying cloud infrastructure needed to connect to a Linux machine.

Step 1. Set up AWS CDK

To get started with the AWS CDK, you must install it locally along with Node.js and additional prerequisites depending on the language you will use for the CDK. Again, the details of how to do this are beyond the scope of this blog post, but there are guides available in the AWS documentation.

In the following examples, I will use TypeScript, but support is also available for JavaScript, Python, Java, C#, and Go.

When you have installed the CDK, make sure that it is working:

Create a new working directory named cdk-demo and initialize a new CDK project inside of it (the output from these commands is truncated for brevity):

You will also have to run a bootstrap command before you can create your first stacks with CDK in a given region. This command creates some required resources for CDK to function in your AWS environment. 

This process takes a few minutes to complete:

The cdk init command creates a new project from a template, and you are given a skeleton application to work with. The full details of how to write your CDK app are beyond the scope of this blog post, but we will see enough about how writing a CDK app works. 

A huge benefit of using TypeScript or another typed language is the great support you can get in your IDE or text editor.

There are two important files that have been created for you: bin/cdk-demo.ts is the entrypoint of your infrastructure:

In this file, an instance of the CdkDemoStack class is instantiated. If your infrastructure consists of multiple stacks this file is where you should instantiate each of the stacks. The CdkDemoStack is defined in the lib/cdk-demo-stack.ts file:

All the work we will do in the following subsections will be in the lib/cdk-demo-stack.ts file.

Step 2. Create the network architecture

All the infrastructure we will create lives in the EC2 service space. To work with these resources, we must import the EC2 library. Add the following import statement to the top of the file:

To create a fully functioning VPC with multiple subnets, an internet gateway, route tables, and much more, we could create an instance of the ec2.Vpc class in our CdkDemoStack class:

This shows the power of abstractions in the CDK. This one line creates hundreds of lines of CloudFormation with a fully configured VPC. Unfortunately, this is more than what we ask for. So to mimic the examples we saw with CloudFormation, we must configure our VPC a bit:

We tell CDK to use a single availability zone, and we specify a single subnet of the public type. Creating a public subnet automatically adds an internet gateway and associates it with the VPC.

There is one more network resource we must create ourselves, this is the security group. We create an instance of the ec2.SecurityGroup class and configure it to allow SSH traffic from anywhere:

To associate the security group to the VPC we simply pass in the vpc instance into the security group configuration. We also see that we do not need to know that “anywhere” corresponds to the CIDR block >0.0.0.0/0, instead we use the ec2.Peer.anyIpv4() method. Likewise, we do not need to know that SSH corresponds to port 22, we just use the ec2.Port.SSH property.

Step 3. Create the EC2 instance

To create and then connect to the EC2 instance we need a public and private keypair and add the public key to the instance. We could use any available Node.js package to create the keypair, but to avoid introducing external dependencies, we will create the keypair using the ec2.KeyPair class:

How do we obtain the private key, you might ask? We will see how to do this in the next subsection.

What is left is to create the EC2 instance using the ec2.Instance class:

A few things to note:

• We pass in the vpc, securityGroup, and keyPair instances directly to the configuration.
• We can define the EC2 instance type using helper classes and methods.
• We obtain the AMI ID simply from the latestAmazonLinux2023 method on the ec2.MachineImage class.

As a last thing, we add an output for the SSH command:

That was it. We were able to define our infrastructure in fewer lines of code than when using CloudFormation, and our editor (VS Code, in our case) helped us a lot.

Step 4. Deploy the demo infrastructure

You can preview the CloudFormation template that the CDK code produces by running the synthesize or cdk synth command:

This command outputs the CloudFormation template to the terminal. You can pipe the output to a YAML file if you want to review it:

In general, running the synth command is not required, but you always have the option of using CDK to produce the CloudFormation template(s) and then using the regular AWS cloud formation commands to deploy the infrastructure if it makes sense in your environment.

To create the infrastructure using CDK, you issue the cdk deploy command (the output is truncated for brevity):

As you can see, the deployment took almost three minutes. Copy the SSH command from the output for later.

If there are any changes to IAM permissions or network traffic rules, the output will indicate these changes clearly and ask you to approve them before continuing. This is a safety mechanism since changes to IAM permissions and network rules can have a huge impact on your environment. In this case there are both changes to network traffic rules and IAM permissions. You might be surprised at the IAM permission changes, but this is simply because CDK adds additional resources for us (e.g. an EC2 instance profile).

To verify that we can access the EC2 instance via SSH, we must get the private key. It turns out that CDK stores the private key for us in an AWS Systems Manager (SSM) parameter. We can use the AWS CLI to obtain the value of the parameter:

Edit the file permissions for the ec2-key file, otherwise the SSH client will reject it due to too permissive permissions:

Connect to the instance using the SSH command you copied above:

Terraform appeared in 2014 as an alternative to AWS CloudFormation. It sprung from the desire to have a “CloudFormation for everything.”

Common for both AWS CloudFormation and AWS CDK is that the orchestration of creating all the resources happens on AWS, with the CloudFormation engine being in charge. This changed with Terraform, where the execution happens locally where you install the Terraform binary with the help of a vast system of providers for interacting with external systems accessible through APIs.

Terraform is similar in spirit to AWS CloudFormation in the sense that it is declarative infrastructure-as-code. Terraform uses a domain-specific language called HashiCorp Configuration Language (HCL). 

HCL has many features that make it easier to work with than the YAML or JSON files of AWS CloudFormation. Most prominent is the ease of splitting the infrastructure into multiple files and having Terraform automatically stitch them up into one file. It is also possible to write Terraform configurations using JSON, but this is an uncommon practice.

Step 1. Install Terraform

To get started with Terraform you need to install the Terraform binary locally. The details of how to do this is beyond the scope of this blog post but you can find instructions in the HashiCorp documentation or in our Terraform installation tutorial.

Once you have Terraform installed locally, verify that it works:

Your version of Terraform might differ, but everything that follows should work with your version unless it is very old (before the 1.0 release).

Create a new working directory and cd into it:

Create a new file named main.tf using your favorite text editor. As mentioned, you can split your Terraform configuration into multiple files, but we will not do that for this simple demo.

Add the following boilerplate code to main.tf to configure Terraform to use the AWS provider to allow you to create resources in AWS:

Step 2. Create the network architecture

Add resources for the AWS VPC and the subnet. Resources can be added anywhere in the root of the main.tf file. Also, add a new variable for the VPC CIDR block:

This looks familiar to what we saw for CloudFormation. However, the use of functions is significantly easier in HCL than the intrinsic functions that exist in CloudFormation.

Add the rest of the networking resources to main.tf:

With a few exceptions, there is almost a one-to-one mapping between what we saw with CloudFormation (e.g., we do not need to add a specific resource to associate the internet gateway with the VPC).

Step 3. Create the EC2 instance

Remember how we needed to know the AMI ID to be able to create an EC2 instance with CloudFormation? This is still true when we use Terraform. However, Terraform has the concept of data sources that allow us to ask for data from AWS.

We can use the aws_ami data source to do this:

This data source takes a number of arguments to filter out and find the AMI ID we want. In this case, we use three different filters along with the owners and most_recent arguments. The output of this data source will be a given AMI ID fulfilling these filters. The data source will work for whatever AWS region we are targeting without requiring any changes or hardcoded values.

Terraform has providers for a vast number of different systems. It can also work with your local filesystem. Of particular interest in our demo is the use of the TLS provider to create a public and private keypair that we can use to connect to our EC2 instance. 

Basically, we can ask Terraform to generate the key that we needed to generate ourselves when we worked with CloudFormation. We will also use the local provider to store the private key in a file.

To do this, add the following two providers to the list of required providers:

Next, create a public and private keypair, store the private key in a local file, and add the public key to AWS:

The last piece is the EC2 instance. Add the instance and reference the AMI ID from above and the public key we added to AWS:

Step 4. Deploy the demo infrastructure

The Terraform workflow consists of a number of Terraform CLI commands. To initialize the Terraform configuration, run the terraform init command (some of the output has been removed for brevity):

The terraform init command downloads the provider binaries and initializes the Terraform state backend. The state backend is where you store your Terraform state. In this case, we use the local backend, which means the state file is a regular JSON file next to your Terraform files.

Next, we can issue the terraform plan command to have Terraform tell us what would happen if we apply the current configuration:

This command produces a lot of output, but it can be very useful if you are not sure of exactly what changes will take place. In this case, the infrastructure is brand new, so the plan is to add 11 resources.

If we are satisfied with what the plan is telling us, we can go ahead and apply it:

Terraform will get to work creating the resources that make up our infrastructure. This process takes a few minutes. Once the apply operation is complete, we can ask Terraform to output the SSH connection command for us:

If we run the SSH command, we end up on our EC2 instance:

Once you are happy with the outcome, exit from the EC2 instance using the exit Linux command and then destroy your infrastructure using the terraform destroy command:

The destroy command takes a few minutes to complete.

OpenTofu appeared in 2023 as a fork of Terraform, responding to HashiCorp’s change of license from a fully open-source license to a business source license (BSL). It is backed by the Linux Foundation.

OpenTofu is fully compatible with Terraform configurations using version 1.5.x. This means that if you want to migrate from Terraform to OpenTofu, it would be a simple process, most likely requiring more work in your CI/CD system than your Terraform configuration.

Step 1. Set up OpenTofu

To get started with OpenTofu, you need to install it on your local system. The details of how to do this are outside the scope of this blog post, but you can find detailed instructions in the OpenTofu documentation.

Once the installation is complete, verify that OpenTofu works:

Create a new working directory for the OpenTofu demo and cd into it:

We could create a new empty file named main.tf and write our OpenTofu configuration in it. Since we are working with OpenTofu, which is compatible with Terraform configurations using version 1.5.x, we can simplify our lives by copying the Terraform configuration from the previous section. 

Reuse your main.tf file from the Terraform example without making any changes.

Step 2. Deploy the demo infrastructure

Deploying infrastructure using OpenTofu follows the same steps as Terraform, with the exception of using the tofu CLI instead of the terraform CLI. The first step is to run the tofu init command (the output is truncated):

Next, we create a plan to let OpenTofu tell us what would happen if we apply the infrastructure changes:

As expected, this is a new infrastructure, so OpenTofu will only create new resources without changing or destroying existing resources. If you are satisfied with the plan output you can go ahead and run the tofu apply command:

OpenTofu creates the resources for you, and the whole process takes about a minute to complete. Once it is done, ask OpenTofu to output the SSH command to connect to the EC2 instance:

Connect to the instance to verify that the infrastructure is working as intended:

Pulumi is the fifth and last tool we will cover in this blog post. 

Pulumi was created around 2017 and open-sourced in 2018. It looks similar to AWS CDK, but it has the advantage of using a similar provider architecture as Terraform. In a sense, Pulumi is like “AWS CDK for everything,” just like Terraform is “CloudFormation for everything.”

Step 1. Install Pulumi

To get started with Pulumi, you need to install it on your local system. The details of this are outside the scope of this blog post, but you can find detailed instructions in the Pulumi documentation. You will also need to sign up for a Pulumi cloud account and authenticate your Pulumi CLI.

Once Pulumi is installed, verify that it is working:

You can write your Pulumi code in one of TypeScript, JavaScript, Python, Go, C#, Java, or a specific YAML variant. Depending on the language you choose, you might need additional prerequisites installed. In the following example, I will be using TypeScript, so I have TypeScript and Node.js installed.

Create a new directory for your Pulumi code and cd into it:

Use the pulumi new command to create a new skeleton Pulumi project. You pass the name of a template to base your project from to the pulumi new command. There are hundreds of available templates to choose from. In this case, we use the aws-typescript template:

If you forget to add a required flag in the command there will be a prompt asking you to provide the required value.

The skeleton aws-typescript project contains everything you need to get started. The important files are:

• Pulumi.yaml contains configuration for your Pulumi project.
• Pulumi.demo.yaml contains configuration specific to your stack. A Pulumi stack is similar to a CloudFormations stack. One Pulumi project can contain multiple stacks.
• index.ts is the source code that defines the infrastructure of your stack.

Step 2. Create the network architecture

There is a specific AWS crosswalk (awsx) package containing convenience resource classes for common network architecture setups. We will use this package to create the VPC resource:

This is similar to how the AWS CDK class for a VPC worked. Since we specified that we want a public subnet in our VPC, we will automatically get an internet gateway and a route table with the default route.

To create the security group, we use the SecurityGroup class from the aws.ec2 package:

We now have all the networking resources that are required.

Step 3. Create the EC2 instance

As in all the other examples, we must configure an SSH public and private keypair as well as an AMI ID to base the EC2 instance on.

We could generate a public and private keypair using any available TypeScript package for this purpose, but to simplify, we will generate a keypair using ssh-keygen and import it into our Pulumi project:

To read the public key into our Pulumi code, we will use two Node.js packages:

This shows the power of using Pulumi (or AWS CDK), where you can use the full Node.js ecosystem apart from the Pulumi-specific packages (similar ecosystems are available for the other programming languages).

Finding the AMI ID is similar to how we did it with Terraform:

We specify filters to find the exact AMI ID we are interested in.

With all the pieces needed for our EC2 instance, we can create it using the Instance class from the aws.ec2 package:

Similar to how the AWS CDK works, we see that there are convenience classes for defining the EC2 instance type.

Step 4. Deploy the demo infrastructure

Run the pulumi up command to get a preview of what changes will be applied (the output is truncated for brevity):

The output is similar to what you get from a terraform plan command. If you do not want to get the prompt asking you to reply yes or no to accept or disregard the changes you can run pulumi up --yes to automatically accept the changes.

Answer yes to the prompt and wait for a few minutes while the infrastructure is created.

The output from the pulumi up command shows the SSH command needed to connect to the EC2 instance. You can also obtain the output with the following command:

Copy the command and run it in the Pulumi working directory:

When you are satisfied with the outcome, make sure to delete the infrastructure to avoid unnecessary costs:

The destruction takes a few minutes to complete. You should also remove the Pulumi stack:

First of all, there is a time and place for each of the tools we have seen. Personal preferences, current environment, worker experience and skills will all have an impact on the tool that is right for you and your organization.

The table below summarizes a few key technical differences between the five tools:

(1) Execution mode refers to where the execution steps of creating the infrastructure takes place. Remote execution takes place in a system you are not really in control of. Local execution means you can run the tool standalone on your own system, but you could of course run it in a remote system as well.

Apart from technical differences, remember that there are also important differences in what you need to know about the AWS platform. CloudFormation, Terraform and OpenTofu all work at a lower level where you must understand how different resources fit together. 

Both AWS CDK and Pulumi try to help you with some of these details. No matter what tool you use, you will have an easier time if you understand the underlying AWS resources and their functionality.

Programming languages (JavaScript/TypeScript, Java, .NET, Go, Python) generally have much better support in the popular IDEs compared to YAML, JSON, and even HCL. If you are a developer working in a specific language (e.g. TypeScript) then you will most likely be more comfortable working with AWS CDK or Pulumi compared to CloudFormation, Terraform, or OpenTofu.

Finally, consider what license makes sense for your environment. If you want to, or are required to use open source tools you should pick one of OpenTofu or Pulumi. The CDK is in itself open source, but the underlying engine (CloudFormation) is not.

No matter what tool you are using for Infrastructure as Code on AWS, there are best practices that apply to all of them. Here are a few important things to keep in mind:

• Store your infrastructure as code in a source code repository (e.g., GitHub). Make sure to have robust access management around your infrastructure repository.
• Keep secrets, keys, and certificates out of your infrastructure code. Utilize secrets management solutions (e.g., AWS Secrets Manager, GitHub Actions secrets, etc). Rotate secrets regularly, or generate short-lived secrets on-demand where possible.
• If you work in a team, you should set up a process for moving changes from implementation into production. All infrastructure updates should go through a review process (pair-programming or pull-request reviews) and be applied consistently through a CI/CD pipeline or other automation platform (e.g., Spacelift).
• Test the infrastructure changes you are making, either using built-in testing support in your tool of choice (e.g., the OpenTofu test framework) or making the corresponding changes in a development or staging environment.
• Set up monitoring and alerts for drift detection, either using the native support in AWS CloudFormation or another platform (e.g., Spacelift). If appropriate, use auto-remediation of detected drifts.
• Build reusable modules and components for common architectural pieces in your AWS environment. Build high-level abstractions in AWS CDK or Pulumi. Build modules in Terraform and OpenTofu. Use nested templates in CloudFormation.
• Apply policy-as-code to set a baseline for what changes are allowed in your AWS environment (e.g., OPA integration in Spacelift). Use policies to positively influence your AWS bill.
• Restrict permissions to the bare minimum. This is true for the automation system applying changes to your infrastructure, as well as the AWS IAM permissions and network rules that you set up as part of your infrastructure.

There are more points that can be made, but following the practices listed above is a great start.

Spacelift is an infrastructure orchestration platform that increases your infrastructure deployment speed without sacrificing control.

With Spacelift, you can provision, configure, and govern with one or more automated workflows that orchestrate Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes. 

You don’t need to define all the prerequisite steps for installing and configuring the infrastructure tool you are using, nor the deployment and security steps, as they are all available in the default workflow.

Spacelift offers a unique set of infrastructure orchestration capabilities, such as:

• Policies (based on Open Policy Agent) — You can control how many approvals you need for runs, the kind of resources you can create, and the kind of parameters these resources can have, and you can also control the behavior when a pull request is open or merged.
• Multi-IaC workflows — Combine Terraform with Kubernetes, Ansible, and other IaC tools such as OpenTofu, Pulumi, and CloudFormation, create dependencies among them, and share outputs
• Build self-service infrastructure — You can use Blueprints to build self-service infrastructure; simply complete a form to provision infrastructure based on Terraform and other supported tools.
• Integrations with any third-party tools — You can integrate with your favorite third-party tools and even build policies for them. For example, you can Integrate security tools in your workflows using Custom Inputs.
• Drift detection and remediation

Spacelift enables you to create private workers inside your infrastructure, which helps you execute Spacelift-related workflows on your end. The documentation provides more information on configuring private workers.

If you want to learn more about what you can do with Spacelift, check out this article, create a free account today, or book a demo with one of our engineers.

In this blog post, we have seen how to use five different approaches to infrastructure as code on AWS.

• AWS CloudFormation is the native tool for infrastructure as code on AWS. It is declarative and you write CloudFormation templates using either JSON or YAML. It has been around for a long time and has evolved over time with additional features.
• AWS CDK is an imperative approach to infrastructure as code. You write CDK code using a high-level programming language such as TypeScript. The output of CDK are CloudFormation templates.
• Terraform is a declarative tool for infrastructure as code. The AWS provider for Terraform is the most downloaded provider in the Terraform registry, indicative of how widespread its use is in the AWS community. Terraform configuration is written in either HCL or JSON.
• OpenTofu is a drop-in replacement for Terraform. It sprung from the movement started after HashiCorp switched the license for its products from open-source to source-available. OpenTofu is declarative, written in HCL or JSON.
• Pulumi is an open-source tool for infrastructure as code. You write Pulumi infrastructure in an imperative fashion in a language of your choice (JavaScript/TypeScript, Python, .NET, Java, Go). Pulumi can work with any target provider that is supported, not just AWS.

What tool is right for your situation depends on your current environment, personal preferences, experience, and skills. Be sure to review the technical differences and evaluate the different options.

Follow best practices for infrastructure as code on AWS to keep your AWS environment secure and cost-efficient.