Best Practices for AWS Organizations

You might have heard the saying, “You can’t manage what you can’t measure.” Generally, we agree. But when cloud resources are concerned, we need to take it a step further: “And you can’t measure what is not organized.”

As a first step in laying the foundation for your FinOps best practices, we recommend that you take the time to organize your AWS accounts and resources. The AWS well-architected principles guide users to separate resources into different AWS accounts, as they provide natural security and billing boundaries that are easy to understand. Separating your resources by account also allows you to leverage all of the features provided by AWS Organizations.

In a previous article, we reviewed the most common FinOps challenges that require proper organization of resources, and which AWS billing tools can benefit the most from your organizational efforts. In this article, we offer best practices for organizing your resources and aligning them with your team members.

1. Collaborate across departments

First things first. Before you organize your AWS resources, you must align the stakeholders. This formality helps to clearly establish and assign responsibilities, while also defining the communication lines needed for efficient r decision making.

Form a cross-departmental task force

Cross-departmental teams for FinOps are formed by incorporating key groups of stakeholders, such as:

• Corporate Executives
• Finance and Procurement Specialists
• Engineering and Operations Managers
• Application or Product Owners

The task force’s primary objective is to promote a culture of responsible spending without affecting innovation or business velocity. Before you define a scope of responsibilities for the taskforce, we recommend that you simply begin by meeting once a month to review last month’s spending and discuss expected usage for the following month. This approach will naturally lead to expanding the scope of the task force's purview over time, and introducing the concepts presented in this and our other related articles.

2. Create separate AWS accounts for your resources

AWS accounts are the optimal security, governance, and billing boundaries for your spending. So the first step in organizing your AWS resources is to move your resources into appropriate accounts.

Move resources out of their original accounts

If you are a FinOps practitioner reading this article, your company has likely already created a few AWS accounts. We recommend that you urge your engineering teams to reorganize them. However, you must know that this is not a small request, as moving resources (such as EC2s, Load balancers, block storage volumes, and Lambda functions) between accounts is a significant time investment and a delicate matter given many of your resources are supporting production applications. It would be best to leave your resources supporting a production application in the original account in which they were created, and move your non-production resources out of their original accounts. The smallest configuration mistake in this migration process could lead to a production outage which would not be the best introduction of your new FinOps taskforce.

Create foundational Organization Units (OU) to contain your AWS accounts

In our primer article on AWS billing organization, we introduce the Organization Unit (OUs) functionality of AWS Organizations, which helps group multiple AWS accounts. Beyond assisting with billing consolidation, an OU can also apply Service Control Policies (SCP) to a group of related accounts in order to restrict user privileges for creating, changing or deleting AWS services.

If your goal is to deliver an accurate bill to each of your cost centers at the end of each month, then you must be able to know the exact value of your common services so that you can distribute those charges across your various applications that benefit from those services. Fortunately, the practice of separating your shared costs into a separate OU is even more important for security reasons, which should help you as a FinOps practitioner convince your engineering counterparts to undertake the effort. The reason for this is that the OU separation helps you more consistently restrict user access to sensitive data, and also to avoid manual errors that could cause a major outage.

The first two OUs that we recommend you create are for common infrastructure and security resources. The infrastructure OU should contain all of your common infrastructure components, such as the Domain Name Service and Networking Services. These are examples of services that are shared across your multiple applications.

The second OU should house your security services. This is the account that will house your services, assets and data that are sensitive from a security perspective, which include:

• Logs that could be used by hackers to penetrate your environment
• AWS security services such as GuardDuty, which is a security threat detection service

In the event of a security breach or disaster, the security OU also helps you control access to all other AWS accounts. This concept is referred to as “break glass,” which is an approach to bypass normal account access during an emergency.

Within the infrastructure and the security OUs, you would house separate accounts for production and for non-production resources. Non-production resources include user acceptance testing (UAT) environment, lab resources, and servers used by developers that AWS often refers to collectively as the Software Development Lifecycle (SDaccountLC).

