Use Terraform to build an AWS landing zone

Author: Oscar Medina

The following guidance 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. We include prescriptive, repeatable, and scalable guidance for platform and application teams building secure, compliant, and automated AWS environments.

The guidance 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

Scope

This guide focuses on the design, deployment, and operationalization of AWS Landing Zones using Terraform and HCP as the control plane. It provides a structured, opinionated methodology for provisioning foundational AWS infrastructure, including account structure, identity and access management (IAM), networking, security, monitoring, and application enablement.

The guidance is applicable to both greenfield and brownfield environments and is modular, scalable, and adaptable to enterprise requirements. It emphasizes automation, policy enforcement, and secure operations, while aligning with the AWS Well-Architected Framework to ensure best practices across all five pillars.

Audience

This document is for two primary personas:

The Platform Team: Responsible for building and maintaining the foundational AWS infrastructure, governance controls, and shared services that enable secure and scalable cloud adoption across the organization.

The Application Team: Focused on deploying and managing workloads within the Landing Zone framework, leveraging the platform's capabilities to build secure, compliant, and resilient applications using Terraform and HCP tooling.

Definitions

Platform landing zone

The platform landing zone (PLZ) is a pre-configured, secure, and scalable AWS environment that provides a foundational framework for deploying and operating workloads in the cloud. The PLZ includes the essential building blocks for governance, security, networking, identity, and automation. This ensures cloud adoption is consistent, compliant, and repeatable across teams and business units.

The PLZ is typically managed by a platform team and includes shared infrastructure and governance controls that support multiple application teams.

Key components of a platform landing zone:

• AWS organizations and account structure: Centralized management of multiple AWS accounts grouped by organizational units (OUs).
• Identity and access management (IAM): Federated access, permission boundaries, and role-based access control.
• Networking: Hub-and-spoke VPC architecture, Transit Gateway, NAT Gateways, VPC Endpoints.
• Security & Compliance: GuardDuty, AWS Config, Security Hub, CloudTrail, Service Control Policies (SCPs).
• Monitoring & Logging: Centralized logging to S3/CloudWatch, SIEM integration.
• Automation & Governance: Terraform modules, Sentinel policies, Vault for secrets management.

This zone is not intended for workloads, but rather for enabling and governing them.

Workload landing zone

The workload landing zone (WLZ) provides a dedicated environment within AWS where application teams deploy and manage their workloads. Application teams inherit guardrails and shared services from the PLZ and then tailor the WLZ to meet the needs of specific applications or business units.

Key components of a workload landing zone:

• Application-specific AWS accounts (e.g., dev, test, prod)
• Terraform-managed infrastructure (e.g., EKS, Lambda, RDS, S3)
• Secrets and credentials managed via HCP Vault
• Service networking using Consul (optional)
• Monitoring and alerting scoped to application needs
• CI/CD pipelines integrated with HCP Terraform and GitHub Actions or AWS CodePipeline

Each WLZ is autonomous in terms of deployment but compliant with the policies and controls defined in the PLZ.

Design principles

This guidance follows the AWS Well-Architected Framework and provides a set of opinionated design principles that ensure AWS landing zones are secure, scalable, and operationally efficient from day one. Implement them using Terraform and HCP to enforce consistency, automation, and governance across environments.

Infrastructure as code (IaC)

Whether foundational (e.g., VPCs, IAM roles) or workload-specific (e.g., EKS clusters, Lambda functions), define, deploy, and manage all infrastructure through Terraform.

This ensures:

• Repeatability and version control
• Automated provisioning and rollback
• Reduced configuration drift

Separation of concern

Use platform landing zones (PLZs) and workload landing zones (WLZs) to separate responsibilities and concerns:

• Platform teams manage PLZs that contain shared services, guardrails, and governance.
• Application teams manage WLZs that isolate environments for deploying workloads.

Deploy each zone in a dedicated AWS accounts and Terraform workspace, ensuring clear boundaries and independent access control.

Policy as code-driven

Sentinel policies and AWS service control policies (SCPs) play critical but distinct roles in governance and compliance. Here is a detailed breakdown of their responsibilities and how they complement each other.

Sentinel policies in HCP Terraform

Sentinel is a policy-as-code framework integrated into HCP Terraform. It enforces fine-grained, pre-deployment rules during the Terraform plan and apply phases. These policies evaluate before Terraform provisions infrastructure, ensuring that only compliant configurations deploy. For example:

• Mandatory tagging
  • Enforce mandatory tags such as Environment, Owner, Cost Center
  • Prevent deployment of untagged resources, crucial for tracking cost, charge-backs and compliance
• IAM policy boundaries
  • Prevent creation of overly permissive IAM Roles or Policies
  • Enforce the principle of least privilege
• Environment-specific rules
  • Apply different rules for development, staging, and production
  • Enforce naming conventions

AWS service control policies

Service control policies (SCP) are part of AWS organizations and define guardrails at the account or organizational unit (OU) level. They restrict what IAM principals (users, roles) can do, regardless of their permissions. SCPs are responsible for:

