AWS Organisations: enabling All Features

So yeah basically what you want to do is go into the AWS Console, under the Organisations section, under Settings there’s a button labelled Begin process to enable all features. You just click that and umm yeah that’s that I guess, great work 👍

Seriously though, as simple as that may seem, I can’t leave you with just that. As close as that is to all that needs to be done, we all know nothing in life is ever that straightforward. Queue the theme music… what? What do you mean I don’t have any theme music? 😮 Well that sucks! Oh fine then let’s just jump straight in I guess.

Adding New Accounts

When adding new accounts to our Organisation, there are two ways to go about it:

1. Inviting existing stand alone AWS accounts to join us, or
2. Creating new accounts from the create accounts section in your AWS Organisations console

The first option is more flexible when you want to eventually disband the Organisation and delete it, this is because you can only remove an account that is capable of becoming a standalone account — due to contracts with AWS and billing details, and that’s easy if it was created separately and already has predefined AWS contracts. But accounts created from the Organisations console are not automatically created with all the information necessary for them to be stand alone accounts — this isn’t exactly a bad thing, it makes it a lot easier to switch from Consolidated billing to All Features enabled later on as these accounts don’t need to accept an invitation like the member accounts that existed prior to joining the Organisation.

When you add an account to your Organisation and enable Full features, this will send an invite out to all of the existing members of the Organisation (remember handshakes we spoke about in our last blog, well this is exactly that). And this is sent to all the member accounts that weren’t created by the Organisation but instead were existing AWS accounts prior to joining the Organisation. I know I keep going on about this but understanding the difference in behaviour between the two account types is key.

Once the invites are sent out (handshakes extended) to the member accounts the process of transformation has begun. This process will continue until all of the member accounts have responded. Kinda like making plans with your group chat, but you decide to change the venue last minute so you send an update on the group chat, what can I say, you live life on the edge, and you gotta wait for all the previous confirms to reconfirm. I mean, pretty standard, right?

Note: when you first create an Organisation, you can immediately start creating accounts through the Organisations console and add those accounts to your Organisation, but, to invite new existing AWS accounts to your Organisation, you need to first confirm your master account’s email address.

The process overview

When the invite is sent out, for All Feature enabling, a key check that’s performed is to see if the member account has the AWSServiceRoleForOrganizations Service Linked Role available in the account, this role is vital for enabling permissions for services integrated with Organisations. We’ll see why in the next section.

Service linked Role

I know what you’re thinking… what in the world is an IAM Service Linked Role?!? 🤷‍♂️ (IAM SLR for shortsies — I can’t keep typing this out haha)

IAM SLRs were created by AWS to provide an easier way for services in AWS to create and manage resources on behalf of the user. For example, IAM SLRs exist for the EC2 Auto Scaling service, as you’d imagine it largely consists of an AWS Managed Policy (predefined and immutable) with permissions to manage a fleet of EC2s (like tag creations, EC2 instance creation based policies, you know the regular business), it’s not much but it’s an honest days work.

Now, the AWS managed policy inside the SLR is of course immutable, however SLRs aren’t. The only rule is that you are unable to remove the managed policy that it has as it’s base that allow the linked service to perform its role — the permissions the linked service needs to perform actions on the resources (the linked service being the service that is integrated with Organisations and performing the actions on a resource). Besides that you are free to change (ie add and remove) any permissions you’d like, provided you have the necessary permissions yourself to add them. i.e. you are an IAM User in this account and your IAM User has the necessary permissions. Because of course you’re not still using root 👀 are you? (whispers *I’m watching you*).

SLRs are normally conceived of at the time of creating the linked service, their lifespan is generally tied to the linked service as nothing else can use it so it makes sense it is removed when the linked service is removed. However, you can create your own IAM SLR and assign that at the time of creation of the linked service, but you gotta handle the lifecycle for that one. The latter option more favoured if you are an expert and know you will need this role and what managed policy you gotta add, and want to get ahead of yourself and add in the permissions beforehand. But remember to check the conventions for IAM SLR creation from the console.

It is important to understand that the IAM SLR is predefined for every service that it is compatible with. An SLR for EC2 Auto Scaling is different and has a different AWS Managed policy than the Elastic Load Balancing SLR.

Aren’t they just the coolest things ever?!? And 👏 there’s 👏 more 👏

Service Linked Role

SLRs, as well as having automatically defined policies, ALSO have immutable trust policies. The permissions policy defines WHAT the role can do and the trust policy defines WHO can assume the role. The WHO in this case being the linked service, again, you can not change this, I can’t stress this enough because this nifty little feature lets your developers create SLRs for AWS Services that have permissions that are maybe greater than that of the developers, and the developers aren’t permitted to use. OKOK I know your brain is freaking out. NO NO NO this can not happen, developers creating IAM roles with more permissions than they themselves have *to the panic station, all aboard the Distress Express*

Ok ok after that mild panic, this is exactly why SLRs are so awesome, even though the devs are allowed to go mad creating all the elevated permission Service Linked Roles they want it doesn’t matter, because only the AWS Service they were created for, the one in the immutable Trusted Policy can use any of the permissions. So all is good in this particular dimension of existence.

Note: a trust policy is another policy document where you define the Principals that you trust to assume the role you’re attaching it to. It’s a resource based policy by nature as it defines who can access it — as apposed to an identity based policy that defines what it can access (more info on Resource vs Identity based policies here). You CAN’T use the * wildcard here though, you need to be a tad more specific than that (Users, Roles, Accounts and Services).

