Automating Your AWS Landing Zone Deployment to Speed Up Large-Scale Migrations

By Jim Huang, Partner Solutions Architect at AWS
By Phil Christensen, Sr. Solutions Architect at Logicworks

Before you deploy your applications on Amazon Web Services (AWS), you need to design and configure a base environment that lays out the account structure, security rules, default network settings, and other foundational services.

Such a base environment is called a landing zone, and this is the best practice recommended for customer needing an environment to support multiple teams or projects.

In this post, we’ll describe best practices and introduce the AWS Landing Zone solution that automates landing zone deployment and configuration. We’ll also provide examples of customers’ landing zone implementations by Logicworks, an AWS Partner Network (APN) Premier Partner with AWS Competencies in DevOps, Security, and Migration, among others.

Regardless of the method you use to build your landing zone, you want to exercise the best practices recommended by AWS, including multi-account structure, security controls, self-service with guardrails, scalability, and extensibility from the initial landing zone environment, and automation with infrastructure as code.

A central element for landing zone best practices is the use of multiple accounts. You could just work within a single account; however, as your environment grows, it’ll become difficult to manage the environment. This is because many teams in the same account would overstep one another due to their different responsibilities and resource needs.

Similarly, you may have completely different business units or products which require different accounts. In addition, account is a unit of protection and isolation. You may need to isolate accounts based on different security profiles or compliance control requirements.

Furthermore, an account is the only true way to separate items at a billing level. A multi-account structure helps billing management like transfer charges across business units.

Landing Zone Best Practices

With the landing zone best practices, AWS recommends a multi-account structure as illustrated in Figure 1 below.

• Organizations master account: It provisions and manages member accounts under AWS Organizations Service.
• Core accounts in an Organizational Unit: It provides essential functions that are common to all the accounts under the Organizations, such as Log Archive, Security management, and Shared Services like the directory service.
• Team/Group accounts in Organizational Units: These are designated for individual business units at the granularity of team or group level. For example, a set of Team accounts may consist of the team’s Shared Services account, Development account, Pre-Production account, and Production account.
• Developer accounts: These are “sandboxes” for individual’s learning and experimentation.
• Connectivity: This is set up with default networking patterns among the accounts and with external data centers.

Figure 1 – Multi-account AWS Landing Zone.

Building such a comprehensive landing zone with the multi-account structure can be daunting. First of all, you’ll make many design decisions, such as number and type of accounts, network architecture, user access, and log aggregation.

Second, you need to configure accounts and services based on organizational structures, team duties, business process, billing, and more. Furthermore, you must address security and compliance requirements with the type of account, data classification, encryption, and auditing.

With the large number of design choices, setting up a landing zone environment can take a significant amount of time and require a deep understanding of AWS services. This leads to the AWS Landing Zone solution described in this post.

AWS Landing Zone Solution

To help accelerate customers’ on-boarding, AWS Landing Zone automates the setup of a landing zone environment with a multi-account architecture, an initial security baseline, identity and access management, governance, data security, network design, and logging.

This solution is built to help customers set up net new AWS environments and can scale to support production implementations for large-scale migrations.

Figure 2 shows the AWS Landing Zone structure. The default solution implementation deploys four core accounts: AWS Organizations, Shared Services, Log Archive, and Security. This multi-account structure is consistent with the landing zone best practices.

Figure 2 – AWS Landing Zone structure.

Here are the major functions you get from AWS Landing Zone:

Account Management

AWS Landing Zone provides a framework for creating and baselining a multi-account environment. The initial multi-account structure includes security, audit, and shared service requirements. To scale the environment, it has functionality called an Account Vending Machine that enables automated deployment of additional accounts.

Identity and Access Management

AWS Landing Zone is configured with cross-account roles to enable centralized access management. In addition, it uses AWS Single Sign-On (SSO) federation to manage user account access.

Solution Extensibility

AWS Landing Zone enables extension of the default landing zone deployment with customer-specific Add-On solutions or services (e.g. Centralized Logging). The Add-Ons are managed and deployed from AWS Service Catalog.

Security and Governance

AWS Landing Zone is pre-configured with a number of security functions. It enables Amazon GuardDuty in all the AWS Regions and removes Amazon Virtual Private Cloud (Amazon VPC) as the network baseline. To provide security guardrails, the solution deploys Account Baseline in each of the accounts.

The default Account Baseline consists of the following resources and services:

• AWS CloudTrail: Sends all the AWS service API calls to the Amazon Simple Storage Service (Amazon S3) bucket in the Log Archive account.
• AWS Config: Forwards the configurations of AWS resources to the Log Archive S3 bucket.
• AWS Config Rules: You define rules for provisioning, configuring, and monitoring AWS resources (e.g. Amazon Elastic Block Store (Amazon EBS) encryption and multi-factor authentication (MFA). AWS Config continuously audits the compliance of the AWS resource configurations.
• Amazon GuardDuty: Provides intelligent threat detection and continuous monitoring to protect your AWS accounts and resources.
• IAM Roles and Policies: AWS Landing Zone sets up security Admin and Read-Only roles and policies for your staff with different job functions.
• IAM Password Policy: AWS Landing Zone sets the password policy to enforce password complexity.
• Notifications: AWS Landing Zone configures Amazon CloudWatch alarms and events to send a notification on root account login, console sign-in failures, and API authentication failures within an account.
• Amazon VPC Infrastructure: AWS Landing Zone configures the initial network for an account. This includes deleting the default VPC in all regions, deploying the AVM requested network type, and network peering with the Shared Services VPC when applicable.

As you can see, with the account baselining, AWS Landing Zone saves customers time by automating the setup of their accounts and guardrails in line with AWS best practices. This helps customers quickly set up a new AWS environment with account management, identity and access management, solution extensibility, security, and governance.

Managing Large-Scale Migrations with AWS Landing Zone

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

The vast majority of Logicworks’ consulting and managed services clients must meet one or more regulatory frameworks, including HIPAA, HITRUST, PCI-DSS, SOC1, SOC2, FedRAMP, and more. For these companies, limiting the scope of any single engineer’s access to AWS is critical, so that accidental or malicious exposure of data in one area of the business does not compromise the entire AWS account.

Rather than separate environments within the same account, separate accounts under one “master” account allows the master to apply policies across all accounts from a single location.

AWS Landing Zone makes setting up multiple accounts not only easier, but less prone to operational errors. Anyone who has set up an AWS account manually knows how time-consuming it can be, particularly when there’s a number of mandatory security configurations and AWS CloudFormation templates. With AWS Landing Zone, we can set up a complex, secure, multi-account structure in a few hours or less, and it automatically enables the security guardrails for each new account.

Logicworks Use Case: Banking

A large bank recently approached Logicworks with a common set of issues: they had different departments with different concerns, and truthfully, some difficulty getting everyone on the same page. Each team wanted to configure and control AWS differently. The organization also had hundreds of regulatory control requirements, and each project required a different subset of these requirements.

This company was a perfect candidate for a multi-account strategy. First, the resulting solution was less disruptive to their existing roles while still improving their capabilities in a way that’s integrated and functional.

During the build, Logicworks was able to help the customer prescriptively define the necessary controls and roles within each AWS account based on different teams:

• Networking staff have the privileges to create and manage routes, peering connections, Virtual Private Networks (VPNs), and AWS Direct Connect, but they can’t deploy Amazon Elastic Compute Cloud (Amazon EC2) instances or other compute services like AWS Lambda.
• The Security team has permission to assume privileged IAM roles in the other accounts, but they have higher authentication standards, requiring more frequent MFA or the use of alternate sources.
• DevOps staff have access to a host of managed services but are limited to which accounts they can actually access.

Logicworks was able to satisfy finance industry regulations, avoiding scenarios where it was hard to know if regulations or policies apply to a certain environment. For example:

• When accessing the Shared Services account, the InfoSec role can see the existing Domain Controllers, but not instantiate new Amazon EC2 instances or modify network settings.
• When accessing other accounts, the Security team can read logs, but not modify network settings directly.
• The DevOps team can view most objects in the Shared Services account, but can only create CodeStar projects in one of the designated application environment accounts.

In order to launch AWS Landing Zone, Logicworks first created the new Organizations master account that would contain all the child accounts, and started thinking about the roles that were actually at play in the collected environments.

This leads to one of the last pre-planning steps, which is determining the boundaries between the various additional child accounts. There are many ways to organize your AWS accounts, and dividing your applications by team is common. But many companies also choose to divide accounts by “regulated” and “non-regulated” workloads.

Logicworks Use Case: Financial Services

Logicworks is also working with a large European financial services company to migrate hundreds of applications to AWS. One of the company’s main concerns was reducing their audit scope, as they spent millions of dollars a year on PCI-DSS compliance and wanted to ensure they weren’t spending time and resources on workloads that did not contain regulated data.

The company began by doing an audit of their existing applications, to confirm where regulated data was stored and transmitted. They ensured that dependencies between these applications were reduced, to facilitate migration to AWS.

With Logicworks’ guidance, the company ultimately decided to maintain five AWS accounts: the master account, a production “regulated” account, a production “non-regulated: account, a non-production “regulated” account, and a non-production “non-regulated” account. These were combined with Logging, Security, and Shared Services accounts to implement a complete customized landing zone.

A key time-saver when launching this configuration was the Account Vending Machine (AVM) functionality that’s an essential part of many builds. AVM capabilities were essential in ensuring that any child account added under the master were built according to a pre-defined template that handled the boilerplate guardrails needed in every new account. Once added, previously defined Stack Sets automatically roll out to the new environments, providing a baseline set of resources for each additional account.

The company was also excited about AWS Organizations for a more practical reason; it can be annoying as a system 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 your engineers are working on the right resources and not inadvertently touching resources that they shouldn’t.

Summary

In this post, we highlighted landing zone best practices. As an implementation example, we introduced the AWS Landing Zone solution that helps customers automate the setup of new AWS environments in line with AWS best practices.

It all starts with a multi-account structure with security and governance controls and network settings. Based on customer business requirements, the initial AWS Landing Zone environment can be scaled up through capabilities like the Account Vending Machine functionality, Landing Zone Add-Ons, and automated resource baselining.

Another takeaway from working on a multi-account structure is the improved efficiencies granted to individual business units. Individual groups within an organization can more easily manage their own resources while knowing they’re still adhering to the security and compliance standards mandated by their organization.

Learn more about AWS Landing Zone, and check out this video to launch faster:

Recently at AWS re:Invent 2018, AWS previewed AWS Control Tower, which is a service for automated landing zone setup and governance using guardrails. With its general availability coming around Q2 2019, AWS Control Tower will provide a service equivalent to the AWS Landing Zone solution described in this post.
.

Logicworks – APN Partner Spotlight

Logicworks is an APN Premier Partner. They provide expertise in complex infrastructure for industries with high security and compliance requirements, including finance, healthcare, and retail.

Contact Logicworks | Practice Overview | Customer Success

*Already worked with Logicworks? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.