• Account-level restrictions
  • Prevent use of specific AWS services
  • Enforce region restrictions (e.g., deny creation of resources outside of us-west-2)
• Security controls
  • Deny actions that turn off security services such as AWS GuardDuty, AWS Config or AWS CloudTrail
  • Prevent deletion of critical resources (some of which HCP provisions for the given AWS landing zone)
• IAM Enforcement
  • Deny creation of IAM Users or Roles with wildcard or broad permissions
  • Enforce MFA for console access

Pre-written policies for AWS provide foundational security best practices

AWS and HashiCorp have made available pre-written Sentinel policies that deliver immediate value by simplifying compliance, accelerating adoption for new customers, and reducing operational overhead for existing teams. Consider using these as a solid starting point.

To better understand when and where you can use Sentinel and SCPs, see the following table.

Least privilege access and zero trust

IAM roles, permissions, and access patterns follow the principle of least privilege, part of the AWS Well-Architected Framework. Vault issues short-lived, just-in-time credentials, and federates access using OIDC or IAM Identity Center (SSO). This reduces the attack surface and supports a zero-standing-privileges model.

Modular and reusable Terraform code

Terraform modules encapsulate best practices and standardize deployments across teams. Modules are:

• Version-controlled and stored in a private registry
• Parameterized for flexibility
• Composed to support complex architectures

Centralized orchestration with HCP

HCP Terraform acts as the control plane for all provisioning and updating of infrastructure activities.

Project and workspace isolation strategy

HCP Terraform enables logical separation of infrastructure through workspaces, each with isolated state, variables, and execution context. This isolation is critical for managing different environments (e.g., development, staging, production) or distinct application stacks. It prevents cross-environment interference, reduces the blast radius of changes, and supports parallel development workflows.

When provisioning the AWS platform landing zone, begin by creating a project in HCP Terraform. This project serves as a container for all required workspaces and provides Variable Sets) to reuse across the PLZ workspaces. Each baseline AWS account has a dedicated workspace within this project to maintain clear boundaries and facilitate secure, scalable infrastructure management.

The AWS workload landing zones also use HCP projects to isolates the workspace(s) needed for deploying workloads that different development teams can manage.

To effectively manage infrastructure across multiple AWS accounts and environments, the recommended best practice is to create one HCP Terraform workspace per AWS account. This approach ensures clear separation of concerns and simplifies lifecycle management.

Figure 2 – HCP Project and Workspace Design

Enforce policy sets and variable sets at the workspace or organizational level.

Policy enforcement

With Sentinel, HCP Terraform allows organizations to define and enforce policy-as-code rules that govern infrastructure provisioning. These policies can enforce security, compliance, and operational standards, for example budgetary constraints, encryption requirements on storage resources, disallowing public IPs, or enforcing naming conventions.

Configuration drift detection

Drift detection in HCP Terraform helps identify when the actual state of infrastructure in the cloud diverges from the expected state defined in code. Once identified, HCP drift detection provides recommended steps to remediate discrepancies.

Audit logging

HCP Terraform records every action in detailed audit logs. These logs provide visibility into who did what, when, and why, which is essential for security, compliance, and incident response.

Version control workflow

HCP Terraform supports native integration with version control systems (VCS) such as GitHub, GitLab, Bitbucket, and Azure DevOps.

This is the most seamless option, where Terraform runs are automatically triggered by events like commits to specific branches or the merging of pull requests.

This workflow is ideal for teams that want to couple infrastructure changes with their GitOps practices. Configuration occurs directly in the HCP Terraform UI, where you can link repositories, define workspace triggers, and manage variables securely

State management

Managing Terraform state in HCP is a best-practice approach that addresses both operational efficiency and security, particularly when it comes to handling sensitive infrastructure data. Terraform state files often contain critical information such as resource IDs, IP addresses, and even embedded secrets or credentials. HCP eliminates security concerns by providing built-in encryption at rest and in transit, ensuring the protection of sensitive state data by default.

HCP ensures the protection and isolation of Terraform state from general access. Role-based access control (RBAC) manages access to state files, API tokens, and workspace-level permissions, allowing organizations to enforce the principle of least privilege. This means only authorized users and systems can interact with the state, and all access gets logged for audit.

From a technical governance standpoint, HCP offers a secure, centralized, and versioned state management solution that aligns with enterprise-grade security and compliance requirements. It enforces automatic state locking, detailed audit logging, and seamless collaboration across teams.

Secure and observable by default

Security and observability are foundational pillars of any modern cloud architecture. 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, we provide a robust baseline that supports compliance, threat detection, and operational insight without requiring additional setup.

Landing zones use:

• 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 approach accelerates deployment and gives teams confidence that their environments incorporate security and visibility from day one.

Why it matters

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.

How it works

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 process is seamless and fully automated, requiring no manual credential management.

Key benefits

• Enhanced security with short-lived credentials
  Generate credentials on-demand and expire them quickly, minimizing the risk of misuse or leakage.

• Seamless integration via OIDC
  HCP Terraform authenticates with AWS using OIDC, eliminating the need to store or rotate static credentials.