We have two different IAM Service Linked Roles that we need to discuss when it comes to AWS Organisations:

1. The OG role — officially known as AWSServiceRoleForOrganizations, this is the IAM Service Linked Role that is automatically added to all member accounts that are part of an Organisation with All Features enabled. Automatically added because this enables our friend below to be created.
2. Hello, I am said friend that is created thanks to the above point. These are the IAM Service Linked Roles that are created by the role we discussed right above, these are SLRs for specific services that are compatible with AWS Organisations.

In either case, IAM Service Linked Roles must exist in an Organisation with All Features enabled.

All Features enabled mode — activated

Can you feel the POWER???

I can! Going from consolidated billing to All Features enabled requires some overall prep work, you don’t just flip a switch and stuff happens… actually I might be wrong there it is very straight forward. BUT, you gotta make sure certain things are in place and you know of the limitations that exist during the transition. Rome wasn’t built in a day. It actually took 1,010,450 days… #fact… I actually had no idea it took that long tbh 🤔

We should take significantly less time one would hope. Actually, we HAVE to take less time, let’s see why.

The invite

Once you (the master account) choose to enabled All Features and an invite is sent out to a member account, the account has 90 days to respond or the invite expires and the master account has two choices:

1. They can be nice and assume you just missed the invite (there’s no junk folder in AWS but for arguments sake let’s assume that’s where we ended up) so they can resend it, or
2. They could be mean and take this as a sign you no longer wanna be friends and kick you out of the Organisation… good riddance imo, we don’t need you anyway

These invitations only apply to member accounts that were previously existing AWS accounts, NOT the AWS accounts the master account created from the Organisations console. That’s because, as mentioned earlier, the invite is partly a way of insuring the member accounts understand what they are signing up to with the All Feature enablement, ie the affect of SCPs and how this will affect administrator access on the member accounts. The other reason is to make sure the member accounts have the automatic Service Linked Role in their account, as this is required to create other SLRs for services integrated with AWS Organisations.

By accepting the invitation the member accounts are agreeing to the creation of this role in their account, and if they were to innocently and completely by mistake delete this SLR later on, oops, that’s no worries as another ‘invite’ would be sent from the master account to reinstate it. I love how passive aggressive this is 😂 an ‘invite’ is sent like “hey I’m sure this happened by mistake so here is an invite to reinstate the role that again I am sure was totally deleted by mistake” wow living for the drama haha

In contrast, this SLR is automatically created in accounts the are created from the Organisations console. So no need to invite them anywhere, they are already in essence ‘ours’.

This all seems super great and you’re probably thinking wow why aren’t all accounts this easy and straightforward. Well, convenience now comes back to bite us in the butt later when we want to delete the Organisation.

The process

It’s a bright Monday morning, the birds are chirping away, you hear cars rushing to get to work. You stare at the AWS console in front of you, you look at the words: Begin process to enable all features. A bead of sweat runs down your head. You click it. In the distance, you hear sirens…

😂 ok but in all seriousness it can be this intense if you don’t know what happens when you click that button, so, like an emotional wall, let’s break it down.

One way transformation

When you start the process of enabling All Features it’s important to know this is a one way process. You can go from Consolidated billing only to All Features enabled but you can’t go back the other way. Once you click that button, you get another window confirming you are aware of this, so it’s best to be sure this is what you want.

But of course we do, we have decided for us the additional features are exactly what we need, so we confidently acknowledge that fact. Next we must know that this process puts all other pending and new invites on hold, actually it goes a step further and automatically cancels all pending new member invites. Until every existing member account has accepted the invite for enabling All Features and completed its necessary requirements (like reinstating the AWSServiceRoleForOrganizations role) we are in a membership freeze. Members must accept or be removed. And again, this only applies to member account that were existing AWS accounts prior to joining the Organisation.

The process detailed

Furthermore, this only applies to inviting existing AWS accounts, you are free to go crazy on creating accounts from the Organisations console during the process. And once the process is over and successful you can go right back to your invites.

Now we’ve covered some of the what and how, let’s have a look at the how many.

Quotas

Some quotas to make sure you are aware of are:

• Funnily enough, the original limit for number of accounts in an Organisation is 4 (this is without contacting AWS support to increase this limit), but the maximum number of OUs is 1000 😂 however that second limit isn’t expandable like the first one.
• And invitations, that we mentioned a lot in the previous section, count towards the limit, so if your non expanded limit of 4 is in place expect not to be able to send more than 4 invites in total, only once another account declines an invite can you invite another account.
• You can have a max of 1000 OUs and this provides a lot of flexibility, like an OU inside an OU inside an OU. However, this is limited to 5 levels deep, so the fun has to end at some point 😞
• The number of open invitations you can add in a 24 hour period is 20, but that doesn’t include accepted invites. So if one is accepted, you can send out another one on the same day. That’s a lot of invites!
• And finally, the number of accounts you can create, concurrently, is 5!! That’s amazing, I mean you can batch them up, but only 5 will go at the same time

There are further limits regarding policy document lengths and numbers as well as number of tags you can attach to an account (50), it’s super useful to be aware of these as I won’t be surprised of they pop up when you’re hitting a limit reached error 😊

Conclusion

I hoped you enjoyed that dive into Service Linked Roles and All Feature enabling as much as I did, I definitely learnt a lot so thank you to me haha but seriously, there’s still a lot to cover still in terms of Organisations, we still have some important points to cover in terms of managing accounts and access. So don’t go anywhere just yet, especially with all these impromptu travel bans, stay safe and until next time, PEACE OUT! ✌️