Organizations is a wonderful service in the AWS ecosystem, both for usability and security. While the cloud provides a lot of security controls within an account, a multi-account setup is far superior in several ways.
With multiple accounts, you don’t need to worry about setting up policies to prevent developers from accessing or disrupting critical resources, as they can be hermetically separated from the production account. This is a rare occasion where security and convenience are aligned: the production system is guaranteed to be left alone, while the devs can experiment with the technology without over-exacting controls.
The account creation process can be scripted all the way down to bootstrapping the new accounts with resources. The process is straightforward: provide an email address for the root user, name a role in the new account, and you are practically done.
With full API and CLI support, it can be automated. Also, with the role in the new account, you can script everything else you might need. With a click of a button, you can have a new AWS account with everything required.
The cherry on top is that you can also define Service Control Policies, that limit what the new account can do. Want to scope it down to only one region, or disable certain services? You can do it easily.
The only downside is that the new account is still considered a new account, so there is a few hours waiting period before you can launch instances. This is some kind of auto-check and it is still required even though the master account has already passed this.
Everything was fine, then one day one of your developers is leaving the company. You then need to get rid of his environment from the Organization.
This is the point when you realize that while creating an account is extremely easy, closing it down is burdensome.
The problems start with the root account. Unfortunately, the process for closing a member account is the same as closing a regular one:
- Log in with the root user
- Request closing the account
- Wait 90 days
And after the process, you can’t use the same email ever again.
Did you register the account with the email address of the leaving dev? Tough luck. You need to manually contact AWS to change the email.
Since you didn’t need to provide a password during account creation, how to sign in? It turned out that you need to request a password reset to the registered email and then you can set a password and finally log in.
When you create an account, there is no confirmation at all. Mistyped a character? Contact support. And the worst part is that it’s likely you’ll only realize it when you try to sign in to close the account.
Fortunately, you can take advantage of the
name+...@gmail.com pattern, if you use Gmail. This address is the same as
email@example.com, effectively giving you an infinite amount of email addresses, all mapped to the same Google account.
When an account is closed, there is a 90 days waiting period, during which the account is only “suspended” and it still counts towards your limit of accounts.
Well, what is the limit exactly?
Luckily, you can contact AWS to increase the limit, and as some companies reportedly use thousands of accounts, there should be no hard upper limits.
But if you don’t want to do that, there is a way to remove the account from the Organization.
The process is to make it a standalone account, and after that, it can be removed from the master. Transforming to a standalone account is providing the data that is required for a regular account, but wasn’t required for the member kind. Billing address, bank card data, things like that.
After entering those, the account can be removed. All this chore just to let it die alone. And it also requires the root user, so there is no way around that.
Never, ever register a new account with an email address you don’t own. Seems like a good idea, but it will come back at you hard when you need to close it down. Also, even though you can technically reuse an account, i.e. give an existing environment to a new dev, I don’t recommend it. If you hit the member account limit, request an increase and aim for a clean state.
Download our ebook on AWS account security basics
Learn 5 simple steps to avoid the rookie mistakes.
- Why the root account is bad for security
- Use multiple users
- Secure accounts with multi-factor authentication
- Security logging with CloudTrail
- Billing alerts as an early warning system
Download the free guide here: