AWS accounts
AWS account structure
Email lists
These accounts are all managed by the management account. They have contact details and a root email address attached to them, they are set via the following distribution lists:
| Purpose | |
|---|---|
| aws-accounts+$name@goodfit.io | root email |
| aws-account-security+$name@goodfit.io | security |
| aws-account-finance+$name@goodfit.io | finance |
| aws-account-ops+$name@goodfit.io | operations |
AWS Accounts
| Name | Account no | Purpose |
|---|---|---|
| dev | 698342338567 | Main development env - use this for developing code and deploying unmerged things |
| staging | 318574063456 | Staging account - things are tested here after merging to main |
| test | 310112903397 | Main test environment - this will be depreciated in favour of dev |
| playpen | 463843035186 | Used for developer adhoc testing, e.g. new AWS services |
| production | 891197216009 | Production environment |
| tools | 975050230633 | Used for revops activities, mainly used by Alex |
The setup of the management account has been done by hand and any of these manually created or altered resources could be imported into terraform at a later stage easily enough. These docs aim to outline the steps taken to perform the basic setup.
Any further changes will be done via IaC in either Terraform, CDK or the Serverless framework.
Control Tower Setup
We have used control tower to setup the AWS account structure following AWS recommended best practices.
This initial setup was point and click, and we have only deviated from the defaults altering log retention, setting a kms encryption key and adding the control tower product to the service catalog. All of these things are documented by amazon and are in step by step guides.
We have set log retention to 5 and 10 years respectively for cloudtrail logging and aws access logs to adhere to future SOC2 requirements.
We have created our own KMS key for cloudtrail and log encryption (as recommended) and setting the permissions according to the docs.
We also created a cloudformation stackset to deploy the control tower execution role to organization migrated child accounts.
IAM Identity Setup
We have simply added users and invited them via email manually here. We have created some groups and made people a member of those groups with pre-canned aws policies. There was no other manual setup steps performed.
AWS Root account access
We are following the AWS recommended best practices here.
We have deleted all the root account logins for the child accounts in our organization.
The root account should be used as a last resort and should be avoided due to security risks.
There is only one root account aws-account@goodfit.io and that password is stored in a dedicated 1password vault. Furthermore, this is secured by MFA.
At least two users should have access to this root account at any one time, and each user whilst they have access to the password, also has each of their MFA devices added to the account.
In future there should be two groups of people, ones with access to the password, and others with access to the MFA, so that two people have to come together to use it.
It is important that the users who have access to this are aware that losing access to both devices will cause significant issues trying to get AWS to remove them and gain access once again. Therefore, if you lose access to your mfa, contact the other persons with access to amend your MFA device. The final warning is not to store your password and MFA in the same place, like in your one password record.
Additionally, in future there will be an alert setup on root login.