Account Strategy

Organize based on security and operational needs

This recomendation is from AWS but we’ve explicitly called it out so that we can apply our interpretation to it.

“… organize accounts using OUs based on function, compliance requirements, or a common set of controls rather than mirroring your organization’s reporting structure.”

Allowing for other AWS recommendations that we will adopt, if we need to expand our organisational structure, we anticipate that the structure will most likely follow the governance i.e. accounts governed by the same TDA committee will sit in the same OU.

AWS Design principles for your multi-account strategy

We have chosen to adopt the following recommendations

• Apply security guardrails to OUs rather than accounts
• Avoid deep OU hierarchies
• Start small and expand as needed
• Avoid deploying workloads to the organization’s management account
• Separate production from non-production workloads
• Assign a single or small set of related workloads to each production account

Initial Organisations Structure

Our initial target is similar to the AWS example Basic organization with CI/CD as a separate function.

We have added the Policy Staging OU but removed the Sandbox OU as we do not intend to target these types of accounts at launch.

• Root
  • Security
    • Prod
  • Infrastructure
    • Prod (see AWS recommendation)
  • Deployments
    • Prod
  • Workloads
    • Prod
    • Test
    • Dev
  • Policy Staging
    • In this example, a set of child OUs mirrors an overall OU structure

We expect that the following OUs will be required in the near future and will consider them soon

• Suspended
• Exceptions
• Business Continuity

References

Design principles for your multi-account strategy