Organization Policies

AWS Organizations manages multiple AWS accounts from a central management account. It provides account grouping, policy enforcement, and consolidated billing.

Organizational structure: The management account (formerly master account) owns the organization. Member accounts are grouped into Organizational Units (OUs). OUs can be nested for hierarchical structures. Example: a company might have a production OU (containing web, api, and database accounts), a staging OU, and a security OU.

Consolidated billing combines all member account usage into a single bill from the management account. Benefits include: volume discounts across accounts (data transfer pricing tiers apply to aggregate usage), RI and Savings Plan sharing (commitments in one account apply to eligible usage in other accounts), and simplified payment (one credit card, one bill).

RI sharing across accounts: Reserved Instances and Savings Plans purchased in the management account apply to any member account in the organization. This means one team can purchase commitments that benefit the entire organization, maximizing utilization and savings.

Service Control Policies (SCPs) are permission boundaries that apply to member accounts. SCPs do not grant permissions; they restrict the maximum permissions available. An SCP denying ec2:RunInstances limits what IAM users in that account can do, regardless of their IAM policies. SCPs are inherited from parent OUs and the organization root.

SCP approaches: Deny-list approach (start with full access, deny specific actions) is common for initial deployment. Allow-list approach (start with no access, explicitly allow specific actions) provides stricter control. Most organizations use a hybrid: deny-list for broad restrictions (no leaving the organization, no leaving approved regions) and allow-list for specific workloads.

Deny-list SCPs start with full access and deny specific actions. A common deny-list SCP: deny leaving the organization (aws:Organizations), deny disabling CloudTrail, denying resource creation outside approved regions, and denying specific instance types without approval. This approach is easy to deploy because it doesn't break existing workloads.

Allow-list SCPs start with no access and explicitly allow only required actions. A restrictive allow-list: allow only EC2 in us-east-1 and eu-west-1, allow only specific S3 buckets, and allow only the required IAM actions. This approach is secure but requires careful planning to avoid blocking necessary access.

SCP inheritance: SCPs apply from the root down. A member account inherits SCPs from the root, its parent OU, and any ancestor OUs. The effective SCP is the union of all inherited policies. If the root denies action X and the parent OU allows action X, action X is denied because deny takes precedence in SCPs.

SCP maximum permissions: An SCP limits what IAM users and roles can do. If an SCP denies ec2:TerminateInstance, even the account root user cannot terminate instances. This is powerful for guardrails but dangerous if misconfigured. Always test SCPs in a non-production account first.

Practical SCP strategy: Start with a baseline SCP that denies: leaving the organization, disabling CloudTrail, leaving approved regions, and creating IAM users without MFA. This protects the organization without breaking existing workloads. Gradually add restrictions as the organization matures.

SCP example - region restriction: Deny all actions where the requested region is not in the approved list. This prevents data from leaving approved geographic locations, which is critical for compliance (GDPR, HIPAA, data sovereignty). Use the aws:RequestedRegion condition key in the SCP.

Tag policies define standard tags and their allowed values across the organization. An organization might mandate: Environment tag can only be prod, staging, or dev; CostCenter tag must be a 4-digit number; Owner tag must be a valid email. Tag policies prevent inconsistent tagging that makes cost reporting unreliable.

Tag policy enforcement: Tag policies can be set to enforced (blocks non-compliant resource creation) or auditing (allows but reports violations). Start with auditing to identify gaps, then move to enforcement. Enforced tag policies require resources to have compliant tags before they can be created.

Tag policy inheritance: Tag policies apply from the root down. A child OU inherits the most restrictive policy from its parent. If the root specifies 3 allowed values for Environment and the parent OU specifies 2, the child inherits the 2-value restriction.

AWS Organizations backup policies define organization-wide backup standards. Create a policy that mandates: all RDS databases must have daily automated backups with 35-day retention, all EBS volumes must have weekly snapshots, and all DynamoDB tables must have on-demand backups. Attach the policy to the organization root or specific OUs.

Backup policy benefits: Consistent backup across all accounts without individual configuration. New accounts automatically inherit the policy. Compliance auditors see a single policy governing all accounts. Backup policies can be delegated to a backup administrator account.

AWS Organizations AI service policies control access to AI services like Amazon Bedrock, Rekognition, and Comprehend. An AI service policy can restrict: which foundation models can be used, whether AI services can process sensitive data types, and which regions AI services can operate in. This prevents unauthorized use of AI services and ensures compliance with data governance requirements.

Example: A financial organization mandates that Amazon Bedrock cannot process customer PII data without explicit approval. The AI service policy denies bedrock:InvokeModel for the claude-3-opus model unless the request includes a specific tag indicating compliance approval. This prevents engineers from accidentally sending sensitive data to AI models.