by Phil Christensen, Sr. Solutions Architect, Logicworks

For many companies, it is more efficient to create multiple AWS accounts for different departments, teams, or projects rather than a single large AWS account. Doing so makes it easier to separate critical data from sandbox environments, and helps to limit the blast radius from a critical security event.

Still, maintaining multiple AWS accounts can require a lot of annoying administrative setup and is prone to configuration drift. In 2018, AWS has launched a series of new services to make that easier.

Last month, AWS announced AWS Landing Zone, a solution that helps to automate the process of setting up and configuring multiple accounts. Best practices for setting up multiple accounts are embedded in the solution, making AWS Landing Zone a great idea for companies with complex workloads and larger teams that want to quickly migrate to AWS.

How do you use AWS Landing Zone?

It’s important to note that Landing Zone is not a new service, per se — it’s a solution, meaning that AWS assembled a series of existing AWS services into a complete architecture.

Landing Zone 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”.

Landing Zone starts with a well-architected AWS Organizations implementation and adds centralized logging, a cross-account permissions structure, and an automated “Account Vending Machine” process to enroll new child accounts at will.

In order to get access to the AWS Landing Zone toolset, you’ll need to work with AWS Professional Services or an approved AWS partner like Logicworks. Logicworks evaluated Landing Zone in tandem with AWS and other early adopters during the Preview period, and now can offer it directly to our customers.

What does AWS Landing Zone include?

1. 4 Accounts:

• An AWS Organizations “Master” Account that includes the most crucial security controls, like default policies and SSO services
• A Shared Services Account for less tightly controlled shared services
• A Logging Account to collect audit data and backups in a tightly controlled account
• A Security Account with elevated access to allow a central security team to monitor and control security tooling

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 Vending Machine (AVM) – essentially, an AWS Service Catalog product that allows you to create new “child” accounts to the existing Organization that maintain all predefined security baselines

From this foundation, you can launch individual accounts for applications, environments, business groups, or corporate entities, while keeping them separate from base infrastructure accounts.

To start with, you might just have one more account that has majority of workloads, and over time add additional accounts. What each account represents depends on your company, and there are a million different ways that could be put together.

Why separate central functions from application accounts?

From the master, you can limit services available to child accounts. Not just permissions, but you can force a set of policies or AWS CloudFormation templates (called “stacksets”) to be applied to all accounts, so that you can force policies on users of an account, create default infrastructure, or notification pipelines . 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 much more difficult.

This can be a core part of your security strategy and cost management strategy. 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 your logs, backups and other things you need to archive, you can more easily restrict  access to those archives and can ensure nothing gets deleted.

AWS Landing Zone and AWS Organizations are most compelling for companies with many different IT roles for security, networking, devops, DBAs, etc. who all have different needs. It is also useful if you want to segregate compliance standards but still have default functionality across environments.

AWS Landing Zone in Real Life

We’re so excited about the potential of AWS Organizations and Landing Zone that we’ve already recommended it to several customers.

We’re currently working with a large financial services organization, where different departments have different concerns, and truthfully, some difficulty getting everyone on the same page in terms of how AWS should be configured and controlled.

Splitting up accounts and responsibilities is particularly good for an organization like this, because it’s less disruptive to their existing roles but improves their capabilities in a way that’s integrated and functional. You can define exactly which roles that different people need to perform. You can also more easily satisfy finance industry regulations, avoiding scenarios where it’s hard to know if regulations or policies apply to a certain environment.

Customers are also excited about AWS Organizations for a more mundane reason; it’s annoying as an systems engineer to scroll through other resources to get to the stuff you want to work on. It may seem like a small thing, but limiting scope in this way ensures that your engineers are working on the right resources and not inadvertently touching resources that they shouldn’t.

In short, both Logicworks and our customers are excited by the potential of multi-account AWS strategies. As larger companies move more workloads to AWS, we expect that this will be the default way to manage large-scale deployments.

Logicworks is one of the few companies in the world that’s an authorized subcontractor under AWS for Landing Zone. Contact us today to learn how we can help you build a secure, multi-account architecture.