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.
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
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
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
So there’s a couple of things to remember when the root user account is created on the
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
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
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,
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
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,