AWS / Advanced: reliability, security, and governance / Lesson 17
Multi-account governance and guardrails
Design account ownership, federated access, policy boundaries, evidence, and exceptions without assuming organizational structure automatically grants or isolates authority.
On this page
Lesson goals
- Explain the assumptions, responsibilities, and trade-offs of multi-account governance and guardrails.
- Interpret both examples and distinguish declared intent from verified evidence.
- Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.
Separate workload and governance responsibilities
Multiple accounts can separate environments, ownership, blast radius, and billing allocation, but the access and operational model must be designed. A development account is not safe merely because of its name. AWS Organizations supplies supported account and policy management features; landing-zone products and patterns add their own setup and responsibilities. Keep management and security administration narrowly owned, and avoid ordinary workload activity in highly privileged governance contexts. Record account purpose, owner, approved Regions, data classification, access path, audit coverage, and recovery duties. Cross-account roles and resource policies can reconnect boundaries that a diagram appears to separate.
Treat SCPs as scoped permission ceilings
Service control policies constrain applicable permissions for principals in member accounts and do not grant actions. Their scope, policy inheritance, and exclusions must be read from current documentation; notably they do not restrict users or roles in the management account. Other organization policy types have different supported targets. The first illustrative SCP denies one regional EC2 launch action outside a chosen example Region. It is not a complete residency policy, does not grant launches inside that Region, and is never attached. A broad policy rollout can lock out legitimate operations, so test impact in an authorized isolated organizational scope before real adoption.
{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"ec2:RunInstances","Resource":"*","Condition":{"StringNotEquals":{"aws:RequestedRegion":"eu-west-1"}}}]}
The chosen Region is an example, not a location recommendation. The deny is limited to the named action and applicable SCP scope; it grants nothing and does not establish complete data residency or cost control.
Use workforce and workload identity deliberately
Workforce federation and IAM Identity Center can support centralized human access under their configured permission and account assignments. Workload roles and service integrations serve a different identity path. Keep role trust, permission policy, session conditions, and resource authorization distinct. Emergency access needs accountable ownership, protected authentication, limited duration where supported, and review afterward. Do not distribute root credentials or shared long-lived keys to simplify cross-account support. A successful central sign-in does not prove a user should administer every member account or that every assigned permission remains necessary after a team changes responsibilities.
Make evidence and cost ownership cross-account
Central audit, security visibility, backup coordination, network services, and cost allocation need their own permissions, retention, service support, and failure-domain analysis. The second matrix assigns owners without publishing real account IDs or resource names. Consolidated billing and tags do not automatically provide a complete workload cost boundary or data-access policy. Protect log and backup destinations from accidental deletion and review access to sensitive metadata. A centralized dependency can become a shared outage or compromise path, so document which operations still work when governance or identity services are unavailable and how authorized recovery proceeds.
concern accountable owner evidence
workload account application team resource and data contract
central access identity team reviewed assignments and sessions
security audit security owner coverage and protected retention
shared network platform owner bounded routes and dependencies
financial allocation project and finance declared scope and current billing
The table assigns review responsibilities rather than real permissions. Each shared function can have separate operational and failure boundaries that need verification.
Govern exceptions and lifecycle changes
Policy changes, account moves, new trust relationships, Region expansion, and account closure can alter authority and recoverability. Assign owners, record exact scope, test negative cases, and give exceptions an expiry and exit procedure. An account that appears unused may still contain retained backups, keys, commitments, or external trust dependencies. No organization, account, OU, SCP, identity assignment, billing configuration, scan, or cloud request is created, inspected, or changed in this lesson. Static JSON and synthetic records illustrate decisions only. Effective governance makes safe paths usable and risky authority visible; it is not a folder hierarchy that substitutes for application and security ownership.
Common errors and fixes
An SCP allow is treated as an IAM grant
- Why it happens
- A guardrail was confused with assignment of permission.
- How to fix it
- Review identity, resource, session, and organization evaluation.
- Prevent it next time
- Test allowed and prohibited operations for exact principals.
A management-account principal is assumed constrained by member SCPs
- Why it happens
- Policy scope and exclusions were not checked.
- How to fix it
- Use the documented management-account protection model.
- Prevent it next time
- Minimize and audit governance identities.
Account cleanup breaks recovery or trust
- Why it happens
- Retained resources and cross-account dependencies were ignored.
- How to fix it
- Inventory ownership, keys, copies, commitments, and trust first.
- Prevent it next time
- Use a reviewed account-lifecycle procedure.
Check your understanding
1. An SCP permits a service action in a member account. Can a role with no applicable grant use it?
Show worked solution
The SCP is not the grant. Evaluate the role and resource policies, session context, other constraints, and documented exceptions. A maximum permitted boundary does not create the authority needed for the request.
2. Why should a Region guardrail not be advertised as complete data-residency proof?
Show worked solution
Its supported actions, services, principals, scope, and exceptions may not cover every copy, log, transfer, external processor, or global feature. Data residency needs a complete workload and contractual review, not one condition key in an illustrative policy.
Key takeaways
- Multiple accounts can separate environments, ownership, blast radius, and billing allocation, but the access and operational model must be designed.
- Workforce federation and IAM Identity Center can support centralized human access under their configured permission and account assignments.
- Policy changes, account moves, new trust relationships, Region expansion, and account closure can alter authority and recoverability.