• Least privilege access
  Each workspace can map to a specific IAM role with narrowly scoped permissions, ensuring Terraform only has access to what it needs and nothing more.

• Simplified credential management
  Teams no longer need to manage, rotate, or distribute AWS access keys. This reduces operational complexity and the risk of human error.

• Built-in observability and audit
  All credential usage gets logged and traceable through AWS CloudTrail, supporting compliance and security audits.

Platform landing zone architecture

The PLZ is the foundational layer of your AWS environment. The platform team designs and maintains it to provide centralized governance, shared services, and security controls that enable consistent and compliant workload deployment across the organization.

This section outlines the HCP architectural components including implementation patterns and best practices for building a scalable and secure PLZ using HCP Terraform as the orchestrator.

Account vending

Account vending is the automated provisioning of AWS accounts within an organizational structure. It ensures the secure and consistent creation of new accounts, with the appropriate guardrails in place.

Key principles:

• Use Terraform modules to automate account creation via the AWS organizations API.
• Assign each account to the appropriate Organizational Unit (OU) (e.g., Security, Shared Services, Dev, Prod).
• Apply service control policies at the OU level to enforce baseline security and compliance.
• Configure CloudTrail, AWS Config, and GuardDuty automatically in each new account.
• Use HCP Terraform workspaces to manage each account lifecycle independently, with policy sets and variable sets applied per workspace.

This approach enables rapid on-boarding of new environments while maintaining centralized governance and visibility.

We use these principles to architect and design the AWS landing zones later in this guide.

HCP configuration and AWS organizational structure

The following HCP project and workspace design uses the design principles outlined earlier in this guide.

Use projects in HCP Terraform as a logical isolation boundary for managing the AWS PLZ. Within this project, each Terraform workspace corresponds to a single AWS account. Organize these accounts into AWS Organizational Units (OUs). Each workspace maintains its own Terraform state, variable sets, and VCS integration. This structure supports delegated administration, policy inheritance via SCPs, and environment-level isolation.

Multiple deployment environments

Create a second HCP project to contain all deployed workloads. Map each workload to an HCP workspace.

Use the Workloads OU to group AWS accounts that host application workloads. To enforce environment-level isolation and governance, create sub-OUs such as Dev, Test, and Prod under the Workloads OU. Each sub-OU contains one or more AWS accounts, each managed by a dedicated HCP workspace. This structure enables environment-specific policy enforcement, cost tracking, and access control.

Root
└── Workloads OU
    ├── Dev OU
    │   ├── App1-Dev Account (App1-Dev HCP Workspace)
    │   └── App2-Dev Account (App2-Dev HCP Workspace)
    ├── Test OU
    │   ├── App1-Test Account (App1-Test HCP Workspace)
    │   └── App2-Test Account (App2-Test HCP Workspace)
    └── Prod OU
        ├── App1-Prod Account (App1-Prod HCP Workspace)
        └── App2-Prod Account (App2-Prod HCP Workspace)

There are multiple benefits of having this structure.

1. Blast radius reduction
   Isolating environments in separate accounts ensures that issues in dev or test do not impact production.

2. Environment-specific guardrails
   Apply stricter Service Control Policies (SCPs) in Prod OU (e.g., deny use of unapproved services, enforce encryption) while allowing more flexibility in Dev OU.

3. Cost allocation and budgeting
   Use account-level billing to track and optimize costs per environment.

4. Access control
   Assign different IAM roles and permissions per OU. For example:

   • Developers: Full access in Dev, read-only in Prod
   • QA: Full access in Test
   • Ops: Admin access in Prod

5. Audit and compliance
   Easier to enforce and audit compliance in production environments without interference from development activities.

   • AWS service control policies attach to the OU.
   • Sentinel policies scope at the HCP workspace and provide multi-layered governance.

HashiCorp Vault integration

As part of the HCP orchestration layer, HCP Vault plays a critical role in securing and automating the provisioning of AWS landing zones. Vault integrates seamlessly with HCP Terraform workspaces, enabling dynamic secrets management, just-in-time access, and policy-based credential issuance across all AWS accounts and environments.

When a new AWS account provisions via Terraform, Vault can automatically configure and issue short-lived AWS STS credentials scoped to that account's IAM roles, ensuring least-privilege access from day one. This eliminates the need for long-lived credentials and supports a zero-standing-privileges model. Vault injects secrets into CI/CD pipelines at runtime, enabling secure, automated deployments without exposing sensitive data in code or configuration files. By embedding Vault into the orchestration workflow, organizations can enforce consistent security policies, reduce operational risk, and accelerate infrastructure delivery across their AWS Landing Zones

Dynamic secrets for AWS

Configure the AWS secrets engine to dynamically generate short-lived STS credentials for each AWS account provisioned via HCP Terraform. Map Vault roles to IAM roles scoped to the specific environment (e.g., dev, test, prod) and enforce TTLs appropriate to the sensitivity of the environment.

Just-in-time access

Use Vault's identity-based access model to issue ephemeral credentials only when needed. Integrate with IAM Identity Center (SSO) or OIDC to federate identity and enforce access policies based on user roles and environment context.

