Many people who work in IT are probably very familiar with setting up an AWS account by now. Whether it is for the purpose of kicking the tires in AWS, going through labs during a training class or starting to build out a corporate presence, the process of creating a new account and navigating all the AWS services is fairly commonplace by now. AWS makes it pretty easy to get off and running so that you can build to your hearts content.
This is great for a single user or very small business, but what about larger companies that have multiple branches or departments that all want to take advantage of AWS in different ways? Sure, there is Identity and Access Management (IAM) and the ability to carve one account up into different pieces using roles and policies, but as AWS usage increases that becomes much more complex to manage. Once an environment begins to scale, things like VPC sprawl, network overlaps and providing user access to specific services start to become a pain. AWS created a service called AWS Organizations to help make it easier to create a hierarchy for multiple AWS accounts and address the organizational complexity that comes with AWS environments at scale.
Why multiple accounts for AWS?
Helping customers configure their accounts under one organization sounds great, but why would you want multiple accounts in the first place? AWS wants architects and developers to adhere to their Well Architected Framework, which really is a set of guidelines for how to optimally build within AWS. From a security perspective, AWS also stresses the principle of least privilege, meaning users or roles should have only the minimum access required to perform their specific tasks.
Using a multi-account strategy helps larger organizations divide up roles and services across a number of accounts specific to certain teams or functions. Rather than needing to define a ton of roles within one account specific to things like dev / test / prod or finance / hr / marketing, architects can build a single account for each “wing” of an organization and allow access to only certain users who need to build services that are specific to that accounts itself. This allows each account to provide services specific to it’s function within the larger organization without stepping on the toes of what is going on within other accounts..
An AWS account itself doesn’t cost anything, so whether you spin up 100 EC2 instances in one account, or 20 EC2 instances each in 5 different accounts, the cost would be the same. Cost Optimization is one of the pillars of the Well Architected Framework, and a multi-account strategy is essentially a “free” way to better organize AWS infrastructure for a large organization.
Of course, when it comes to cost, everyone who has opened an AWS account is familiar with the part where you submit payment information. Yes, each account still has it’s own separate billing method, but with AWS Organizations a master account is defined to act as the billing master that receives the bill for both itself and all other member accounts within the organization. This allows for an easier way to view AWS costs across departments/accounts and get insight into the cloud costs for an organization at a more granular level.
Using AWS Organizations
Selecting the AWS Organizations service from within the AWS console brings up a fairly simple looking screen. If you are doing this from within a brand new AWS account, you can click to enable the service and create your organization. When you create an organization, all features are the service are enabled by default.
Note: You can also choose to create an organization for consolidated billing only, which means the organization will only get the benefit of having one overall bill sent to the master account.
Once an organization is created, you can invite other existing accounts into your organization or create new accounts directly into the org by selecting the Add account button:
The star next to an account designates the master account for the organization. You will also see a few different menu options at the top:
Accounts – lists the accounts in the organization, pretty vanilla
Organize Accounts – allows for accounts to be grouped into Organizational Units (OUs)
Policies – define Service Control Policies (SCPs) that can be assigned to specific accounts and/or OUs
Organize accounts with OUs
AWS Organizations uses an OU structure similar to Active Directory. There is a root level of the hierarchy, under which an OU tree structure can be created. Accounts can be moved to reside under specific OUs. This allows not only for better representation of accounts within a hierarchy, but the ability to assign policies to specific OUs within the organization.
How policies work with AWS Organizations
SCPs are specific types of policies that can be assigned to either the root, OU or individual account within an organization. These policies are similar to IAM polices in that they use JSON to define the policy itself, but they are in no way related to permissions within an account. Rather, SCPs define what can or cannot be done within specific accounts. For example, you could create a SCP that says only services within a North American region are available. For a global organization that has different OUs based on geographical location, you could assign that SCP to OUs that contain accounts that cannot have data stored anywhere outside of North America. You could also create SCPs that disallow the EC2 service, or flag if MFA is not enabled for a root user.
There are lots of different reasons to utilize SCPs based on an organization’s security and governance requirements. These SCPs are considered to be “guardrails” for an organization, effectively ensuring that accounts within an organization comply with any policy defined for the cloud environment. AWS provides a list of example SCPs to show the syntax as well as give ideas as to what type of guardrails can be deployed.
What next?
AWS Organizations helps define a framework for customers who are interested in building a multi-account architecture within AWS. It is a fairly simple service that provides some very important functionality, but it only scratches the surface of what could be important to customers who are looking to build a greenfield environment within AWS. Stay tuned for the next post which expands upon multi-account architectures by diving into the concept of landing zones.
