Managing more than one AWS accounts can become challenging. AWS Organizations provides a way to manage many accounts. You can automate account creation and management. If you use a naming schema you can leverage landingzone-organization! 

Naming schema?

Using a naming schema improves your ability to find the correct account faster. For example, let say your company Xebia has some workloads. Each workload requires a full DTAP environments. When you follow the best practices of AWS, you will end up using an account per environment.

Using a naming schema your account name would look like this: xebia-<workloadname>-<environment>

When you make use of AWS SSO you will see a list of accounts. In each account you will have one or more roles that you can assume. Depending of your permissions that could be none or all accounts.

When you are a workload engineer you will have a short list. When you are a platform operator or an auditor you might have access to all accounts. In the later, it helps when you have applied this schema. For example, you can search on the workload name. This will filter out the list only showing the environment account for that workload. Or you can search on environment, or even a combination.

Going a step further

Combining a naming schema with an OU layout wil result in even more flexibility. 

First, lets address obvious advantages. When you use a OU structure as followed:

• workloads/development/xebia-myworkloadname-development
• workloads/testing/xebia-myworkloadname-testing
• workloads/acceptance/xebia-myworkloadname-acceptance
• workloads/production/xebia-myworkloadname-production

This allows you to place a SCP on the workloads OU this one applies to all workloads. But you also have the ability to apply a SCP on each individual environment OU. This SCP is then only applied to the development accounts for example. I will not go into SCP that is a topic on its own.

The other advantage is that you now know where your workloads live. Combine that with landingzone-organization and you can do things like this:

from landingzone_organization import AWSOrganization

# Fetch the organization information and instantiate the organization object
organization = AWSOrganization().parse()

# Define the OU structure where the workload accounts live
nested_ou = ["Workloads"]

# Iterate over all workloads in the provided OU location
for workload in organization.workloads(nested_ou):
    # Display the workload name
    print(f"Workload: {workload.name}")

    # Iterate over each account in the workload
    for account in workload.accounts:
        # Display the environment name and id of the account (aka the workload environment)
        print(f"\tEnvironment: {account.environment} has {account.account_id}")

Why does this help me?

Keeping track of workloads that are actually running is hard. But if it does not have a production account you know the workload is not in production yet. Next to that keeping track of what workloads exists within your organization is hard. Most of the times this comes from spreadsheets, how do you keep those up to date?

With this tool you can write all the needed data to a CSV file for later consumption. It could become the source of truth within your company and you can automate! 

Conclusion

Automation makes are life easier! So stop keeping track of your workloads the old fashion way and start using automation tools. 

There are various applications for this that I will hope to address in a future blog, so stay tuned!

Photo by Sangria Lips