AWS Organization Management Account and OU Best Practices¶

Overview¶

The recommended AWS architecture is to use a dedicated AWS Management Account as the administrative account for the AWS Organization.

The Management Account should be used for:

AWS Organizations administration
Organizational Unit (OU) management
Account creation and account lifecycle management
Billing and consolidated cost management
IAM Identity Center administration
Organization-wide governance

The root user of the Management Account should not be used for routine administration. Administrative tasks such as creating OUs should be performed by an appropriately privileged IAM Identity Center role or IAM role.

Recommended AWS Organization Structure¶

AWS Organization
│
├── Management Account
│   ├── AWS Organizations
│   ├── Billing
│   ├── IAM Identity Center
│   └── Organization Administration
│
├── Security OU
│   ├── Security Account
│   └── Log Archive Account
│
├── Infrastructure OU
│   ├── Network Account
│   └── Shared Services Account
│
├── Workloads OU
│   ├── Databricks Dev Account
│   ├── Databricks Prod Account
│   └── Application Accounts
│
└── Sandbox OU
    └── Developer / Sandbox Accounts

Management Account vs. Root User¶

AWS Organizations has one designated Management Account. A separate "Organization Management Account" should not be created.

The distinction is:

Component	Recommended Use
Management Account	Organization-level administration
IAM Identity Center	Human administrative access
Organization Admin Role	OU/account/policy administration
Root User	Break-glass and root-only operations
Member Accounts	Workloads and infrastructure

The Management Account should remain isolated from application and workload resources.

Creating OUs¶

Recommended¶

Administrator
      │
      ▼
IAM Identity Center
      │
      ▼
Organization Administrator Role
      │
      ▼
Management Account
      │
      ▼
AWS Organizations
      │
      ├── Create OU
      ├── Create Account
      ├── Move Account
      └── Attach SCP

An administrator should sign in through IAM Identity Center and assume a role with the permissions necessary to manage AWS Organizations.

Avoid¶

Management Account
      │
      ▼
Root User
      │
      ▼
Create OU

The root user should not be used for routine AWS administration.

Root User Best Practices¶

Treat the Management Account root user as a break-glass account.

Recommended controls:

Enable MFA for the root user.
Do not create root access keys.
Do not use root credentials for CLI or Terraform.
Do not share root credentials.
Restrict access to root credentials.
Store recovery information securely.
Monitor and audit root-user activity.
Use root only when an operation specifically requires root credentials.

Recommended Account Structure for Databricks on AWS¶

For a Databricks AWS implementation, a multi-account structure provides better security, isolation, governance, and cost management.

                         AWS ORGANIZATION
                                │
                 ┌──────────────┴──────────────┐
                 │                             │
        MANAGEMENT ACCOUNT              SECURITY OU
                 │                             │
        Organizations                  ┌────────┴────────┐
        Billing                        │                 │
        IAM Identity Center        Security Account  Log Archive
        Governance                       │             Account
                                         │
                                         │
                              INFRASTRUCTURE OU
                                         │
                              ┌──────────┴──────────┐
                              │                     │
                       Network Account       Shared Services
                              │                     │
                              │                     │
                       Transit Gateway          DNS / CI-CD
                              │
                  ┌───────────┴───────────┐
                  │                       │
            DATABRICKS OU             APPLICATION OU
                  │                       │
          ┌───────┴───────┐         Application
          │               │          Accounts
     Databricks Dev   Databricks Prod

Suggested AWS Accounts¶

Account	Purpose
Management Account	AWS Organizations, billing, governance
Security Account	Security Hub, GuardDuty administration, security operations
Log Archive Account	Centralized CloudTrail and security logs
Network Account	Transit Gateway, VPC networking, centralized network services
Shared Services Account	DNS, CI/CD, shared infrastructure
Databricks Dev Account	Development Databricks workspace
Databricks Prod Account	Production Databricks workspace
Application Accounts	Application-specific workloads
Sandbox Accounts	Developer experimentation and testing

Why Workloads Should Not Run in the Management Account¶

The Management Account should be treated as a highly privileged control-plane account.

Running workloads in the Management Account creates several risks:

Greater blast radius if credentials are compromised
Difficulty applying organizational controls
Reduced separation of duties
Increased risk of accidental administrative changes
Less effective SCP governance
More difficult auditing and compliance

For this reason, Databricks, EC2, RDS, S3 application workloads, and other production resources should be deployed in member accounts.

IAM Identity Center¶

Use AWS IAM Identity Center as the primary mechanism for human access to AWS accounts.

A typical structure is:

Corporate Identity Provider
          │
          ▼
