Setting up developer AWS accounts for a new startup

When folks sign up to my newsletter, I have a short survey that asks ”what’s your number 1 question about using or adopting serverless in your organisation?”. A common question that I get asked is how to set up AWS accounts for their organisation, and specifically how to do so for development environments.

In the past, I have advocated for giving individual developers their own AWS account. While I still think this is a good option for teams with a more mature level of cloud and governance capability, I now generally recommend to most smaller teams and startups I work with to just create a single dev account that all developers can work within as this approach generally involves less administrative overhead while still allowing for developer autonomy.

Whichever of these two options you take, here are some key principles to follow when setting up AWS accounts and development environments for your team:

• Individual developers must be able to work in the cloud in isolation from other developers in their team and not just rely on working locally for this isolation. They should be able to deploy their own stacks of cloud resources and not share any with others in their own team. When using deployment frameworks such as Serverless Framework, SST or the CDK inside a shared single dev account, this means using a value for the stage argument which is unique for each individual developer on the team.
• Always use AWS Organizations to manage your AWS accounts in order to tie together billing and other governance functions.
• Use SSO instead of IAM users to authenticate developers into your AWS accounts.
• Enable billing alerts on all your AWS accounts so you are notified when a certain threshold may be exceeded.
• Ensure developers have visibility of the billing section of the AWS console (ideally for all accounts, but at least for development). They should be able to see how much the resources they’re provisioning are actually costing.
• Enable CloudTrail audit logging on all your AWS accounts so you can track which developers have performed what actions in each account.
• Never include production (or even UAT/staging) cloud resources in the same account as development environments. This separation is important to do at an early stage because once resources go into production usage, it becomes very hard to move them (usually everything non-production needs to move instead). For more info on creating AWS accounts for non-developer environments, see Deciding on what environments to create for a serverless team.

I’ve set up all this stuff for many startups building serverless apps on AWS, so if you need help with doing this, just hit reply to this email (or get in touch here if you’re reading the web version).