Skip to content
Building a Control Tower-Like Multi-Account Landing Zone in AWS China Regions
Cloud Computing 29 min read

Building a Control Tower-Like Multi-Account Landing Zone in AWS China Regions

The author details building a multi-account AWS landing zone in China regions where Control Tower is unavailable, using Organizations, IAM Identity Center, CloudFormation StackSets, and Terraform to create a four-account structure with SCPs, centralized logging, Config, Security Hub, and a validated compliance loop, documenting real-world pitfalls and timings.

DevOps Coach
DevOps Coach
DevOps Coach

Available Foundation in AWS China Regions

Control Tower is not available in AWS China regions (cn-north-1, cn-northwest-1). The AWS China blog (May 2025) explicitly states it is "not yet released in China." No managed guardrails, Account Factory, or compliance dashboard exist. However, core primitives are present and surprisingly recent: IAM Identity Center (GA Sep 2023), Service Control Policies (GA Oct 2023), CloudFormation StackSets with service-managed permissions (GA Apr 2023). The only AWS-endorsed alternative is Cloud Foundations — an open-source self-deployed accelerator, not a managed replacement; deployment, upgrades, and drift remain the user's responsibility. The author chose a hand-built thin version so every layer stays measurable.

Target Architecture

The build uses four accounts, three OUs, and one identity source:

Management account — only Organizations, SCPs, billing; no production workloads.

Security OU / log-archive — audit and aggregation seat: Security Hub delegated administrator, future Config aggregator, central evidence.

Workloads OU / demo-dev , demo-prod — one product team, pipeline-onboarded; future products land here as new account pairs.

Identity layer reuses the existing IAM Identity Center instance (internal identity store, no external IdP). Groups per product: poc-demo-devops, poc-demo-readers, plus poc-auditors and poc-platform-admins. The permission-set matrix maps groups to accounts.

Two China-specific identity notes: portal and CLI experience match global ( awsapps.cn/start, aws sso login against oidc.cn-north-1.amazonaws.com.cn, 1-hour default / 12-hour max session). However, Identity Center lacks multi-region replication (the 2026 global feature covers 17 commercial regions, not China). Therefore, a non-portal break-glass path is not optional — it separates incident from outage.

Product Team Onboarding

A single YAML file and one terraform apply provisions a new team:

# products/demo.yaml
name: demo
email_prefix: aws          # aws-demo-dev@<domain>, aws-demo-prod@<domain>
environments: [dev, prod]
cidr: 10.60.0.0/16         # recorded for pipeline; VPC not created at this stage
groups:
  devops: poc-demo-devops
cost_center: POC-DEMO-001

