If you’re in charge of a team of developers building a serverless application and your number one goal is to have them deliver quality software to users as fast as possible, then you should do whatever’s in your power to get them their own individual AWS account.

I’ve discussed approaches for managing shared accounts or projects in the past, but in this post I want to talk about sandboxed AWS accounts that are paid for by the company but are for use only by an individual developer. Here’s why I think they are a good idea…

Fully local development workflows are suboptimal or even impossible in serverless stacks

In traditional server-based development projects, developers would typically run the full stack on their local development machine. Once a feature is ready and merged into the main branch, it would be deployed (either via a CI/CD process or manually by an engineer) to a shared environment for further testing.

In serverless stacks however, while local emulators do exist for some cloud-native services (e.g. DynamoDB Local), I almost always want to use the real cloud services for a few reasons:

• It’s faster and less error prone to consistently setup across the team (baseline cloud environments are more homogeneous than individual developer machines)
• It reduces integration bugs that “worked on my machine” (e.g. often around IAM permissions or infra config)
• I only need to configure a resource once (e.g. using CloudFormation YAML) rather than first manually creating and configuring a local emulator at dev time and having to separately configure the cloud equivalent once my feature is ready to integrate.

Given that Lambda functions are probably the resource developers will be iterating upon most frequently, we don’t want one developer deploying changes over the top of another one. You could introduce a naming convention to prevent such collisions, but that adds unnecessary complexity to your configuration management.

You give developers more exposure to infrastructure management

One of the big benefits of serverless architectures is that in many (most?) cases you should no longer need an engineer 100% dedicated to managing and operating the infrastructure of your system. But a corollary of this is that your developers will need to improve their DevOps skills, in particular around Infrastructure-as-Code and configuration management . By entrusting each developer with their own cloud account, you automatically expose them to these concepts at an early stage from within the safety of their own sandbox.

The good news is that this learning curve should be quite shallow as serverless cloud services are generally much simpler to configure than server-based systems that involve EC2 instances and VPCs.

You give less experienced developers more confidence to experiment

Often a large part of the development process involves experimentation and trial and error. If a developer is new to software development in general or just new to serverless, then this is even more the case.

I was working on a project for a client recently where the CTO wanted to jump in and fix a bug in an API to help out his team who were busy working on other projects. He is a highly experienced developer and architect but was new to serverless. At the time, he hadn’t his own personal AWS development account set up. He was easily able to identify and make the necessary changes to the codebase to fix the bug but couldn’t deploy and test his changes. There was a shared DEV account available but this was being used as the backend for a mobile app that was due to be demoed to a client the following day and so was nervous about breaking it. Basically he needed a sandbox to safely experiment in before being confident enough to deploy to this shared account.

A much more egregious example I witnessed was a large enterprise who used a single AWS account for a whole department of developers who were responsible for delivery of a range of products. This one account contained a mishmash of resources for different projects/products, personal resources for individual developers and resources for all shared environments (including production 😱). Being productive as a developer in those conditions was a real challenge, never mind all the security concerns!

Common objections

Isn’t this a big admin overhead to have to set this up?

There is a small overhead but this only needs to be done once whenever a new developer joins your team. Each developer can re-use the same personal AWS account for different projects. You can use AWS Organizations to provision the account from a master account without needing to separately enter credit card details, etc. If you are doing this very frequently, you can create a script using the AWS CLI to automate the entire account provisioning process.

How will we control costs?

I have 2 recommendations on this point:

1. Give developers read-only access to the Billing Dashboard for their own account (this isn’t enabled by default). Not only does this treats them like responsible adults who can manage their own money (!) but also encourages them to be curious about the costs of the cloud services they are consuming.
2. Developers aren’t always responsible adults! Be sure to set up a billing alert with a sensible threshold so a senior person can be notified if a rogue developer starts mining bitcoin (or more likely, accidentally triggers an infinitely recursive loop of Lambda invocations).

Another mitigation to the cost objection (that’s specific to fully serverless systems) is that serverless cloud resources have pay-per-use pricing. So you won’t be getting billed for an EC2 instance that a developer who infrequently helps out your team forgot to turn off. And you’ll often find that each developer’s usage of a service won’t exceed the free tier quota, so will be costing you next to nothing.

What about security?

Developer accounts will be completely isolated from other AWS accounts within your organisation so cannot interfere with important resources. If you’re concerned about the actions developers take within their personal account, you can use AWS Organizations to set a Service Control Policy on all child accounts to limit the specific AWS services they have access to.

Our IT department simply won’t allow this

Big enterprise red tape can be a real PITA for dev teams looking to ship quality software fast to their users. But it is what it is and if this is you, you have my sympathies. I don’t have a great recommendation for you here other than to use whatever influence you do have to lobby whoever is making this decision and educate them on the overall benefits of building serverless apps for your organisation as a whole.

In your place of work, how are AWS accounts allocated? Do you have your own personal one? Let me know in the comments...

💌 If you enjoyed this article, you can sign up to my newsletter. I send emails a few times a week where I share my guides and deep dives on building serverless solutions on AWS with hundreds of developers and architects.

Originally published at winterwindsoftware.com.