AWS for the Real World

πŸ“š AWS Essentials: The Rise of Infrastructure as Code

Published 7 months agoΒ β€’Β 4 min read

πŸ‘€ This is not properly displayed? Read all of our issues online! πŸ’‘

Hi Reader πŸ‘‹πŸ½

now that we have completed most of the main services in our newsletter we are jumping on another important chapter in Cloud Computing: Infrastructure as Code.

Knowing cloud services is one thing. Implementing applications is another thing. You won't see a real production workload (hopefully) that wasn't provisioned without any infrastructure as a code tool.

This newsletter is all about the history and different tools that are out there for infrastructure as code. In the next upcoming newsletters, we will dive deeper into:

  • CloudFormation
  • Terraform
  • Serverless Framework
  • CDK

and maybe even more πŸ˜‰

Application Code IS Infrastructure Code

Before serverless & cloud computing it was very common to distinguish infrastructure from application code. For example, your Java Spring server was application code. The database and docker provisioning code was infrastructure.

Nowadays this is different. Think of the combination of Lambda and SQS. It is hard to say what exactly here is infrastructure and what Application.

This is an important pre-requisite to clarify first.

What is Infrastructure as Code?

Infrastructure as Code (IaC) describes the practice of provisioning your infrastructure with source code. By having source code, you gain many benefits:

  • You can duplicate the same environment in another account or region.
  • Every change is documented and versioned (thanks to GIT).
  • Infrastructure as Code enables you to follow DevOps best practices, such as automated testing, continuous deployment, and feature flagging. All of these practices are possible.
  • You get a reproducible setup. There are no manual checklists or steps to remember. Executing the code is sufficient.

There are many more benefits. You cannot use AWS professionally without being able to provision resources via Code.

History of IaC

"If you want to understand today, you must search yesterday."

Pearl S. Buck, American novelist (1892-1973)

There are many IaC tools available, and each has its place. To understand their differences, we need to take a step back and understand where we are coming from. Each step in the timeline had a different philosophy.

Remember that cloud computing has only been evolving for the last two decades, and software development has undergone many changes during that time.

The image below shows some of the main categories of different IaC tools.

We started with a manual approach by clicking in the AWS Console. Nowadays, we have several IaC frameworks available and can use them in our favorite programming language. Let's see the single steps in a bit more detail.

Manual - Clicking in the AWS Console

When AWS was launched it was common to create your resources in the UI. This is also called ClickOps. This was very error-prone. It was common to have documents with screenshots and checklists on how to create the resource.

There was no code, history, or governance. With more complex AWS setups this approach became very bad.

Scripted - Provision AWS Resources with the CLI

AWS has a very powerful CLI. At some point, people started using the CLI to provision resources. For example, you can create a bucket like this:

aws s3api create-bucket --bucket awsfundamentalstestbucket

These CLI commands were added to pipelines like Jenkins and that is how infrastructure was provisioned.

While this was the first step of going in the direction of having code it was still suboptimal.

The CLI had no idea which resources were already created, or if you needed to update or create new resources, and error handling was also non-existent.

Declarative - Describe the Infrastructure

The next step was using a declarative method. A declarative approach defines what the final state looks like. We know this approach from SQL. We don't care how it will be done; we only define the final state.

For example, we can define that we need an S3 bucket. How the tool takes care of providing us with that bucket is not of interest.

AWS introduced the service CloudFormation. CloudFormation allows you to provision resources, handle errors, and roll back states. A CloudFormation template is a configuration file in a YAML or JSON format. For example, a file could look like this:

CloudFormation has a state and knows which infrastructure was already provisioned and which needs to be updated.

The engine underneath is still used in most of the frameworks like CDK, Amplify, or SST. It is still to this day a very common approach to use CloudFormation.

If you want to use any of the other tools (except for tools like Terraform) you need to understand the basics of CloudFormation.

Tools in this step are for example:

  • CloudFormation
  • Terraform
  • Serverless Framework

Componentized - Use your Programming Language to Build Abstractions

Componentized frameworks allow you to build reusable abstractions that developers can use. There is one big difference between the other stages. Now developers can build infrastructure in a proper programming language. Languages like Python, TypeScript, or Java are very common for these frameworks. Under the hood, CloudFormation will often be used.

Popular frameworks are:

  • CDK
  • SST (Based on CDK)
  • Pulumi

Using a proper programming language is the major benefit here. Developers use these languages, concepts, and IDEs daily. There is no need to learn a new syntax. But it is important to learn the basics of the engine underneath, e.g. CloudFormation.

Creating a bucket can be as simple as that:

You have all the benefits of using a programming language but also the benefits that if you don't understand the concepts (or software engineering) well enough, you can easily over-abstract a lot!


This newsletter edition gives you an overview of existing IaC tools, their different stages, and why we have them.

Please remember that the stages don't refer to which tool is better suited than the others. Not every tool in the componentized area is better than in the declarative one.

It depends a lot on the organization, use case, and the team that will be working with it.

In the next newsletters, we will dive deeper into each tool and show you some examples of how to provision cloud resources with it.

See you in two weeks πŸ‘‹πŸ½
Sandro & Tobi

Still hungry for AWS content? Have a look at our blog! πŸ“š ↓

AWS for the Real World

by Tobi & Sandro

Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

βŒ› Reading time: 7 minutes πŸŽ“ Main Learning: Visual Regression Testing with AWS CloudWatch Synthetics πŸ‘¨πŸ½πŸ’» GitHub Code πŸ“ Blog Post Hey Reader Keeping your website running smoothly is important.It's also important to keep an eye on its visual appearance and that it doesn't change due to an unwanted change. AWS CloudWatch Synthetic Canaries is a tool that helps you check on your websites (and APIs!) to make sure it’s working well and look as expected. In this newsletter, we’re going to show you...

15 days agoΒ β€’Β 4 min read

Hi Reader and happy May the 4th ⭐. We want to start the spring by giving you an amazing discount on our book and other resources. For that, we have partnered with four different AWS Creators around the globe. You can use the code AWSFUND30 to get 30% off. The resources are: πŸ“™ AWS Fundamentals - Like this newsletter, it covers the basics of essential AWS Services for real-world applications. πŸ“˜ The DynamoDB Book - Level up your DynamoDB modeling and finally understand Single-Table Design. πŸ—οΈ...

22 days agoΒ β€’Β 1 min read

βŒ› Reading time: 6.3 minutes πŸŽ“ Main Learning: Working with the Bedrock API πŸ‘¨πŸ½πŸ’» GitHub Code πŸ“ Blog Post Hey Reader πŸ‘‹πŸ½ in this newsletter, we’ll explore how to build a serverless chat application that uses Amazon Bedrock and the OpenAI API. We’ll use SST (Serverless Stack) to develop and deploy the application on AWS, featuring Next.JS for the frontend and DynamoDB and Lambda for backend services. πŸ’‘ The application's full repository can be found on our Github organization. You can deploy it with...

about 1 month agoΒ β€’Β 9 min read
Share this post