A for_each over products/*.yaml expands into accounts in Workloads OU, Identity Center groups and users, and permission-set-to-group account assignments. Measured time: 45 seconds per team .

Two real-world pitfalls hit during the same run:

InvalidClientTokenId when assigning permissions to a brand-new account. Root cause: Identity Center must pre-provision a role in the new account, but it raced ahead of credential propagation. Fix: wait 30 seconds and retry (11 seconds success). Lesson: pipeline must bake in this retry.

Account quota default = 2 (management + 1 member). Third account fails with You have exceeded the allowed number of AWS accounts. No self-service quota increase; Organizations in this partition has no Service Quotas entry. Must open an AWS China support ticket (author's approved in one day). Any real multi-account project should schedule this ticket for day one.

New accounts receive baseline via a service-managed StackSet targeting the OU with auto-deploy enabled — the closest equivalent to Account Factory baseline steps in this partition.

Guardrails & Organization Logging

Three SCPs cover the basics:

Root-level Deny organizations:LeaveOrganization — prevents any account from leaving the organization (validated from a member account).

Root-level Region deny — allows only cn-north-1 / cn-northwest-1 plus standard global-service exemptions.

Workloads OU-level Audit trail protection — denies cloudtrail:StopLogging, config:DeleteConfigurationRecorder, and related actions.

Organization-level CloudTrail revealed a genuine China-partition difference. Global docs show bucket policy resource as AWSLogs/* — copying that causes CreateTrail validation to reject. The validator requires both prefixes : AWSLogs/* and AWSLogs/* (note the account-id path). With both, creation succeeds; object listing shows management account logs appear under both forms. Multi-region trail then writes all four accounts' logs into one bucket (hundreds of objects per account on day one), readable org-wide, with read-only console access in each member account.

Config Bootstrap Chain

The most instructive failure chain in the entire build. First baseline template did the obvious: one IAM role, one Config recorder, one delivery channel, two managed rules — failed; revised, failed again; revised again, still failed. Three root causes, each verified:

Recorder won't start without a delivery channel. start-configuration-recorder throws NoAvailableDeliveryChannelException. In this partition, the channel is a prerequisite, not optional.

Central bucket policy must authorize Config writes per account ID. Using aws:PrincipalOrgID (which works for CloudTrail) yields InsufficientDeliveryPolicyException. Switching to aws:SourceAccount with the member account ID list works. This policy is now auto-generated from the live account list; new accounts are covered automatically.

Role created milliseconds earlier fails channel check due to IAM propagation ( unable to assume role). Wait 20 seconds and retry clears it.

Working recipe: assume member role → create recorder role → put-configuration-recorder → put-delivery-channel pointing to central bucket → start, with retries between steps. One script, three accounts recording within three minutes.

Generalizable lesson: behind every detective control in China lies a bootstrap chain that Control Tower's ConfigBaseline would have absorbed. Your baseline repo is not a template — it's load-bearing structure with its own failure modes.

Organization-Level Detective Controls

Security Hub supports organization mode + delegated administrator in China. Two hard rules:

Delegated administrator must be a member account (author uses log-archive), not the management account. auto-enable only affects accounts that join after enablement — existing accounts must be explicitly added via CreateMembers to become visible. This step is missing compared to Control Tower's global auto-registration, so it belongs in the Runbook.

Standards are subscribed per account. China catalog contains ~10 standards including AWS Foundational Security Best Practices (FSBP) and CIS benchmarks; member accounts receive default rule sets on association.

Critical dependency order invisible in console until it breaks: Most FSBP controls do not evaluate when the account lacks a Config recorder — subscription shows INCOMPLETE with reason code NO_AVAILABLE_CONFIGURATION_RECORDER. Config must be running before Security Hub subscription. Reverse the order and the dashboard shows unexplained yellow.

Compliance Loop Live Test

Acceptance criteria defined upfront: an engineer makes a mistake, audit function sees it from another account, fixes it with least privilege, engineer watches compliance recover. Four steps, all screenshot-documented.

Create violation. As ProductDevOps in demo-dev, create an S3 bucket left publicly readable.

Detect. Minutes later (findings page shows "1 minute ago"), FSBP control S3.2 turns red.

Remediate with least privilege. Auditor switches to SecurityRemediator — a 1-hour permission set with inline policy allowing only S3 Block Public Access actions. Enables block public access on the bucket. Same session, attempted bucket delete is denied. By design: audit function can remediate this finding class, nothing else.

Verify recovery. Config records change, control re-evaluates, S3.2 returns green, finding workflow becomes RESOLVED — confirmed by engineer from ProductDevOps session, same portal, different role. Detection to resolution in minutes, not days, fully visible across three distinct permission sets, no shared credentials.

AI Agent & Automation Scenarios

This stack was designed for human engineers, but its biggest beneficiaries are "non-human engineers": AI agents, CI/CD pipelines, IaC automation, ChatOps bots. Common trait: code that autonomously calls APIs at machine speed with no human gate per call; permission boundary is the only security boundary. In the prompt-injection era, attackers need not steal credentials — just trick an agent into using its existing credentials for an unintended API call. Isolating each agent/toolchain in a dedicated account is the hardest blast-radius lock, and that's exactly what the account-vending flow does: add ai-agent.yaml or cicd.yaml to products/*.yaml, 45 seconds later a machine account with full baseline, SCP guardrails, and audit aggregation is live, compliance starting line identical to human teams.

Foundation existence: China runs machine workloads — SageMaker available, Bedrock AgentCore GA in China (Identity component uses workload identity + token vault for short-lived credentials, isomorphic to this governance; Bedrock model hosting absent, but that's model layer, not identity governance). Crucially, account system decouples from runtime: whether agent runs on AgentCore, SageMaker, or self-managed containers; whether pipeline comes from GitHub Actions, Jenkins, or internal scheduler — every AWS API call rides IAM credentials and passes the SCP gate. Three integration patterns:

AI Agent: one account per agent/class; capabilities via IdC permission sets or IAM roles; runtime assumes STS short sessions (min 15 min); session tags agent-id / task-id — every CloudTrail API call attributable to which agent's which task, not a vague shared identity.

CI/CD Pipeline: deploy job uses OIDC federation or self-hosted runner instance role to assume target account role; zero long-lived credentials; each pipeline gets dedicated role — who deployed what to which account when, queryable per line in CloudTrail.

IaC Automation: Terraform state and execution live in automation-only account; apply uses short session role; plan drift caught by Config — this article's companion drift-check runs inside the same system.

Post-onboarding, machine account behavior monitored via:

Trail retention: Organization CloudTrail already aggregates all account events into log-archive; enable data events for agent model invocations and toolchain credential reads (default off) to capture key actions in audit trail.

Anomaly detection: GuardDuty in China since 2021, but two realities: organization management policies unavailable in China (enable per account via script); AI workload protection partially available — AnomalousModelInvocation and CostHarvesting (via SageMaker call patterns) work, PromptInjection.Direct unavailable due to Bedrock absence. China machine workload detection must combine available signals with custom rules.

Finding aggregation & response: Security Hub delegated admin (already configured) aggregates all machine account findings; the S3 compliance loop above applies identically to agent or pipeline mistakes — detect, least-privilege remediate, verify recovery, minute-level closure.

Why IAM user AK/SK must be banned for machine scenarios, summarized in a table (each row amplified in machine context: credentials embedded in code/config → larger exposure surface; high call frequency → anomalies harder to spot manually; accountability must pin to agent/pipeline level. AK/SK leaves all three to human ops; IdC + STS turns them into architectural properties. The stack's value for AI agents and DevOps toolchains lives in this row-by-row comparison.

What This Stack Is Not

Ceiling is structural, not cosmetic. Global Control Tower brings catalog of 750+ AWS-maintained controls (preventive SCP sets, detective Config/Security Hub rules, proactive CloudFormation Hooks controls), versioning and deprecation managed by AWS; drift detection, deduplicated notifications, one-click reset compliance dashboard; Account Factory with identity assignment pre-wired; landing-zone-semantic IaC surface.

We replicated the replicable parts, and replicated well: onboarding flow genuinely close, region deny via one-hour SCP, end-user portal nearly identical, compliance loop above is real. No equivalents exist for "content" and "governance experience" — every rule, every Runbook, every upgrade forever lives on your team's backlog. Proactive controls (CloudFormation Hooks) and Resource Control Policies (RCP) have zero China availability documentation; treat as non-existent until proven.

Bottom line: architecture replicable, governance content and experience yours. Realistic posture: a 20–50 control curated set you personally maintain, residual risk documented.

Complete Pitfall Checklist (in order of appearance)

Account quota default = 2. Support ticket, not Service Quotas. Reserve one day.

SCP policy type may need enabling before first policy attaches — one CLI call, but error is cryptic if missed.

One Statement cannot contain both Action and NotAction — SCP validator here is strict.

Service-managed StackSets trusted access only configurable via console. Docs' CLI principal ( cloudformation.amazonaws.com) returns UNRECOGNIZED_SERVICE_PRINCIPAL in this partition; the API that accepts it cannot flip CloudFormation's switch. One manual click, once — plus a Runbook note.

Organization trail bucket policy needs two prefixes ( AWSLogs/* and AWSLogs/*), else CreateTrail rejects.

Config requires role + recorder + delivery channel + start, with retries — three root causes detailed above.

Security Hub organization mode: delegated admin must be member account; auto-enable only for future accounts; NO_AVAILABLE_CONFIGURATION_RECORDER means your Config step regressed.

Identity Center China has no multi-region replication. Break-glass path must not depend on portal.

Organization billing ignores your OU structure. Cost allocation via tags and CUR, same as global — but RMB settlement, separate contracts per operator (Beijing Sinnet / Ningxia NWCD) forces product-line chargeback earlier.

Cost & Repeatability

This footprint — four accounts, full Config, Security Hub default standards, one organization trail — monthly cost is single-digit USD; Security Hub per-finding billing negligible at this volume, CloudTrail management events free. Environment kept as repeatable demo: same products/*.yaml flow that spun up demo team spins up the next; teardown script walks full destroy path. Expensive part isn't AWS bill — it's engineering hours burned on pitfalls 1–8 during first build. Shrinking that number is exactly why this article exists.

FAQ

Can China use Control Tower? No. Not in supported regions list, no China docs chapter, AWS May 2025 blog says "not yet released in China." Need landing zone? Build with Organizations, IAM Identity Center, StackSets, Terraform — this article is the full live run.

How many accounts can a new China organization create? Tested default limit 2 (management + 1 member). Quota increase via AWS China support ticket; Organizations in China partition has no Service Quotas entry. Author's 10-account increase approved in one day, but plan the ticket for day one.

Does Terraform work with AWS China partition? Yes, end-to-end. hashicorp/aws provider (tested v6.70.0) manages Organizations, SCPs, Identity Center, permission sets, account assignments, service-managed StackSets without partition-specific tweaks. Adjustments are provider version schema details and service-side bootstrap ordering — never the partition itself.

Any official alternative? One: AWS Cloud Foundations, open-source self-deployed. AWS China blog positions it as China-usable, non-Control-Tower mode. Saves build time, but deployment, upgrades, drift remain yours; Control Tower's governance content and experience gaps stay yours.

References

AWS Control Tower supported regions — list excludes China

AWS China blog — Manage Control Tower with Cloud Foundations (May 2025) — source of "not yet released" and Cloud Foundations positioning

IAM Identity Center China launch (Sep 2023)

Service Control Policies China launch (Oct 2023)

CloudFormation StackSets China GA, service-managed (Apr 2023)

AWS China blog — Automated Account Creation Practice (2024)

China AWS Service Getting Started — official user guide PDF — authoritative per-service China differences

AWS China FAQ — accounts, real-name, operators, RMB settlement

More China vs global measured gaps (version, feature, quota, experience, cost across five dimensions) at Chinaready service parity tracker.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

ComplianceTerraformMulti-AccountStackSetsAWS ChinaIAM Identity CenterLanding ZoneOrganizations
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.