top of page

Pros and Cons of Using Top IaC Technologies with Amazon API Gateway

A brief comparison of three leading Infrastructure-as-Code (IaC) technologies for templatized deployment of AWS serverless resources.

James Bayman, Senior Software Engineer

Within the pantheon of IaC, everyone seems to have a favorite technology. Three popular choices for use with Amazon Web Services (AWS) are Hashicorp Terraform, AWS CloudFormation, and the AWS Serverless Application Model (SAM). Terraform, an open-source provisioning tool, is one of the most popular. Its declarative nature makes it an easy solution for starting a new project, templating an existing architecture, or preparing for a migration. Yet, while it is an excellent tool for deploying resources in a cloud agnostic manner and enabling third-party tie-ins, Terraform is not always the simplest or quickest solution for every scenario, and it can be cumbersome to learn, set up, and maintain.

Before you decide on your IaC technology, we recommend investing time in understanding the benefits and limitations of different IaC languages for your unique architecture. This approach will save you significant costs and headaches in the long run. This article offers insights into the pros and cons of the top IaC technologies for templatizing deployment of AWS serverless resources to support your evaluation process.

To compare these three IaC technologies, we will deploy the same set of AWS resources in three different ways using Terraform, AWS CloudFormation, and the AWS Serverless Application Model (SAM). First, each template will deploy a simple REST API with two endpoints using AWS API Gateway and AWS Lambda (Python). Then, each method will provide a simple response based on the REST verb used.

#1: Terraform

Terraform is widely beloved for its versatility and continues to rise in popularity with the release of version 1.0. It is an open-source provisioning tool with an active online community and is updated frequently with new and exciting features.

The following is a Terraform template for deploying our example API.


In this scenario, Terraform boasts significant advantages over current AWS IaC offerings. These include:

  • Versatile Modularity

    • Perhaps its most useful feature, Terraform allows you to create reusable and sharable modules.

    • Though not shown in the above example, modules allow subsequent templates to abstract away the nitty-gritty details of creating and configuring individual, low-level resources in favor of consolidated and easily consumable modules.

  • Modules allow for versatility that isn’t quite matched by AWS CloudFormation’s nested stacks or stack sets.

  • Cloud Agnosticism

    • Unlike AWS CloudFormation and SAM, Terraform is not locked into AWS.

    • Terraform currently supports over 70 different providers, including cloud and on-prem - a number that continues to grow.

    • Multiple providers can be used in conjunction to create a multi-cloud architecture or integrate third-party resources.

  • Industry Adoption

    • Terraform is quickly becoming an industry standard for IaC. Therefore, familiarity with creating/updating Terraform templates is a valuable skill for developers.

    • An active community makes it easy to find documentation and template examples.


While Terraform is an excellent option for a wide variety of workloads, when it comes to AWS specific architecture deployments, it lacks significant features compared to proprietary AWS offerings like AWS CloudFormation and SAM.

  • Lack of Deployment Rollback Automation

    • Automatic rollback following a failed deployment is not currently supported.

    • If a particular resource’s creation fails, the template’s deployment ends.

    • Any resources created up to failure are retained, leaving the deployment in a broken state until the resources are deleted/recreated by a subsequent command.

  • Weak CI/CD integration

    • Integrating Terraform into CI/CD pipelines like AWS CodePipeline is less trivial than using the AWS native AWS CloudFormation

      • CodePipeline offers direct AWS CloudFormation integration for use as a deployment provider.

  • Terraform templates must be deployed from a separate build instance, either running in AWS CodeBuild or a third party like Jenkins or GitLab Runners

  • Poor Readability

    • Terraform’s HCL is an improvement over writing in pure JSON, but it isn’t quite as readable as YAML templates.

  • Using a common language like YAML helps reduce the learning curve for AWS CloudFormation and SAM.

#2: AWS CloudFormation

As a proprietary solution, AWS CloudFormation is arguably one of the best options for deploying AWS resources as IaC. As shown in the AWS CloudFormation template below, the technology deploys the same API resources in a very similar way to Terraform, though it is noticeably more readable:


Key benefits of AWS CloudFormation compared to Terraform:

  • AWS managed state

  • AWS provisions a separate S3 bucket automatically to store any deployed templates.

  • Available AWS console UI

    • Visual representation of template state during the deployment process.

    • Simple to read UI provides easier debugging, configuration, and deployments.

  • Easy Integration with AWS Services

    • AWS CloudFormation integrates seamlessly with other AWS services, such as AWS CodePipeline and SSM Parameter Store.

  • Rollback options

    • Should a deployment fail, AWS CloudFormation resources can: 1) retain the resources created successfully before the failure and wait for an updated template to retry the deployment, or 2) roll back to the previous state and remove any newly created resources.

  • Choice of config language

    • You can choose between JSON and YAML for templates.


When compared to other IaC solutions, AWS CloudFormation does have some apparent drawbacks:

  • Limited to AWS

    • The most significant disadvantage is that it is an AWS specific product unless you plan to stay with AWS for a prolonged period.

    • Exceptions include self-defined “custom” resources and paid integrations for third-party resources like Data Dog, New Relic, and Atlassian.

    • Migrating to a new cloud provider may require swapping IaC providers and retemplate your architecture in a new language.

#3: SAM

The AWS Serverless Application Model (SAM) is a shorthand syntax for AWS CloudFormation that abstracts a lot of the base configuration for AWS Serverless resources like Amazon API Gateway, Amazon DynamoDB, and AWS Lambda. The result is that SAM templates are much more concise than vanilla AWS CloudFormation or Terraform templates, as seen in the following example:

Though we seem only to be creating two resources, a REST API and a Lambda function, this template is making the same resources as its AWS CloudFormation and Terraform counterparts. Once built, the SAM template is translated into a ready to deploy standard AWS CloudFormation template, with an explicit definition for each implicit resource not defined within the initial SAM template.


In terms of benefits, SAM provides a level of abstraction and is easy to use:

  • Same benefits as AWS CloudFormation

  • Simple configuration

    • Much simpler and quicker to stand up a working architecture than other IaC

  • Local Testing

    • SAM provides the invaluable (and valuable, for that matter) ability to perform local testing of serverless resources

    • No need to deploy your architecture to AWS to test

    • Reduce development costs


In terms of disadvantages, SAM is less versatile and more complex:

  • Less fine-grain control

    • Less upfront configuration means less low-level control, particularly when it comes to implicitly created resources

  • Limited to serverless resources

    • The primary benefit of SAM is its use with serverless resources specifically, though standard AWS CloudFormation resources can still be defined and referenced within a SAM template.

  • More complex CI/CD

    • Requires the extra step of building the SAM template into a deployable AWS CloudFormation template. However, the newly released SAM Pipelines allow for far simpler configuration and deployment with several CI/CD providers, like Jenkins, GitLab, and AWS CodePipeline.


So, which IaC solution should you choose? As you may have guessed, the answer is that it depends on your unique architecture.

Terraform is most likely the best option if you’re looking for overall versatility. However, if you’re working solely within AWS, use AWS CloudFormation. And if you’re working within AWS and with primarily serverless resources, SAM is a fantastic technology - particularly for those with less experience working with IaC.

In summary, there is currently no overall “best” IaC tool. However, there are IaC tools better suited for certain situations, and learning to recognize which tool is best for a particular job is an invaluable skill for any professional.



bottom of page