Generated by Merlin Studio (https://app.merlin-studio.cloud). Licensed under the Apache License, Version 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

AWS Landing Zone — AcmeCorp

Profile: ADVANCED Compliance: GDPR, EUCS, NIS2

Two must-reads before you deploy: this zone uses HSM-backed KMS - cdk deploy and the LZA pipeline will FAIL until you complete HSM_SETUP.md. INPUT_ASSERTIONS.md lists spec inputs not represented in the output (e.g. the EKS sections are not emitted in any format).

---

What's in this zip

This tree lists only the files generated for your configuration — optional files (e.g. transit_gateway.tf, aft.auto.tfvars) appear here only when the matching feature is enabled, so nothing below is "missing".

.
├── README.md                  (this file)
├── DEPLOYMENT_GUIDE.md        Step-by-step deploy for every format
├── architecture.mmd           Mermaid diagram of the landing zone topology
├── HSM_SETUP.md               (!) CloudHSM custom key store setup - REQUIRED before deploy
├── INPUT_ASSERTIONS.md        Known gaps: spec inputs not represented in the output
├── PLACEHOLDERS.md            Tokens to replace before deploy
├── aws-lza/                   Format 1: AWS Control Tower + Landing Zone Accelerator (YAML)
│   ├── global-config.yaml
│   ├── accounts-config.yaml
│   ├── organization-config.yaml
│   ├── iam-config.yaml
│   ├── network-config.yaml
│   ├── security-config.yaml
│   ├── customizations-config.yaml
│   └── service-control-policies/, kms/, vpc-endpoint-policies/  (supporting JSON)
└── aws-cdk/                   Format 2: AWS CDK (TypeScript)
    ├── bin/app.ts
    ├── lib/*-stack.ts         organizations, accounts, iam, network, kms, kms-replica,
    │                          logging, security, config, backup, cost
    ├── package.json, tsconfig.json, cdk.json
    └── .gitignore

---

Quick facts

Organization name	AcmeCorp
Primary contact	admin@acme.com
Security contact	my2mail@acme.com
Billing contact	my3mail@acme.com
Home region	eu-central-1
Enabled regions	eu-west-1, eu-west-2, eu-west-3, eu-central-1, eu-north-1
Profile	advanced (enterprise)
Compliance	gdpr, eucs, nis2
LZA version	1.14.x
aws-cdk-lib	^2.150.0

---

Account inventory

Mandatory accounts (LZA-required)

Name	Purpose	OU
Management	AWS Organizations payer + LZA control plane	Root
LogArchive	Central log archive (CloudTrail org trail, Config)	Security
Audit	Security tooling delegated administrator	Security
SharedServices	DNS resolver endpoints, golden AMIs, etc.	Infrastructure
Network	Central network hub (TGW, Direct Connect)	Infrastructure

Workload accounts

Name	OU	Description
AppSandbox	Workloads/Sandbox	Application sandbox / experimentation
AppDev	Workloads/Dev	Application development
AppStaging	Workloads/Staging	Application staging / pre-prod
AppProd	Workloads/Prod	Application production

---

Before you deploy

1. Search and replace PLACEHOLDER_ tokens. The wizard could not infer real AWS account IDs, OU IDs, or some ARNs. See PLACEHOLDERS.md if present.
2. Pre-create your AWS Organization with a Management account. LZA / CDK / OpenTofu cannot bootstrap the org itself.
3. Enable AWS Organizations trusted service access. organizations.tf carries the required principals on a count = 0 resource — a documentation anchor only, so Terraform does not enable them (it must not manage your existing org). From the management account, enable trusted access for each principal — or confirm AWS Control Tower already has — before deploying:

   aws organizations enable-aws-service-access --service-principal cloudtrail.amazonaws.com
   aws organizations enable-aws-service-access --service-principal config.amazonaws.com
   aws organizations enable-aws-service-access --service-principal controltower.amazonaws.com
   aws organizations enable-aws-service-access --service-principal guardduty.amazonaws.com
   aws organizations enable-aws-service-access --service-principal securityhub.amazonaws.com
   aws organizations enable-aws-service-access --service-principal ram.amazonaws.com
   aws organizations enable-aws-service-access --service-principal sso.amazonaws.com
   aws organizations enable-aws-service-access --service-principal fms.amazonaws.com

   And enable the organization policy types the zone uses:

   aws organizations enable-policy-type --root-id <ROOT_ID> --policy-type SERVICE_CONTROL_POLICY
   aws organizations enable-policy-type --root-id <ROOT_ID> --policy-type TAG_POLICY

   Skipping this breaks org-wide CloudTrail, the Config aggregator, GuardDuty / Security Hub org auto-enable, RAM sharing (Transit Gateway), IAM Identity Center, and Firewall Manager — they fail to deploy or silently no-op.
4. Enable AWS IAM Identity Center in the management account if you want SSO permission sets to provision. Set the instance ARN via CDK context or the relevant tfvars field.
5. Bootstrap state storage for OpenTofu (S3 + DynamoDB lock) — see DEPLOYMENT_GUIDE.md.
6. Bootstrap CDK (cdk bootstrap) in the home region of each target account.

---

Compliance posture

This zone is configured to meet the requirements of:

• GDPR
• EUCS
• NIS2

Specific controls applied:

• CloudTrail organization trail with KMS-CMK encryption and log file validation
• AWS Config recorder + aggregator delegated to the Audit account
• GuardDuty with auto_enable = true for all org members
• Security Hub with framework-aligned standards subscriptions
• IAM password policy: min length 14, rotation every 60 days
• KMS CMKs with automatic key rotation enabled (CIS 3.8 — which mandates rotation be enabled, not a specific period) with an annual rotation period
• Object Lock on the central log archive bucket (when FedRAMP / SOX is in scope)
• S3 default encryption + SSL-only bucket policies
• VPC Flow Logs on every VPC, all-traffic, with CloudWatch + S3 destinations

---

How this Landing Zone was generated

This zone was authored by Merlin Studio v2, which uses a compile-AI approach. LLMs were used at design time to encode AWS best-practice patterns, compliance- framework requirements, and discovery-driven defaults into a static rules engine. At generation time, every value below was derived deterministically from your discovery answers + a layered rules engine — no LLM call happens during generation. The same answers always produce the same artifact.

Deeper reading: "Compiled AI for GCP Landing Zones" → dev.to/boristep. The methodology is identical for the AWS pipeline.

The layer model

Values in this spec come from up to four layers, with later layers winning on conflict:

1. Schema defaults       ← floor: a value exists for every field
2. Profile defaults      ← simple / standard / advanced — broad shape
3. Compliance overlays   ← HIPAA / CIS / PCI / FedRAMP add-ons (per framework)
4. Discovery overlays    ← driven by YOUR answers (multi-region, encryption, ...)
5. User edits            ← anything you typed in the wizard ALWAYS wins

Arrays append by name — a compliance overlay adding a required account (e.g. PhiWorkload) to your workload_accounts inventory does not erase the accounts you selected. Scalars: discovery overlays overwrite profile defaults (the discovery answer is the more specific signal); compliance overlays only fill empty slots; your saved values are merged last and override everything.

---

What fired for your spec

The wizard ran these overlays against your answers. Each entry is the rules-engine trace — what was added, why, and what triggered it.

Discovery overlays

Section	Overlay	Triggered by	Rationale
03_iam_model	github_actions_oidc_and_deploy_role	existing_cicd contains 'github_actions'	Discovery declared GitHub Actions as an existing CI/CD platform (existing_cicd). Scaffold the GitHub OIDC provider and a Terraform deploy role so the pipeline has a keyless federated path to AWS. Without this, a Terraform-via-GitHub-Actions team gets a landing zone with no pipeline auth path and must hand-build the OIDC provider + role.
04_networking	multi_region_secondary_networking	multi_region_required=true	Multi-region answers (warm/active-active DR) require a second hub VPC + workloads VPC in the secondary region, a secondary regional Transit Gateway, and an inter-region TGW peering attachment. Without these, the spec declares warm-standby but is physically single-region — a direct contradiction the generators cannot recover from.
04_networking	regulated_centralized_egress	compliance_requirements contains 'pci_dss' OR compliance_requirements contains 'fedramp_moderate' OR compliance_requirements contains 'fedramp_high' OR compliance_requirements contains 'nist_800_53' OR compliance_requirements contains 'eucs'	Boundary-control frameworks (PCI-DSS Req 1 NSCs, NIST 800-53 / FedRAMP SC-7, EUCS) require a controlled, inspected egress boundary. The egress model is set to centralized so spoke egress flows through the inspection VPC's AWS Network Firewall; the compliance overlay adds that inspection VPC.
07_advanced_security	regulated_enables_macie	compliance_requirements contains 'pci_dss' OR compliance_requirements contains 'hipaa' OR compliance_requirements contains 'gdpr' OR compliance_requirements contains 'eucs' OR compliance_requirements contains 'nis2'	Data-protection frameworks require knowing where sensitive data (PANs / PII / PHI) lives — PCI-DSS Req 3 / 12.5.1, HIPAA, GDPR. Amazon Macie is the native S3 discovery/classification control, so it is enabled by default when any of these is in scope. Matches the Architecture Scorecard, which fails Macie-off for these frameworks.
07_advanced_security	regulated_enables_inspector	compliance_requirements contains 'pci_dss' OR compliance_requirements contains 'fedramp_moderate' OR compliance_requirements contains 'fedramp_high' OR compliance_requirements contains 'nist_800_53' OR compliance_requirements contains 'eucs'	PCI-DSS 11.3.1 (internal vulnerability scanning) and NIST 800-53 / FedRAMP RA-5 require continuous vulnerability scanning. Amazon Inspector is the native control, so it is enabled by default when any of these is in scope. Matches the Architecture Scorecard, which fails Inspector-off for these frameworks.
08_logging_monitoring	multi_region_enables_log_replication	multi_region_required=true	Multi-region DR needs the central log bucket replicated to the secondary region so a regional outage does not destroy the audit trail of last resort.
10_backup_dr	multi_region_secondary_region	multi_region_required=true	Multi-region answers (warm/active-active DR) require AWS Backup to copy recovery points to the secondary region. Pre-fill from discovery.secondary_region so the user does not have to retype it.
10_backup_dr	warm_or_active_standby_strengthens_backup	dr_requirements = 'warm_standby' OR dr_requirements = 'active_active'	Warm-standby / active-active DR strategies imply org-level backup policy + vault lock so the secondary region can never lag.
14_observability	medium_availability_target_basic_observability	availability_target in ['99.9', '99.95'] AND availability_requirements != 'very_high'	99.9% / 99.95% targets need Synthetics + X-Ray but not the full Prometheus/Grafana stack. Mutually exclusive with the very_high rule: when the categorical tier is 'very_high' (a stronger signal than the raw target percentage), the high rule wins and this one stays quiet so the 'What fired' trace never shows both tiers firing on the same spec.
17_ec2_compute	multi_region_ebs_snapshot_cross_region	multi_region_required=true	Multi-region answers require EBS snapshots to be copied to the secondary region for warm-standby.

---

Next

See DEPLOYMENT_GUIDE.md for the deploy-and-verify runbook tailored to each output format.