IaC, or Infrastructure as Code, is gaining significant attention in the tech industry. This approach, also known as software-defined infrastructure, involves automating the management and provisioning of technology stacks for applications using software. Unlike traditional manual configurations of hardware devices and operating systems, IaC streamlines this process, aligning with the principles of DevOps. Its aim is to enhance organizational agility, productivity, and work quality.

When seeking tools to implement infrastructure as code on AWS, the decision often boils down to AWS CloudFormation or the open-source tool Terraform. Let’s examine the distinctions between these two tools to help you ascertain which best suits your requirements

CloudFormation

AWS CloudFormation is a managed service by AWS, offering a unified language for modeling and provisioning AWS and third-party application resources securely and consistently in your cloud environment. It serves as a central hub for mapping AWS infrastructure and development tasks.

One of CloudFormation’s key benefits is its abstraction of complexities related to managing dependencies between AWS resources. This simplifies the process and facilitates the modification and deletion of provisioned resources in a predictable manner, easing infrastructure versioning and iteration.

CloudFormation is deeply integrated with AWS services, making it inherently AWS-native. It eliminates the need for users to manually determine which AWS services to provision or how to configure their dependencies; CloudFormation handles these tasks autonomously. Once deployed, users can manage and modify AWS resources in a controlled manner through CloudFormation, leveraging features like CloudWatch for monitoring and version control. This enables iterative testing and, when properly configured, facilitates rollback procedures.

Terraform‍

Created by HashiCorp, Terraform is an open-source infrastructure-as-code tool designed to facilitate the setup and provisioning of datacenter infrastructure. Unlike CloudFormation, Terraform is cloud-agnostic, allowing users to manage resources across multiple cloud providers.

Terraform operates by translating APIs into declarative configuration files , enabling users to define their infrastructure requirements in a human-readable format. These configuration files can be shared among team members, treated as code, and managed using version control systems.

Having established an overview of these two infrastructure-as-code platforms, let’s delve deeper into some of the key differences between them.

State Management

Both CloudFormation and Terraform require users to maintain oversight of all managed resources.

In CloudFormation, users can conduct regular drift detection checks on their provisioned infrastructure to identify any discrepancies. This process provides detailed feedback if changes are detected. While some resources within a CloudFormation stack can have parameters adjusted without requiring destruction and rebuilding, others are considered immutable and will be reconstructed. Moreover, CloudFormation analyzes dependencies before deleting a resource and halts the process if any dependencies would remain unresolved post-deletion.

On the other hand, Terraform stores the infrastructure state either locally on the provisioning machine or in a remote location for collaborative team usage. This state file, in a custom JSON format, acts as a reference for Terraform, outlining the managed resources and their configurations.

CloudFormation, being a managed AWS service, automatically handles state management by consistently monitoring the provisioned infrastructure to ensure it maintains the desired state and configuration. On the other hand, Terraform stores its state locally by default, although it offers a remote state option for team collaboration, which writes the state data to a remote data store. This remote state feature supports integration with Amazon S3, although users need to configure it themselves.

With state management differences covered, let’s now shift our focus to the topic of modularity.

Modularity

In the constantly changing world of infrastructure requirements,  flexibility is key. CloudFormation and Terraform have unique ways of addressing this need.

Terraform has a modules, which are containers for multiple resources that are used together. Modules allow developers to abstract their infrastructure into reusable, shareable code and increases iteration speed for teams (much like functions do in a programming language like Ruby).

CloudFormation utilizes a system called “nested stacks.” That is, CloudFormation  templates being called from within CloudFormation templates. These nested stacks can further be abstracted into StackSets. It should be noted that StackSets require additional permissions, beyond those of normal AWS CloudFormation.  

A benefit of Terraform is increased flexibility over CloudFormation with regards to modularity. Terraform modules can be pulled in for any provider supported, or organizations can roll their own.

Conversely, in a multi-cloud or hybrid environment, CloudFormation doesn’t easily allow users to provision or natively coordinate non-AWS resources. It’s not impossible, as there is a custom resources feature in CloudFormation, but it requires additional templating and design to bring in third party resources, or those AWS services not available organically.

Configuration

CloudFormation and Terraform differ in how they handle configuration and parameters.

Terraform uses provider specific data sources. The implementation is in a modular fashion, allowing data to be fetched or computed for use elsewhere in a Terraform configuration. This lets a Terraform configuration make use of information defined outside of Terraform (such as an Elastic IP address), to update or provision infrastructure.