AWS IAM Identity Center
          │
     ┌────┴────┐
     │         │
Admin Group   Developer Group
     │         │
     ▼         ▼
Management    Member Accounts
Account       / Workload Accounts

Use permission sets to control access.

Example permission sets:

OrganizationAdministrator
SecurityAdministrator
NetworkAdministrator
PlatformAdministrator
DatabricksAdministrator
Developer
ReadOnly

Grant the minimum permissions required for each role.

Service Control Policies¶

Use Service Control Policies (SCPs) at the OU level to establish organization-wide guardrails.

Example:

Management Account
       │
       ▼
AWS Organizations
       │
       ├── Security OU
       │      └── Security SCPs
       │
       ├── Infrastructure OU
       │      └── Infrastructure SCPs
       │
       ├── Databricks OU
       │      └── Databricks Guardrails
       │
       └── Sandbox OU
              └── Restrictive Sandbox SCPs

Potential controls include:

Restricting unsupported AWS Regions
Preventing disabling of CloudTrail
Preventing deletion of security logging
Restricting certain IAM operations
Restricting public access to sensitive resources
Preventing unsupported services
Enforcing security guardrails

SCPs should be tested carefully before applying them broadly.

Databricks and Transit Gateway Architecture¶

For the Databricks architecture, a dedicated Network Account is recommended.

                         AWS ORGANIZATION
                                │
                    ┌───────────┴───────────┐
                    │                       │
             Management Account       Network Account
                                            │
                                     Transit Gateway
                                            │
                     ┌──────────────────────┼──────────────────────┐
                     │                      │                      │
                     ▼                      ▼                      ▼
               Databricks Dev       Databricks Prod        Application VPCs
                     │                      │
                  VPC                     VPC
                     │                      │
               Databricks              Databricks
                Workspace               Workspace

This allows the Network Account to provide centralized network connectivity while keeping Databricks workloads isolated in dedicated accounts.

Recommended Administrative Model¶

Tier 1 — Root User¶

Purpose: Emergency/break-glass access only.

Do not use for:

Creating OUs
Creating accounts
Terraform
AWS CLI
Routine administration
Day-to-day console access

Tier 2 — Organization Administrator¶

Purpose: AWS Organization management.

Typical responsibilities:

Create OUs
Create accounts
Move accounts
Attach SCPs
Manage organizational policies
Manage IAM Identity Center assignments

Tier 3 — Platform Administrators¶

Purpose: Manage infrastructure and workloads.

Examples:

Network Administrator
Security Administrator
Databricks Platform Administrator
Application Platform Administrator

Tier 4 — Developers / Data Engineers¶

Purpose: Workload development and operations.

Access should be limited to the appropriate workload accounts and environments.

Recommended OU Design¶

A practical starting point is:

Root
│
├── Security OU
│   ├── Security
│   └── Log Archive
│
├── Infrastructure OU
│   ├── Network
│   └── Shared Services
│
├── Databricks OU
│   ├── Databricks Dev
│   ├── Databricks Test
│   └── Databricks Prod
│
├── Applications OU
│   ├── Application Dev
│   ├── Application Test
│   └── Application Prod
│
└── Sandbox OU
    └── Sandbox Accounts

The exact structure should be adjusted based on organizational size, security requirements, and environment separation.

Key Recommendations¶

Area	Recommendation
Organization	Use one dedicated Management Account
OU Creation	Use IAM Identity Center / assumed administrative role
Root User	Break-glass only
Workloads	Keep out of Management Account
Databricks	Use dedicated member accounts
Networking	Consider a dedicated Network Account
Security	Use dedicated Security and Log Archive accounts
Identity	Use IAM Identity Center
Governance	Use SCPs
Terraform	Use delegated/admin roles, not root
CLI/API	Use assumed roles, not root credentials
Production	Separate production accounts from development

Final Recommendation¶

For an enterprise AWS Databricks environment:

Do not use the Management Account root user to create OUs or administer the organization on a day-to-day basis.

Instead:

Create the AWS Organization using the Management Account.
Secure the Management Account root user with MFA.
Configure IAM Identity Center.
Create an Organization Administrator permission set/role.
Use that role to create and manage OUs.
Create dedicated Security, Log Archive, Network, Shared Services, and workload accounts.
Deploy Databricks into dedicated member accounts.
Use SCPs for organization-wide guardrails.
Use Transit Gateway from a dedicated Network Account when centralized VPC connectivity is required.
Keep the Management Account free of application and Databricks workloads.

This provides a strong foundation for a secure, scalable AWS Databricks multi-account architecture.