If you’re planning a large-scale AWS deployment, you’re probably wondering how to orchestrate multiple applications and teams on AWS. How do you make sure that every team can access AWS without your accounts turning into sprawling, ungoverned chaos?

For many companies, a multi-account structure can help meet the unique needs of each application team or business group. AWS provides free native tools like AWS Organizations to help provide central orchestration of multiple accounts, so that you can enforce security and billing configurations while still giving each team some degree of autonomy over their account. Still, maintaining multiple AWS accounts can require a lot of annoying administrative setup and is prone to configuration drift.

Recently, AWS launched a series of new services to make that easier. AWS Control Tower is essentially an opinionated architecture that builds out a multi-account architecture with pre-configured security and access settings, plus a dashboard to manage that multi-account architecture over time.

Since its launch, AWS Control Tower has become the go-to solution for Logicworks when we’re doing a large-scale AWS migration. This is especially true when working with companies that have significant regulatory requirements.

Download the AWS Control Tower Guide (with architecture diagrams + templates)

Why Multi-Account?

• Network isolation. Ensure that services of one account are not affected by the others. By separating applications or teams into completely separate accounts, there’s a better chance that an issue in one account won’t affect all accounts.
• Separation of concerns & modularity. An architecture that is separated into distinct services allows you to make changes, without affecting the rest of the company’s accounts. It often takes less time and coding to make a change to modular infrastructure than to monolithic infrastructure where features are mixed up together.
• Scalability. Need to spin up or down a new application or SDLC tier? You can do so knowing that the additional account is connected to the Hub and central security requirements.
• Compliance. Limit the scope of your audits (and cut audit expenses) by maintaining regulated data in a limited number of accounts and by putting non-regulated data into another account. Also, it is often a compliance requirement to separate development and production environments (ex. SOC1 + 2). The multi-account model allows you to do this without duplicating security controls for each account.

What is AWS Control Tower?

AWS Control Tower is a solution that helps automate the process of setting up and configuring multiple accounts. (Formerly known as AWS Landing Zone.) Best practices for a multi-account architecture are embedded in the solution, making AWS Control Tower perfect for companies with complex workloads and larger teams that want to quickly migrate to AWS. Control Tower is deeply tied into AWS Organizations, a service that allows you to enroll any number of “child” accounts under a parent account and apply policies across all accounts from a single location. This extends similar functions originally used for
Consolidated Billing and provides additional capabilities like AWS CloudFormation “stacksets”. Stacksets allow you to provision infrastructure across child accounts.

To start, you might have one account that has the majority of workloads. From this foundation, you can launch individual accounts for applications, environments, business groups, or corporate entities, while keeping them separate from base infrastructure accounts.

AWS Control Tower deployment. Source: AWS

Why separate central functions from application accounts?

As Control Tower is built on the backbone of AWS Organizations, which allows you automatically control access and permissions for child accounts. AWS Organizations allows you to define Service Control Policies to limit the services that are available to different accounts within the Organization. You can enforce policies on users of an account and define cross-account permissions to ensure your organization has the guardrails in place to maintain a secure environment. This is particularly useful for setting restrictions to powerful roles in child accounts. If the master account denies a privilege, a child account has no ability to override that restriction. Without the controls available inside an AWS Organizations structure, granting select administrative access is more difficult.

This can be a core function of your security and cost management strategies. Even if a malicious actor accesses one account, there is no way for them to access other accounts, and they may have limited privileges within that account. This limits the blast radius of certain activities. Additionally, by having a cross-account destination for all of your logs, backups and other items you need to archive, you can more easily restrict access to those archives and ensure nothing gets deleted.

AWS Control Tower and AWS Organizations are most compelling for companies with many different IT roles who have different needs. It is also useful if you want to segregate compliance standards but still want default functionality across environments.

What does a default AWS Control Tower include?

1. Core Organizational Unit with 3 accounts:

• Master Account – Provides the ability to create and financially manage member accounts. Also used for Account Factory provisioning and accounts, managing Organizational Units, and guardrails
• Log Archive Account – Contains central Amazon S3 bucket for storing logs of API activities and resource configurations from all accounts in the solution.
• Audit Account – A restricted account that’s designed to give security and compliance teams read/write access to all accounts in the landing zone. From the audit account, you have programmatic access to review accounts, by means of a role that is granted to Lambda functions only. The audit account does not allow you to log in to other accounts manually.

2. Within each account, an initial security baseline that includes:

