Cloud-hosting account structures
As a new startup bootstrapping, or an existing company looking to better organise there existing cloud estate, the correct design of your underlying cloud account structure is key to obtaining a solid on which to enable stability, security, and growth.
Getting this right can have a massive impact on the security, maintainability, scalability, and audibility of your cloud estate. This one (often overlooked) design decision sets the tone and structure for your deployment in any cloud. Effecting placement of every other cloud resource, and [prehapse] more importantly setting the nomenclature and ground rules for how engineers and architects will interact with and build on top of your cloud estate.
Every cloud architect will have their own favourite strategy for account placement, and reasons why theirs is to be prefered. Over the last eighteen years, I have been lucky enough to work alongside some very talented engineers, on many different styles of architecture. The following is my chosen cloud account structure, suitable for any enterprise from startup to growth over $1B.
Note: Every company/project is different, you are encouraged to read this article, take the contents as a base, and then adapt for your own use case.
Account types
Root
The root account is the master account used for billing and super-user management. Access to this account should be tightly managed, and resources should not be deployed here.
Login
Integration account for SSO providers, or account containing all IAM users. Users enter through this account and then assume roles in other accounts. Resources should not be deployed here.
Production
Account for production compute workloads. Put your production apps, services, and servers here. Data resources will go in a separate account. Read and write access to this account must be limited, and closely audited.
Non-production
All non-production compute workloads. This will include “pre-prod”, “staging”, “test”, “QA”, “dev” or any other such environments. The non-production account should never process production or sensitive data. A single Non-production account for all non-prod environments is suggested as this allows flexibility, new environments can be created and removed as needed without the need to provision a new account. As all non-prod accounts should be copies of prod (or subsets of prod), it should be possible to generate these on the fly as needed in the non-production account.
Data
Account for production data workloads (and storage). This is kept separate from production compute workloads for security and audit purposes. Often the users for data resources are different from compute, and security constraints around data are different from those of compute workloads. As such, separating data and compute allows for easier control of auth, auditing and billing.
Non-production-data
All non-production data environments. As with the non-production compute account, this should never contain production or sensitive data. If data is being imported into this account from [production] Data it should be sanitised in the [production] Data before export. The structure of this account can mirror that of the non-production compute account.
Corp
Account for any corp IT resources. This may include AD servers, office file shares, backup jobs. Startups may not need this account.
Shared
Shared dev resources such as build servers and CD servers. Resources here may access all production and non-production accounts (to deploy resources).
Audit
Audit and logging resources. Logs and audit records for all other accounts can be found here.
Other accounts
There are other accounts which may be needed for more complex deployments, these may include: state (for Terraform state), transit (for VPN/peering and complex networking), security (for GuardDuty and other security workloads), and 3rd-party (for external use).
Do you have your own favourite account structure you like to use for your deployments? Have any improvements or comments on mine? I’d love to hear them, get in touch!
