An Overview of HashiCorp Terraform Landing Zone

July 1, 2020

Tweet This:
Share on LinkedIn:

By John Valentine, Kovarus Cloud Practice Manager

I suppose before we dive into how cool the Terraform Landing Zone is, it’s important to understand why the original AWS Landing Zone was created and its drawbacks. Basically, a Landing Zone (not to be confused with the Terraform Landing Zone) is a secure, multi-account AWS environment based heavily on AWS best practices and security epics. If you don’t know what a security epic is, AWS states “Security epics are the five capability categories that you should consider early in the migration process, because they are fundamental to get the journey started: Identity and access management, detective controls, infrastructure security, data protection, and incident response.”

Landing Zones are designed to simplify the management of multiple (100s–1000s) accounts at scale by automating the creation of each account and the infrastructure inside of it. There’s a master billing account, a set of shared services accounts that provide services that every other account would need and then all of our vended accounts we hand out to our end users. To automate account creation, we use a solution called Account Vending Machine, which is basically a Cloud Formation Template for accounts. Most customers will provision multiple accounts for a single application, with each account having certain permissions and security policies depending on if it’s in development, test, QA or production. The last piece is a solution called Transit Gateway, which acts as the networking hub for all of these accounts to communicate with each other; it eliminates most of the need for VPC peering and all that complexity.

While this approach has a lot of benefits, there are also some drawbacks. The first was that customers found this challenging to manage at scale due to all the moving pieces. The second challenge, and the one most complained about, was the requirement to use AWS native services only. In order to make AWS Landing Zones work, customers *had* to use CloudFormation, AWS Account Vending Machine (Systems Manager & Lambda), AWS Single Sign-On, and so on. This limited the functionality and integrations many customers looked for.

AWS Control Tower

Ultimately, AWS went away from recommending the AWS Landing Zone architecture due to the complexity. To address this main issue, AWS Control Tower was born. The idea behind Control Tower is similar to Landing Zones — It’s designed to provide a secure, multi-account AWS environment, based on AWS best practices and security epics. However, instead of relying heavily on infrastructure as code, automation and APIs used by Landing Zone, it’s a fully baked service that is designed to simplify deployment and management. This is great for an organization looking to spin up environments quickly and allows customers to adopt public cloud at a much faster pace. That said, it doesn’t allow for Infrastructure as Code (IaC) or API use and is still restricted to AWS native services, so organizations that need automated deployment infrastructure, containers or want to use 3rd-party tools are out of luck.

Terraform Landing Zone

This brings us to Terraform Landing Zone. TLZ is what a lot of customers wanted AWS Landing Zones to be — a secure, multi-account AWS environment, still based on AWS best practices and Security Epics, but with an IaC approach that extends beyond native AWS services.

I should probably take a minute to explain what Terraform is, as not everyone may be terribly familiar. Think of Terraform as achieving the same goal as AWS CloudFormation templates or Azure Resource Manager. It enables users to drive infrastructure as code and automates the provisioning of infrastructure in a repeatable manner. The big difference is that Terraform is portable between your private cloud to any other public cloud environment, meaning that we are no longer locked into any one cloud. The other benefit is it integrates with configuration management tools like Puppet or Ansible to further configure resources once Terraform provisions them, all while maintaining an accurate state of the environment. Super cool stuff!

The whole idea is that we can use whatever 3rd-party tooling we want. Instead of AWS SSO, we can use Okta (supported out of the box) or another SSO tool of our choice. For cloud native security, Palo Alto Prisma is supported out of box, but we could use any other solution such as TrendMicro if we wish. The whole idea is to give customers the freedom to choose the tool that best fits their need.

The key software that drives a TLZ deployment is Terraform Enterprise due to many required features that make the whole architecture work. One of these features is called TFE Workspaces, which we should dive a bit deeper into. Think of a Workspace as a baseline for that account that consists of Terraform code, variables (username, password, etc.), state, the APIs, RBAC, etc. When we say state, we mean that every time Terraform runs, it maintains a state file that describes everything that Terraform has provisioned, such as EC2 instances, AMI, volume type, number of instances and so on. We can also share the data from one workspace with others. The diagram that follows shows how TFE Workspaces are used to progress the application development lifecycle from Dev all the way through production. It could go something like this:

  • A developer or cloud admin provisions our first automated vended account (using Account Vending Machine) called “Dev.” You also see “access methods” which outlines the ways in which our users can access this account.
  • Terraform Enterprise uses a Workspace to provision two different workspaces.
    • TFE Workspace 1 configures the security baseline that integrates CloudTrail, Config, IAM, etc.
    • TFE Workspace 2 deploys the needed infrastructure, CICD pipeline or whatever else the user needs to get started.
  • The developer uses this Dev account to make the desired changes to the code or application they’re working on.
  • The developer would then publish that new code to a code repo such as GitHub.
  • Assuming we are using a CICD pipeline, the CICD Pipeline would test the code and builds the new software package.
  • The CICD Pipeline would then trigger a pipeline to build a new AMI.
  • When that AMI is built, the new AMI ID would be specified via the variable in the TFE workspace for the Test account from CICD Pipeline #1.
  • CICD Pipeline #1 would then run an automated integration tests on the newly deployed version of the code in the Test account.
  • When these tests succeed, the customer can either continue using automation to push the App to the QA and Prod Accounts by using CICD Pipeline #1, or can be configured in a few different manual interactions depending on how comfortable the customer is with their automated testing and deployment.

Because Terraform is a more flexible and powerful tool than native IaC solutions, it is easier to manage at scale, especially since it manages the state of the environment. Kovarus also offers a cost-effective managed service that scales easily with the customer’s TLZ environment. We have helped customers modernize the way they approach cloud operations using this solution. The great thing about this offering is that it doesn’t take months and months to architect and deploy. Kovarus is able to spin up a fully functional TLZ in as little as eight weeks so that customers can focus on the next project.

Feel free to reach out to a Kovarus account executive or engineer for a deeper dive on this offering.

Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.

Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.