Tested for you: multi-account setups with AWS Landing Zone

Update 2018–11–27: AWS Landing Zone 2.0 has been released and we updated the article accordingly.

Update 2018–12–01: AWS Control Tower has been announced (currrently private preview) and will using / compatible with Landing Zone according to AWS.

What are AWS Best Practices? How do I secure my workloads? How can I give teams maximum autonomy without compromising security or consistency? Which basic design should I use in AWS? How do I manage users and access rights? How does AWS Multi-Account work?

These are some of the many questions we hear over and over again, particularly from customers who are new to AWS and struggling to negotiate their way through the vast array of concepts and services.
Blog posts on best practices are to be found here and there — some of them posted by AWS itself — many of them current and many already outdated. But wouldn’t it be great to have some kind of automated process that would provide a quick start, one that would allow you to get down to your actual work straight away?

We often see the AWS basic setup being ‘clicked’ for various reasons in the AWS web console — in other words, manually executed, making what ensues scarcely understandable or reproducible. Furthermore, good or best practices are often included in response to chance events; for example, an employee reads a blog post and links to the article in a dev chat as a ‘we should do this’ item. These items are often then left undone, as there is ‘no time’, it is ‘not within scope’, or the initial cost is excessive. Or they are done, but then ‘clicked’, whereupon the knowledge often remains in the clicker’s head and in many cases left to gather dust.
Previously there was no solution (that we were aware of) for the setup process, but this has changed with the AWS Landing Zone. Landing Zone is an ‘AWS solution’ that codifies current best practices and rolls them out in an automated manner.

What does Landing Zone promise?

• Automated AWS multi-account setup
• Basic security guidelines
• Codified best practices (including updates directly from AWS); for example, automated CloudTrail setup, GuardDuty setup and VPC/network design
• DevOps best practices: Infrastructure-as-Code with the use of codified templates and continuous delivery, whereby your own extensions can be rolled out globally.
• High adaptability owing to the use of templates
• Modularity
• Single Sign-On and central management of access rights (optional)

First impressions

While some blog posts have been content simply to copy the news from AWS, we decided to try it out for you ourselves.

Installation

Installation is performed using a CloudFormation template, also referred to as an ‘initiation template’, in which you select certain basic settings.

The initialisation process writes a config template to an S3 bucket. This serves as the source for a CodePipeline, which is also created using the initiation template.

This config can be adjusted later and is the ‘single source of truth’ for your Landing Zone. The CodePipeline runs with every change made to the config and applies the changes to the infrastructure. CloudFormation templates are a part of the configuration process in addition to the manifest, such as for virtual private clouds (VPCs) (and therefore also can be adjusted or extended).

For the first test, we recommend that you set the BuildLandingZone parameter to false to prevent the pipeline from immediately ‘taking off’. This will give you a chance to inspect the generated config first and make any necessary adjustments to it before it begins to run. You may also want to set LockStackSetsExecutionRole to false first, as otherwise you may lose direct access to the sub-accounts. It is recommended, however, that you later set the parameter to true, as this restricts administrator role access in sub-accounts to the Landing Zone resources.

The basic setup creates the following accounts:

• Master: This is where you will find the AWS organisation, along with the CodePipeline, which rolls out the Landing Zone. Also found here are Single Sign-On (SSO) and a service catalogue for the ‘Account Vending Machine’ (AVM), which automates the process of creating new AWS accounts.
• Security: Here you can find roles that allow you to switch to other accounts or receive notifications of security incidents.
• Shared services: This is the place for Active Directory and other services that are used by all accounts.
• Logging: This is the central landing place for logs, such as CloudTrail audit logs.

