AWS CDK and AWS CloudFormation are powerful infrastructure as code tools to automate the creation of your AWS resources. Both tools can help you achieve operational excellency on AWS by removing manual provisioning methods like AWS Management Console or AWS CLI and eliminating possible human errors caused by only using them.
However, you might be wondering which to choose if you are new to AWS CDK or CloudFormation or just beginning to apply infrastructure as code on AWS. Therefore, in this post, I will discuss the differences and similarities between AWS CloudFormation and AWS CDK to help you understand them.
Why manage your AWS infrastructure as code?
Managing your AWS infrastructure as code standardizes your provisioning process and provides a reliable mechanism to roll back possible mistakes fast and securely. But let’s discuss why you need to apply infrastructure as code by returning to the history behind AWS CloudFormation and AWS CDK.
When AWS was new, you could only use AWS Management Console, or AWS CLI later, to create AWS resources. It was great then because the cloud concept was also new and revolutionized the way to create new IT infrastructure. It replaced the servers you order and manage on-premises with a few configuration steps provided through a website or a command line tool.
However, using manual methods are prone to errors. If you want to launch the same AWS architecture, you must exactly repeat the steps taken to create the previous one, like clicking buttons, filling in forms or typing commands, etc. You can’t reuse your previous work.
So DevOps engineers started writing bash or Python scripts using AWS CLI commands or API calls to automate this process. It helped them solve the automation problem but caused new ones.
For example, what if your automation script has an error or your Internet connection goes off in the middle of it? There is no way to roll the AWS resources created back automatically. You must locate where the problem occurred yourself and manually remove the created resources. Or you have to write a more complicated deployment script to handle these failures.
So as a solution, AWS launched its first infrastructure as code tool, AWS CloudFormation.
What is AWS CloudFormation?
AWS CloudFormation enables you to code the state of the AWS resources you want to launch in JSON or YAML templates. Then, you create CloudFormation stacks from these templates to create and manage your resources. So templates are boilerplates for the stacks you launch.
You update your resources by modifying your template with their new expected states and updating your stack accordingly. If you no longer need your AWS architecture, you can remove your AWS resources by just deleting the stack that created them. So CloudFormation simplifies managing your AWS resources.
Advantages of CloudFormation
There are many advantages of using AWS CloudFormation to automate the creation of your AWS resources. Let’s list some of the most important ones that come to mind at first thought.
AWS CloudFormation standardizes the way you create your AWS resources. You define your resources according to the CloudFormation specification in your templates. Then you use those templates to create or update your stacks.
You can reuse existing CloudFormation templates to create similar stacks to easily replicate your AWS architecture. For example, you can use the same template to create development, test, and production environments.
CloudFormation provides tools to increase the reusability of your templates by defining parameters, mappings, conditions, etc.
You can extend the capability of your CloudFormation templates using custom resources.
If an error happens during stack creation or update, CloudFormation automatically rolls the resources created or updated until then back. So CloudFormation is a fast, secure, and reliable mechanism for handling failures.
CloudFormation is integrated with other AWS Developer Tools, such as AWS CodePipeline. So you can easily create a CI/CD pipeline to manage your infrastructure code as a software project and automate the deployments of your changes with only Git pushes.
And AWS CloudFormation’s reliability has been proven for years. AWS also uses CloudFormation stacks behind the scenes in many AWS services, such as Elastic Beanstalk or the new Amazon ECS Console.
Therefore, CloudFormation is a well-established infrastructure as code tool to create your AWS resources reliably, securely, and fast. But AWS CloudFormation lacks some features avoiding it to increase your productivity even more.
Limits of AWS CloudFormation
So let’s discuss some of the limits of CloudFormation templates.
You must use JSON or YAML to write CloudFormation templates in a declarative format. Although writing CloudFormation templates, especially in YAML, isn’t difficult to learn, you can’t use common programming languages to type your infrastructure code as real code.
You can’t use control flow tools, such as ‘for’ loops, ‘if else’ statements, etc., supported by common programming languages. So sometimes, you still repeat yourself while defining your resources. For instance, if you need to create similarly configured 10 S3 buckets, you must define them all separately.
You must know the AWS resources you define well because you configure their properties in detail while using AWS CloudFormation.
You can’t use the power of abstractions in object-oriented programming to set standards for your resources or group multiple resources together. As I said, all resources should be defined in detail and declaratively while using vanilla AWS CloudFormation.
Therefore, to simplify your adoption of infrastructure as code, AWS launched its second tool on top of AWS CloudFormation, AWS Cloud Development Kit, or AWS CDK for short.
What is AWS CDK?
Now let’s discuss how CDK is different than or similar to CloudFormation one by one.
You can replace JSON or YAML with your favorite programming language via CDK
AWS CDK has first-class support for popular programming languages like Python and Java. So if you are already developing applications with them, CDK can simplify your transition to managing your infrastructure as code. Instead of JSON or YAML, you can use CDK libraries in your programming language and use the control flow tools provided by them to write more efficient code.
So some CloudFormation features just created by AWS to provide reusability for your templates become obsolete with CDK. For example, you replace CloudFormation conditions with if-else statements and stack parameters with object initialization arguments in CDK. You can still define them in your CDK apps, but it would not be a best practice, as there are more efficient methods.
You use the power of abstractions in AWS CDK
As you can use object-oriented programming languages like Python in CDK, you can define methods or classes to modularize your code or set standards for your AWS resources in your organization. Besides, AWS CDK provides classes for many AWS resource types to create resources with sensible defaults according to the most used scenarios and security best practices. Therefore, even if you don’t know the AWS service well, you can still create resources following AWS best practices.
For example, you can use CDK to create a complete VPC with its subnets, route tables, internet gateways, or even NAT gateways only by initializing an instance of the L2-level VPC construct provided in CDK Construct Library. By the way, constructs are basic building blocks of CDK applications representing one or more AWS resources. CDK has a construct hierarchy according to the level of abstractions provided, L1, L2, and L2, which will be a topic of another post.
CDK is still subject to CloudFormation stacks’ limits
AWS CDK generates JSON CloudFormation templates from your CDK code and uses those templates to launch CloudFormation stacks to deploy your AWS resources. So you only replace the language and structure of your infrastructure code with CDK. CDK still uses CloudFormation behind the scenes. Therefore, CDK depends on AWS CloudFormation and is subject to its limits, such as resource quotas per stack during deployments.
CDK simplifies CloudFormation features
Although CDK depends on CloudFormation, it simplifies the usage of CloudFormation’s features. For example, you can create multiple stacks in a CDK app and pass values between them by adding input parameters and setting instance attributes. Then, depending on whether you define those stacks independently or under a root stack, CDK configures cross-stack references or nested stacks automatically. So you only apply the object-oriented methods you are used to while using CDK. You don’t have to know the low-level CloudFormation features in detail.
CDK expands CloudFormation’s capabilities
AWS CDK brings encapsulation on top of CloudFormation. Therefore, CDK Construct Library provides features to enhance the capabilities of CloudFormation. For example, you cannot delete an S3 bucket with objects using vanilla CloudFormation. It results in a stack deletion error. As a solution, you can retain your buckets or customize your stacks by writing Lambda functions to empty your buckets and triggering them on stack deletions. However, you can achieve this in CDK by setting a single boolean property to ‘true’ on your S3 buckets. Then, CDK configures the setup for you.
Another example is replacing an EC2 instance when updating the User Data property. If you are familiar, EC2 user data scripts are only executed at launch. So updating them is ineffective on vanilla CloudFormation stacks. However, by enabling a single property, CDK can cause replacements on your EC2 instances if their user data properties are updated.
Therefore, although CDK depends on CloudFormation, it brings more capabilities with the power of encapsulation. Of course, you can also code your own logic using AWS SDKs if CDK doesn’t have support for the solution you are looking for.
Sharing code differs in CDK and CloudFormation
In CloudFormation, you share your templates to reuse the code you’ve written while launching new stacks. However, in CDK, each stack has its own template. So templates are not shared in CDK. Instead, you share your code as packages or libraries in your programming language. You can define custom constructs as CDK patterns, the highest-level L3 constructs in the hierarchy, and share them as common libraries.
Knowing AWS CloudFormation is an advantage for AWS CDK
As AWS CDK depends on AWS CloudFormation, you can become a real CDK expert if you also know CloudFormation well. So you can relate the CDK features with CloudFormation correspondents and understand their usages better. However, you don’t have to know CloudFormation to learn CDK. It is just an advantage.
AWS CDK and CloudFormation offer different ways to achieve the same goal: managing your infrastructure as code to automate the creation of your AWS resources and avoid human errors.
If you like defining your resource states declaratively as JSON or YAML templates, CloudFormation would suit your style better. However, if you already develop applications in a programming language with first-class CDK support, like Python, CDK can make writing infrastructure code easier. It can be more fun for you with CDK’s imperative coding style.
So the choice is yours. I hope this post helps you by explaining some of AWS CDK and CloudFormation’s differences and similarities. However, what matters is applying infrastructure as code as much as you can, whichever tool you choose.
Thanks for reading!
Would you like to learn AWS CDK or AWS CloudFormation, or both?
We discussed the differences between both AWS tools. So where can you learn them?
I have two online AWS CloudFormation courses targeting beginner and intermediate users on Udemy. If you are interested, please find their links on our courses page.
Besides, I am developing a new course to teach AWS CDK with Python step by step and expect to launch it soon. I will announce it on this blog when ready. So stay tuned if you want to learn AWS CDK.
Learning CloudFormation might be a viable option until then if you want to become a complete infrastructure as code expert on AWS. You can also find the links to the AWS documentations of both tools if you prefer to learn them on your own.