AWS Organizations tutorial: scale your cloud

AWS is a great tool for companies of any size. Yet, while a startup may put all its resources into a single account, an enterprise has a different need. In fact, a big company doesn’t want everyone to see everything. Some departments may work on some resources, and some others on other resources. In this AWS Organizations tutorial, we will see how to make AWS scalable for a big company.

To better enjoy this article you should be familiar with AWS, at least a little. If you are not, start from this 5 minutes AWS tutorial.

Before we start…

The needs of a big company

As mentioned, a big company needs granularity. But what does this mean exactly?

First, the company needs to have separate instances of AWS, in such a way that the people working in one cannot see what the people working in the other are doing. This ensures nobody messes up with the work of others, particularly if he is not intended to work on that.

This also limits security breaches (if an employee has bad intentions, he can only damage one part of the resources in AWS), and helps to understand billing. In fact, if each project remains separated from the others, you can know how much each project is spending.

At first, you can think of registering many different AWS accounts. That would address the issues above, but in this AWS Organizations tutorial, we will go further. In fact, a company has other needs we need to address.

The company most likely wants one invoice from AWS, regardless of how many accounts they have. In fact, the billing process should not change regardless of the technical infrastructure, even if it is scaled up or down.

Furthermore, companies would like to enforce some security and compliance features. For example, not anyone can just log in to an account and create as many resources as he wants. You may want to put additional control on things like Internet access or VM sizing.

As we will see, AWS offers a great tool to do all of that: AWS organizations.

Account vs IAM user

Accounts, IAM users, roles… all this granularity can get people a little bit confused at first. Thus, it is important we say a few words on this so that understanding the rest of the post will be easier.

AWS has a particular concept of account. An account is a subscription to AWS, a logical container of resources like storage and virtual machines. Unlike Facebook, Google, or most places on the Internet, it does not represent a person. There is only one payment for all the resources you have in the account. You create a new account by registering to AWS with an email address.

When you create a new account, you can later log into it with the email and password you selected. In that case, you log in as root and have full access. You don’t want to do that all the time.

Instead, people should log into an account with IAM users. IAM stands for Identity Access Management, and an IAM user is simply a user inside the account. You can specify which kind of privileges each user has inside the account, and create more users as needed.

Additionally, AWS has the concept of the IAM role. That is a provider of users, like a federation with Active Directory. Each user coming from the external provider will have the same privilege, which is configured for the entire role. Of course, you can have as many roles as you need.

AWS Organizations Tutorial

To start with this AWS Organizations Tutorial, log to the AWS Console and then use the search bar to find “AWS Organizations”, and click on it. You will see a list of accounts, which starts empty.

This is your dashboard to control AWS Organizations. From here, we will see how to set up a scalable account infrastructure for AWS.

Creating a child-account

Using AWS Organizations, you can create child accounts. A child account is simply another account that you can terminate and control from your master account. In fact, you can apply some policies to define what is possible to do inside the child account.

Each AWS account can have multiple child-accounts, meaning that you can have a nested hierarchy on multiple levels.

Billing is consolidated, meaning that the parent account will pay for the resources used in all its children, and also grandchildren and so on.

Creating a child account is simple, and you can make another existing account of your children, or create a new one from scratch. From the AWS Organizations view, click on Create new account and a simple wizard will pop up.

Once you complete the wizard and validate the email, you will have the new account in the list.

AWS Organizations Policies

The next great tools we present in this AWS Organizations tutorial are the policies inside AWS Organizations. With policies, you can define a set of privileges. For example, you can create a custom policy that allows users to view and work with S3 buckets, but not to create new ones.

To create a policy, from the AWS Organization home select the Policies tab in the top left. You will see a list of policies, that is likely to start empty. Click on Create new policy to create a custom policy.

Once you create a policy, you need to apply it to an account (or to an organizational unit, which we will see in a moment). You can apply the same policy to multiple accounts. To do that, click on the policy in the list. On the menu that will appear on the right, select Accounts and then click Attach in relation to the account you want to associate.

This may throw you an error because we first need to make the policy available to be used. This is something we do with Organizational Units.

