Skip to main content

Build Your Cloud Foundation

To build a reliable infrastructure, we must start with a solid foundation. This guide walks you through the four essential layers of a well-architected AWS landing zone: project governance, multi-account organization, identity and authentication, and network isolation. OceanSoft is the first enterprise onboarded using this pattern; every account ID, email, region, and bucket below is a variable — swap them to onboard any enterprise with the same two ClickOps steps below.

Minimum ClickOps — Two-Step Bootstrap​

Once per enterprise, exactly two manual steps are required. Everything else is Terraform IaC:

  1. Enable AWS IAM Identity Center in your home region (e.g., Sydney ap-southeast-2 for OceanSoft) — sign in to the management account console as root, navigate to IAM Identity Center, click Enable.
  2. Create the S3 Terraform-state bucket — using S3 console or CLI: aws s3api create-bucket --bucket <ACCOUNT_ID>-tfstate-<REGION> (e.g., 111111111111-tfstate-ap-southeast-2). Enable versioning and server-side encryption. This bucket stores the infrastructure state with native file-based locking (use_lockfile = true).

After these two steps, deploy the remaining layers (Organizations, OUs, SSO groups, permission sets, accounts) via Terraform.

Foundation Architecture​

The cloud foundation consists of four sequential layers. Each layer builds on the previous one and can be provisioned using Terraform Infrastructure as Code.

1 Initialize Project and Infrastructure Repository​

Start by creating a GitHub repository to host your infrastructure toolchain and configurations. This repository will contain all Terraform modules, DevContainer configuration, and deployment automation for your AWS landing zone.

Key setup items:

  • Create a GitHub repository with branch protection rules
  • Configure repository collaborators and access policies
  • Set up a Terraform DevContainer for local development
  • Provision an S3 bucket for Terraform state with native locking via use_lockfile = true (DynamoDB-based locking is deprecated as of Terraform 1.10)
The "Big Picture" Overview

2 Provision AWS Organizations and Multi-Account Structure​

Design a scalable account architecture that isolates workloads by function and security domain. AWS Organizations is the control plane for your multi-account structure, enabling centralized billing, service control policies, and account lifecycle management.

Recommended OU structure (based on AWS best practices):

Foundational OUs (required for all organizations):

  • Security OU — Audit, Log Archive, and security tool accounts
  • Infrastructure OU — Networking, Shared Services, and Transit Gateway management

Application OUs (workloads organized by function, not environment):

  • Workloads OU — Production AND non-production accounts for your business applications
  • Sandbox OU — Experimental and learning environments (isolated for compliance)

Production vs. Non-Production Isolation (within Workloads OU):

Within the Workloads OU, isolate production from non-production environments using separate AWS accounts. This ensures that a misconfiguration, compromised credential, or failed deployment in development does not expose production data or cause a production outage.

Recommended account structure (per AWS Organizing Your AWS Environment and AWS Security Reference Architecture):

  • Prod OU (nested under Workloads) — Production accounts only. Attach stricter Service Control Policies to prevent accidental deletion, restrict IAM privilege escalation, and mandate encryption.
  • Non-Prod / SDLC OU (nested under Workloads) — Development, Test, SIT, UAT accounts. More permissive SCPs to enable rapid iteration; developers can create, destroy, and modify resources within quotas.
  • Account isolation: Use one AWS account per environment (dev, test, SIT, UAT, prod). The account boundary is AWS's strongest isolation mechanism—separate accounts prevent blast radius from a compromised credential and enforce independent resource quotas, billing, and audit trails.
  • Data isolation: Keep production data, IAM roles, and networking in production accounts only. Non-production environments should not contain or reference production credentials, encryption keys, or databases.

Benefits (from AWS Benefits of Using Multiple Accounts):

  • Blast radius containment: A developer mistake (e.g., overly permissive security group) affects only non-prod; production remains isolated.
  • Compliance evidence: Separate production and non-production accounts simplify APRA and SOC2 audit trails and demonstrate segregation of duties.
  • Independent quotas and billing: Track non-prod iteration costs separately from production; easier to measure environment-specific spend.
  • Stricter guardrails on Prod: Apply SCPs to the Prod OU that prohibit account deletion, restrict cross-account access, and enforce MFA-protected root usage.

Key concepts:

  • Service Control Policies (SCPs) attach to OUs by function (e.g., Security OU SCPs prevent policy modification; Workloads OU SCPs enforce tagging)
  • This structure aligns with Control Tower and AWS Security Reference Architecture (SRA)
  • Start minimal (e.g., Management, Security, Workloads, Sandbox) and expand as you grow
  • Apply Service Control Policies (SCPs) to enforce guardrails across all accounts
  • Enable CloudTrail organization trails for centralized logging and audit
AWS Organization Architecture

3 Deploy Identity and Single Sign-On​

Set up fine-grained access control for your entire organization using AWS IAM Identity Center (successor to AWS Single Sign-On). Identity Center integrates with external identity providers and enables both human and machine access through IAM roles.

Infrastructure as Code Deployment (after the two-step ClickOps bootstrap above):

Deploy the three IaC root modules in sequence. All sources are pinned to a stable SHA commit: git::https://github.com/nnthanh101/terraform-aws.git//modules/<name>?ref=978f8fc70e0c54975fd0ff6c19ae7dd972cad0ce

  1. bootstrap → S3 state bucket with use_lockfile = true and encrypt = true (native file-based locking; DynamoDB deprecated as of Terraform 1.10)
  2. accounts → AWS Organizations with OUs (Security, Infrastructure, Workloads) + vend workload accounts (b2b-prod, b2b-non-prod) under Workloads OU
  3. identity → IAM Identity Center groups, permission sets, and account assignments

Four SSO Groups (defined in identity IaC):

  • PlatformTeam — Full administrator access to management account
  • PowerUsers — Deploy and manage workloads; no IAM or billing mutations
  • AuditTeam — Read-only access for compliance and audit
  • SecurityTeam — CloudTrail, GuardDuty, Config, and security tooling access

Default Account Emails (OceanSoft example — customize per enterprise):

  • Management/SSO: sso@oceansoft.io
  • Non-prod workload: b2b@oceansoft.io
  • Prod workload: b2b-prod@oceansoft.io

Verify live after deployment:

aws sso-admin list-instances --region ap-southeast-2
aws organizations list-accounts --region ap-southeast-2
aws identitystore list-groups --identity-store-id <store-id> --region ap-southeast-2
How to Log Into AWS

4 Build Network VPCs and DNS Architecture​

Design a robust, secure network that isolates resources by account and enables controlled inter-account communication. This layer establishes Transit Gateway for account connectivity, deploys Client VPN for developer access, and configures DNS for service discovery.

Key architecture patterns:

  • Deploy a single VPC per account for resource isolation
  • Use Transit Gateway hub-and-spoke topology to connect account networks
  • Deploy AWS Client VPN in the network account for remote developer access
  • Implement service discovery domains for internal service-to-service communication
  • Allocate vanity domains for customer-facing applications
Network and DNS

Next Steps​

Once your foundation is complete, you are ready to set up your platform to deliver applications and services to your customers.