CloudFormation uses parameters, and has a maximum of 60 parameters per template. Each parameter must have a logical and unique ID among all others in the template. The parameters must be of a type supported by CloudFormation and they have to be provided at the stack’s runtime. Additionally, each parameter must be declared and referenced from within the same template. CloudFormation does have the capability to use Dynamic References to retrieve parameters at runtime from AWS Systems Manager parameter store, if one has been configured properly. 

Language‍

Terraform uses HashiCorp Configuration Language (HCL), a language built by HashiCorp. It is fully compatible with JSON, and was created to strike a balance between human-friendly and machine-friendly languages, while remaining interpretable to humans.

AWS CloudFormation utilizes either JSON or YAML, with the YAML version being slightly easier to read (as well as more compact). CloudFormation also has a limit of 51,000 bytes for the template body itself. If a larger template is needed, AWS advises developers to separate resources into nested stacks.

With those distinctions established, let’s look at a couple of Renova Cloud use cases where we employed Terraform as a solution for customers.

Customer Use Case: GSM

GSM is the leading producer of electric vehicles in Vietnam. They decided to move to the AWS cloud, working with Renova Cloud as a managed service provider. Renova Cloud supported the adoption of Amazon EKS, entrusting its container orchestration capabilities would provide a robust solution for GSM’s complex IT infrastructure. As a result, the company was subsequently able to scale it’s platform’s operations across various regions, ensuring optimal performance and responsiveness.

The broader perspective — CloudFormation or Terraform‍

Both CloudFormation and Terraform offer robust capabilities for managing cloud infrastructure. If your organization is heavily invested in AWS and primarily uses AWS tools without many external integrations, CloudFormation might offer greater convenience. However, if you seek additional flexibility and wish to work with a cloud-agnostic platform that seamlessly integrates with services from various providers, including AWS, Terraform could be a more suitable choice.

When making this decision, it’s essential to not only consider current requirements but also anticipate future infrastructure needs. Both toolsets offer long-term benefits, and the ultimate decision may hinge on factors such as usability and developer comfort.

Regardless of your choice, leveraging either of these versatile tools for AWS infrastructure management is likely to enhance productivity, portability, and efficiency within your organization.

FAQ

How do AWS CloudFormation and Terraform seamlessly integrate with other DevOps and CI/CD tools?

When evaluating the integration and compatibility of AWS CloudFormation and Terraform with other DevOps and CI/CD tools, it’s crucial to understand their respective capabilities. Terraform, being open-source, boasts a wide array of integration options thanks to its plugin system and active community contributions. It seamlessly integrates with popular CI/CD tools such as Jenkins, GitLab, and GitHub Actions, enabling infrastructure changes to be incorporated into CI/CD pipelines effortlessly.

On the other hand, AWS CloudFormation offers deep integration within the AWS ecosystem, including direct compatibility with AWS CodePipeline and other AWS services. However, integrating it with third-party CI/CD platforms might require additional tools or custom scripting to bridge the gap.

Overall, both CloudFormation and Terraform are designed to facilitate automation and collaboration, but Terraform’s open nature often provides more flexibility in integrating with various DevOps and CI/CD tools.

How do AWS CloudFormation and Terraform perform at scale and complex environments with hundreds of resources?

When it comes to performance and scalability, both AWS CloudFormation and Terraform are engineered to handle large-scale infrastructure deployments, although their methodologies differ. Terraform’s state management system enables it to effectively handle and monitor the state of numerous resources across multiple providers, making it particularly advantageous in complex environments. However, managing Terraform state on a very large scale can pose challenges and necessitate careful state management practices like state locking and remote state storage.

On the other hand, CloudFormation is intricately integrated with AWS and is optimized for managing AWS resources, rendering it highly efficient within AWS environments. Nevertheless, managing extensive deployments with CloudFormation may require meticulous organization of templates and could encounter service-specific limitations.

In summary, both CloudFormation and Terraform are capable of scaling to accommodate large and complex environments, albeit with differing approaches and considerations for effective management.

What’s the beginner’s learning curve like for AWS CloudFormation and Terraform, and where can one seek support for mastering these technologies?

The learning curve for both AWS CloudFormation and Terraform can vary depending on the user’s background. Terraform’s use of HCL (HashiCorp Configuration Language) is often praised for its readability and simplicity, which might make it easier for beginners to grasp. The extensive documentation, tutorials, and community forums contribute to a supportive learning environment. CloudFormation uses JSON or YAML, which might be more familiar to those already accustomed to working with AWS services, but the overall complexity of AWS-specific configurations can present a steeper learning curve. The community support for CloudFormation is robust within the AWS user community, though Terraform’s open-source nature has fostered a larger, more diverse community support network.