AWS 414: Organizations, SCPs, account vending, and deployment guardrails
Why this lesson matters
An AWS account is a security, quota, billing and failure boundary. Organizations groups accounts and applies policy; account vending creates repeatable boundaries and baselines; SCPs cap permissions. None grants application access or replaces identity, network, detective and recovery controls.
Organization and OU design
Use an all-features organization and keep workloads out of the management account. Separate security/log archive, infrastructure/shared services, production, nonproduction, sandbox and suspended/quarantine concerns according to ownership and risk. OUs are policy attachment and lifecycle groupings, not a direct mirror of every business hierarchy. Keep nesting understandable because inherited policy interactions become operational dependencies.
Register delegated administrators for supported security/operations services so daily administration avoids management-account credentials. Trusted access may create service-linked roles in member accounts; SCPs do not restrict service-linked roles, so understand the integrated service's permissions and disable trusted access carefully.
| Layer | Purpose | Does not do |
|---|---|---|
| Root/OU/account | Scope policy and lifecycle | Grant IAM access |
| SCP | Maximum permissions/explicit deny | Create an Allow |
| IAM/resource policy | Grant within boundary | Override an SCP deny |
| Tag policy | Standardize/report tag values | Universally enforce every request |
| StackSet/pipeline | Deliver baseline resources | Guarantee they stay configured |
| Config/security services | Detect/evaluate drift/findings | Replace preventive authorization |
SCP evaluation and safe design
An SCP affects member-account IAM principals, including root, but not the management account and not service-linked roles. Effective permission requires an IAM/resource-based authorization plus allowance through every relevant SCP level, with no applicable explicit deny. If replacing the default FullAWSAccess model with allow lists, required actions must be allowed at root, every parent OU and account attachment.
Prefer targeted denies for high-value invariants when teams need broad service choice: leaving approved Regions, disabling audit/security controls, changing protected roles, unencrypted/public data paths or leaving the organization. Conditions need exact global-service, requested-Region, principal/resource and exception behavior. Not every AWS service supports every condition key, and management/CloudFormation calls may invoke dependent actions.
Do not put a permanent broad administrator exception into every deny. Use narrow protected automation and recovery roles, control who can assume them, alert on use and test them. SCP changes are high-risk production changes: policy validation, simulator/evidence cases, canary OU/account, staged moves/attachments, observation, rollback and break-glass communication are mandatory.
Account vending lifecycle
An account request records owner, purpose, environment, data class, Regions, budget, network/connectivity, identity groups, support/operations, retention and expiry. Vending creates the account and baseline through a governed factory such as Control Tower Account Factory or an approved custom workflow; do not hand-build accounts inconsistently.
Baseline includes contacts, root protection, federation and recovery access, CloudTrail/Config/security enrollment, log delivery, budgets, approved Regions, DNS/network/endpoints, encryption keys, inventory/tags, backup policy, deployment roles and owner/on-call records. Verify every control in the member account and central aggregators before release. StackSet operation success alone is not an outcome.
Lifecycle covers owner change, exception expiry, OU moves, quarantine, account closure and retained evidence. Moving an account changes effective inherited policy immediately and can break workloads or weaken controls. Precompute source/destination effective policy and test required operations before movement. Suspended accounts still need cost, evidence and recovery ownership.
Inspection and failure proof
~~~bash aws organizations describe-organization aws organizations list-roots aws organizations list-organizational-units-for-parent --parent-id PARENT_ID aws organizations list-policies-for-target --target-id TARGET_ID --filter SERVICE_CONTROL_POLICY aws organizations describe-effective-policy --policy-type TAG_POLICY --target-id ACCOUNT_ID aws iam simulate-principal-policy --policy-source-arn ROLE_ARN --action-names ACTIONS ~~~
IAM simulation does not fully prove SCP/resource-policy/context behavior. Build a request matrix with principal, account/OU path, IAM grants, SCPs at every level, resource policy, boundary/session policy, conditions and expected decision. Execute authorized positive and negative tests in a canary account. Preserve CloudTrail request IDs and denial context.
Monitor account creation/move/leave/closure, policy create/update/attach/detach, trusted-access/delegated-admin changes, root use, baseline drift, failed StackSets, unenrolled Regions, stale owners, budgets and exceptions. Reconcile organization inventory against security, logging and billing systems.
Workshop and failure analysis
Design an organization for a fictional 40-account company, place ten workloads, and write five SCP invariants with 20 request cases. Build an account product, acceptance checklist, quarantine path and OU-move plan. Diagnose denials by tracing all policy layers instead of removing the SCP first.
Test 24 failures: workload in management account, OU mirrors org chart, nested inheritance missed, SCP treated grant, parent allow absent, explicit deny overlooked, management account assumed governed, service-linked role assumed blocked, global service broken by Region deny, unsupported condition key, exception principal broad, protected role mutable, CloudFormation dependent action denied, policy size forces unsafe wildcard, untested root attachment, canary skipped, baseline partial, StackSet success trusted, new Region ungoverned, account owner stale, OU move changes policy unexpectedly, quarantine blocks investigation, closure loses evidence, and break-glass untested.
Cost and acceptance
Organizations/SCPs have no direct charge, but Control Tower integrations, Config, CloudTrail, security services, StackSets resources, networking, logs and idle baselines do. This lesson creates nothing. Submit organization diagram, policy inheritance/request matrix, five SCPs, account product/acceptance evidence, rollout/rollback, recovery/quarantine lifecycle and all diagnoses. Pass requires correct SCP semantics, safe canary rollout, verified baseline and tested recovery access.