The intersection of Amazon Web Services multi-account governance and HashiCorp Terraform infrastructure as code has produced a set of patterns that organizations use to establish a secure, repeatable, and observable cloud foundation. The discussion begins with the AWS Terraform Landing Zone Accelerator preview announced at HashiConf and demonstrated by senior cloud delivery architect Brad Hankel. That preview represented an explicit recognition by AWS that a significant portion of enterprise customers were baselining on Terraform and operating hybrid, multi-cloud environments where a Terraform-native solution was required.
The preview materialized as an AWS Accelerator named Terraform Landing Zone, TLZ. The stated purpose of TLZ is to help customers more quickly set up a secure, multi-account AWS environment based on AWS best practices with a strong isolation barrier between workloads. The solution saves time by automating the provisioning of core and application accounts and leverages the extensive providers Terraform has to extend provisioning to third party resources in addition to AWS. This enables a self-service and automated secure infrastructure within AWS. The announcement also included an update that HashiCorp and AWS have now built a more secure and seamless system for managing multi-account AWS in Terraform. The service is called AWS Control Tower Account Factory for Terraform, AFT, and is the evolution of the Terraform Landing Zones discussed in the preview video. It offers an easier way to set up and govern multi-account AWS environments.
The evolution from preview to AFT signals a maturation of the approach from an accelerator preview to a supported factory pattern for account creation and governance. The original TLZ positioning focused on automation of core and application account provisioning and on the ability to extend provisioning beyond AWS to third party resources through Terraform providers. The AFT evolution carries that intent forward with enhanced security and seamlessness for multi-account management.
AWS Control Tower Landing Zone Terraform Landing Zone Separation
The reference materials distinguish three related AWS constructs and their relationship to infrastructure as code.
AWS Control Tower is described as a service. It is the least effort path to begin provisioning accounts. The workflow is click driven and service managed. Because it is a service, it is a little bit more restrictive than some of the other things. It may not have all the features or functionality that a customer wants.
AWS Landing Zone is presented as an infrastructure as code model. It puts a CloudFormation based model at the core of the landing zone build. AWS Landing Zone really put the infrastructure as code model in there. A lot of CloudFormation, which is the baseline infrastructure as code for AWS.
AWS Terraform Landing Zone is the response to enterprise demand for code first, multi-provider control. The narrative notes that customers were hybrid, multi-cloud and had different reasons for picking Terraform. The pressure was to do everything as code. The TLZ concept was to tackle that by leveraging providers. The summary is that when we took a look at the TLZ and we see, Hey there's a lot of providers; we can do everything as code. Everything from documentation to third parties and everything on the provisioning side of it. That is what we were trying to tackle with this.
The practical consequence for platform teams is a choice between service managed guardrails with limited extensibility, CloudFormation native landing zone with AWS only coverage, and a Terraform native landing zone with provider extensibility and self-service automation.
HCP Terraform As Control Plane And Governance Layer For Landing Zones
The validated patterns guidance authored by Oscar Medina presents an opinionated approach to designing and deploying AWS landing zones using Terraform as the infrastructure as code engine and HashiCorp Cloud Platform, HCP, as the control plane and governance layer. The guidance includes prescriptive, repeatable, and scalable guidance for platform and application teams building secure, compliant, and automated AWS environments.
The approach aligns with the AWS Well-Architected Framework, ensuring that all architectural decisions support operational excellence, security, reliability, performance efficiency, and cost optimization. By leveraging HCP Terraform, Vault, Sentinel, and Packer, this approach enables organizations to enforce policy as code, manage secrets securely, and automate infrastructure provisioning across multiple AWS accounts and environments using GitOps workflows.
The getting started section provides high level steps to accomplish the following architecture. Figure 1 – AWS Landing Zones Architecture provisioned by HCP is referenced as the visual representation of that architecture.
The guide focuses on the design, deployment, and operationalization of AWS Landing Zones using Terraform and HCP as the control plane. The operational claim is that every landing zone deployed through this initiative is secure and observable by default, ensuring the use of best practices from the start. By integrating key AWS and HashiCorp services, a robust baseline is provided that supports compliance, threat detection, and operational insight without requiring additional setup.
The real world impact for platform teams is a reduction in manual credential handling and an increase in repeatability. The control plane centralizes state, run coordination, and policy enforcement while the data plane remains distributed across AWS accounts.
Secure And Observable By Default Component Set
The landing zone pattern uses specific AWS and HashiCorp services to achieve the secure and observable by default claim.
- AWS Control Tower and AWS Organizations to configure preventative control such as Service Control Policies, SCP
- AWS Config, CloudTrail, and GuardDuty for continuous security monitoring and threat detection
- CloudWatch and SIEM integration to provide deep observability and centralized logging
- HCP Packer to deliver hardened AMIs and container images, ensuring secure and consistent infrastructure artifacts
This component set means that compliance monitoring, threat detection, and logging are provisioned as part of the baseline rather than as an afterthought. The integration of HCP Packer ensures that image build pipelines produce hardened artifacts consistently across accounts.
The contextual layer connects these components to the broader Well-Architected pillars. Preventative controls via Organizations and Control Tower address security and reliability. Continuous monitoring via Config, CloudTrail, and GuardDuty addresses security and operational excellence. Observability via CloudWatch and SIEM addresses operational excellence and performance efficiency. Hardened images via Packer address security and reliability.
Identity Federation With OpenID Connect And Dynamic Credentials
Traditional methods of managing AWS credentials, such as embedding access keys in configuration files or environment variables, introduce risk and overhead. Dynamic credentials eliminate these concerns by using OpenID Connect, OIDC, to establish trust between HCP Terraform and AWS.
HCP Terraform uses OIDC to federate identity with AWS. When a workspace needs to perform actions in AWS, it assumes a pre-defined IAM role using a secure, short-lived token. This eliminates long lived credentials and reduces the blast radius of credential compromise.
The impact for security teams is the ability to enforce short lived access, audit role assumptions, and remove secrets from source control. The contextual layer ties this pattern to the policy as code and secrets management claims made for the HCP approach.
Landing Zone Accelerator Configuration And Scope
Using Terraform with Landing Zone Accelerator on AWS is explored as a complementary pattern. The post explores how you can incorporate HashiCorp Terraform to manage your Amazon Web Services application infrastructure after using AWS Control Tower with Landing Zone Accelerator on AWS, LZA, to manage your AWS ecosystem.
LZA deploys a cloud foundation that is architected to align with AWS best practices and multiple global compliance frameworks. Through a set of YAML configuration files in the management account, an organization can configure additional functionality, manage networking, deploy security services.
The LZA solution is targeted towards customers in Public Sector and highly regulated industries. For central managed governance, using AWS Control Tower is strongly recommended if you are deploying LZA to a Region where AWS Control Tower is supported. LZA’s complementary capabilities provide a comprehensive no-code solution across more than 35 AWS services to manage and govern a multi-account environment to support highly-regulated workloads and complex compliance requirements. AWS Control Tower and LZA helps establish platform readiness with security, compliance, and operational capabilities.
The scenario overview describes an example organization that has deployed the LZA solution and has a number of development, test, and production AWS accounts running various workloads. The use case is to illustrate how Terraform can be used with LZA to manage application infrastructure while LZA governs the foundation.
The impact is a separation of concerns. LZA and Control Tower provide the no-code foundation and governance guardrails. Terraform provides the code driven application and workload provisioning within the guardrails.
Enterprise Landing Zone Design With Organizations OUs SCPs And IAM Identity Center
A practical approach to setting up a secure, scalable multi-account AWS infrastructure is described as a real implementation for a portfolio project simulating a mid-size organization with around 500 employees.
The article states that when organizations grow, managing AWS resources in a single account becomes challenging. Security risks increase, cost tracking becomes difficult, and teams step on each other’s toes. The solution is a well-designed Landing Zone - a multi-account AWS environment with proper governance, security, and access management.
The implementation discussed includes:
- Setting up AWS Organizations with a multi-account strategy
- Designing Organizational Units, OUs, for different teams and environments
- Using Service Control Policies, SCPs, as security guardrails
- Configuring IAM Identity Center, SSO, for centralized access management
- Enabling security services like CloudTrail and GuardDuty across all accounts
- Structuring Terraform modules so the code stays clean and reusable
The why multi-account strategy section explains the rationale. With a single AWS account, one misconfiguration can affect everything. Cost tracking becomes hard because all teams share the same billing.
The impact for finance and security teams is clear cost allocation and blast radius containment. The contextual layer ties OUs to lifecycle and compliance boundaries, SCPs to preventative guardrails, and IAM Identity Center to centralized access.
Startup Landing Zone Terraform Resource Set And Prerequisites
A Terraform example for a startup landing zone creates a basic landing zone for a startup to begin building on Amazon Web Services.
The Terraform will create the following resources:
- Amazon Virtual Private Cloud, VPC
- NAT Gateways
- Public and private subnets
- Route tables
- Tags for AWS resources
Prerequisites are explicit.
- AWS Access Key ID
- AWS Secret Access Key
- Amazon S3 bucket used to store the Terraform state
- At least 2 Elastic IP Address allocation IDs
To create AWS Access Key ID and Secret Access Key, instructions are referenced at the AWS premium support knowledge center article for creating access keys. It is a best practice that you should assign the policy with permissions as narrowly as possible. But in this case, we will choose AdministratorAccess policy. After creating the AWS Access Key, please read the best practices for managing AWS access keys guide.
Instructions for allocating Elastic IP addresses are referenced at the VPC user guide. An Amazon S3 bucket is needed to store Terraform state. Instructions for creating S3 bucket are referenced at the Amazon S3 user guide.
The impact for a startup is a minimal viable network foundation with state management. The contextual layer connects this to the broader landing zone journey where the initial VPC and networking are later extended into multi-account governance.
Prerequisites And Resource Summary
The startup example highlights the minimum inputs required before Terraform can run.
- AWS Access Key ID
- AWS Secret Access Key
- Amazon S3 bucket for Terraform state
- At least 2 Elastic IP Address allocation IDs
The resources produced by the example are summarized in a table for clarity.
| Resource Category | Example Items |
| VPC Foundation | Amazon Virtual Private Cloud |
| Connectivity | NAT Gateways |
| Subnetting | Public and private subnets |
| Routing | Route tables |
| Governance | Tags for AWS resources |
The table reinforces that the example is network focused and does not yet include Organizations, SCPs, or security services.
Comparison Of Landing Zone Approaches
The three AWS approaches can be contrasted.
| Approach | Code Model | Extensibility | Typical Audience |
| AWS Control Tower | Service managed clicks | Limited to AWS services | Teams wanting least effort governance |
| AWS Landing Zone | CloudFormation | AWS only | Teams wanting infrastructure as code with AWS native templates |
| AWS Terraform Landing Zone | Terraform | Multi-provider, third party | Hybrid multi-cloud teams wanting everything as code |
The comparison shows a progression from service managed to CloudFormation to Terraform provider extensibility.
Operationalization With GitOps And Policy As Code
The HCP based guidance emphasizes GitOps workflows for infrastructure provisioning across multiple AWS accounts and environments. Policy as code is enforced via Sentinel. Secrets are managed via Vault. Image builds are standardized via Packer.
Together these capabilities create a feedback loop where changes to landing zone configuration are proposed via Git, validated via Sentinel policies, applied via HCP Terraform workspaces using OIDC federated credentials, and audited via CloudTrail and Config.
The impact is that platform teams can move from manual account requests to self-service account provisioning with guardrails enforced automatically.
Conclusion
The reference materials collectively describe a maturing ecosystem where AWS multi-account governance and Terraform infrastructure as code converge. The AWS Terraform Landing Zone Accelerator preview demonstrated intent to serve customers who baseline on Terraform and operate hybrid environments. The evolution into AWS Control Tower Account Factory for Terraform provides a more secure and seamless system for managing multi-account AWS in Terraform.
The validated patterns guidance adds HCP as a control plane and governance layer, integrating HCP Terraform, Vault, Sentinel, and Packer to enforce policy as code, manage secrets securely, and automate provisioning with GitOps. The secure and observable by default architecture relies on AWS Control Tower and Organizations for preventative controls such as SCP, AWS Config, CloudTrail, and GuardDuty for continuous monitoring, CloudWatch and SIEM for observability, and HCP Packer for hardened artifacts.
The Landing Zone Accelerator on AWS provides a YAML driven, no-code foundation across more than 35 AWS services for public sector and highly regulated industries, with Terraform used for application infrastructure after the foundation is established. Enterprise designs emphasize AWS Organizations with a multi-account strategy, OUs for teams and environments, SCPs as security guardrails, IAM Identity Center for centralized access, and security services enabled across all accounts.
The startup example shows a minimal Terraform landing zone that provisions VPC, NAT Gateways, public and private subnets, route tables, and tags, requiring AWS access keys, an S3 bucket for state, and Elastic IP allocations.
Across all references, the common theme is isolation, automation, and governance. Multi-account strategy contains blast radius and enables cost tracking. Terraform providers extend provisioning beyond AWS. HCP provides control plane centralization and dynamic credentials via OIDC. The combination yields a landing zone that is secure and observable by default and adaptable to organizational growth from startup network foundations to enterprise regulated environments.