Hello everyone.
After playing around for about 6 months with GCP/AWS and Serverless Framework, we have decided to rethink our AWS Organisation structure entirely.
Why reorganise AWS?
Because our current way of doing things actually limits us, and we need to lift those limits.
Here is what’s the most annoying thing at the moment:
Only I can use the Serverless framework, because we created a
serverless-adminIAM user withAdministratorAccesspermissions.
This user is used to manage everything through Serverless, from staging to production applications.
- If I give this user to any collaborator, I take the risk that any of them can destroy anything on the production environments.
- If I don’t give it, then none of them can access staging environment.
Of course, at the beginning, it didn’t matter much because I was mostly playing around doing a bunch of R&D and testing all those amazing things like Lambdas and alike. But now, I need to be able to allow other people into the playground and get dirty. #scalability
That particular limitation is what I aim to fix, by restructuring our usage of AWS.
How to reorganise AWS?
That’s what I’m currently wondering. I’ve talked with several people about the Serverless Framework’s particular case, where you basically need to give a “admin” role to your collaborators so that they can actually use it.
Especially at the beginning because it just makes life easier to get started with. (and because there is nothing critical online at that moment)
Also, we all noticed how setting up IAM properly is a pain, so many permissions to deal with, so difficult to figure out what you actually need. Using an “admin” role is just so much simpler.
But this practice doesn’t scale, you can’t add new people and give them “admin” permissions. That’s where we are, trying to change our AWS structure and looking for a proper solution that’ll hold for years to come and will scale with the upcoming people and projects.
That’s where AWS Organisations and AWS Accounts come into action. The first thing is to understand how those two should be used.
I’ve had a long discussion with other SLS members (thanks to Franklin and Rob) on Slack, see Slack
AWS Organisation
An Organisation is the top-level block or your company on AWS, you should only have one. It’s where you manage AWS Accounts, consolidated-billing (overview for all Accounts) and top-level DNS.
AWS Account
An Account can represent different things, depending on how you decide to use it.
It can be a person, an environment, a product+environment, and many other things. It totally depends on your design.
An Account has its own billing unit and permission unit.
When you first sign up on AWS, you automatically create an Account. Quite often, that same account is used to become the Master Account of your AWS Organisation
The Master Account shouldn’t be an environment nor product, it shouldn’t contain any deployed service. It should just handle top-level configuration like top-level DNS (your main domain name). The email linked to the Master account shouldn’t be an individual, but rather an alias.
Then, depending on how you want to manage your company, you may use AWS Accounts in different ways, but in my case, it’s as follow:
AWS accounts:
Master account (has access to AWS Organisation configuration)
Consolidated Billing (for all other AWS Accounts)
Top-level DNS and Route 53 domain management
IAM Users (with cross-account access when needed)
Account production
Account staging
Account development
Production, staging and development Accounts have their own AWS Services, unit billing, etc.
When a User needs access to multiple accounts (dev + staging for instance), it’s handled through “cross-account” configuration.
This setup provides enough flexibility:
- You have both consolidated billing for all your accounts, and per-account billing. You know exactly how much cost you staging and production environments, separately. Even if you don’t use tags, it gives a good and reliable cost overview.
- Security is enhanced, each IAM User can be setup in a way that allows access to AWS Console, and programmatic access. Using the “switch role” feature allows for a smooth transition between the different roles (AWS Console)
Configuring which environment to works with, locally
Alright, now that there is a proper separation between environments, let’s talk about how it changes the way developers manipulate SLS on their machine.
Since every environment (production, staging, development) has its own Account, a User who has access to development will not have access to staging (I’m not sure, but I don’t think cross-account apply to programmatic access, it may only work for Console access), one simple way to properly configure your multiple AWS IAM credentials, is through the use of Profiles.
There are several ways of doing it, I prefer the automated way which chooses the right profile based on the environment you’re deploying to.
Ressources:
- AWS security credentials - AWS Identity and Access Management
- Security best practices in IAM - AWS Identity and Access Management
- https://www.quora.com/Can-I-create-an-AWS-account-under-a-company-name-Do-AWS-accounts-even-have-names/answer/Paul-Beda
- Enable a New Feature in the AWS Management Console: Cross-Account Access | AWS Security Blog
- Sample Serverless.yml for multiple AWS accounts needed!
This post is a work in progress, it’s a struggle to setup AWS properly, and anticipate how your company will grow and how you should organise it. The goal here is to build some kind of “AWS Setup Guide” from the experience and feedbacks of the community. Don’t hesitate to ask questions and share your own struggles! I also may misunderstand some parts of AWS and don’t hesitate to tell me if so!
