6 minute read

AWS Multi-Account Security Architecture: A Practical Guide

An AWS multi-account architecture creates boundaries for ownership, production risk, security administration, logging, and billing. The account structure is useful only when the organization also defines how accounts are created, which controls are inherited, who can administer shared services, and how exceptions are reviewed.

This guide owns the landing-zone and account-boundary intent in the Daily DevOps security cluster. For a service-by-service baseline, begin with the AWS security best-practices checklist.

Reviewing an AWS organization? Schedule a multi-account security assessment or use the contact page to share the current account inventory and governance constraints.

The core account model

A practical starting model separates responsibilities that should not share the same administrators or blast radius.

Account or OU Primary purpose Important boundary
Management account Organizations, billing, and landing-zone administration Do not run ordinary workloads or day-to-day security operations here
Security tooling Delegated administration and security operations Restrict who can change organization-wide security configuration
Log archive Protected organization logs and evidence Separate log writers from readers and deletion authority
Shared services Directory, tooling, artifact, or other approved shared capabilities Treat dependencies and cross-account access as explicit contracts
Network Central network capabilities where the operating model requires them Avoid centralization that obscures ownership or creates an untested single failure path
Production workload accounts Production services grouped by ownership and risk Keep production access and changes separate from development
Non-production workload accounts Development, test, sandbox, and training Apply spend, data, and exposure limits appropriate to the environment

The exact OU tree is less important than the decision record. A separate account is justified when ownership, data sensitivity, compliance scope, deployment lifecycle, or recovery requirements need a stronger boundary.

Management account discipline

Keep the Organizations management account focused on tasks that require it. Use delegated administrator accounts for supported security services and tightly limit persistent access.

For root access, follow current AWS root user best practices. AWS supports centrally managing root access for member accounts, which can remove member-account root credentials and provide controlled access to root-only tasks. Whether adopting that capability immediately or not, document the management-account recovery process and monitor root activity.

Delegated security administration

Use a security tooling account as the delegated administrator for services that support it, such as Security Hub CSPM, GuardDuty, Inspector, Detective, and IAM Access Analyzer. Delegation reduces daily dependence on the management account, but it does not automatically configure every account and Region.

For each service, record:

  • delegated administrator account;
  • enabled accounts and Regions;
  • organization auto-enable behavior;
  • configuration policy or baseline;
  • finding destination and owner;
  • suppression and exception rules; and
  • a test showing that a finding reaches the response workflow.

The AWS Security Reference Architecture is the authoritative starting point for security services across management, security tooling, log archive, network, shared services, and workload accounts.

Centralize logs without losing evidence integrity

An organization trail and other service logs should write to a protected destination in the log archive account. The team that investigates logs may need read access, but routine workload administrators should not be able to change retention or delete evidence.

Validate the path rather than assuming centralization works:

  1. Perform a known API action in a non-production workload account.
  2. Find the management event in the central trail.
  3. Confirm the log object is protected by the intended bucket and key policies.
  4. Test the alert for a trail change or delivery failure.
  5. Record who can read, change retention, and authorize deletion.

Identity and cross-account access

Use IAM Identity Center or another federated identity provider for workforce access. Map job functions to permission sets and assign them to accounts through groups. Avoid a unique hand-built role pattern in every account.

For machine access:

  • prefer short-lived role sessions;
  • scope trust policies as carefully as permissions policies;
  • use external IDs or source conditions where the trust relationship requires them;
  • keep CI/CD deployment roles separate by environment and blast radius; and
  • review unused services and actions with last-accessed information.

Every cross-account role should have a named owner, purpose, caller, target resources, session controls, and review date.

Preventive and detective guardrails

Service control policies set the maximum available permissions for identities in affected accounts. They do not grant permissions. Start with narrowly scoped controls that prevent a clearly unacceptable action, test them in a non-production OU, and maintain a controlled recovery path.

Detective controls show when resources drift from policy. AWS Config and Security Hub CSPM can provide findings, but a finding without ownership and remediation criteria is only another dashboard row.

A useful guardrail record includes:

Field Example
Intent Prevent disabling the organization trail outside the approved administration role
Scope Production workload OUs
Enforcement SCP plus alert on attempted change
Exception Time-bound approval with account, owner, and expiration
Test Attempt the denied action in a test account and verify the alert
Recovery Named break-glass path and rollback instructions

Account vending and lifecycle

Account creation should produce an owned, usable, and observable environment. AWS Control Tower provides a managed landing-zone experience with account enrollment and controls. Account Factory for Terraform can fit organizations that want a Terraform pull-request workflow around Control Tower account provisioning.

An account request should capture:

  • business and technical owner;
  • environment and data classification;
  • cost center and budget contact;
  • required Regions and network connectivity;
  • privileged-access groups;
  • log, security, and backup baseline;
  • decommission trigger and retention requirements.

Retirement matters as much as creation. Close or quarantine unused accounts only after data retention, DNS, identity, shared-resource, and billing dependencies are reviewed.

A concrete implementation example

The following is an illustrative design pattern, not a claimed client case study.

A team needs separate production and development accounts for an internet-facing service. The organization places them in different OUs, assigns workforce access through separate permission sets, deploys through environment-specific roles, and sends CloudTrail and application security logs to the log archive. GuardDuty and Security Hub CSPM use the security tooling account as delegated administrator. Production denies leaving the organization and restricts unapproved Regions; development adds a tighter budget workflow and scheduled cleanup.

The validation is concrete:

  1. Provision both accounts through the supported vending workflow.
  2. Deploy a minimal test workload through CI/CD.
  3. Attempt one prohibited action and confirm denial plus alerting.
  4. Generate a safe test finding and verify central routing.
  5. Locate a deployment event in the protected log archive.
  6. Remove the test workload and confirm the lifecycle process cleans up dependencies.

This exercise proves the control path before the organization scales the pattern across more teams.

A 90-day implementation sequence

Days 1–30: inventory and foundation decisions

  • Inventory accounts, owners, root-access posture, Regions, and existing trust relationships.
  • Define the initial OU and core-account model.
  • Decide management-account access and delegated administrators.
  • Document central logging and evidence-retention requirements.

Days 31–60: baseline and test

  • Establish federation and permission sets.
  • Configure organization logging and security-service coverage.
  • Apply a small set of tested preventive and detective guardrails.
  • Provision one non-production account through the target workflow.

Days 61–90: onboard and operate

  • Onboard one workload with explicit production readiness criteria.
  • Run a finding, access, log-delivery, and recovery exercise.
  • Measure account-vending lead time, exceptions, uncovered Regions, and control drift.
  • Improve the workflow before onboarding the next group of accounts.

Evidence to retain

Keep these artifacts current:

  • account and OU inventory with owners;
  • delegated-administrator and Region-coverage matrix;
  • identity assignments and privileged-access review;
  • SCP and control decision records;
  • organization trail and log-destination validation;
  • account-vending input and output evidence;
  • exception register with expiration dates; and
  • exercise results for findings, recovery, and account retirement.

Frequently asked questions

Should Security Hub run in the management account?

Use a delegated administrator account for steady-state Security Hub CSPM operations where supported. Keep the management account focused on organization administration.

Does every application need its own account?

No. Separate accounts when ownership, environment, data, compliance, lifecycle, or blast-radius requirements justify the boundary.

Should service control policies be broad from day one?

No. Start with a small, testable set of controls, deploy them to a test OU, and verify the recovery path before wider enforcement.

Contact Jon Price to review an AWS multi-account architecture.

Updated:

You may also enjoy