# AWS Landing Zone Reference

A vendor-neutral, opinionated reference for setting up an AWS environment that is secure by default, audit-ready, and ready to grow from 1 account to 100 without re-architecture. MIT licensed. Authored by VantagePoint Networks.

**Audience:** IT Managers, Cloud Engineers, Infrastructure Architects, Heads of Security
**Use this when:** standing up AWS for the first time, formalising an unmanaged account sprawl, preparing for SOC 2 / ISO 27001, or reviewing an existing environment against good practice.

---

## 1. Principles (decisions that drive everything else)

1. **Multi-account by default.** One workload = one account. The account boundary is the strongest isolation AWS offers.
2. **Centralised identity, federated authentication.** No long-lived IAM users in workload accounts. Humans assume roles via AWS IAM Identity Center (formerly SSO).
3. **Centralised logging.** All CloudTrail, VPC Flow Logs, GuardDuty findings, and Config records land in a dedicated log archive account. Read-only.
4. **Network paths are explicit.** No transitive peering. East-west traffic between workloads goes through a Transit Gateway with route table segmentation.
5. **Egress is inspected.** No direct internet egress from workload accounts. All outbound traffic exits through a centralised egress VPC with a Network Firewall or third-party NGFW.
6. **Guardrails over manual controls.** Service Control Policies (SCPs) prevent the worst mistakes. Config rules detect drift. Both are deployed as code.
7. **Tags drive cost, ownership, and lifecycle.** Required tags enforced via SCP.
8. **Recovery is tested, not assumed.** Backup vaults are cross-account. Restore tested quarterly.

## 2. Account structure (AWS Organizations)

```
Root
├── Security OU
│   ├── Log Archive account
│   └── Security Tooling account (GuardDuty admin, Security Hub admin, IAM Identity Center)
├── Infrastructure OU
│   ├── Network account (Transit Gateway, egress VPC, central DNS)
│   └── Shared Services account (CI/CD, container registries, monitoring)
├── Workloads OU
│   ├── Production OU
│   │   ├── prod-app-1
│   │   └── prod-app-2
│   └── Non-Production OU
│       ├── dev-app-1
│       └── stage-app-1
├── Sandbox OU (auto-cleaned weekly, time-boxed)
└── Suspended OU (decommissioned accounts pending deletion)
```

### Account creation rules
- New workload accounts requested via a service request form (Change ticket category: AWS Account).
- Approved by Cloud Platform Lead + Security Lead.
- Created via AWS Control Tower account factory (or Terraform/CloudFormation if not using Control Tower).
- Auto-baselined on creation: GuardDuty, Config, Security Hub, CloudTrail, IAM Identity Center permission sets attached.

## 3. Identity & access

### Identity provider
- Source of truth: corporate IdP (Entra ID / Okta).
- Federation: SAML or OIDC into AWS IAM Identity Center.
- IAM Identity Center deployed in the management account (or delegated administration to Security Tooling).

### Permission sets (baseline)
| Permission Set | Audience | Scope |
|---|---|---|
| `AdministratorAccess` | Cloud Platform team | Management account + Security Tooling only |
| `BillingAccess` | Finance | Management account, billing-only IAM |
| `WorkloadAdmin` | App owners | Their workload account, all services |
| `WorkloadDeveloper` | Developers | Their workload account, scoped to their app's resources via tag-based policies |
| `ReadOnly` | Auditors, on-call observers | All accounts, read-only |
| `BreakGlass` | Emergency only | Stored in vault, use triggers SIEM alert |

### Rules
- No human IAM users in workload accounts.
- No access keys for human users. Federation only.
- Service accounts use IAM roles assumed via OIDC (GitHub Actions OIDC, GitLab OIDC, EKS service account token).
- Long-lived programmatic access keys: prohibited unless explicitly justified, max 90-day rotation.

## 4. Network architecture

### Hub: Network account
- **Transit Gateway** is the centre of the network.
- **Egress VPC:** all outbound internet traffic from workload VPCs flows here. AWS Network Firewall (or appliance NGFW HA pair) inspects, filters, logs.
- **Inbound VPC:** for public-facing workloads, reverse proxy (ALB / NLB / WAF) lives here when centralised.
- **Inspection VPC:** optional, for east-west deep inspection between zones.
- **DNS:** Route 53 Resolver endpoints + private hosted zones, cross-account shared via Resource Access Manager.

### Spokes: workload VPCs
- One VPC per workload account (sometimes more, e.g. dev/stage/prod within a non-prod account).
- Standard CIDR block: /16 from a managed IPAM pool. Subnets:
  - 3x private subnets (one per AZ) for compute / data
  - 3x intra subnets (one per AZ) for AWS-managed services (RDS, EKS control plane, etc.)
  - 0 public subnets by default (egress through TGW)
- Attached to Transit Gateway via dedicated TGW attachment subnets.
- VPC Flow Logs enabled, destination = central S3 bucket in Log Archive account.

### CIDR allocation
- Reserved IPv4 space: pick from RFC1918 (e.g. 10.0.0.0/8 for AWS, 10.0.0.0/9 for primary region, 10.128.0.0/9 for DR region).
- Per-account allocation: /16 each, registered in IPAM.
- IPv6: dual-stack ready. AWS-allocated /56 per VPC, /64 per subnet.

### Route table segmentation (Transit Gateway)
- Production route table: only routes between production workload VPCs + egress + on-prem.
- Non-production route table: only routes between non-prod VPCs + egress.
- Inspection route table: forces traffic through inspection VPC.
- Egress route table: routes 0.0.0.0/0 to egress VPC.

## 5. Logging & monitoring

