Part 1 of this series discussed why a multi-account architecture has become the best practice for large organizations that consume AWS. It also introduced a service that helps organize those accounts, AWS Organizations. Having an easy way to organize accounts is great, but that only begins to scratch the surface of what is necessary to run a full scale multi-account infrastructure using best practices in AWS.
The concept of a landing zone is what suits many large organizations who are looking to start fresh in the cloud. A landing zone is a greenfield environment that is created with standardized policies for security, administration, management and best practices. It provides many of the necessary controls out of the gate, rather than having to build everything from the ground up. It can be the backbone for organizations to start building in the cloud with the knowledge that their environment is governed according to a set of best practices.
AWS Landing Zone
The best practices recommended for a landing zone can certainly vary across cloud providers. AWS spent a lot of time working with customers to define their own set of best practices for a multi-account architecture and created an offering that provides an out-of-the-box environment called AWS Landing Zone. This solution is a codified version of these best practices that can be run to create a brand new environment for an organization to use as a starting point in AWS.
The AWS Landing Zone architecture consists of a few default accounts that are built under the umbrella of a “root” organizational account that acts as the billing master and contains some centralized governance. This architecture provides a number of key benefits that help get AWS customers off the ground:
- Organizational level governance for security and management
- Centralized CloudTrail and AWS Config Logging
- Account baselines for security and networking
- Cross account access
- RBAC via AWS Single Sign-On
- Automated account creation
Account Architecture
The architecture above describes a default AWS Landing Zone deployment. It consists of four accounts out of the gate:
Organization Master – Master billing and root AWS Organizations account. Utilizes AWS Single Sign-On for user access into specific accounts which can be federated with Active Directory or third party SSO. Repository for AWS Landing Zone configuration via CloudFormation and corresponding AWS CodePipeline that builds/updates the solution. Also uses the AWS Service Catalog to provide automated account creation via an account vending machine service.
Shared Services Account – Contains network baselines, can be used to build out a shared network account utilizing things like Transit Gateway and Shared VPCs to allow connectivity across accounts. Other shared services like AWS Microsoft AD should go here.
Log Archive Account – Centralized landing spot for CloudTrail and Config logs across all accounts into AWS S3.
Security Account – Repository for cross-account access and security related notifications. Amazon GuardDuty master account that runs across the organization.
Deploying an AWS Landing Zone
The AWS Landing Zone architecture is defined using Infrastructure as Code (IAC) and launched via CloudFormation. The CloudFormation template is provided by AWS to create a config template, which is used as the source for a CodePipeline that is built during initialization. There are a good number of parameters that are required to run the stack, such as the email addresses to use as the root user for each of the new accounts that will be created, the names of OUs to add into AWS Organizations, shared services VPC info and a bunch of AWS Config Rules.
One of those parameters is a boolean called “Auto Build Landing Zone,” which defines whether the CodePipeline should be triggered immediately after creating the CloudFormation stack. This is set to yes by default, but can be changed to no so that changes to the config could be made prior to the pipeline deploying the rest of the infrastructure. One of the great things about AWS Landing Zone being available via IAC is the ability to customize the default specifications provided by AWS. The AWS Landing Zone solution is fairly complex, but the modular nature provided by delivering through IAC allows for the flexibility to bolt on custom components that may be of value beyond the defaults.
Once the pipeline is triggered, the process to build out the entire AWS Landing Zone takes roughly an hour to complete. You can view the status of the build within the AWS CodePipeline service. If the pipeline execution succeeds, you will have a landing zone as described above that is ready for your organization to start building away.
Account automation with Account Vending Machine
Within the root/master account, AWS Service Catalog provides a service called the Account Vending Machine (AVM). The purpose of this service is to create/update accounts within the organization. When accounts are created using the AVM, the account baselines provided by AWS Landing Zone are automatically provisioned into the new account. That means the new account will ship it’s logs back to the S3 bucket in the log archive account, AWS Config rules will be set, cross-account access and notifications/alarms will be available via the security account, etc. The service requires user access, so once you define who should have the ability to launch new accounts, you can provision the service to those users. Launching the service will allow a user to name the account, provide an email address for use as the root user, set the OU where the account should be placed, and optionally add VPC information.
Users still have the ability to go into AWS Organizations and manually create a new account directly within the organization. AWS Landing Zone doesn’t lock users out from consuming the underlying services, but should you create a new account outside of the AVM, the automated deployment of the landing zone account baselines will not happen. You would be left with a brand new sub-account within the organization that does not contain any of the governance provided by the landing zone via the AVM.
Flexibility vs. Simplicity
AWS Landing Zone is the result of a lot of time and effort spent to define recommended best practices for a multi-account organization and to codify that architecture into a service that is deployable within AWS. While AWS Landing Zone succeeds in creating this baseline infrastructure, it is still fairly complex. AWS Landing Zone still requires a good bit of leg work to make some of the modular components useful from an administrative stand point. Organizations that are very well versed in the AWS landscape and are fairly comfortable with IAC and CloudFormation may have an easier time bridging the gaps, but it could be more daunting for new AWS customers. Many organizations also have separation of duties between admin and developer teams, where developers are more familiar with AWS, but key components of a landing zone may fall under the domain of the admin team.
AWS released a service called Control Tower in the middle of 2019, which is a managed platform for deploying and governing new landing zones. Like other AWS PaaS offerings, Control Tower gives the perception of simplicity by masking the underlying infrastructure. Control Tower is in it’s infancy, but seems destined to be the authoritative way to deploy a landing zone within AWS. As with any new service, there are still some growing pains. I will explore Control Tower along with some pros and cons in the next post of this series.
