This is the first post in the “Essential Guide to AWS Governance” series. In this series I will drill down into different areas of governance on AWS. I will also provide in-depth recommendations and implementation guides to form a framework around an efficient and automated governance approach.
If you are interested you can also see all the other posts in this series:
- Essential Guide to AWS Governance – Part 2: Enable Single Sign-On for AWS using ADFS 3.0 and configure Cross Account Access
- Essential Guide to AWS Governance – Part 3: Enable CloudTrail on your AWS Accounts and deliver logs to a central S3 Bucket
- Essential Guide to AWS Governance – Part 4: Send CloudTrail logs from AWS Accounts to a central Elasticsearch Instance and visualize them using Kibana
- Essential Guide to AWS Governance – Part 5: Save cost on AWS using Roham
When we talk about governance we are mainly targeting larger organizations which host multiple projects on AWS. However many of these recommendations and guides apply to smaller organizations as well. It is just a matter of finidng the right fit.
This post is dedicated to best practices on structuring AWS Accounts.
Q. What are the essential AWS Accounts that you need for your governance strategy?
Here are the AWS Accounts you need and their purpose:
- Billing Account: On this Account:
- Enable consolidate billing. That means all your other Accounts will not be billed separately and their bills will be consolidated under this Account.
- Create an AWS Organization and make sure all the other Accounts are members of this Organization.
- Any new Account under the AWS Organization will automatically be configured to use consolidated billing.
- Security and Auditing Account: On this Account:
- Configure Single Sign-On with SAML using ADFS.
- Enable CloudTrail and configure all the other Accounts to send their activities to this Account.
- Shared Resources Account: On this Account:
- Place the shared services which will be used by all the other Accounts. i.e. Route53
- Place all your automation tasks/functions to be executed against the project Accounts.
- Project Account: This account is dedicated to your project/application. In a normal case:
- Each project/application has its own dedicated AWS Account.
- You could have separate Accounts for the Test, Development, Staging, and Production environments of the same project/application. You could also have all these environments in the same Account and isolate them from one another. That really depends on your own preference and of course in some cases depends totally on the sensitivity of your data and services.
- Enable Cross-Account Access to allow access into this account from the Security and Auditing Account. This helps SSO access into every single project Account.
The diagram below shows the structure in a visual format and also shows the relation between the Accounts:
In the diagram above there are three separate project Accounts together with the three other standard Accounts.
In the next posts in this series we will cover the details in each of these accounts and of course the processes which should exist in each of them. We will also cover some of the automation techniques which need to be created to make life easier in the cloud.