Memory hook: Design the account, identity, network and evidence boundaries before centralising services.
Must remember
- Use accounts as isolation and ownership boundaries. Organise OUs by control requirements rather than copying every management-chart level. Separate security/logging, shared services, networking and workloads where justified; avoid routine workloads in the organisation management account.
- Identity Center/federation gives workforce access through scoped roles. SCPs limit applicable permissions but do not grant them. Resource policies, organisation conditions, permission boundaries and delegated administration solve different cross-account problems. Design and test emergency access rather than removing controls during an outage.
- Centralise logging and evidence with protected destinations, KMS policies and retention. Control Tower can establish a governed landing zone; account vending and StackSets automate consistent baselines. Existing-account onboarding still requires conflict, ownership and remediation planning.
- Choose peering, Transit Gateway, Cloud WAN or service-level PrivateLink according to topology, segmentation, routing scale and operational ownership. Centralised egress/inspection creates dependencies and transfer costs; verify symmetric stateful paths and per-AZ resilience. Hybrid DNS requires Resolver endpoints/rules and zone association, not merely network connectivity.
- Share supported resources through RAM where appropriate instead of duplicating everything or granting broad cross-account administration. Check quotas, Region boundaries, service compatibility and the failure domain of each central service.
- Cost visibility needs activated allocation tags, linked-account ownership, exports and budgets. Purchase commitments only after rightsizing and measuring stable usage. Chargeback/showback should distinguish shared platform costs from workload-controlled spending.
- Governance has preventive, detective and corrective controls. Apply proportionate guardrails, document exceptions, test changes in a limited OU and preserve business continuity. A centrally enforced error can have a larger blast radius than a local error.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Many accounts need consistent infrastructure baselines | Account provisioning plus StackSets/pipelines and scoped roles. |
| Teams need one service without broad network access | PrivateLink where the service pattern fits. |
| Security needs tamper-resistant organisation evidence | Centralised protected logs, encryption permissions and appropriate retention. |
Traps
- Consolidated billing does not merge account permissions.
- One central firewall can become a shared failure/cost bottleneck.
- An SCP applied broadly can block required service operations if exceptions are poorly designed.
Active recall
1. Why separate the log archive from workload administrators?
To reduce the ability of a compromised workload identity to alter its own evidence.
2. What determines a useful OU design?
Common governance requirements and manageable blast radius.
3. Why test guardrails in a limited OU first?
To discover service/deployment exceptions before organisation-wide impact.
4. Does a shared Transit Gateway solve hybrid DNS automatically?
No. Resolver configuration and private-zone associations remain separate.
5. Why rightsize before a long-term commitment?
Otherwise the organisation may commit to persistent waste.