A blog about doing things with computers

Blog | Archive | Twitter | Github | Rss

AWS Account structure - An Opinionated Post

01 Nov 2016 | aws, accounts, environments

I tend to work on a lot greenfield projects where we create AWS stuff from scratch. When I roll down somewhere the very first thing I need to think about is account structure. There are pros and cons to various account structures. There’s no ‘right’ way to do this but I’m going to cover why I generally prefer multiple accounts.

However, as with every technical decision, it’s not perfect and there are trade offs:


If going with multiple accounts I have a couple of reccommendations to make things a little smoother and have some things to avoid:

Don’t create one account per application evironment

Very often in places where testing has typically been hard you notice that there can sometimes be many different application environments. E.g DEV1, SIT7, UAT1, QA3 etc.. Creating an account per one of these is a really bad idea. It’s going to become complicated and expensive to manage. Instead think of environment accounts as different classes of infrastructure. I.e. You’re development area is where you put things that may occasionally break. Staging might just be there because we want something that is an exact clean replica of production where we can debug production issues with impacting live users and avoid getting swamped by any API limts in development.

What about hybrid things?

We may also want an account for core services which are common. For example, is your CI server development or production? You might think, if it goes down no live users of my application are impacted so it’s development I guess. However, often CI servers are the only way something can get into production, so if it’s broken you have no way of deploying to prod. What about monitoring? If it’s down the users don’t care. However, if something breaks in the middle of the night you have no way of knowing. There may be a need for a tooling classification of infrastructure which we should treat like production but doesn’t necessarily impact users. Another reason for doing this is that putting this stuff in the development or production account means that environments could become inconsistent. For example put CI in the prod account and you may not need any assume role stuff in production, but it may be required in development. Environment inconsistencies are evil and have often been the source of much drama throughout my career.

Peer accounts

Self explanatory, unless you like having to sign in on different browsers with some in incognito mode etc..

Treat all your accounts like production

Yes, I know this sounds contradictory but your accounts are just a way of diving up APIs. People who want to run bitcoining mining on your accounts don’t care what name you give it. You should have MFA enabled for all your human user accounts not just production. Just because it’s development it doesn’t make it any less desirable to someone who wants to spin up 3000 EC2 instances and charge you for it. If you’re hitting API limts on development you are wasting a lot of peoples time with people waiting to run things. All your accounts are important!

Older · View Archive (11)

Terraform outputs in Ruby Code with ruby-tfoutputs

This post details a way to get your terraform outputs into your Ruby code. I wrote a little ruby gem to handle it. Why might you do this? Well good question, sometimes people like to write some scripting that uses things from terraform outputs. Of course you can just make a command line call to terraform output which is pretty simple. After writing this gem I was wondering whether or not I should have bothered:


AWS Big Brother - What's it for?

This post details a command line tool I’ve written called awsbigbrother. It can be used to audit AWS accounts and check that you are not exposed in certain areas. The mentality behind it is continuous checking and monitoring for security issues.