AWS Organizations Whitepaper

Complete FinOps Guide
Chapter 1.4 Drilldown: Guide to AWS Organizations

Your business may already enforce resource tagging and use a management account for consolidated billing. So why bother with AWS Organizations, isn’t it basically the same as having several member accounts linked to a management account? Well, not quite. In this article, we’ll show you why using AWS Organizations is very effective for cost management.

What are AWS Organizations?

AWS Organizations is an optional feature of management accounts that provides a more flexible hierarchical structure to your fleet of AWS accounts and resources in the form of Organizational Units (OUs).

Think of OUs like a folder directory. You might have folders for each department in your organization on a shared filing system. This helps add context to the files inside a given folder and it makes finding files easier. But not everyone needs access to each department’s documents, such as sensitive employee information stored in an HR folder. Folders can be secured using role-based permissions: Create, Read, Update, Delete. Sure, you could secure those files individually and perhaps name them in such a way that they are easily found in a flat-filing system, but that type of system breaks down at scale.

In the same way, a flat view of all your cloud resources is less meaningful than one that has structure. AWS Organizations provides that structure in a way that management-member account relationships cannot match alone.

How to View AWS Organization Details

There are several levels of AWS Organizations. At some point, you may need to check each level’s details (such as the owner) or to review associated policies. Here’s how you can do that:

You can access the new AWS Organizations configuration page from the Settings menu of your AWS console.
The new and intuitive AWS Organizations configuration page.
AWS Organizations Terminology
Management AccountThe account all bills consolidate to; defines the organization.
  1. Log in to your business’s AWS Organizations Console.
  2. Navigate to Settings.
RootContains every account in an organization.
  1. Navigate to Organize Accounts > Home.
  2. Select Root.
OUGroups of one or many AWS accounts, and child OUs, in an organization.
  1. Log in to your business’s AWS Organizations Console.
  2. Navigate to Organize Accounts.
  3. Select an OU or, if it is a child OU, navigate through each ancestor to find the one you’re looking for.
AccountA member account associated with the organization.
  1. Log in to your business’s AWS Organizations Console.
  2. Navigate to Organize Accounts.
  3. Open the OU that possesses the account.
  4. Select the account’s card.

AWS Organization Feature Sets

There are two feature sets available for AWS Organizations: Consolidated Billing and All Features.

Consolidated Billing

Consolidated Billing, as a feature set, is limited to only shared billing. An AWS Organization using this minimal feature set can upgrade to using all features at any time, but to do so each member account must approve of the change individually by accepting an invitation.

All Features

The All Features set allows for advanced control over the accounts and OUs in your AWS Organizations through policies.

Service Control Policy (SCP)

This type of policy determines which services and actions are available to users (or roles) for specified accounts. Note that SCPs do not grant permissions, they instead act as a filter. This means that the targeted accounts, users, and roles must already have these permissions available directly or in a higher level of the account hierarchy.

Since OUs may be layered thus prone to conflicting permission instructions at each layer, the SCPs apply permissions conservatively thereby requiring SCPs at every level of hierarchy to agree. Consider the following diagram as an example which illustrates that an account is only allowed permissions granted by both sets of governing SCPs:

If an AWS account is governed by two Service Control Policies (SCP), it only complies with the permissions common to both SCPs.
An AWS account conforms only to matching permissions in case of a SCP conflict (source: Amazon Web Services)

SCPs are useful when you are uncertain resource use is being fairly attributed to the right projects, departments, or teams. You can use SCPs to restrict (explicitly deny) account access to designated user groups, ensuring that resource costs in one account fully belong to the account owner.

Tag Policy

Do not underestimate the challenge of tag compliance. Tags are powerful because they are user-defined and flexible, however, the same virtue also creates sprawl, typos, and omissions. This type of policy enforces tag standardization across accounts in your organization. For example, when a user tags their new EC2 with `costcenter: web-app`, the policy may either reject the tag until it matches the policy (e.g., `CostCenter:web-app`) or flag it as non-compliant since it didn’t adhere to the right capitalization. Non-compliant tags can be reviewed from AWS Resource Groups.

Best Practices

Build a Foundational OU Structure

AWS recommends approaching your organization’s structure by first deciding on what natural divisions make up your cloud footprint. This can mirror segmentation by company-wide roles, products, departments, geographies, projects, and so on. However, AWS recommends to start with two: infrastructure and security.

The infrastructure OU must contain all of your common infrastructure such as networks and domain name service (DNS) that are shared across your applications. The security OU should house sensitive data and services such as your system and application logs that may be valuable to hackers, and also AWS security services such as GuardDuty. The intent behind separating these two OUs is to protect and track your most sensitive assets.

AWS recommends creating dedicated OUs to house your common infrastructure as well as your security assets.
Common infrastructure and security assets are respectively housed in dedicated, foundational OUs.

Using this example, a global organization could understand their infrastructure spend from a worldwide lens and then proceed to dive deeper by application or Software Development Lifecycle (SDLC), which essentially separates development from pre-production and production. Many OUs could also be defined to represent specific cost centers

The best practice would be to dedicate an AWS account to each cost center when using AWS Organization Units.
Each cost center would have its own AWS account under the same OU.

Create a Policy Inheritance Framework

A Policy Inheritance Framework sounds complicated, but it really just means that you should consider the full impact of policies applied to OUs at lower levels of your organization’s hierarchy. This is no different than sharing permissions with a user to access a folder on your system and later remembering that you had sensitive data in a sub-folder. Generally, it’s best to set the broadest access (through permissions) to your resources and services at the foundational-level.

With each tier of the OU, you can set more limited access, leveraging role-based permissions tailored to the exact teams that own or work in the accounts belonging to that OU. This can continue on further at the account and instance level, where permissions would be the most restricted.

The AWS Organization OUs may be nested and then associated with AWS accounts.
A hierarchy of OUs and associated AWS accounts (Source: https://aws.amazon.com/)

Layering policies helps your organization stay secure without locking out essential employees, but it can also save significant time (and money) on other things, such as onboarding. Just imagine how expensive it would be to have your infrastructure admin triaging permission issues for each new hire. In fact, AWS goes as far as recommending that you create a dedicated AWS account to host certain system logs as well as security services such as Amazon GuardDuty and Amazon Detective so that only your security personnel can access them.

Organize Using Tag Policies

Tag policies enforce consistency, which is essential at any scale when talking about cost allocation reporting. Creating tag policies specific to cost centers and cost types is a huge win for FinOps professionals who need deep and accurate insights into their business’s cost data.

Consider Trusted Access

Use Trusted Access to set up trusted services across your organization. Trusted services enable you to assign permissions to a service itself without affecting the existing permissions of your users and roles. Trusted services create a service-linked role that is applied to every relevant account when the service is needed to perform management actions. This can be useful in scenarios where access to certain accounts needs to be extremely limited, but FinOps-enabling services must still be run for proper (centralized) billing governance.

Conclusion

AWS Organizations is a very powerful resource for FinOps practitioners who need to establish a well-defined, multi-dimensional hierarchy for cost centers across their business. Infrastructure and security stakeholders can also utilize AWS Organizations to safely and intelligently limit access to individual resources without blocking financial governance.

Continue Reading this Series