(source: https://aws.amazon.com/answers/aws-landing-zone/)

Account baseline

A ‘baseline’ is provisioned in all accounts. In the default configuration, the baseline contains:

• CloudTrail setup (audit logs)
• AWS GuardDuty setup for automatic threat detection
• AWS Config and a basic rule set (‘Governance’) used, for example, to send an alert if CloudTrail has been deactivated
• IAM password policy for IAM users
• Cross-account access from the Security account
• An optional VPC according to specifications
• Notifications and alarms, for example when root users log in

Creating a new AWS account

Once the AWS Landing Zone has been successfully set up, you can create a new AWS account through the AWS Service Catalogue, where an
AWS-Landing-Zone-Account-Vending-Machine product has been created. This now allows you to provision new accounts. The baseline is automatically created along with it.

Selecting the product in the Service Catalogue

Once the product has been selected, the root user’s email address can be selected for the new account, along with a name and the organisational unit. In addition, you can set whether and how a VPC is to be configured.

Setting the parameters for the new account

What we like

• Codification: The entire solution is documented in code, and there are no manual steps (with one exception: bending the CodePipeline to something other than S3 as a source takes just one click).
• Extensibility: Landing Zone provides a solid basis on which to roll out, for example, your own CloudFormation stacks across AWS accounts.
• Best practises directly from AWS: Here AWS has accumulated and codified their experience.
• Landing Zone is continually maintained and extended by AWS. No sooner than we run our test had a new version came out that fixed two bugs we had encountered. There are, as yet, no notifications or changelogs, however.
• Application to existing setups: It is fundamentally possible to migrate existing multi-account setups to AWS Landing Zone and thereby extend the benefits to existing setups as well.
• Idempotence: During the test we encountered several errors that brought everything to a standstill, for example in the pipeline. But after we fixed the code, we were able to re-initiate the pipeline, and things proceeded. We never ended up at an impasse. This is no doubt thanks to the consistent use of Lambda and Step Functions, which force a certain idempotence.

What we don’t like so much (yet)

We noticed the following, among other things, during the first tests:

• Complexity as a result of the large number of services used: This makes it difficult at times to understand what is happening. Here’s an example: Service Catalog triggers CloudFormation, which has custom resources that trigger Lambda, which triggers a Step Functions state machine, which in turn calls inter alia CloudFormation StackSets. On the other hand, the consistent use of serverless components also guarantees that maintenance costs are lower.
• Not quite properly published yet: The solution is public but ‘hidden’. It can be used all the same, and our first tests resulted in a fundamental ‘production readiness’. Moreover, it is subject to the Amazon Software License, which permits its use and alteration in the AWS context.
• T̶h̶e̶ ̶A̶W̶S̶ ̶S̶S̶O̶ ̶s̶o̶l̶u̶t̶i̶o̶n̶ ̶i̶s̶ ̶l̶i̶m̶i̶t̶e̶d̶ ̶t̶o̶ ̶u̶s̶-̶e̶a̶s̶t̶-̶1̶,̶ ̶a̶n̶d̶ ̶i̶n̶h̶e̶r̶e̶n̶t̶l̶y̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶m̶u̶l̶t̶i̶-̶f̶a̶c̶t̶o̶r̶ ̶a̶u̶t̶h̶e̶n̶t̶i̶c̶a̶t̶i̶o̶n̶. Update 2019–02–27: AWS SSO is now available in multiple regions. Update 2019–01–16: Still no multi-factor authentication AWS SSO, but at least email verification.

And the costs?

Landing Zone sets up a few resources by default that cost money. The most costly of them are AWS Config Rules and GuardDuty. According to AWS, these add up to about $200 a month.

How do you test it on your own?

You can test AWS Landing Zone yourself. We recommend that you first run your tests in a newly created account with a new organisation so that you can gain some experience in a sandbox environment. Landing Zone itself comes as a CloudFormation template and can therefore be installed with one click:

(in some cases, you may have to change the region in the URL if you do not wish to provision Landing Zone in ` us-east-1 `.)

Here are AWS’ docs:

• AWS Landing Zone Developer Guide
• AWS Landing Zone Implementation Guide
• AWS Landing Zone User Guide

superluminar is an AWS Consulting Partner and will gladly help you automate or optimise your new or existing multi-account setup with AWS Landing Zone.

Summary and outlook

With Landing Zone, AWS provides us with a solid basis for secure and automated multi-account setups. In addition, the solution creates a positive impression on the strength of its extensibility, consistent use of Infrastructure-as-Code, continuous deployment, and updates from AWS.

We also discuss other aspects in the following articles:

• How do I extend Landing Zone, for example to roll out my own CloudFormation stacks globally across all accounts and keep them up to date?
• How do you get an existing AWS multi-account setup into Landing Zone? What do you have to watch out for?
• How do you adjust the baseline in order to, for example, start without Active Directory / SSO?
• How do you update Landing Zone with new releases? What happens during an update?
• How do I accomplish different account settings for different environments (e.g. dev/prod) or teams/organisational units?
• How does the built-in SSO solution work? What do you have to watch out for?