Managing Organizations with Takomo

I have had my own personal AWS account for over half a decade now. Back in 2015 I didn’t have any need for multiple accounts. All my workloads were running fine within a single account. Nevertheless, my appetite grew and in 2017 I migrated to AWS Organizations. I was able to separate different functions from one another. After a while I had separate accounts for backups, shared services etc. Creating accounts is fast. However, management of all these different accounts was rather cumbersome and time consuming. Luckily Takomo can change this.

Steps taken on this post assume you are already running AWS Organizations. If not the case, you enable Organizations either via console/cli or using command tkm org create .

Please keep in mind that the default limit for accounts in Organizations is 4. If you are planning to test the features, make sure you raise the limit via support beforehand!

I have been working for a while migrating my personal website from Lightsail into VPC. Things are already running smoothly on my development account and I am now ready to create a separate production account.

Before I can create a new account I need to tell Takomo I want the application to support AWS Organizations. This is done by creating a new directory (organization) and configuration file (organization.yml). Below is a bare minimum of what the configuration file should look like.

masterAccountId is used to define the organization master. It is used to ensure that organization management operations target the correct AWS organization. 

organizationalUnits define the OU structure. In this example we simply define just our Master account to appear on the root OU. We’ll take a closer look at organizational units later in the post.

Now I am ready to create a fresh account.

Output of creating a new account with Takomo

My new account is now ready to be taken into use. I could access it with OrganizationAccountAccessRole. However, I want to add some core functionality to the account first.

Creating new accounts is easy. I could do the same from within the console, CLI or various 3rd party tools. However, not many tools give me capability to manage the entire organization and store the entire organization structure into a configuration file.

First thing I want to do is to organize accounts into organizational units (OU). OU can be used to administer accounts as a single unit. For example, I might want to attach service control policies (SCP) to an OU. Once enabled, these policy files would affect all accounts within the OU.

organization.yml

This is the first step of configuring my organization. Next we’ll walk thru the new parameters on the configuration file:

trustedAwsServices defines trusted access for various AWS services. Takomo will enable all services by default when organization is deployed. Since I don’t want to enable everything I can list only the ones applicable for my use case.

serviceControlPolicies defines SCPs used in the organization. I have defined two policies: FullAWSAccess and AllowedRegions. First is awsManaged, meaning we use policy defined by AWS (FullAWSAccess is the default SCP. It is attached to all accounts in your Organization by default). The latter is a custom policy. The actual policyfile, called AllowedRegions.json, is located in the service-control-policies directory. In this example I limit my accounts to only use European regions and us-east-1.

AllowedRegions.json

Last changes are made on organizationalUnits. I need to define all my accounts on the configuration file in order for Takomo to work correctly. I don’t want to create a difficult structure for my existing accounts (master, shared, bc). I will keep my old accounts on Root OU. I will add a new OU (“WebProject”) where I add my development and production accounts. I will also enable additional AllowedRegions SCP to limit which regions can be used on workload accounts.

Now I can start deploying my organization with tkm org deploy command. Tool will display changes about to be done: few new OUs will be created, accounts are about to be moved to new OUs and some SCPs will be attached to accounts. Few seconds later I have my new organization structure ready!

Deployment summary after running takomo org deploy

Entire Takomo Organizations guide can be found at Takomo documentation [2].

Being able to define organization units and service control policies for accounts within AWS organization is great but let’s be honest, it only gets you so far. The real struggle is to create your base infrastructure. Perhaps you want to deploy IAM users or cross-account roles for your administrators. Or maybe you want to create a VPC and network resources into your workload accounts to limit the burden of your development team. This can be accomplished with config sets.

In the next example I will utilize Takomo to deploy a VPC stack to my development and production accounts. Once my base infrastructure is in place I could hand over these accounts to the actual development team. By default, Takomo will use OrganizationAccountAccessRole to perform this. However, I can define any role available if needed. 

organization.yml with modified account information

Looking at the existing WebProject OU, we can see first changes in the configuration. I have changed the formatting of my dev and prd accounts. I have also added new sections, “vars” with CidrBlock and EnvironmentName definitions. These variables are passed to my configuration set when I want to deploy my accounts. This way I can define different CIDR blocks for my development and production VPCs.

Let’s continue to the bottom of the file. I have added a new block, “configSets”, where I define my base configuration (baseConfiguration). Naming isn’t important here, I could call it whatever I want. What is important is that I also have something on my commandPaths. In this case “/base” reflects a directory in my stacks folder. configSet is also added to my organizationalUnits configuration for my development and production accounts.

The last thing is to define the actual VPC stack. If you read my previous blog post [1] or have tried Takomo you should already be familiar with how standard Takomo stack configuration looks like. We defined baseConfiguration commandPath to be /base. After this we just need to create a new directory inside the stack configuration directory. I will create a new stacks/base/vpc.yml file and define the required parameters as below.

stacks/base/vpc.yml

If you find the text above confusing here is the whole directory tree:

Now we are ready to deploy the new VPC stacks with tkm org accounts deploy -command. The tool will present me a list of stacks about to be deployed. I am able to review my changes and proceed with the deployment. Once done, I will get a nice deployment summary telling me how my deployment went.

Now I am ready to start working with my new accounts!

If you are looking for more guidance how to manage Organizations with Takomo, take a look at official Takomo example [3].

In the next part of the series we will take a look at the advanced features of Takomo, including custom stack resolvers. Stay tuned!

[1] https://webscale.fi/blogi/introducing-takomo-a-new-cloudformation-deployment-tool/

[2] https://takomo.io/config-reference/organization.html

[3] https://takomo.io/examples/managing-organization.html