Building an AWS Landing Zone with Terraform

Designing and deploying a multi-account AWS Landing Zone focused on governance, security and centralized management

AWS Landing ZoneAWS OrganizationsAWS IAM Identity CenterAWS CloudTrailAWS ConfigAWS IAMAWS S3AWS BudgetsAWS BackupAWS Access AnalyzerSCPs

Introduction

As AWS environments grow, managing multiple projects and environments from a single account can become difficult to control. Permissions, security, auditing, costs, and resource management start becoming increasingly difficult to manage as the number of workloads increases.

This project focuses on building an AWS Landing Zone from scratch using Terraform.

The objective is to create a structured foundation where different AWS environments can be deployed while keeping account separation, centralized access, security controls, auditing, compliance, cost management, and backup capabilities under control.

The result is a local implementation of the core principles behind an AWS Landing Zone, designed to serve as the foundation for integrating additional AWS workloads in future projects.

What is a Landing Zone?

An AWS Landing Zone provides a structured foundation for managing AWS environments at scale.

Instead of placing every workload inside a single AWS account, resources can be distributed across multiple accounts and organizational units according to their purpose. This provides several advantages:

Isolation between environments.
Centralized governance.
Better security boundaries.
Centralized auditing.
Controlled access.
Improved cost management.
A foundation for future workloads.

The architecture created in this project follows these principles while keeping the implementation focused and understandable.

AWS Organizations

The first step was creating the AWS Organization and defining the initial account structure.

The organization was divided into different Organizational Units (OUs), allowing accounts to be grouped according to their role.

The initial structure is composed of:

Security OU
Development OU
Production OU

Each OU contains the corresponding AWS account.

This separation provides an initial security and governance boundary between environments.

Service Control Policies

Service Control Policies were introduced to establish organization-wide restrictions.

The Landing Zone currently includes SCPs for:

Restricting AWS operations outside the approved region.
Preventing modifications to AWS CloudTrail.
Preventing modifications to AWS Config.
Protecting the AWS Organization itself.

These policies provide guardrails that cannot simply be bypassed by granting additional IAM permissions inside an account.

AWS IAM Identity Center

Once the account structure was created, centralized access management was implemented using AWS IAM Identity Center.

A dedicated CloudEngineers group was created and associated with the appropriate Permission Set and AWS account assignment.

This approach provides centralized authentication and authorization while avoiding the need to create and manage individual IAM users for normal access to the AWS accounts.

Infrastructure

Once the organizational structure and access management were established, the next step was implementing the infrastructure required for security, auditing, compliance, cost management, and recovery.

The main components are:

AWS CloudTrail
AWS Config
Amazon S3
AWS IAM Access Analyzer
AWS Budgets
AWS Backup
Resource tagging

AWS CloudTrail

AWS CloudTrail was configured as an organization-wide trail to centralize the auditing of AWS API activity.

The configuration includes:

Organization Trail.
Multi-region logging.
Global service events.
Log file validation.
Centralized S3 storage.
S3 encryption.
S3 versioning.
Lifecycle management.

The architecture centralizes CloudTrail logs in an S3 bucket, providing a common location for auditing activity across the organization.

AWS Config

AWS Config was introduced to continuously evaluate the configuration of AWS resources against predefined rules.

While CloudTrail answers the question of what happened, AWS Config helps answer whether the current configuration complies with the expected security and governance requirements.

The Landing Zone includes Config Rules covering areas such as:

S3 security.
IAM security.
EC2 security.
Security Groups.
RDS configuration.
DynamoDB configuration.
ECR security.

AWS IAM Access Analyzer

AWS IAM Access Analyzer was introduced to identify resources that can be accessed from outside the AWS account.

This provides an additional security control for detecting unintended external access.

The Analyzer complements the IAM and AWS Config controls already implemented in the Landing Zone.

AWS Budgets

AWS Budgets provides the initial cost management layer for the Landing Zone.

A monthly budget was configured with notifications when predefined cost thresholds are reached.

The objective is not to provide a complete FinOps platform, but to establish an initial mechanism for detecting unexpected increases in AWS spending.

AWS Backup

AWS Backup was introduced to provide a centralized backup foundation.

The initial implementation contains:

A Backup Vault.
A Backup Plan.
Daily backups.
A 30-day retention period.

At this stage, the plan is intentionally not associated with every workload.

Specific resources will be incorporated into the backup strategy as the projects are progressively integrated into the Landing Zone.

Resource Tagging

A basic tagging strategy was introduced using Terraform default tags.

The initial tags identify:

The management method.
The project.
The environment.
The owner.

This provides a consistent foundation for resource identification, cost allocation, governance, and future automation.

Landing Zone: Local vs Corporate

The objective of this project is not to reproduce a complete enterprise AWS Landing Zone.

Instead, the implementation focuses on understanding and building the fundamental concepts required to create one.

A Corporate Landing Zone would extend this foundation mainly through automation, centralization, scalability and stronger governance.

Compared with the local implementation, a corporate environment would typically introduce:

Automated account provisioning instead of creating and configuring accounts manually.
Centralized security services such as GuardDuty, Security Hub, Inspector and Macie.
Centralized networking, commonly using Transit Gateway and shared network services.
Centralized compliance and monitoring across all AWS accounts.
Advanced IAM governance, integrated with the company’s identity provider and automated permission management.
Automated infrastructure deployment through CI/CD pipelines instead of running Terraform locally.
Centralized FinOps, with more advanced cost allocation, reporting and governance.
Enterprise backup and disaster recovery, potentially including multi-region strategies.
Automated tagging and governance policies applied consistently across accounts.
Account Factory / Control Tower or similar mechanisms to standardize the creation and configuration of new accounts.
Scalability for hundreds of accounts and multiple teams, rather than a small number of accounts supporting a portfolio or laboratory environment.

The key difference is therefore not necessarily the AWS services being used, but how they are managed and operated at scale.

The Local Landing Zone demonstrates the architecture. The Corporate Landing Zone industrializes it.

Challenges & Troubleshooting

One of the main challenges during the implementation was restricting the AWS environment to the eu-south-2 (Spain) region.

An AWS Organizations Service Control Policy (SCP) was implemented to deny operations outside the approved region for the Development and Production environments, while allowing specific global AWS services required for account and organization management.

This introduced an important consideration: not every AWS service is regional, so the SCP had to include exceptions for services such as IAM, Organizations, Route 53, CloudFront, Support and Budgets.

The final configuration provides a regional guardrail while maintaining the functionality of required global AWS services.

Future Improvements

The next step will be to progressively integrate the AWS projects previously developed in this portfolio into the Landing Zone.

This will allow the workloads to benefit from the centralized governance, security, monitoring and cost controls implemented in this project.

As new projects are integrated, the Landing Zone will evolve according to the requirements of each workload.

References

Project Code

You can find the Terraform code used in this project in the following GitHub directory.

View on GitHub