How To Use AWS Organizations

AWS’ ‘Organizations’ feature is a great tool for businesses managing multiple clients with multiple projects. Our CTO, Jamie, discusses how to use AWS Organizations…

See below for a full video transcription.

VIDEO TRANSCRIPTION:

Hi, I’m Jamie. I’m the CTO at Flaunt Digital, and today, we’re just going to be doing a quick video on how to use AWS Organizations.

So here at Flaunt Digital, we use AWS quite extensively. We have a lot of clients and then a lot of different projects. And once you get to this level of usage, it’s really important that you have your AWS account set up correctly. So AWS have got a great tool called Organizations. Now, this is something that they’re working on all the time. You can see improvements coming into this quite regularly. And you can sort of tell with AWS services, when they’re working on them, when they’re bringing them up to date. The UI sort of starts to peel away from the other bits of UI that’s in the console. So you can see on AWS Organizations, it’s like a navy bar, and it sort of looks a bit more modern. So you can tell they’re working on it, and they’re really trying to sort of push it on.

So the way we use AWS Organizations is to split every client, or every project even, into their own AWS account. And the way you do this from your AWS account is to go into the top right bit where your account settings are, and then go to My Organization. And then from there, what you can do is you can add an account. You can either invite or you can create an account.

So quite often you’ll be creating an account. It gives you a couple little fields. One of the key ones is the IAM role name. So what it does when you create an account, it creates an entirely separate AWS account. It also creates a role within that account which has full admin. So you need to sort of settle on a naming convention here, and you probably want to use the same IAM role name across all your accounts that you’ve got. And once you’ve done that, basically press go and it will say that it’s just establishing the account back in your Organizations page, and when it’s done you’ll get an account ID. Now, you need to remember this basically, so it’s a good idea to jot these down, or have a list or a spreadsheet somewhere where you’ve got all the client names, all the projects, and their account IDs so you’re not always looking it up, because it’s quite awkward to find them.

Now, one of the key reasons you should go to these lengths and split out all the accounts is for billing and root user access. So in <AWS you can only have one billing account and one set of payment details per account, so obviously, splitting into multiple accounts gives you the option to split the billing for multiple people. So that’s one reason. Another reason is that you split out the root user. So you should never use the root user in AWS. You should always leave that to one side, and you should always use roles.

So one reason why the account number’s so important, and the role name, is that when you want to switch between these accounts that you’ve got set up under a master account, you need to use the account switcher. So there’s a Switch Role function at the top right hand corner, similar to where My Organization is, and from here you can enter the account ID, the role name, and you can give the account a label, and then you can also pick a colour. Don’t know why. Probably just for easy visual differentiation. But that’s all in the top right of the console.

So there’s a couple of things to remember when the root user account is created on the sub accounts, and that is that you never see a password. So they don’t really tell you this, but in order to gain access to this root account, you need to reset the password, and it’ll send you the instructions through to your email address, and then from there you can log in. And what you should always do with a root account is enable two-factor authentication straight away. So a really easy way to do this is using Google Authenticator. It’ll give you a QR code. Now these are great until you lose your phone, because you can’t transfer Google Authenticator codes across phones. So a really good way to make sure you’re protected from this is to print out the QR code and put it somewhere safe, so ideally a filing cabinet, or somewhere for safe keeping.

Another bit of setup that we usually do is, once you’ve logged in to the root account and applied two-factor auth to it, is to go and find your role that’s been created with full admin, and take billing off that. What that means is that if you need to share this account with your development team, they’ll be able to switch roles into that account, have full admin, but they won’t be able to see the billing, and this is just a little privacy concern really, that clients have. They don’t really want the monetary value being, you know, being exposed to people who don’t need to see it. So that’s a really good thing to do. And one little gotcha there is that there isn’t an IAM policy that exists that does full admin minus billing, so you have to create that policy yourself, but it’s dead easy once you learn the JSON syntax.

So by creating an AWS Organization, one thing that it does is it allows you to pay for that account. Now this is quite a standard thing, but sometimes clients want to be billed directly, so you can detach the account from the master account, and then you can get a separate invoice. You can even plug the client’s billing details directly into the sub AWS account. Now reserved instances are also really important in AWS – we’ve talked about these before. And one really cool feature is you can buy reserved instances at a master level, have them apply to your sub accounts. This is great, but if clients are being billed directly, you probably don’t want this to happen, so you can actually detach sub accounts from using the master account’s reserved instances.

One thing to note when switching accounts, using the top right functionality, is you’ve only got five roles you can choose from, and once you add the sixth one, it pushes off the oldest one and it drops out of your interface. This means you have to add it again, so you have to get the account ID. You also have to get the role name, which is a pain. I don’t know why they don’t support any more than five. It really seems like that bit of UI is lacking in AWS. I’m sure that’ll come on later, because a lot of people are organizing their accounts using these functions now. It just seems like that bit is quite far behind in terms of the whole AWS Organizations interface.

Another little thing, another little gotcha, is that the switch account interface seems to be cookie-based. So these five accounts that it remembers, if you switch browser, they all disappear. And you might have noticed this when you’re pinning services to the top of the AWS console, same thing. For some reason, it’s not sticky to the user account or the login. It’s sticky to your browser. So that’s a problem if you use multiple computers and multiple browsers. You lose your role history, which is really frustrating, because like I said, you have to dig out the account numbers again and again. 

So that’s it. There are some key tips for using the AWS Organizations. It’s really important, especially on client work, because it means that if you were to ever lose a client, you can then detach their account from yours very easily, give them root access, and then they can log in and do with it as they please. And this saves you from having a really torrid time detaching client-based work out of a single master AWS account later, because it’ll creep up on you and it’ll become very hard to separate, especially if you’re sharing servers or services across clients. So that’s one of the main reasons, really, why you should set up your AWS account as an organization with sub accounts. And then what you can do is you can give the root user to the client, and they can do what they want with that.

So that’s it, I hope that was interesting and useful. If you have any ideas for future videos or talks just let us know in the comments below. Thanks, bye!