Don't panic, organize

Creating an Organizational Unit with two accounts in it

Since we already laid the foundation in the form of an AWS Organization accompanied by basic IAM groups and users, our next step will be creating an Organizational Unit (OU) with two accounts in it. OU is basically a container for your accounts and an easy way to group them logically.

Moreover, as we'll see later, we can attach policies at the OU level and all of the accounts that belong to it will inherit them as well. Wanna stop your admins from in advertently shutting down your Direct Connect or perhaps from spinning up a certain kind of instances? You can easily enforce that with OU level policies, the so called Service Control Policies or SCPs. At the OU level, you can also enable a trusted access for certain AWS services, such as AWS Single Sign On, which you can utilize if you decide to allow your users to log in using their corporate credentials.

Furthermore, you can enable tag policies via AWS Organizations. Basically, these policies dictate how resources must be tagged under given OU in order to be compliant.

Okay, let's start by – you’ve guessed it – making a module for OUs:

+ aws-organizations-example/organizations-organizational_units/main.tf

+ aws-organizations-example/organizations-organizational_units/variables.tf

+ aws-organizations-example/organizations-organizational_units/outputs.tf

Next, a module for an AWS account:

+ aws-organizations-example/organizations-accounts/main.tf

+ aws-organizations-example/organizations-accounts/variables.tf

Finally, let's create an OU with two accounts in it by adding the following lines to our aws-organizations-example/main.tf, and then follow it with terraform init, terraform plan and terraform apply commands:

NB, an email address (email aliases are supported as shown in the example) can be associated with an AWS account only once, i.e. reusing the same email address for a creation of a different AWS account, even if the original one has long since been deleted, is impossible

NB2, to close an AWS account that is apart of an AWS Organization, you must assure first that it can be transformed into a standalone account

+ aws-organizations-example/main.tf

To access either of the two newly created accounts you need to log in to your master account as a user with permissions allowing the sts:AssumeRoleaction on the adminAssumeRolerole in your destination account.

(The admin_user_1, which we created earlier, being a member of the `administrators`group has such permissions.)

Once logged in, grab the number of the account to which you want to switch from AWS Organizations. Next, click on your username located in the upper-right corner of the screen to reveal a drop down list similar to the one shown below:

You'll be taken to the screen shown below. Click on the _switch role_ button:

Finally, enter the account number you've copied earlier and the name of the role which you want to assume (adminAssumeRolein our case). Hit the blue button:

To log in to the other account you'll need to go back to the master account, grab the second account's number and repeat the steps given above.

As far as programmatic access via AWS CLI is concerned, all you need to do is configure your admin_user_1 in the ~/.aws/credentialsfile:

And then create profiles referencing it in the ~/.aws/configfile:

With the above set, you can use the CLI as follows:

Applying a Service Control Policy (SCP)

Lastly, we'll compose and attach an SCP blocking the root users of ou-1 OU's accounts, both current and future ones, from taking any (or rather the majority as certain exceptions apply) actions, either via the console or programmatically. (For inspirations on writing other SCPs, check out this webpage.)

So, as usual, we'll commence with a module:

+ aws-organizations-example/organizations-policies/main.tf

+ aws-organizations-example/organizations-policies/variables.tf

And we'll invoke it as follows:

+ aws-organizations-example/main.tf

Now, on to the last dance:

Conclusion

In this article we have shown how AWS Organizations service can be utilized to: a)automate accounts creation, b) group accounts together into Organizational Units, and c) apply policies to these groups for additional governance.

One other important feature of AWS Organizations is Consolidated Billing, which is described in AWS documentation as follows:

You can use AWS Organizations to set up a single payment method for all the AWS accounts in your organization through consolidated billing.

With consolidated billing, you can see a combined view of charges incurred by all your accounts, as well as take advantage of pricing benefits from aggregated usage, such as volume discounts for Amazon EC2 and Amazon S3.

...and just to recap, here's what we’ve built:

+ The above diagram was crafted in CloudCraft

And here's the final file structure:

"That's all Folks!" Hope you enjoyed the read and until next time!