Overview
There's a lot of best practices when it comes to cloud computing, and they seem to change almost daily. I'm here to tell you about one simple change that can have a huge impact.
AWS Organizations is a service provided by AWS that allows you to partition your cloud resources across multiple accounts, and organize them by "Organizational Units" (OUs). We'll discuss later the finer points of OUs, but more importantly, this service also allows you to create multiple sub-accounts that roll up under a single "master" account.
While there are many reasons why you might choose to partition resources across multiple accounts, here's a few that come up most often:
Security / Authorization
By separating resources into different accounts, it is easier to apply Principle of Least Privilege (POLP) across AWS resources by granting Developers and QA access to non-production accounts for development and testing without risking exposure to production data.
For example, let's say you host a web application in AWS, using resources such as EC2 instances, Lambda functions, RDS databases, S3 buckets, etc. You want to empower your team by granting them full access to AWS for a shared development environment. However, you also want to reduce the risk of a human or script accidentally making changes to the production environment that could result in downtime or data loss. You could create fine-grained policies, that only allow developers to perform actions on specific resources, but that will require constant maintenance as the environment changes over time.
By using separate AWS accounts, you can move the development environment to a separate account, and simply create a "SuperUser" or "Developer" role that grants full access to any services relevant to your system, knowing that this policy will be limited to only resources within the sub-account, so team members cannot accidentally make changes to the production environment.
Cost Management
AWS provides multiple resources to manage costs, including AWS Trusted Advisor, Cost Explorer, the AWS Calculator for estimating costs, and pages of documentation detailing how costs are calculated for individual services. Despite these resources, it can be still be very difficult to predict or track monthly usage and costs across your environments.
Using AWS sub-accounts, it is really easy to track costs across different segments, depending on how you've partitioned your accounts. Using the AWS Cost Explorer, you can use Linked Accounts to apply Filters or Group By operations to see how costs are distributed across your account. This makes it trivial to see how different workloads compare month-to-month so you can quickly spot anomalies.
For example, let's say you want to spin up a new website as part of a campaign your company is running for a new product. You will host the site on an EC2 instance with a MySQL instance running in RDS, and a CloudFront distribution. When you launch the application, you misconfigure your retention policies, resulting in a "trickle up" effect as you continue to pay storage fees for stale snapshots and log data. If you deploy this configuration alongside other resources, it would be really difficult to determine which costs are associated with your new website, and which are coming from your other products. However, by creating a new sub-account, you can see really easily how your usage costs change over time, including the upward trend caused by the unnecessary storage, and quickly make changes to fix the issue.
Organization Units
So far, we've mostly been talking about the benefits of multiple accounts and how they can help organize workloads within AWS so you can manage them effectively. Next, we'll discuss briefly the concept of Organization Units (OUs) and how they can provide an extra layer of administration on top of your sub-accounts.
Simply put, OUs allow you to add structure to your AWS sub-accounts. You might choose to create OUs, to group accounts by:
- Company / Subsidiary
- Department
- Product / Line of Business
- Environment (Production vs. Non-Prod)
- Customer
OUs are more than just a visual aid to organize accounts into groups, they also allow you to apply policies to all accounts assigned to the OU. For example, you might create an OU for all "production" accounts, and apply a policy that restricts the ability to disable or modify AWS GuardDuty for those accounts.
Considerations
Before you go tell your boss that you want to migrate all your resources to sub-accounts, there is one important thing to consider first. Sharing resources across accounts can be a bit tricky. In general, support for this continues to improve as the use of multiple accounts becomes more widespread, but in my experience, it requires a non-trivial amount of effort to configure resources that must be shared across accounts.
If this is something you need to support, such as storing artifacts in S3, or deploying containers from a single ECR registry, you should take a moment to review how to achieve your objective across multiple accounts, in case the solution turns out be more complicated than you anticipated.
Summary
Prior to AWS Organizations, we used Tags and other tricks to try to keep track of resources across multiple environments. With the ability to partition resources across accounts, it's easier to configure "catch all" rules, such as Budgets, Cost and Usage Reports, IAM Policies, and others.
How are you using AWS Organizations to help keep track of your resources? Share your stories in the comments!
Top comments (0)