Define workspace-specific Vault roles and policies

For each HCP Terraform workspace (which maps to a single AWS account), create corresponding Vault roles and policies. These should enforce least-privilege access and align with the account's OU (e.g., stricter policies for Prod OU than Dev OU).

Secrets injection into CI/CD pipelines

Configure Vault Agent or environment variable injection to deliver secrets into CI/CD pipelines in AWS CodePipeline at runtime. Store secrets in environment-specific paths (e.g., secret/dev/app1) and restrict access using Vault policies.

Vault audit logging strategy

To support enterprise-grade compliance and observability, integrate Vault audit logging with centralized logging systems. Vault supports multiple audit backends, including file, syslog, and socket. For HCP Vault, audit logs can stream to external systems via supported integrations.

Implementation

• Enable audit logging at the Vault cluster level.
• Forward logs to a centralized SIEM, AWS CloudWatch Logs using a log forwarder.
• Include audit events such as token creation, secret access, and policy changes.
• Use log filters and alerts to detect anomalous access patterns or policy violations.

This ensures traceability of all Vault interactions and supports incident response and compliance audits.

Vault namespaces for multi-tenancy

For organizations using HCP Vault with multiple teams or environments, Vault namespaces provide logical isolation and delegation of administrative control.

Implementation

• Create a namespace per AWS Organizational Unit (OU) or environment (e.g., /dev, /prod, /shared-services, /networking, /identity etc.).
• Delegate Vault administration to platform or application teams within their respective namespaces.
• Apply policies, secrets engines, and auth methods independently within each namespace.

Namespaces enhance security, simplify policy management, and support scalable multi-team operations.

Networking and connectivity

HashiCorp virtual network

When deploying HCP services in AWS, always provision a HashiCorp virtual network (HVN) and establish private connectivity using AWS PrivateLink or AWS Transit Gateway. This ensures that traffic between your AWS VPC and HCP services like Vault or Consul remains secure, low-latency, and isolated from the public internet. Configure routing and security groups to allow only necessary traffic and align HVN CIDR blocks with your existing IP address management strategy to avoid conflicts. This approach enhances security, simplifies compliance, and follows AWS and HashiCorp-recommended network architecture patterns.

Hub and spoke VPC architecture

The Platform Landing Zone (PLZ) is responsible for establishing the foundational network architecture that supports secure, scalable, and governed connectivity across all AWS accounts and environments. A key design pattern implemented within the PLZ is the Hub and Spoke VPC Architecture, which centralizes shared services and network control in a Hub VPC, while enabling isolated workload deployments in Spoke VPCs across multiple AWS accounts.

Core design

Hub VPC (deployed in the PLZ networking or shared services account)

• Host centralized services such as NAT gateways, transit gateway (TGW), DNS resolvers, and VPC endpoints.
• Act as the egress point for internet-bound traffic from spoke VPCs.
• Optionally include centralized inspection layers (e.g., AWS Network Firewall).

Spoke VPC (deployed in WLZs)

• Create per application or environment (e.g., dev, test, prod).
• Connect to the hub via TGW attachments.
• Do not configure direct internet access; route all egress through the hub.

Implementation

• Provision the Hub VPC in the HCP networking workspace
  • Use Terraform modules to deploy the hub VPC in the dedicated plz-networking AWS account and corresponding HCP workspace.
  • Include subnets for TGW attachments, NAT gateways, and VPC endpoints (e.g., S3, DynamoDB).
  • Enable VPC Flow Logs and GuardDuty for visibility and threat detection.
• Deploy and configure transit gateway in the HCP shared services workspace
  • Provision TGW in the plz-shared-services AWS account and share it with spoke accounts using AWS RAM.
  • Attach the hub and all spoke VPCs to the TGW.
  • Use TGW route tables to control traffic flow between VPCs and to/from on-premises networks.
• Standardize spoke VPC creation
  • Use reusable Terraform modules to provision Spoke VPCs in workload accounts.
  • Ensure each spoke VPC:
    • Has private subnets only.
    • Routes outbound traffic through the Hub's NAT gateway.
    • Uses TGW for east-west communication with shared services.
• Centralize egress and inspection
  • Route all internet-bound traffic from spoke VPCs through the hub.
  • Deploy centralized inspection (e.g., AWS Network Firewall) in the hub for compliance and threat detection.
  • Use Gateway Load Balancer or Traffic Mirroring for advanced inspection scenarios.
• Enable shared services access
  • Deploy services like Active Directory, CI/CD runners, and logging agents in the shared services AWS account VPC.
  • Use VPC endpoints and TGW routing to allow secure access from spoke VPCs.
• Enforce network segmentation and governance
  • Use TGW route tables and security groups to isolate environments (e.g., Dev cannot access Prod).
  • Apply SCPs to prevent unauthorized VPC peering or direct internet gateway usage in Spoke accounts.
  • Monitor and audit all network activity centrally from the PLZ.

Security and monitoring

Security and observability are foundational pillars of the PLZ architecture. This section outlines how to implement a secure, audited, and observable AWS environment using HCP as the orchestration layer, in alignment with the design principles of least privilege, policy as code, and infrastructure as code.