Organizational Units

An organizational unit (OU) is – you can guess – a unit inside your organization. For example, it may be Finance, HR, Engineering and so on. You can group our AWS accounts into different organizational units, and even have OUs nested in one another (for example, Accounting and Budgeting inside Finance).

You start from the root, which is the master that can have no parent. From there, you can have accounts and OUs as children, and each OU can have other OUs and accounts as children.

The first thing to do is to enable policies to be used in the root. This will make them available in the rest of the hierarchy. Navigate to organizational units from the top-left menu, and then select root from the tree on the left. Without selecting anything else, on the right, enable service control policies.

Once this is done, you can focus on creating your organizational tree. Doing that is pretty easy, you can create new OUs from there, and you can move your accounts that you already added between them.

This is an example of an organizational tree.

You can play and nest all the ways you want.

AWS Organizations Best Practices

Creating accounts, policies and OUs is fairly simple. Doing it in a good way may not be so obvious. In fact, some things come to the surface only when you have a lot going on in your AWS Organizations structure.

To start with the right foot, we have some best practices you can follow from the first moment.

Empty master

The first thing you want to do is create your AWS master account, and then create children accounts from it. You don’t want any resources (e.g. storage, virtual machines) inside your master account.

This is because, inside that account, you can tune the roles children accounts will get. Thus, you want only a few people in that account, and only to manage your AWS Organizations structure, not to do other things. All the operational stuff should go into child-accounts.

The master account will be also the center for the billing. No worries, you will still be able to see how much each other account is spending.

OUs for departments, accounts for projects

In your organizational tree, you should use Organizational Units to represent departments that use whatever you develop with AWS. Departments are units in your company, like Finance and Engineering. They are users of what you develop with AWS: for example, the Finance team will use the budgeting application you have developed. Use sub-OUs if needed.

Instead, create a new account for every single project. New payroll application? Create an account. The Engineering software to do calculation goes into the cloud? New account. You get the point. In this way, you can be granular on how much each project, tool, or application is costing you.

Of course, put the accounts in the OUs they should belong to. For example, the account for the payroll application should go in the HR organizational unit.

Try to use policies for OUs as much as possible, and less for accounts. You want something that is highly repeatable, you don’t want to tailor the policies for every account.

Sub-accounts for environments

Modern development processes require quality. In fact, you are likely to have a development server, a test server, a quality server and a production server for larger applications. Don’t cram everything into a single account.

Instead, create an account for the project (e.g. the payroll application), and then create sub-accounts of that account. In this approach, the account for the project will be empty of resources, like the master account. It will instead contain the other accounts containing the resources (e.g. payroll-test, payroll-qa, payroll-prod).

Of course, you don’t need to do all the time. For small applications, everything in a single account can be fine. However, this is the way to go for big applications with large teams working on them.

Use the policies

Use them! It is important to apply some level of control of what accounts can do. There is no easy fix here, no policy will work for all companies.

However, there are some key areas on which you should think a little bit. One is Internet access: you may want to prevent the creation of resources that allow Internet access, like NAT gateways. This might be a good idea if you plan to develop private applications that run only inside your company (and that you access with a VPN to Amazon). It might not ideal if you want to develop cloud or public applications.

Another area is AWS organizations itself. You may not want people working in your child-accounts to create other sub-accounts. Even when you do want the sub-accounts, like in the test/qa/prod environment, you may not want people do create them on their own. You want to enter in their account, create the sub-accounts, and then block the creation of any other.

If you are in a big company that is seriously considering going to the cloud, spend some time thinking about the policies.

In conclusion

In this AWS Organizations Tutorial, we saw how to use AWS Organizations to segment and control AWS accounts for a large company. Besides the practical how-to guide, we focused on the best practices to do things in the right way.

Remember that moving to the cloud does not mean moving your VMware farm “away” from your datacenter. It means transforming, changing IT and business processes to be faster – that’s the Digital Transformation. If you find your existing processes clashing against the account structure of AWS, consider the reasons why you are moving to the cloud. If you are not willing to adapt a little bit, you may have to think about what moving to the cloud is worth for you after all.