Security in the cloud is a topic that keeps coming around.  It’s often the number 1 reason people avoid the cloud, assuming (wrongly) that security or data protection laws mean they can’t adopt cloud infrastructure.  The reality is you’re probably more secure in the cloud.  In fact you can be highly secure for a much lower cost than on-premise alternatives.  In this second part I’ll suggest how to structure your AWS Account(s)

Master Account

On the surface of it, Public Cloud security is less secure than having a private infrastructure.  Nobody would give public internet access to their management console, but that’s exactly what you have in Public Cloud.  For that reason there’s a lot of focus on the security of the management console, and a few steps you should take beyond those of a traditional infrastructure.

The first step is to create multiple accounts.  You will probably host production and non-production loads in your environment.  In AWS accounts are free, so there’s no reason to have them in the same account.  IAM access is separate in each account, so there’s no risk users will gain access by mistake.  Why risk accidental misconfiguration of prod?  You can also be certain that your dev team doesn’t have access to the customer data.

Create a master payer account, and aim to have no infrastructure running here.  Keep access only to a very small group of the most trusted people.  (Possibly give access to billing only to your finance team).  From the master account, send a payer request to each sub-account.  This is the only thing that links the accounts in AWS terms.  Linking the accounts together means you get the same volume discount as if it were in a single account, and reserved instances can float across accounts if they’re not used in the account they are purchased.

Having multiple accounts is also useful for auditing purposes.  A pattern we routinely use is to duplicate (or centralise) cloudtrail files into the master account.  This means and sub-account that becomes compromised can’t modify the audit trail of how it happened.  We’ve also previously used Lambda and DynamoDB to detect changes (e.g. security group) compare the current config to the previous one, then create an email alert.

At some point, someone will suggest VPC Peering between the accounts, which creates the possibility of breaking the security benefits.  Remember here that network and OS level security is totally different than AWS Account level security, but mirroring the separation makes sense.

Instead use AMI sharing between accounts, use shared access S3 Buckets.  Consider creating another account for your central monitoring systems, authentication etc. rather than peer between VPC in different accounts.