This is a guide for starting your AWS setup and by in large covers the areas you must look into to build a robust security and cost-optimized AWS setup.
Any single account setup is a bad idea which is going to bring numerous issues as you grow your platforms and applications and not only goes against AWS Best Practices, you are exposing your setup to huge security risks and you won’t be able to properly isolate your AWS setup.
Think of your AWS Account setup the same way medieval castles were designed,
Think of your AWS Account setup the same way medieval castles were designed, oversimplifying, walls within walls isolating critical areas from each other so if one area of the castle was compromised the blast radius of the compromise was contained to that specific area.
How do we apply this principle to AWS, separate the accounts according to logic which isolates them from each other and in case of an account level compromised you have a reduce blast radius of the compromise.
For this above example, your Production environment will be completely isolated from Development and Testing on different AWS Accounts and will have different access levels which give you the advantage, some bullet points:
- Different levels of access at the environment level mean that your Developers can change anything on the Dev Account and only have Read-Only access on the Production environment.
- Development environments are prone to have platforms or applications which aren’t 100% on security bugs etc and are at a higher risk of compromise.
- Having production and development data on the same AWS account is a risk since an error in configurations or code could lead to unwanted consequences, plus the risk of exposure.
- You cannot set proper permissions unless you break development, you have AWS IAM Policies which you can apply to users groups and roles on AWS, but, having 2x environments on the same AWS account means you have to be more restrictive to what developers can do and this will block them.
When you create your AWS Organisation the account you are logged in will be assigned the role of “Master” where you will create additional Organisation accounts and also add existing accounts if you choose to which will allow you to easily consolidate billing, but also set up your OU (Organisational Unit) structure so you can setup policies and settings accordingly.
In the case you have decided to setup your account structure throughout multiple accounts lets now look at the different types and purposes of the AWS accounts.
MASTER AWS ACCOUNT as we mentioned above this is the main account which by design will have access to all other accounts, leave the access to this account only to AWS Administrators with MFA enabled on all accounts as a minimum. I’ve seen some implementations where the user accounts are also here but the users themselves have very specific and limited access, but, configuration errors could cause compromise so we recommend users to be on a separate account.
DEVELOPMENT AWS ACCOUNT we recommend them to be separate accounts as well, the rationale is that DEVELOPMENT is the area for your developers have the freedom to build and change whatever they want to ensure autonomy as opposed to having very limited and restricted access, we want the developers to have the freedom to experiment and create PoC’s very quickly and autonomy, which is the opposite for any other accounts.
STAGING; INTEGRATION; TESTING AWS ACCOUNT make sense when there are many different development teams using different dev AWS accounts, you want to have a more stable environment for testing and integration testing (since dev is constantly changing) or for any other valid reason, this type of account will begin to give a more limited access, ideally you can only deploy and change the platform trough your CI/CD pipeline and this gives you a taste of what will happen when you deploy to Production.
COMPLIANCE & GOVERNANCE AWS ACCOUNTS is where all the configurations and logging information from other accounts is stored, a good example is, a hacker will try to delete all tracks to prevent them from being detected and traced, having these accounts isolated and with different levels of access to a very restricted number of users allow you to protect this information much more efficiently and again contribute to a smaller blast radius in case of compromise.
PRODUCTION AWS ACCOUNTS on this example we display 3x different accounts, one for your actual platform where only a very limited access is in-place (PRODUCTION AWS ACCOUNT) one for your Data Backup, a most recent Ransome Attack trend involved encrypting the customer data removing it’s access to it, plus you will secure your data on a different AWS Region (BACKUP AWS ACCOUNT) and lastly your Logs should be stored separately to avoid tampering (LOGS AWS ACCOUNT).
Setting this up by hand us obviously a time-consuming task and this is why AWS as introduced AWS Control Tower which allows performing a very advanced setup without the hassle of doing this by “hand”, we will cover this in more detail in another article.
