Organizations can choose between two architectural patterns to isolate and separate resources:
• Centralized Management: Minimum overhead with centralized information security management • Single Account Structure: All teams and departments within one AWS account • VPC Isolation: Use multiple Virtual Private Clouds for separation
• Account Isolation: Create separate AWS accounts with VPC in each account • Common Practice: Large and small organizations tend to use this approach • Business Unit Separation: Individual accounts for various business units • Environment Separation: Separate accounts for development, test, and production
Advantages
Isolation Benefits:
Challenges
Management Complexities:
• Common Resources Account: Single account for shared resources (DNS, Active Directory, CMS) • Autonomous Projects: Separate accounts for departments/projects • Cross-Account Access: Grant permissions and policies across accounts
Account management service for consolidating multiple AWS accounts into a centrally managed organization:
• Centralized Management: Consolidate and centrally manage multiple accounts • Account Creation: Streamlined account creation and management capabilities • Consolidated Billing: Single billing across all accounts with tier pricing discounts • Hierarchical Structure: Organize accounts in organizational units (OUs) • Policy Control: Centralized policy control using Service Control Policies (SCPs)
• Organizational Units (OUs): Hierarchically group accounts with different access policies • Nesting Support: Nest OUs within other OUs up to five levels deep • Fine-Grained Policies: Create and customize policies targeted to single or multiple OUs • Maximum Permissions Control: SCPs specify maximum permissions for member accounts
AWS Organizations builds upon IAM by expanding granular control to the account level, ensuring users can access only what both Organizations and IAM policies allow.
Create hierarchy of OUs in the primary account: • Root Container: Organization automatically creates parent container called root • OU Structure: Define OUs under the root based on organizational structure
Assign member accounts to appropriate OUs: • Member Account Assignment: Each AWS account assigned to specific OU • Multiple Assignments: Accounts can be organized by function, environment, or business unit
Create SCPs that apply permission restrictions to specific member accounts: • Policy Creation: Define SCPs with specific permission boundaries • Inheritance: Policies flow from root down through hierarchy
Attach SPCs to root, OUs, or individual accounts: • Root Attachment: Policies attached to root affect all OUs and accounts • OU Attachment: Policies can be attached to specific OUs • Account-Level: Individual account policy attachment possible
• Central Control: Offer central control over maximum available permissions • Service Access Control: Control which services are accessible to IAM users in member accounts • Account-Wide Impact: Define permissions affecting entire accounts • Guardrails: Set limits on actions account administrators can delegate • Cannot Override: SCPs cannot be overridden by local administrators
SCPs work in conjunction with IAM policies defined in individual accounts: • Boundary Setting: SCPs provide general service and permission boundaries • IAM Granularity: IAM policies set specific, granular access controls • Intersection Principle: Effective permissions are intersection of both policy types • Explicit Deny: Explicit deny in any policy overrides allows
• Service Blocking: Deny users from disabling AWS CloudTrail in all member accounts • Resource Tagging: Enforce tagging requirements (e.g., prevent EC2 AMI launch without specific tags) • Organization Protection: Prevent member accounts from leaving the organization
{"Version": "2023-06-17","Statement": [ { "Effect": "Deny", "Action": ["organizations:LeaveOrganization"], "Resource": "*" }]}This SCP prevents member accounts from leaving the organization by explicitly denying the LeaveOrganization action.
Permissions granted are those allowed in both an SCP and an IAM identity-based permissions policy:
• Intersection Principle: User permissions are calculated from combination of policies • Explicit Allow Required: User must have explicit permission in identity-based policy • SCP Boundaries: SCP sets limits on what identity-based policies can grant • Explicit Deny Override: Explicit deny in any policy overrides allows
Example scenario: If SCP allows S3 but not EC2, and identity-based policy allows both S3 and EC2, the effective permission is S3 only.
Advanced feature using managed policy to set maximum permissions for IAM entities:
• Maximum Permissions: Sets ceiling on what identity-based policies can grant • Entity-Specific: Applied to individual IAM users or roles • No Direct Permissions: Boundary doesn’t provide permissions, only limits them • Intersection Effect: Effective permissions are intersection of identity-based policy and permissions boundary
If permissions boundary allows only S3, CloudWatch, and EC2: • Identity-based policy granting IAM:CreateUser permission will fail • User cannot perform operations outside boundary scope • Even with appropriate identity-based policy, boundary limitations apply
User in Test OU with:
Results:
Scope: Applies to IAM entity (user or role)
Function: Defines maximum permissions that identity-based policies can grant
Permissions: Does not grant permissions
Usage: Scope which resources user/role can access
Example: Allow IAM role developer to access only EC2, S3, and CloudWatch regardless of other policies
Scope: Applies to all members of organization or OU
Function: Defines maximum permissions for account members
Permissions: Does not grant permissions
Usage: Deny access to specific sets of resources
Example: Deny access to Amazon RDS for all Internal IT OU members regardless of other policies
AWS Control Tower facilitates setup and governance of secure, multi-account AWS environment:
• Automated Setup: Well-architected multi-account environment based on best practices blueprints • Governance Rules: Security, operations, and internal compliance rules • Prescriptive Guidance: Govern AWS environment at scale • Landing Zone: Well-architected, multi-account baseline following AWS best practices • Guardrails: High-level rules providing ongoing governance expressed in plain language
• New AWS Environment: Building new AWS environment • Cloud Initiative: Starting new cloud initiative • AWS Beginners: Completely new to AWS • Existing Environment: Prefer solution with built-in blueprints and guardrails
• Landing Zone: Multi-account baseline with security and operational best practices • Guardrails (Controls): Governance rules for ongoing compliance and security • Built-in Blueprints: Pre-configured templates for common scenarios • Centralized Management: Single interface for multi-account governance
AWS Control Tower provides control over environment without sacrificing speed and agility AWS provides for builders.
Managing access across multiple AWS accounts requires strategic planning and the right tools. AWS Organizations provides the foundation for centralized account management, while SCPs and permissions boundaries offer granular control mechanisms. AWS Control Tower simplifies the entire process by providing pre-built, best-practice templates for multi-account environments, making governance and compliance more manageable at scale.