Building an AWS Landing Zone: Setting Your Cloud Infrastructure Up for Success

Introduction

In the ever-evolving landscape of cloud computing, establishing a robust foundation for your AWS environment is crucial. A landing zone serves as the bedrock for your cloud infrastructure, providing a structured approach to organizing and managing resources efficiently. In this blog post, we delve into the core concepts of a landing zone as well as an example architecture that follows best practices described in AWS’s Well Architected Framework.

What is a Landing Zone?

At its essence, a landing zone is a structural framework that segregates AWS accounts based on their intended purpose. The primary objective is to compartmentalize responsibilities, enhance security, and streamline management processes. Each AWS account within the landing zone is designated for a specific function, creating a modular architecture that is easier to scale and adapt to changes in organizational structure. Individual accounts also enable precise tracking of costs associated with specific functions or projects.

Core Components Within a Landing Zone

1. Organizational Management Account:
   1. Is responsible for overseeing all aspects of the AWS organization such as service control policies, tag policies, 
   2. Delegates service administration to specialized accounts, like Identity Center and Security Hub.
2. Identity Management Account
   1. Centralizes identities for all accounts.
   2. Leverage groups to grant specific access, promoting the principle of least privilege.
3. Security Account
   1. Handles security tools, logging, and centralizes CloudTrail logs from all accounts and regions.
   2. Hosts security appliances
4. Networking Account
   1. Implements a central networking hub using the hub-and-spoke model, simplifying network management and improving scalability
   2. Routes all traffic through the hub, enabling security appliances in the dedicated Security account to inspect and monitor network traffic.
5. DevOps Account
   1. Serves as a centralized hub for managing application and infrastructure deployment pipelines, as well as CI/CD runners.
6. Workload Accounts
   1. Create individual accounts for each environment (e.g., development, test, production).
   2. Shared resources live in their own accounts, and securely shared to the other accounts for the workload

Example Landing Zone

Below is an example landing zone, consisting of 8 different accounts. In this example AWS environment, Terraform is used to manage infrastructure and is deployed through the chosen Git providers CI/CD tool.

AWS Organization Account

This account is the AWS Organizations admin account. It delegates Identity Center administration to the Identity account, Security Hub and Config administration to the Security account, and Cloudformation Stacksets administration to the Devops Tooling account. The only purpose of the Organization account is to manage tasks related to AWS Organizations, such as Organization Unit (OU) management with service control and tag policies, as well as consolidating billing for all accounts.

Identity Account

This account is the Identity account for the Organization. It administers IAM Identity Center, and all users and groups for the entire Organization are managed in this account. The Git provider of choice authenticates into the AWS environment through an OIDC connection in this account for all CI/CD purposes, and this OIDC provider has permissions to assume a deployment IAM role with the minimum necessary permissions in each account to manage resources. 

Security Account

This is the Security account for the Organization. It’s the service administrator for Config and Security Hub. It manages Config rules for the entire Organization, as well as aggregates all Config results in one spot. It also manages Security Hub subscriptions and reports on compliance for all accounts in the Organization. Finally, all Cloudtrail logs in the Organization are sent to a centralized S3 bucket in this account, creating one spot to query logs in the event of an audit.

Devops Tooling Account

This is the Devops Tooling account for the Organization. It hosts all infrastructure needed for a private CI/CD runner. All activities related to Terraform are managed in this account, such as execution and state storage. Any resources in any account that need to be deployed through Cloudformation are done so through Cloudformation Stacksets managed in this account. 

Networking Hub Account

This is the Networking Hub account. This account manages all Route53 hosted zones and DNS records for the Organization. It also serves as a hub that all VPCs in other accounts are peered to, and routes traffic between VPCs if needed, typically from the devops VPC to VPCs in the workload accounts. It also handles routing traffic between regions.

Dev/QA/Prod Accounts

These are the accounts that host the application. The dev account is used to develop new features for the application. QA is used as a mirror of prod to test those new features, and prod is the environment that serves the clients of the organization. Networking infrastructure is deployed across two regions in each account for disaster recovery purposes. Resources that host the application are deployed in the primary region, and may or may not be deployed in the secondary region depending on recovery time objective requirements. Terraform assumes an IAM role in each of these accounts from the devops account to manage and deploy cloud infrastructure.

Conclusion

In the dynamic landscape of cloud computing, constructing a robust foundation for your AWS environment is pivotal for sustained success. The concept of a Landing Zone serves as the cornerstone for a resilient, secure, and scalable cloud infrastructure. By implementing these principles and best practices, organizations can navigate the complexities of cloud computing with confidence, setting the stage for innovation, growth, and ongoing success.