Use when designing, reviewing, or hardening the AWS Organizations and account topology for a system after infrastructure-platform and security have decided the org structure and environment ladder. Produces the AWS Organizations OU structure, landing-zone approach (Control Tower or custom), Service Control Policy guardrails, environment-isolated account layout, central billing and cost-allocation tagging, and baseline AWS Config/audit posture. Do not use for in-account VPC/IAM/KMS design, workload compute selection, observability wiring, or DR topology; use the other aws archetype skills (network-and-identity-foundation, workload-runtime-and-deployment, observability-and-cost-readiness, dr-and-multi-region-readiness) instead.
Use when designing, reviewing, or hardening the AWS Organizations and account topology for a system after infrastructure-platform and security have decided the org structure and environment ladder. Produces the AWS Organizations OU structure, landing-zone approach (Control Tower or custom), Service Control Policy guardrails, environment-isolated account layout, central billing and cost-allocation tagging, and baseline AWS Config/audit posture. Do not use for in-account VPC/IAM/KMS design, workload compute selection, observability wiring, or DR topology; use the other aws archetype skills (network-and-identity-foundation, workload-runtime-and-deployment, observability-and-cost-readiness, dr-and-multi-region-readiness) instead.
AWS Account and Organization Topology
When to use
Invoke when establishing a new AWS Organization, restructuring accounts/OUs, adding an environment to the account ladder, or auditing org-level guardrails before workloads land.
Do not use for: in-account network/identity foundation — VPC, IAM roles, KMS, Secrets Manager (use aws-network-and-identity-foundation), workload compute primitives (use aws-workload-runtime-and-deployment), observability/cost instrumentation (use aws-observability-and-cost-readiness), or DR/multi-region (use aws-dr-and-multi-region-readiness).
Inputs
Required:
Approved infrastructure-platform.md declaring the org topology intent and the environment ladder (which environments exist and how they isolate).
Approved architecture/security decisions on the guardrail posture: required encryption, allowed regions, root-usage policy, and audit/logging centralization.
Optional:
Existing AWS Organization state (accounts, OUs, SCPs, Control Tower status).
Compliance regime (e.g. PCI/HIPAA/FedRAMP) driving isolation and audit requirements.
Tenancy model (single-tenant vs multi-tenant) affecting account-per-tenant decisions.
Cost-allocation and chargeback requirements.
IaC tooling preference for org management (consumed by terraform skills, not implemented here).
Operating rules
Consume the topology; do not invent it. The OU structure intent, environment ladder, and isolation requirements come from infrastructure-platform.md; the guardrail posture comes from architecture/security. If either is silent on a needed decision (e.g. account-per-environment vs shared, allowed regions), pause and raise an ADR candidate.
Accounts are the strongest AWS isolation and blast-radius boundary. Environment isolation (prod vs non-prod) is account-level, not tag-level or VPC-level. A shared prod/non-prod account is rejected absent an ADR.
Mandatory foundational accounts: a management (org root, no workloads), a log-archive (immutable central logging), and an audit/security account. Workload accounts never hold org-management privileges.
Prefer a landing zone (Control Tower or a documented custom equivalent) over hand-built org plumbing; justify a custom landing zone with an ADR if Control Tower is rejected.
SCPs are guardrails, not IAM. They express organization-wide denies (deny disallowed regions, deny root actions, deny disabling CloudTrail/Config/GuardDuty, require encryption) and never substitute for in-account least-privilege (that is aws-network-and-identity-foundation).
Guardrails are default-deny at the edges that matter: every SCP names the threat or policy it enforces from architecture/security. No guardrail without a mapped rationale; no required control left unguarded.
Central, tamper-resistant audit is non-negotiable: org-wide CloudTrail to the log-archive account, AWS Config baseline rules, and GuardDuty enabled org-wide, with the log-archive account access-restricted.
Cost allocation is structural: a mandatory tagging policy (Environment, Workload, CostCenter, Owner) enforced via tag policies, consolidated billing, and per-OU/account cost visibility. Tagging discipline defined here; spend monitoring/anomaly detection is aws-observability-and-cost-readiness.
Stay at the org/account boundary. VPCs, IAM roles, KMS keys, and workloads are explicitly downstream — name the handoff, do not design them here.
This skill emits IaC-ready definitions and policy documents; it does not own the IaC module mechanics or state (that is the terraform Family H skills).
Output contract
The org and account topology MUST conform to:
security-standards — centralized immutable audit logging, encryption-required guardrails, no org-management privilege in workload accounts, restricted log-archive access.
deployment-standards — environment isolation is account-level and reproducible via IaC; no click-ops-only org structure.
observability-standards — org-wide CloudTrail/Config/GuardDuty enabled and routed to the log-archive account.
Upstream contract: infrastructure-platform.md is the source of truth for the OU structure and environment ladder; architecture/security is the source of truth for guardrail posture, allowed regions, and audit centralization. If a needed decision is unstated, pause and raise an ADR candidate. VPC/IAM/KMS/Secrets and all workload concerns are downstream handoffs, not designed here.
Process
Load infrastructure-platform.md (org intent, environment ladder, isolation requirements) and architecture/security (guardrail posture, allowed regions, audit centralization, compliance regime). If a required decision is missing, pause and raise an ADR candidate.
Inventory current state (if any): existing accounts, OUs, SCPs, Control Tower status, CloudTrail/Config/GuardDuty coverage, and tagging. Record every gap against a security/platform requirement.
Design the OU structure: foundational OUs (Security, Infrastructure/Shared, Workloads) and workload OUs aligned to the environment ladder and tier classification. Place the mandatory management, log-archive, and audit accounts.
Choose the landing-zone approach: AWS Control Tower (default) or a documented custom landing zone (with an ADR justifying the rejection of Control Tower). State the enrollment/account-vending mechanism.
Define the account layout: account-per-environment (and per-tenant where the tenancy model requires), naming, ownership, and the rule that workload accounts hold no org-management privilege.
Design SCP guardrails: per guardrail, the deny/condition and the architecture/security rationale it enforces — deny disallowed regions, deny root usage, deny disabling CloudTrail/Config/GuardDuty, require encryption (e.g. S3/EBS), restrict leaving the org. Map each SCP to OU scope.
Design centralized audit: org-wide CloudTrail to the log-archive account (immutable, MFA-delete/Object-Lock as applicable), AWS Config baseline conformance pack, GuardDuty org-wide, and access restriction on the log-archive account.
Define the tagging and cost-allocation policy: mandatory tag keys (Environment, Workload, CostCenter, Owner), AWS tag policies enforcing them, consolidated billing, and cost-allocation activation. Note the handoff of spend monitoring to aws-observability-and-cost-readiness.
Produce the topology assessment: OU/account diagram or narrative, the SCP guardrail → rationale matrix, the audit posture, the tagging policy, and an explicit gap list with ADR candidates for any unstated/unmet requirement.
State downstream handoffs explicitly: VPC/identity foundation → aws-network-and-identity-foundation; workload runtime → aws-workload-runtime-and-deployment; spend/observability → aws-observability-and-cost-readiness; DR → aws-dr-and-multi-region-readiness; IaC module/state mechanics → the terraform Family H skills.
account-organization-topology.md: OU structure, account layout (incl. mandatory management/log-archive/audit accounts), landing-zone approach, and the environment-ladder mapping.
SCP guardrail set with, per policy, its scope and the architecture/security rationale it enforces.
Gap list with ADR candidates and the explicit downstream-handoff list.
Output rules:
IaC-ready definitions/policy documents, not prose-only; not the IaC module/state mechanics (that is terraform).
Environment isolation is account-level; no tag-only "isolation".
Every SCP maps to a named security/platform rationale; unmapped guardrails are removed, unguarded required controls are reported as gaps.
No VPC/IAM/KMS/workload design; those are named handoffs.
Quality checks
OU structure and environment ladder are sourced from infrastructure-platform.md; guardrail posture from architecture/security (or an ADR candidate is raised).
Mandatory management, log-archive, and audit accounts exist; workload accounts hold no org-management privilege.
Environment isolation (prod vs non-prod) is account-level, not tag- or VPC-level.
A landing-zone approach is chosen; a custom landing zone (if used) has an ADR justifying rejection of Control Tower.
Every SCP names the architecture/security rationale it enforces and its OU scope.
Org-wide CloudTrail routes to an access-restricted, immutable log-archive account; Config baseline and GuardDuty are org-wide.
A mandatory tagging policy (Environment, Workload, CostCenter, Owner) is enforced via tag policies with consolidated billing.
Tier classification (architecture-schema) is reflected in account isolation strictness and guardrail severity.
Downstream handoffs (network/identity, workload runtime, observability/cost, DR, IaC mechanics) are named, not designed here.
Outputs are IaC-ready definitions/policies, not prose-only.