Centralized security controls via Terraform and HCP

Provision and manage all security services and configurations using Terraform modules orchestrated by HCP Terraform workspaces. Each security-related AWS account (e.g., plz-security) maps to a dedicated HCP Workspace, ensuring isolation and lifecycle control.

Key HCP Configuration

• Create a plz-security workspace under the PLZ project
• Apply variable sets for region, account ID, and security configurations
• Attach Sentinel policies to enforce encryption, tagging, and IAM boundaries

AWS Services Provisioned

• AWS GuardDuty - Enable in all accounts and aggregate findings in the security account.
• AWS Config - Enable across all accounts with centralized delivery to an S3 bucket in the security account.
• AWS Security Hub - Enable and aggregate findings for CIS, PCI, and custom controls.
• AWS CloudTrail - Enable organization-wide trails with logs delivered to a centralized S3 bucket and optionally to CloudWatch Logs.

Implement monitoring using a combination of AWS-native services and Terraform-managed configurations to ensure full visibility into infrastructure and application behavior.

AWS services and configuration

AWS CloudWatch

• Enable metrics and alarms for all critical services (e.g., EC2, RDS, Lambda).
• Use metric filters to detect anomalous behavior (e.g., unauthorized API calls).
• Create dashboards for platform and application teams.

AWS CloudWatch logs

• Centralize logs from CloudTrail, VPC Flow Logs, and application logs.
• Use log groups with retention policies and encryption enabled.

VPC Flow Logs

• Enable for all VPCs and route logs to CloudWatch or S3.
• Use for traffic analysis and anomaly detection.

AWS Config rules

• Deploy managed and custom rules to enforce compliance (e.g., encryption, public access).
• Aggregate compliance data in the security account

SIEM integration using AWS native services

To support enterprise-grade security operations, integrate AWS-native logging and monitoring services with a Security Information and Event Management (SIEM) platform. The recommended pattern is as follows:

• Centralized S3 Buckets
  • Store CloudTrail, Config, and VPC Flow Logs in versioned, encrypted S3 buckets.
  • Use S3 Event Notifications or AWS Lambda to forward logs to the SIEM.
• Amazon Kinesis Data Firehose
  • Stream logs from CloudWatch Logs to third-party SIEMs (e.g., Splunk, Datadog, Elastic)
  • Use transformation Lambda functions to normalize log formats.
• AWS OpenSearch Service
  • Optionally deploy OpenSearch in the Shared Services account for log indexing and visualization.
  • Integrate with Kibana or Grafana for dashboards and alerting.

Sentinel policies

Within the Platform Landing Zone (PLZ), Sentinel policies serve as a critical control mechanism to enforce security, compliance, and operational standards across all AWS accounts and environments.

From an AWS PLZ perspective, Sentinel policies:

• Enforce baseline security controls across all Terraform workspaces.
• Ensure compliance with organizational standards before provisioning infrastructure.
• Prevent mis-configuration and non-compliant deployments at the plan and apply stages.
• Support environment-specific rules (e.g., stricter policies in production).

These policies evaluate during the Terraform plan and apply phases in HCP Terraform, ensuring that violations get caught before Terraform makes changes to infrastructure.

Pre-written Sentinel policies

HashiCorp and AWS collaborated to provide a curated set of pre-written Sentinel policies to accelerate your adoption of HCP, and ensure secure, consistent configurations.

These policies offer immediate value by:

• Enforcing best practices aligned with both HashiCorp and AWS standards
• Reducing time-to-value by eliminating the need to write policies from scratch
• Improving governance and compliance across your infrastructure
• Providing a solid and extendable foundation for your own custom policies

We strongly recommend using these pre-built policies as a starting point, and then layering in any organization-specific rules to meet your unique requirements.

By using these policies, you're not just saving time, you're aligning with proven patterns that help ensure secure, scalable, and reliable infrastructure deployments.

Policy storage and management

Version control all Sentinel policies in a dedicated Git repository alongside documentation and test cases.

Manage policy using policy sets in HCP Terraform, which allow for grouping and applying to specific workspaces or projects.

Policy application strategy

• Define policy sets in HCP Terraform
  • Create policy sets for each environment or OU (e.g., plz-core, workloads-prod, workloads-dev).
  • Assign relevant Sentinel policies to each set.
• Attach policy sets to workspaces
  • Use HCP UI or API to attach policy sets to the appropriate workspaces.
  • For example, attach plz-core policy set to plz-networking, plz-security, and plz-shared-services workspaces.
• Policy evaluation
  • Policies are automatically evaluated during terraform plan and apply.
  • Violations block the run and provide detailed feedback to the user.
• Policy testing and maintenance
  • Use the Sentinel CLI to test policies locally before deployment.
  • Maintain a changelog and test suite for each policy to ensure reliability.

Packer for hardened images

Use HCP Packer to build, manage, and distribute hardened Amazon Machine Images (AMIs) and container base images. These images are foundational to ensuring that compute resources across PLZs and WLZs are secure, consistent, and production-ready from the moment they provision.

