Study guide
10.3 Multi-Account Security: Organizations, SCPs & Identity Center
AWS Certified CloudOps Engineer – Associate SOA-C03
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Monitoring & Observability Infrastructure
1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms
2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation
2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda
3 Chapter 3: Performance Optimization for Compute, Storage & Databases
3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance
4 Chapter 4: Compute & Database Scalability and Elasticity
4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB
5 Chapter 5: High Availability, Fault Tolerance & Load Balancing
5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments
6 Chapter 6: Backup, Data Protection & Disaster Recovery
6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience
7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK
7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures
8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC
8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows
9 Chapter 9: Systems Manager & Event-Driven Operations Automation
9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation
10 Chapter 10: Identity, Access Management & Governance
10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs
11 Chapter 11: Data Security, Encryption & Vulnerability Management
11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings
12 Chapter 12: VPC Architecture, Endpoints & Network Protection
12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing
13 Chapter 13: DNS, Route 53 Routing & Content Delivery
13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator
14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity
14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting
10.3 Multi-Account Security: Organizations, SCPs & Identity Center
Key Takeaways Explain This Topic AI
AWS Organizations establishes a multi-account management hierarchy with Organizational Units (OUs), consolidated billing, and centralized governance, while isolating blast radiuses across workloads.
Service Control Policies (SCPs) act as central guardrails that set the maximum allowable permissions across member accounts; SCPs filter permissions and never grant access.
SCPs apply to all IAM users, IAM roles, and the account root user within member accounts, but the management account is strictly exempt from all SCP restrictions.
Adopting a deny-list strategy with the default FullAWSAccess policy attached at the root enables operators to surgically enforce guardrails, such as restricting regions, blocking root actions, and preventing audit tampering.
AWS IAM Identity Center centralizes workforce access by federating with external IdPs (via SAML 2.0 and SCIM) and provisioning standardized Permission Sets across AWS accounts and OUs.
Last updated: September 2026
10.3 Multi-Account Security: Organizations, SCPs & Identity Center
CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your ability to govern multi-account AWS environments using AWS Organizations, establish organizational guardrails via Service Control Policies (SCPs), deploy hardened SCP patterns that protect security infrastructure and enforce regional restrictions, and centralize workforce identity and single sign-on using IAM Identity Center.
Multi-Account Architecture: Management Account & OU Hierarchy
Operating enterprise workloads in a single AWS account creates severe blast-radius risks, shared service limit bottlenecks, and complex audit boundaries. Modern cloud operations enforce a multi-account architecture managed through AWS Organizations .
Account Roles: Management vs. Member Accounts
Management Account: The root anchor of the AWS Organization. Manages consolidated billing, account creation, SCP authoring, and cross-account delegations. Operational Rule: Application workloads, public endpoints, and production databases must never run in the management account.
Member Accounts: Dedicated accounts that contain workloads or platform services, subject to organizational policies.
Organizational Unit (OU) Hierarchy
Organizational Units (OUs) group accounts into logical containers to apply shared governance hierarchically (nestable up to 5 levels deep):
Core / Base OU: Houses foundational shared services, including the Log Archive Account (immutable centralized CloudTrail and VPC logs) and the Security Tooling Account (delegated administrator for GuardDuty, Security Hub, and IAM Access Analyzer).
Workloads OU: Hosts business services, segmented into Production (strict compliance and immutable change control) and Non-Production (development and testing) child OUs.
Sandbox OU: Isolated accounts for developer prototyping with no connectivity to internal corporate networks.
Consolidated Billing
Consolidated billing rolls all member account charges into a single invoice. It delivers automatic volume pricing discounts on tiered services (S3 storage and KMS requests) and allows Savings Plans and Reserved Instances purchased in one account to cover matching usage across all member accounts.
Service Control Policies (SCPs): Guardrails & Evaluation Mechanics
Service Control Policies (SCPs) are JSON guardrails attached to the Root, OUs, or individual accounts that establish the maximum allowable permissions across member accounts.
Core SCP Evaluation Principles
SCPs Never Grant Permissions: SCPs define permission boundaries. An account principal must still be granted explicit access by an identity-based or resource-based policy.
Effective Permissions are an Intersection: An action is permitted only if it is explicitly allowed at each hierarchical level (Root -> Parent OU -> Child OU -> Account) and never denied by an SCP.
Management Account Immunity: The management account is completely exempt from all SCPs. SCPs never restrict management account root, users, or roles.
Member Account Scope: Within member accounts, SCPs govern all IAM users, all IAM roles, and the account root user .
Service-Linked Role Exemption: SCPs do not affect service-linked roles , ensuring internal AWS service workflows (e.g., Auto Scaling, ELB) are never disrupted.
Allow-List vs. Deny-List Strategy
Allow-List Strategy: Removing the default FullAWSAccess SCP from the Root requires explicitly listing every approved action. This strategy is operationally brittle because new AWS service launches remain blocked until SCPs are updated.
Deny-List Strategy (Recommended): Retains FullAWSAccess at all levels and attaches custom SCPs containing explicit Deny statements. Because explicit denies override all allows, this approach enforces strict guardrails without impeding standard service adoption.
Essential CloudOps SCP Patterns
Production environments employ standardized SCP patterns to enforce non-negotiable security guardrails:
1. Protecting Security & Audit Telemetry
Prevents member accounts from disabling CloudTrail logging, deleting trails, or stopping AWS Config recorders: {
- "Effect": "Deny",
- "Action": [
- "cloudtrail:StopLogging",
- "cloudtrail:DeleteTrail",
- "cloudtrail:UpdateTrail",
- "config:DeleteConfigRule",
- "config:StopConfigurationRecorder"
- ],
- "Resource": "*"
- }
- 2. Preventing Member Accounts from Leaving the Organization
Blocks unauthorized disconnection by denying organizations:LeaveOrganization .
3. Restricting Allowed AWS Regions (Geo-Fencing)
Restricts resource provisioning strictly to approved operating regions (e.g., us-east-1 and us-west-2 ). It uses NotAction to exempt global services that lack regional endpoints: {
- "Effect": "Deny",
- "NotAction": [
- "iam:*",
- "organizations:*",
- "route53:*",
- "cloudfront:*",
- "sts:*",
- "support:*"
- ],
- "Resource": "*",
- "Condition": {
- "StringNotEquals": {
- "aws:RequestedRegion": ["us-east-1", "us-west-2"]
- }
- }
- }
- 4. Enforcing IMDSv2 on EC2 Launches
Mitigates SSRF vulnerabilities by denying ec2:RunInstances when ec2:MetadataHttpTokens is not set to required .
5. Denying Root User Actions in Member Accounts
Denies API operations executed by member account root credentials using Condition: {"ArnLike": {"aws:PrincipalArn": "arn:aws:iam::*:root"}} .
IAM Identity Center: Centralized Workforce Access & Federation
Managing individual IAM users across 50+ member accounts leads to credential sprawl and delayed deprovisioning. AWS IAM Identity Center (successor to AWS Single Sign-On / AWS SSO) centralizes workforce access.
External Identity Provider (IdP) Federation
SAML 2.0: Federates with corporate identity providers (Microsoft Entra ID, Okta, Ping Identity, Google Workspace) for single sign-on using existing corporate credentials and MFA.
SCIM (System for Cross-domain Identity Management): Automates user and group synchronization. When an employee is offboarded in Okta or Entra ID, SCIM instantly removes their identity from AWS IAM Identity Center, revoking access across all AWS accounts simultaneously.
Permission Sets & Multi-Account Role Provisioning
A Permission Set defines an access profile bundling AWS managed policies, customer managed policies, or inline policies, along with session durations (15 minutes to 12 hours). When an administrator assigns a Permission Set to a user or group in a target account:
IAM Identity Center automatically provisions a corresponding IAM role in that member account prefixed with AWSReservedSSO_* .
Trust policies and role lifecycles are managed transparently by Identity Center.
User Experience & CLI Access
Employees log into a centralized AWS access portal ( https://my-company.awsapps.com/start ) displaying all authorized accounts and permission sets. Developers using the AWS CLI v2 authenticate using aws sso login , which retrieves and caches temporary STS credentials without storing long-term access keys on local machines.