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.
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.
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:
|Management Account||The account all bills consolidate to; defines the organization.|
|Root||Contains every account in an organization.|
|OU||Groups of one or many AWS accounts, and child OUs, in an organization.|
|Account||A member account associated with the organization.|
There are two feature sets available for AWS Organizations: Consolidated Billing and All Features.
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.
The All Features set allows for advanced control over the accounts and OUs in your AWS Organizations through policies.
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:
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.
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.
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.
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
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.
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.
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.
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.
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.