Image pipeline workflow with HCP Packer

Author and store Packer templates in a VCS

Define Packer templates using HCL2 and store them in a version-controlled Git repository. These templates should include provisioning logic for installing required packages, applying security hardening, and configuring monitoring or logging agents.

Register image pipelines in HCP Packer

Use HCP Packer to register image builds as part of a centralized image pipeline. Each pipeline tracks metadata such as image version, build timestamp, source template, and compliance status. This metadata is automatically available to downstream consumers via HCP image channels.

Integrate image building with CI/CD

Trigger image builds using AWS-native CI/CD services (e.g., CodePipeline, CodeBuild) or external runners. During the build process:

• Use Vault to inject temporary secrets or credentials required for provisioning.
• Ensure that no secrets persisted in the final image.
• Validate the image against security benchmarks or internal compliance checks.

Promote and distribute images

Promote validated images to a stable channel in HCP Packer (e.g., production, staging).

• HCP Packer automatically tracks AMIs associations with each channel.
• Share AMIs across AWS accounts using AWS Resource Access Manager (RAM) or publish them to a centralized account (e.g., plz-shared-services).

Use images in HCP Terraform workspaces

In HCP Terraform, reference the latest approved AMI from HCP Packer using the hcp_packer_iteration and hcp_packer_image data sources.

• This ensures that all infrastructure provisioned via Terraform uses the most up-to-date and validated image.
• Sentinel policies can enforce that only images from approved HCP Packer channels get used in production environments.

By integrating HCP Packer into the landing zone architecture, platform teams deliver secure, consistent, and compliant images to application teams, while maintaining full control of the image lifecycle and image use across all AWS accounts and environments.

Workload landing zone architecture

The WLZ represents the application-centric layer of the AWS landing zone architecture. Rather than a single monolithic environment, organizations should implement multiple WLZs to support different business units, application domains, or operational requirements. Each WLZ is a dedicated, isolated AWS environment where application teams can deploy and manage workloads independently. This is typically structured as one or more AWS accounts. This approach provides a smaller blast radius, environmental isolation, and delegated administration, while still inheriting centralized governance, security controls, and shared services provisioned by the PLZ.

Multiple WLZs allow organizations to scale their cloud footprint in a modular and secure manner. Create separate WLZs for regulated workloads, customer-facing applications, internal tools, and different subsidiaries within a larger enterprise. Manage each WLZ through its own set of HCP Terraform workspaces, mapped to specific AWS accounts and environments (e.g., App1-Dev, App2-Prod). This structure supports GitOps workflows, policy-as-code enforcement via Sentinel, and least privilege access through Vault and IAM, ensuring that each workload operates within its own secure, compliant, and audited boundary.

Infrastructure provisioning and governance

Use Terraform modules to provision all infrastructure within a WLZ. Use a dedicated Terraform workspace for each environment (e.g., App1-Dev, App1-Prod) to maintain isolated Terraform state, variable sets, and VCS integration. This supports GitOps workflows, enabling the management of infrastructure changes through pull requests and version-controlled code.

Attach Sentinel policies to each workspace to enforce environment-specific rules, such as mandatory tagging, encryption, IAM boundaries, and naming conventions. These policies evaluate during the terraform plan phase, ensuring that only compliant infrastructure deploys. Apply AWS SCPs at the OU level to provide an additional layer of enforcement, restricting the use of unapproved services or regions.

Workload application deployment with CI/CD

Use AWS-native CI/CD services such as AWS CodePipeline and AWS CodeBuild to deploy application workloads in the WLZ. Each application has its own pipeline, which triggers by changes to source code repositories (e.g., GitHub or AWS CodeCommit). These pipelines execute build and deployment steps, and optionally invoke HCP Terraform to provision or update infrastructure components.

Integrate HCP Vault into the CI/CD process to manage secrets securely. During pipeline execution, use Vault to inject short-lived secrets such as database credentials or API tokens into the build environment using environment variables or Vault Agent. Scope secrets to the environment (e.g., secret/prod/app1) and automatically expire them after use.

Pipeline architecture using AWS native services

We recommend using AWS CodePipeline as the orchestration engine and AWS CodeBuild as the build and deployment executor. These services are fully managed, scalable, and integrate natively with AWS Identity and Access Management (IAM), CloudWatch, and other AWS services.

Create a dedicated pipeline for each application or workload deployed into a WLZ. Changes to source code repositories (e.g., GitHub or AWS CodeCommit) trigger these pipelines and execute Terraform plans and applies via HCP Terraform workspaces.

Key Components:

• AWS CodePipeline - Defines the stages of the CI/CD process (e.g., Source, Build, Deploy).
• AWS CodeBuild - Executes Terraform commands and application deployment scripts.
• HCP Terraform - Manages infrastructure provisioning and policy enforcement.
• HCP Vault - Injects secrets and credentials securely at runtime.

This architecture ensures automated, repeatable, and governed infrastructure and application deployments.

HCP Terraform integration

HCP Terraform serves as the control plane for all infrastructure provisioning activities. Each AWS account maps to a dedicated HCP Terraform workspace, and each workspace integrates with a version control system (VCS) such as GitHub or GitLab.