• AWS CloudTrail, sent to a centrally managed S3 bucket in the Logging Account
• AWS Config, also sent to a centrally managed S3 bucket in the Logging Account
• AWS Config Rules enabled for monitoring encryption, IAM password policies, MFA, and security group rules
• AWS IAM roles, potentially including restrictions applied from the master account
• An initial Amazon VPC network

3. An Account Factory – essentially, an AWS Service Catalog product that allows you to automatically create new “child” accounts to the existing Organization that maintain all predefined security baselines
4. The Control Tower Dashboard – limited UI to the base Control Tower constructs. Only components deployed and managed by Control Tower are seen in the dashboard.

Control Tower can additionally work with functionality not yet exposed in the Control Tower dashboard interface, but available in the direct configuration of the foundational services. An example of this is repointing AWS SSO to another identity provider directory, including Azure Active Directory (AD) or AWS Managed Active Directory. This AWS SSO configuration works in a Control Tower environment, but is not yet displayed in the Control Tower dashboard itself.  Control Tower can also be extended with customizations or “add-ons”.

The following diagram shows the Control Tower dashboard, with a few accounts provisioned.

Control Tower Dashboard

Launching Control Tower in the Real World

For the past year, Logicworks has launched nearly a dozen multi-account solutions for a wide variety of customers. Control Tower is a perfect toolset for any company that needs to segregate business units or SaaS tenants while maintaining central billing and security baselines. And companies that we’ve worked with have been pleased at the result: a secure, well-organized account structure that can expand with their company.

Here are just a few of the multi-account projects that we’ve worked on in the last 12 months: 

• A financial investment management firm used a landing zone to provide dedicated accounts for each portfolio manager or team, with automated baselines and security tooling by default.
• A franchise-based service delivery organization used a landing zone to provide accounts for every business unit and application development lifecycle
• A billing management SaaS provider used a landing zone to deploy dedicated accounts per end tenant for clear infrastructure segmentation by customer. This also allows them to maintain different security and compliance requirements for each customer, if necessary. 

Sample AWS Control Tower Architecture

The following are actual architecture diagrams from a project Logicworks recently completed with a SaaS company. Each account had its own diagram, but for the purposes of this guide, we’ve provided the overall account structure and a look at network flow between various critical components.

A few notes: 

• Account Vending Machine has been renamed Account Factory, as explained above.
• The customer was a single tenant SaaS company, so ever customer maintained a separate account.
• This diagram is representative of the core account architecture plus a single customer account. Obviously, the SaaS company managed multiple customer accounts.

Network Flow Detail

This architecture diagram shows how information flows from the on-premises datacenter through the Network Accounts to the App Account.

• Data flow from on-premises to AWS:
  • Data flows back and forth from their on-premises datacenter through an AWS Direct Connect (dedicated network connection) to the Network Account
  • The Direct Connect Gateway can transfer connections to multiple VPCs, like a Transit Gateway
  • On the App account, a Virtual Private Interface acts as the endpoint from the Direct Connect
• End user access to the applications:
  • From the internet and Akamai (a CDN) to the load balancer, which distributes the traffic to the instances that are contained in private subnets. This represents all inbound traffic from external users to the eCommerce website assets (all static content)
• Logs flow from every account (including the Network Account, Sandbox, Dev/Test, QA/STG, and Production accounts) to the Log Account using a Lambda function and IAM access
• Cross-account IAM permissions are allowing access from services in the Shared Services account to the App Account

How to Deploy This Architecture

Since AWS Control Tower is a multi-account solution, it’s not possible to give you a CloudFormation template, as we will for other architectures in this Guide. Control Tower isn’t really an AWS service in its truest form. It has no API and you can’t create it with CloudFormation. It’s just a wrapper for other AWS services through the console. 

To launch a Control Tower, navigate in the AWS console to https://console.aws.amazon.com/controltower. Once there, you can pick your desired home region, provide details about core OUs, review service permissions, and launch Control Tower. 

We recommend checking out the extensive AWS documentation here, in order to launch a Control Tower or reach out to an approved AWS partner like Logicworks. 

Summary

In this guide, we discussed the basics of AWS Control Tower and outlined a few best practices. As an implementation example, we introduced the AWS Control Tower solutions that we used to help customers deploy real-life applications. A multi-account architecture is an ideal solution if you’re migrating a large, complex set of applications to AWS. AWS Control Tower is meant to help reduce the complexity of building and managing a multi-account structure long-term.

Need help architecting a custom solution or managing your AWS Control Tower? Our team of AWS experts have designed hundreds of custom AWS environments and can help you get the most out of AWS. Contact Logicworks to learn more.