Most teams enable AWS Organizations, create a few OUs, and stop there. They’ve technically set up multi-account management, but they’re missing the configurations that actually matter. The difference between an Organizations setup and a production-ready one isn’t the org chart: it’s the policy types, service integrations, and delegated administrators you configure from day one.
Here’s the problem: AWS Organizations supports eight distinct policy types, thirty-plus service integrations, and delegated administration for dozens of services. Most of these get ignored during initial setup, creating governance gaps that surface later as security incidents, compliance failures, or cost overruns. By then, retrofitting these controls is significantly harder than enabling them early.
This po…
Most teams enable AWS Organizations, create a few OUs, and stop there. They’ve technically set up multi-account management, but they’re missing the configurations that actually matter. The difference between an Organizations setup and a production-ready one isn’t the org chart: it’s the policy types, service integrations, and delegated administrators you configure from day one.
Here’s the problem: AWS Organizations supports eight distinct policy types, thirty-plus service integrations, and delegated administration for dozens of services. Most of these get ignored during initial setup, creating governance gaps that surface later as security incidents, compliance failures, or cost overruns. By then, retrofitting these controls is significantly harder than enabling them early.
This post covers the specific AWS Organizations configurations that reduce risk in multi-account environments. Not theory: the settings we configure in every Landing Zone deployment to establish baseline governance before the first workload runs.
Enable Critical Policy Types Early
AWS Organizations supports eight policy types that control everything from maximum permissions to backup requirements. Most teams only use Service Control Policies (SCPs), leaving seven other policy types untouched. That’s a mistake.
Here’s which policy types to enable and why:
| Policy Type | Enable? | Primary Use Case |
|---|---|---|
| AI Services Opt-Out Policies | If handling sensitive data | Prevent AI services from using customer content for training |
| Backup Policies | Recommended | Enforce organization-wide data protection standards |
| Chat Applications Policies | If using Amazon Q Developer | Control access to chat applications (Slack, Teams, Chime) |
| Declarative Policies (EC2) | Recommended | Durable security configurations (IMDSv2, block public snapshots) |
| Resource Control Policies (RCPs) | Recommended | Data perimeter - restrict external access to resources |
| Security Hub Policies | If using Security Hub | Control where Security Hub is enabled across regions |
| Service Control Policies (SCPs) | Required | Maximum permission boundaries for principals |
| Tag Policies | Recommended | Standardize cost allocation and resource management tags |
Enable these policy types during initial Organizations setup, even if you’re not attaching policies immediately. Enabling a policy type doesn’t enforce anything: it just makes the capability available. Enabling them later requires additional change management and coordination that you don’t need when you’re establishing baseline configuration.
Why These Policy Types Matter
Resource Control Policies:
- SCPs control what principals can do; RCPs control what can be done to resources
- Establish a data perimeter by restricting permissions granted through resource-based policies
- Prevent S3 bucket policies, KMS key policies, and STS trust policies from allowing external access
- Essential for data perimeter strategy: prevent resources from being accessed outside your trust boundary
Backup Policies:
- Define backup requirements once and enforce across every account automatically
- New accounts inherit backup policies from parent OU immediately upon creation
- Eliminate inconsistent backup coverage and missed resources
- Prevent the discovery during incidents that critical data wasn’t being backed up
Declarative Policies:
- Enforce configuration at the service control plane level, not through IAM
- Govern service-linked roles and prevent non-compliant API calls regardless of invocation method
- Maintain desired state even when AWS introduces new features or APIs
- Examples: enforce IMDSv2, block public EBS snapshots, prevent public AMI sharing
Tag Policies:
- Standardize tags applied to resources across your organization
- Enable accurate cost allocation, resource lifecycle management, and compliance checks
- Define required tags (
CostCenter,Environment,Owner) and enforce on resource creation - Enforcement through AWS Resource Groups prevents non-compliant tagging
Service Control Policies:
- Set maximum available permissions for IAM users and roles in member accounts
- Central control over actions principals can perform: acts as permission guardrails
- Restrict even administrator access in member accounts
- Only denies permissions; does not grant any permissions
- Does not affect the management account or service-linked roles
SCPs are foundational and deserve detailed treatment. We’ve covered them extensively in AWS Service Control Policies Explained and provided practical implementation examples in AWS SCP Examples. For this post, we’re focusing on the other policy types that frequently get overlooked.
Configure Essential Service Integrations
Service integrations enable AWS services to operate across all accounts in your organization through trusted access. Without these integrations, services like CloudTrail, Config, and Security Hub operate in isolation within each account, eliminating the centralized visibility that makes multi-account architectures manageable.
Here are the critical service integrations to enable:
| Service | Integration Type | Why It Matters |
|---|---|---|
| AWS Backup | Trusted Access + Delegated Admin | Centralized backup monitoring and policy enforcement |
| CloudTrail | Trusted Access + Delegated Admin | Organization trail logs all API activity across accounts in one place |
| Config | Trusted Access + Delegated Admin | Centralized compliance monitoring and resource inventory |
| Declarative Policy for EC2 | Trusted Access | Enable policy enforcement at EC2 service control plane level |
| Firewall Manager | Trusted Access + Delegated Admin | Deploy WAF rules, security groups, Network Firewall policies org-wide |
| GuardDuty | Trusted Access + Delegated Admin | Automatic threat detection across all accounts from central location |
| IAM Access Analyzer | Trusted Access + Delegated Admin | Identify resources shared outside organization boundary |
| IAM Identity Center | Trusted Access + Delegated Admin | Single sign-on access to all accounts using corporate credentials |
| Resource Access Manager | Trusted Access | Share resources across accounts without invitations |
| Resource Explorer | Trusted Access + Delegated Admin | Search and discover resources across all organization accounts |
| Security Hub | Trusted Access + Delegated Admin | Aggregate security findings from all accounts for unified threat response |
| Service Quotas | Trusted Access | Automatic quota increases for new accounts via templates |
| Systems Manager | Trusted Access + Delegated Admin | Centralized operations management and change control |
| Tag Policies | Trusted Access | Enforce tagging standards across organization (policy type, not service) |
Special: Account Automation and Provisioning
| Service | Integration Type | Why It Matters |
|---|---|---|
| AWS Control Tower | Trusted Access | Automated landing zone setup with guardrails and Account Factory |
| CloudFormation StackSets | Trusted Access + Delegated Admin | Deploy infrastructure across accounts with single operation |
Control Tower and CloudFormation StackSets are essential if you want to automate AWS account provisioning and infrastructure deployment across your organization. Control Tower provides Account Factory for automated account creation with pre-configured guardrails, while StackSets enable infrastructure-as-code deployment at scale. For comprehensive guidance on implementing these capabilities, see our post the learn more about what an AWS Landing Zone is and how you can utilize it to manage your AWS accounts.
Why These Specific Integrations
AWS Organizations supports over 45 service integrations. We’ve selected these specific integrations because they address the core governance, security, and operational requirements every multi-account environment needs:
- Security and Compliance Foundation: CloudTrail, Config, Security Hub, GuardDuty, and IAM Access Analyzer provide the observability and threat detection required to maintain security posture across accounts
- Access Management: IAM Identity Center centralizes workforce access, eliminating the need for IAM users in each account
- Operational Efficiency: Systems Manager, CloudFormation StackSets, and Control Tower enable centralized operations and automated account provisioning
- Data Protection: AWS Backup enforces consistent data protection standards through backup policies
- Resource Management: Resource Access Manager simplifies cross-account resource sharing, Resource Explorer enables discovery, and Service Quotas prevents quota-related issues in new accounts
- Configuration Enforcement: Declarative Policy for EC2 and Tag Policies ensure configuration standards persist across the organization
Enable these integrations early. The other 30+ service integrations serve specialized use cases: add them when your requirements demand them, not during initial setup.
When to Enable Trusted Access:
- Enable during initial Organizations setup, even before configuring individual services
- Trusted access creates the foundation: allows services to create service-linked roles and perform organization-scoped operations
- Minimal risk enabling early: creates capability but doesn’t consume resources until you configure the service
- Some services require trusted access before organization features work (even from management account)
- Enable proactively to avoid blocking deployments later when you need organization-wide capabilities
Service Dependencies to Consider:
- Firewall Manager requires Config enabled in all accounts before it can deploy policies
- Security Hub aggregates findings from GuardDuty, IAM Access Analyzer, and other security services
- Control Tower creates CloudTrail organization trails and Config aggregators automatically
- Plan your enablement sequence to satisfy dependencies and avoid configuration failures
Organizational Structure Considerations
Your OU structure directly impacts how policies inherit and which accounts are affected by organization-level configurations. A well-designed OU structure makes policy management predictable and reduces the risk of misconfigured accounts.
Policy Inheritance Basics
Policies attached to the organization root affect all accounts. Policies attached to an OU affect all accounts in that OU and all accounts in child OUs. Policies attached to an account affect only that account. This inheritance model means your OU structure determines policy scope.
A Practical OU Structure
Start with a basic structure that separates security concerns from workload operations:
Root
├── Security OU
│ ├── Log Archive Account
│ ├── Security Account
│ └── Audit Account
├── Infrastructure OU
│ ├── Network Account
│ ├── Shared Services Account
│ └── Operations Account
└── Workloads OU
├── Development OU
│ └── Dev Accounts
├── Staging OU
│ └── Staging Accounts
└── Production OU
└── Production Accounts
This structure supports policy inheritance patterns that reduce risk. Security accounts in the Security OU inherit SCPs that prevent resource deletion and enforce strict access controls. Infrastructure accounts inherit policies that allow broader AWS service access for platform operations. Workload accounts inherit environment-specific policies (development accounts get permissive policies, production accounts get restrictive ones).
How OU Design Impacts Policy Management
With this structure, you can attach a backup policy to the Workloads OU that applies to all development, staging, and production accounts but not to security or infrastructure accounts. You can attach tag policies to the organization root that require Environment, Owner, and CostCenter tags on all resources across all accounts.
You can attach SCPs to the Production OU that enforce IMDSv2, require encryption, and block public access without affecting development accounts where teams need more flexibility. The OU structure makes these policy scopes obvious and manageable.
Keep It Simple Initially
Don’t over-engineer your OU structure in the first iteration. Start with Security, Infrastructure, and Workloads OUs. Add child OUs (like Development, Staging, Production) when you have multiple accounts in each environment and need different policies for each.
Avoid deeply nested OU structures (five or six levels deep) unless you have hundreds of accounts and clear policy differentiation at each level. Deep nesting makes policy troubleshooting difficult because the effective permissions are the intersection of policies from every level in the hierarchy.
For more comprehensive guidance on OU patterns for different organizational growth stages, see our post on AWS multi-account strategy.
Set Up Delegated Administrators Correctly
In the organizational structure above, you created dedicated accounts with specific functions: Security Account for security services, Operations Account for operational tools, Log Archive Account for centralized logging, and Network Account for shared networking resources. These aren’t arbitrary divisions. They’re designed to support delegated administration, which moves service management out of the management account and into these purpose-built member accounts.
The management account should be nearly empty: no workloads, minimal resources, restricted access. Delegated administrators make this possible by moving service administration to dedicated member accounts. This reduces the attack surface of your management account and implements separation of duties across your organization.
Understanding Trusted Access
Before you can designate delegated administrators, you must enable trusted access for the service at the organization level. Trusted access is the foundation that allows AWS services to perform operations across all accounts in your organization.
When you enable trusted access for a service:
- AWS Organizations creates service-linked roles in member accounts automatically
- The service gains permissions to read your organization structure (accounts, OUs, policies)
- The service can perform organization-scoped operations like aggregating data or deploying configurations
- Member accounts designated as delegated administrators can query the organization structure
- Delegated administrators can perform administrative actions across all member accounts for that specific service
Without trusted access enabled, services operate in isolation within individual accounts. With trusted access enabled, you unlock organization-wide capabilities, but you still need to designate a delegated administrator to manage those capabilities from a member account instead of the management account.
The Security Benefit of Delegated Administration
Service Control Policies don’t affect the management account. That means you can’t use SCPs to restrict what principals in the management account can do, creating a privileged environment that’s difficult to secure. Delegated administrators solve this by moving administrative operations to member accounts where SCPs do apply.
A delegated administrator for Security Hub operates from a member account (typically in a Security OU). That account can be restricted by SCPs, monitored like any other member account, and isolated from workload operations. If the delegated administrator account is compromised, the blast radius is limited to that service’s scope, not your entire organization.
Which Services Should Have Delegated Administrators
Not every service needs a delegated administrator, but security and operational services should be delegated to dedicated accounts:
| Service | Recommended Admin Account | Reason |
|---|---|---|
| Security Hub | Security Account | Centralize security findings management away from management account |
| GuardDuty | Security Account | Threat detection administration by security team |
| Macie | Security Account | Sensitive data discovery managed by security team |
| IAM Access Analyzer | Security Account | External access analysis by security team |
| Inspector | Security Account | Vulnerability management by security team |
| CloudTrail | Log Archive Account | Centralized audit log management with restricted access |
| Config | Security Account | Compliance monitoring by security/compliance team |
| Firewall Manager | Network Account | Firewall policy management by network team |
| CloudFormation StackSets | Operations Account | Infrastructure deployment by platform team |
| Systems Manager | Operations Account | Operational management by platform team |
| Backup | Operations Account | Backup policy and monitoring by operations team |
This delegation model aligns administrative responsibilities with team boundaries. The security team manages security services from the Security Account. The platform team manages infrastructure deployment from the Operations account. The network team manages firewall policies from the Network account.
Implementation Best Practices:
- Create dedicated accounts for delegated administration, not mixed with workload accounts
- Security accounts should contain security service delegated admins only, not production workloads
- Apply SCPs restricting delegated administrator accounts to their specific service scope
- A Security Hub delegated admin doesn’t need EC2, S3, or Lambda permissions
- Document which accounts serve as delegated administrators for each service in your runbooks
- Make this mapping easily discoverable during incident response
Common Mistakes to Avoid:
- Don’t register too many delegated administrators without clear ownership: each represents elevated permissions requiring defined ownership, access controls, and monitoring
- Don’t use the management account as a delegated administrator: the point is moving administration out of the management account
- Don’t skip applying restrictive SCPs to delegated administrator accounts: they should only have permissions for their specific service scope
- Don’t forget to document the delegated administrator mapping in your runbooks for incident response
Moving from Setup to Production-Ready Governance
The configurations covered in this post represent the difference between an AWS Organizations setup and a production-ready multi-account environment. Enabling policy types, configuring service integrations, and establishing delegated administrators during initial setup prevents the retrofit work that dominates organizations that skipped these steps.
These configurations aren’t theoretical best practices: they’re the baseline controls required to operate a multi-account AWS environment at scale without creating compliance gaps, security vulnerabilities, or operational bottlenecks. Get them right during initial setup, and your organization scales smoothly. Skip them, and you’ll spend months implementing governance controls after discovering they should have been there from the start.
title=“Build Your AWS Foundation the Right Way” subtitle=“Get expert guidance on multi-account architecture, governance, and compliance. We’ll design a scalable landing zone tailored to your organization’s needs.” href=“/services/aws-landing-zone” buttonText=“Schedule AWS Foundation Assessment” />
Written by Danny, Founder @ towardsthecloud → Helping startups cut costs and ship faster on AWS.
FYI; I’m also building cloudburn.io → Help developers catch expensive infra in PR’s before they deploy on AWS Cloud.