1. Source Control Integration - Terraform configurations store in a Git repository. Commits to specific branches trigger runs in HCP Terraform.
2. Workspace Triggers - HCP Terraform workspaces configure to automatically run terraform plan and apply when changes get pushed.
3. Policy Enforcement - Sentinel policies evaluate during the plan phase to ensure compliance before any changes apply.
4. State Management - Terraform state gets securely stored and versioned in HCP, with encryption and RBAC enforced by default.

This integration supports GitOps workflows, enabling teams to manage infrastructure changes through pull requests and code reviews, while maintaining full audit ability and compliance.

Pipeline security

The PLZ provisions and governs the foundational security services, while Vault and Sentinel provide runtime and policy-based controls.

HCP Vault integration

• Dynamic secrets - Vault issues short-lived AWS STS credentials to CodeBuild jobs, scoped to the least privilege required for the task.
• Secrets injection - Secrets (e.g., database passwords, API keys) inject into the build environment using Vault Agent or environment variables.
• Environment isolation - Secrets store in environment-specific paths (e.g., secret/prod/app1) and access controls via Vault policies.
• Audit logging - All secret access logs and forwards to a centralized SIEM for monitoring and compliance.

IAM and OIDC federation for pipelines

• CodeBuild assumes IAM roles using OIDC federation, eliminating the need for long-lived credentials.
• IAM roles define with fine-grained permissions and scoped to specific actions and resources.

This security model supports a zero-standing-privileges approach, ensuring that access grants only when needed and only for the duration required.

Vault for secrets injection into AWS pipelines at runtime

In this architecture, HCP Vault delivers secrets to AWS-native CI/CD pipelines during runtime. When a pipeline triggers, AWS CodePipeline orchestrates the workflow and invokes AWS CodeBuild to execute the build and deployment steps. At this point, Vault injects the necessary secrets into the build environment without ever exposing them in source code or configuration files.

Use Vault's AWS secrets engine to generate short-lived AWS STS credentials or retrieve static secrets (e.g., database passwords, API tokens) from environment-specific paths (e.g., secret/prod/app1). Authenticate CodeBuild to Vault using an IAM role mapped to a Vault role. This authentication is typically handled via Vault Agent or direct API calls using the AWS IAM auth method. Once authenticated, Vault issues a token scoped to the required secrets, and makes the secrets available the build environment as environment variables or temporary files.

This process ensures that secrets are only accessible during the execution of the pipeline and are automatically revoked or expire after a short TTL. It supports zero-standing-privileges, least privilege access, and audit, as Vault logs all secret access events and can forward events to a centralized SIEM. This model eliminates the need for hard-coded credentials and reduces the risk of secret leaks in CI/CD workflows.

Recommended infrastructure deployment patterns

• Multi-stage GitOps pipelines - Trigger an infrastructure change by a commit or pull request. Terraform plans the changes. Sentinel evaluates the change to enforce compliance. Proceed to applying the change, either automatically (in non-prod) or after manual approval (in prod).
• Plan/Apply separation - Separate the plan and apply phases in production environments with a manual approval gate. This supports change control and audit.
• Environment-specific workspaces - Use dedicated HCP Terraform workspaces for each environment (e.g., plz-networking-dev, plz-networking-prod) to enforce isolation and reduce blast radius.
• Policy as code enforcement - Attach Sentinel policies to workspaces via policy sets, ensuring that infrastructure adheres to tagging standards, encryption requirements, IAM boundaries, and naming conventions.
• Secrets management with Vault - Use Vault to inject secrets required for provisioning (e.g., provider credentials, API tokens) at runtime, with short-lived credentials scoped to the workspace and environment.

Recommended application/workload deployment patterns

• CodePipeline orchestration - Define pipelines that include stages for source retrieval, build, test, and deploy. Use CodeBuild to execute application builds and trigger HCP Terraform runs when infrastructure needs to change.
• Secrets management with Vault - Authenticate CodeBuild to HCP Vault during the build or deploy stage using an IAM role. Issue short-lived secrets (e.g., database credentials, API keys) from Vault into the runtime environment as environment variables or files. Scope secrets to the environment (e.g., secret/prod/app1) and automatically expire after use.
• Blue/green and canary deployments - For high-availability applications, use deployment strategies that allow the deployment of new versions alongside existing ones. Gradually shift traffic using Route 53, ALB target groups, or ECS deployment strategies, and roll back if you detect issues.
• Automated testing and validation - Integrate unit tests, integration tests, and security scans into the pipeline. Use CodeBuild or third-party tools to validate application behavior and compliance before promotion.
• Environment isolation and least privilege - Run each workload environment (dev, test, prod) in a separate AWS account and manage it with a dedicated Terraform workspace. Use IAM roles and Vault policies to enforce least privilege access to secrets and infrastructure.

Getting started

This section provides a structured, high-level roadmap for implementing the AWS landing zone architecture using Terraform, orchestrated by HCP.

Provision the AWS organization and OU structure using HCP Terraform