### Centralised in Log Archive account
- CloudTrail organisation trail → S3 bucket in Log Archive (object lock enabled, retention 7 years).
- VPC Flow Logs (all VPCs) → S3 in Log Archive.
- Config configuration history + snapshots → S3 in Log Archive.
- GuardDuty findings → cross-account aggregation in Security Tooling account.
- Security Hub findings → cross-account aggregation in Security Tooling account.

### Detective controls always-on
- GuardDuty: enabled in every account, every region.
- AWS Config: enabled in every account, every region. Conformance pack baseline.
- Security Hub: CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices.
- IAM Access Analyzer: enabled in every account.
- Macie: enabled for accounts containing S3 with PII (cost-conscious enablement).

### Monitoring
- CloudWatch metrics → centralised dashboards in Security Tooling account.
- Critical alerts → SNS topic → PagerDuty / Opsgenie / Slack.
- Cost & Usage Report → Athena-queryable in Shared Services account.

## 6. Service Control Policies (guardrails)

Apply at Root or OU level. Examples to start with:

| SCP | Purpose | Apply to |
|---|---|---|
| `DenyRootUserActions` | Block root user actions except explicit allow-list | Root |
| `DenyDisablingSecurityServices` | Cannot disable GuardDuty, Config, CloudTrail, Security Hub | Root |
| `RequireRegionRestriction` | Only approved regions (e.g. eu-west-1, eu-west-2) | Root |
| `DenyUntaggedResources` | Resources must have required tags | Workloads OU |
| `DenyImdsv1` | Force IMDSv2 on EC2 instances | Workloads OU |
| `DenyPublicS3` | Block public S3 ACL/policy | All non-Public OUs |
| `RequireEncryptionAtRest` | Cannot create unencrypted EBS, S3, RDS, etc. | All |
| `DenyKeyMaterialDeletion` | Cannot delete KMS keys (force schedule + window) | All |

## 7. Tagging strategy

Mandatory tags (enforced via SCP and Config rule):
- `Environment` — prod / stage / dev / sandbox
- `Owner` — team email or distribution list
- `CostCentre` — finance code
- `Application` — application short name
- `DataClassification` — public / internal / confidential / restricted

Tag governance: tags case-sensitive, lowercase values, hyphen-separated.

## 8. Backup & recovery

- AWS Backup organisation policy applied at OU level.
- Default plan: daily snapshots, 35-day retention, encrypted with customer-managed KMS keys.
- Critical workloads: cross-account, cross-region copy to dedicated Backup account.
- Quarterly restore test: documented, evidenced, fed to BCP register.

## 9. Cost controls

- AWS Budgets at organisation level (monthly forecast vs actual, alert at 80% / 100% / 120%).
- Per-account budgets for workload accounts.
- AWS Cost Anomaly Detection enabled.
- Reserved Instances / Savings Plans purchased centrally (Shared Services or management account).
- FinOps review: monthly, with workload owners attending.

## 10. Compliance mapping (starter)

| Control area | This reference covers |
|---|---|
| CIS AWS Foundations | Section 3 (IAM), 5 (logging), 6 (SCPs); plus Security Hub CIS pack enabled |
| ISO 27001 A.5.15 (access control) | Section 3 |
| ISO 27001 A.8.16 (monitoring activities) | Section 5 |
| ISO 27001 A.8.24 (cryptography) | SCP requiring encryption at rest, customer-managed KMS |
| SOC 2 CC6 (logical access) | Section 3 + IAM Identity Center + permission sets |
| SOC 2 CC7 (system operations) | Section 5 + GuardDuty + Config + Security Hub |
| Cyber Essentials Plus | Section 4 (boundary firewalls), 6 (SCPs as secure config), 5 (monitoring) |

## 11. What this reference is NOT

- Not a Terraform / CloudFormation / CDK module — those are tools to implement this. Use AWS Control Tower for the fastest path; Terraform for full control.
- Not a single-account / pet-project guide. For a single-account learner setup, this is over-engineered.
- Not a managed service replacement. AWS Organizations / Control Tower / IAM Identity Center are still required.

## 12. Implementation order (12-week starter)

| Week | Milestone |
|---|---|
| 1 | Management account hardening, billing alerts, root MFA, IAM Identity Center deployed |
| 2 | OU structure created, Log Archive + Security Tooling accounts provisioned |
| 3 | Organisation-wide CloudTrail, GuardDuty, Config, Security Hub enabled |
| 4 | Baseline SCPs applied at Root |
| 5 | Network account + Transit Gateway + egress VPC stood up |
| 6 | First workload account migrated / stood up against this reference |
| 7-8 | Tag enforcement, backup org policy, cost budgets |
| 9 | First restore test |
| 10 | Drift remediation pass on existing accounts |
| 11 | Documentation + handover to Cloud Platform team |
| 12 | First quarterly review |

## 13. Useful AWS-native tools

- **AWS Control Tower** — opinionated landing zone (use this if you can; this reference describes what it does).
- **AWS Organizations** — account / OU management, SCP enforcement.
- **IAM Identity Center** — federated access, permission sets.
- **Service Catalog** — pre-approved infrastructure templates for app teams.
- **Config Conformance Packs** — declarative compliance rule sets.

## 14. Keep this reference alive

- Re-baseline annually.
- Track AWS service launches that change recommendations (Re:Invent, mid-year announcements).
- Compare to AWS Well-Architected Framework reviews; this is the operational floor, WAR is the per-workload review.

---

**Authored by:** VantagePoint Networks (Hak, Senior Engineer & Author)
**Licence:** MIT — use, customise, ship.