This further separation of your resources into Organization Units helps you with margin analysis. If the resources supporting your production environment are intermingled with the resources supporting your testing and development activities, then you would never be able to measure the exact direct infrastructure costs that should be expensed against your service revenues.

Create additional OUs for other use cases

The total infrastructure costs attributed to an application service is made of the allocated portion of the common infrastructure charges explained in the previous section, plus the costs of resources dedicated to the operations of that application. These components typically include databases, web servers, application services, and related networking charges. These resources should be housed in a separate OU to help financial accounting, and also secure administrative access.

As you isolate the resources associated with application workloads, you must create additional OUs to contain resources that fall into other categories. AWS recommends using 9 different OUs, including the two described above, however, we suggest you start with only 4 to avoid overwhelming your teams. After Infrastructure and Security, the next 2 OUs that we recommend are:

Workloads OU

This is where you should keep your AWS accounts that host all AWS services that support your applications outside of your common infrastructure resources . Both production and non-production resources should be under this OU.

Sandbox OU

This is the OU that should house accounts for individual users who would like to experiment with new AWS services. It is important for innovation to allow such accounts to be created without hindrance from regular governance. It also helps you monitor its costs separately. This OU should initially contain all other resources that don’t fit into the other 3 OUs.

Only after this stage, should you consider working on the final 5 AWS OU recommendations, which are:

Policy staging

To test policy changes

Suspended

To contain accounts that have been, or are being closed

Individual business users

Accounts for non-developers who need to access data to create reports

Exceptions

For highly customized use cases

Deployments

If you have a different operational model for code that is continuously integrated and delivered, also known as CI/CD

Separate your accounts by business unit or department

Note that in the diagrams shown above, we separate production environments from non-production environments. However, you are likely to further separate your accounts under each OU by business unit or department. The more you separate your accounts by cost center, the easier it becomes to manage your resources from both a security and billing perspective.

3. Use AWS tags to further organize your resources

You may be wondering why we must organize resources even more, if OUs provide such effective logical grouping. But by creating OUs and separating out ourAWS accounts, we have only created relatively high-level security and billing boundaries. Tags provide for more granular organization, which is helpful for when your accounts contain:

• Many different applications.
• Many different supporting components such as web servers, micro-services, database servers, messaging services, caching services, and more.
• Multiple architectural versions (e.g., legacy and 2.0) while in a transition.

Tagging accounts and OUs enable your teams to reliably track their assets and spending and compare monthly costs for one application’s database servers versus another’s. Here are some use cases that could benefit from tagging:

• Assigning responsibility for managing costs to individual application owners.
• Isolating a jump in spending at the end of a month to a specific component or application.
• Calculating gross margin for specific applications.

Remember that AWS requires you to activate a regular tag to become a cost allocation tag. This is required for a tag to be displayed in Cost Explorer reports. For a closer look at cost allocation tags, see our in-depth guide.

4. Use AWS cost allocation reports and categories

A surprisingly low percentage of AWS users take advantage of Cost Allocation reports and AWS Categories. One reason may be that these features are relatively new; another is simply that there are too many AWS features and functionalities for one person to learn.

That being said, the cost allocation report allows you to create a column for each tag-key so that you can track each tag-value as a row. In the previous section of this article, we recommended separating your production from your non-production accounts, as well as by business unit and department. By further tagging your resources within a single account, you can create chargeback reports by application, or help isolate spending trends over time. This report will also help the cross-departmental task force’s monthly reviews.

The AWS Categories allow you to create rules to group cost and usage information. For example, a rule would create a category for all ELB, EC2, and EBS services that have a tag of application:e-commerce in the western region. The categories are then available for you to use in Cost Explorer and Cost and Usage Reports (CUR).

Conclusion

A successful FinOps practice begins with forming a task force and organizing your resources. In our next articles, we explore how to measure efficiency, set budgets, automate collaboration, and reconcile spending. However, it all begins with laying a foundation that is thoughtfully grouped, tagged, and categorized so that your spending reports are clear, reliable, and easy to discuss with a group of stakeholders. If you are new to FinOps, we recommend checking out the FinOps Foundation.