The foundational step in building your AWS Landing Zone is to provision your AWS organization, including the Organizational Units (OUs) and Service Control Policies (SCPs) that define your governance model. Automate this entire process using Terraform modules, executed through HCP Terraform workspaces.

• Set up a Git repository to store your Terraform code for managing the AWS organization. This repository should include:
  • A root module for the AWS organization and account structure.
  • Reusable modules for creating OUs, SCPs, and baseline accounts (e.g., plz-networking, plz-security, plz-shared-services).
  • Version control and branching strategies to support GitOps workflows.
• Create a dedicated HCP Terraform project (e.g., plz-core) and initialize a workspace (e.g., plz-root) to manage the AWS organization
  • Configure the workspace with VCS integration pointing to your Git repository.
  • Apply variable sets for region, organization ID, and SCP definitions.
  • Attach Sentinel policies to enforce tagging, naming conventions, and IAM boundaries.
• Use Terraform to provision:
  • The AWS organization root structure.
  • OUs for Platform, Workloads, and sub-OUs for Dev, Test, and Prod.
  • SCPs to enforce region restrictions, deny unapproved services, and enforce security controls.

This step ensures governance of your AWS environment from the start, with a scalable and secure organizational structure that supports the rest of the landing zone architecture.

Set up HCP Terraform as the orchestration layer

• Create a project in HCP Terraform to represent your PLZ.
• For each AWS account (e.g., plz-networking, plz-security, plz-shared-services), create a dedicated HCP Workspace.
• Configure each workspace with:
  • VCS integration (e.g., GitHub, GitLab)
  • Variable sets for region, account ID, and environment
  • Policy sets for Sentinel enforcement (e.g., tagging, encryption, IAM boundaries)
• Use dynamic provider credentials via OIDC to securely authenticate Terraform to AWS without static credentials.

Deploy the platform landing zone

Using reusable Terraform modules, provision the foundational infrastructure:

• Networking: Deploy a hub VPC with Transit Gateway, NAT Gateways, and VPC Endpoints.
• Security: Enable GuardDuty, Security Hub, AWS Config, and centralized logging.
• ShareServices: Deploy services such as Active Directory, CI/CD runners, and ECR.
• Identity: Configure IAM Identity Center (SSO), permission sets, and federated access.

Deploy each of these components in a dedicated HCP workspace, mapped to a dedicated AWS account and governed by Sentinel policies.

Implement account vending and workload landing zones

After provisioning the AWS organization and foundational OUs, automate the creation and configuration of WLZs. Use account vending principles, which provision new AWS accounts in a consistent, secure, and policy-compliant manner. We recommend using AWS Account Factory for Terraform (AFT), which integrates seamlessly with Terraform and supports GitOps workflows.

When to set up AFT

Set up AFT immediately after provisioning the AWS organization and OUs, and before deploying any workload-specific infrastructure. This ensures that all new account creation has the appropriate guardrails, SCPs, baseline configurations, and HCP Terraform workspace mappings.

How to set up AFT

1. Deploy AFT in a dedicated management account:

   • AFT is typically deployed in a centralized management account within the platform OU.
   • Use the official AWS AFT Terraform module to deploy the AFT framework.
   • Configure AFT to integrate with your version control system (e.g., GitHub, CodeCommit) for account request and customization repositories.

2. Configure AFT repositories:

   • Account requests repository: Stores JSON or YAML files that define new account requests (e.g., account name, email, OU, tags).
   • Account customizations repository: Contains Terraform code to apply baseline configurations to new accounts (e.g., IAM roles, logging, networking).
   • Global customizations repository (optional): Applies shared configurations across all accounts.

3. Integrate AFT with HCP Terraform:

   • For each new account provisioned by AFT, create a corresponding HCP Terraform workspace.
   • Use automation (e.g., GitHub Actions, Lambda, or Terraform automation pipelines) to:
     • Register the new account in HCP.
     • Assign the correct variable sets and policy sets.
     • Trigger initial provisioning runs (e.g., VPC, IAM, GuardDuty).

4. Provision workload landing zones:

   • Use AFT to create accounts under the appropriate sub-OUs (Dev, Test, Prod) within the workloads OU.
   • Each account becomes a WLZ with management via a dedicated Terraform workspace.
   • Apply environment-specific Sentinel policies and Vault configurations to enforce security and compliance.

5. Baseline infrastructure deployment:

   • After account creation, use HCP Terraform to deploy baseline infrastructure in each WLZ:
     • VPCs (spoke architecture)
     • IAM roles and permissions
     • Logging and monitoring agents
     • Vault secrets engines and roles

Conclusion

By adopting the architecture and practices outlined in this guide organizations can fully automate the lifecycle of their AWS Landing Zones. This enables consistent, secure, and scalable provisioning of both platform and workload landing zones (PLZs and WLZs) across multiple accounts and environments. Because each environment is modular, isolated, and managed through infrastructure as code, you can treat them as ephemeral and decommission them when no longer needed. This not only enhances agility and governance but also drives cost efficiency by eliminating idle or underutilized resources.

Appendices

Glossary of terms