Centrally deploy and manage AWS accounts
Use organization design, delegated administration, account vending, shared services, and centrally governed security capabilities.
- Lesson
- d6-lesson
- Practice pool
- d6-questions
- Application
- scs-l01, scs-l05
Apply repeatable account governance, secure deployment, compliance evidence, policy enforcement, delegated administration, and exception handling.
Use organization design, delegated administration, account vending, shared services, and centrally governed security capabilities.
Turn security requirements into versioned infrastructure, preventive controls, drift detection, exception workflows, and automated remediation.
Map requirements to controls and evidence, evaluate scope and inheritance, preserve auditability, and remediate gaps proportionately.
Governance connects intent to repeatable operation. A policy without an enforceable control, owner, evidence, exception process, and review date is only a statement. A technical control without business scope and authority can block the wrong work or create unmanaged bypasses.
Use the chain requirement → accountable owner → preventive control → detective control → evidence → exception → remediation → retest. Apply it across accounts, identities, networks, data, deployments, and suppliers.
| Objective | Required judgment | Proof |
|---|---|---|
| 6.1 Centrally deploy and manage AWS accounts | Design organizations, OUs, accounts, delegated services, shared security capabilities, and account lifecycle | A new account receives the approved baseline and central visibility automatically |
| 6.2 Deploy resources consistently and securely | Convert requirements into versioned templates, preventive gates, drift detection, remediation, and exceptions | Approved deployment succeeds; prohibited and drifted states are detected or blocked |
| 6.3 Meet compliance requirements | Map obligations to scoped controls, evidence, ownership, inheritance, gaps, and retest | An assessor can trace a requirement to current evidence and an accountable decision |
Use AWS Organizations to establish ownership and policy boundaries. Organize accounts by control needs and lifecycle, not only by the current org chart. Separate production from non-production and consider dedicated management, security tooling, log archive, network, shared services, and backup responsibilities. Keep workloads out of the management account. Apply service control policies as maximum-permission guardrails; SCPs do not grant access and should be tested for service and recovery dependencies before broad rollout.
AWS Control Tower can establish and govern a landing zone with account enrollment and controls. Account vending should assign ownership, contact data, budgets, identity access, logging, configuration, backup, network connectivity, and decommissioning from the start. Delegated administration lets security teams operate supported organization services without daily use of the management account. The delegated model still needs least privilege, change control, and monitoring.
Centralize organization trails, configuration visibility, findings, threat detection, and security data according to the organization's architecture. Central does not mean one team owns every response. Define what the platform team enforces, what workload teams remediate, escalation times, exception authority, and how service or Region coverage is proven.
Infrastructure as code makes review, reproduction, and drift comparison possible, but insecure code can reproduce insecurity reliably. Govern source, review, CI identities, artifact integrity, secrets, plans, approvals, deployment roles, and rollback. Use CloudFormation StackSets for governed multi-account or multi-Region deployment where they fit. Service Catalog can constrain approved products. AWS Config rules and conformance packs evaluate state. CloudFormation Hooks and policy-as-code gates can evaluate proposed changes before or during provisioning. Choose preventive, proactive, detective, and responsive controls based on failure cost and operational maturity.
Avoid permanent administrator pipelines. Separate build, review, and deploy responsibilities. Scope deployment roles to the target environment and approved resource patterns. Protect iam:PassRole, policy creation, organization changes, logging controls, KMS administration, and network control planes. Record the commit, artifact, approver, plan, deployment result, and post-deploy validation.
Drift can be authorized, accidental, or malicious. Detection should produce a comparison to the approved source, resource owner, severity, and remediation path. Automatic remediation is appropriate when the desired state is unambiguous, the action is bounded and idempotent, and rollback is understood. High-impact drift may require containment or human approval.
Start by scoping the obligation: legal entity, accounts, systems, data, Regions, people, suppliers, time period, and control owner. Map requirements to control objectives before mapping to services. The same AWS configuration may support several requirements, but evidence must show that the control operated for the relevant scope and period.
AWS Artifact provides access to supported AWS compliance reports and agreements. AWS Audit Manager can help collect and organize evidence for supported frameworks and custom assessments. AWS Config supplies configuration evidence. CloudTrail records many control-plane actions. Security Hub CSPM provides supported control and finding views. None decides that the customer is compliant. The customer must address shared responsibility, applicability, compensating controls, evidence quality, exceptions, and management acceptance.
Evidence should be attributable, time-bounded, protected, reproducible, and understandable. A screenshot is often weaker than a versioned configuration plus execution record and independent query. Record collection method and limitations. When a control fails, determine affected scope and duration, reduce risk, assign remediation, preserve the exception decision, and retest.
| Need | Strong pattern | Warning |
|---|---|---|
| Restrict prohibited services or actions across accounts | Tested SCP at the appropriate OU | SCP does not grant required permissions |
| Establish repeatable account baselines | Account vending plus Control Tower/IaC and ownership metadata | Enrollment without lifecycle ownership creates orphaned accounts |
| Deploy a standard across accounts | Governed StackSet or approved pipeline | Broad execution role can become an escalation path |
| Detect resource drift | Config or source-to-runtime comparison with owner | Detection without remediation and exception flow becomes noise |
| Collect audit evidence | Requirement-to-control mapping plus Artifact/Audit Manager/log/config evidence | Tool output is not a compliance conclusion |
| Remediate a known unsafe state | Bounded automation with idempotency, approval as needed, and rollback | One generic auto-fix can disrupt critical workloads |
A company is adding 80 AWS accounts across regulated and unregulated products. Teams want autonomy, while security requires centralized logs, approved Regions, encryption, identity federation, and evidence for audits.