This article describes the requirements and complexities of implementing a secure landing zone in AWS cloud. Its purpose is to prove the value of the AWS Control Tower service and demonstrate the head-start it provides to your cloud team while addressing the extensibility required for the majority of implementations.

I spent 3.5 years at AWS Professional Services with the majority of my time spent on customer projects with a landing zone requirement. These were for both greenfield, enabling mass migrations from on-premises and also where customers’ had an existing footprint which saw unmanaged account sprawl.

Micro-segmentation

An enterprise may have hundreds, if not thousands of applications. With cyber security being front and centre of all digital transformation programmes, more and more organisations are adopting a micro-segmentation strategy to reduce the blast radius and damage caused by a cyber security incident. The UK government’s National Cyber Security Centre (NCSC) describes micro-segmentation as “… a technique whereby the workload of a system is divided into segments, based on security needs. Necessary controls are then applied on a per-segment basis.”

Customers often use multiple accounts to isolate their resources because they provide natural boundaries for security, access, and billing. Applying a micro-segmentation approach to AWS workloads entails confining applications to dedicated AWS accounts (AKA segments) with a highly controlled least-privileges approach to connectivity between this dedicated account and others.

Managing Multiple AWS Accounts

Whereas managing a single account is trivial, ensuring a solid infrastructure and security baseline across multiple accounts is much more involved. Here are some of the fundamental questions that need answering in order to build out a landing zone.

• ‘Vending’ accounts: what mechanism will you adopt to create AWS accounts for use by application teams?
• SSO: how do you ensure proper authentication/authorization for AWS console and API access, preferably using a customer’s existing Identity Provider (IdP) such as Active Directory or Azure AD?
• Guardrails: how do you ensure both detective and preventative guardrails are consistently applied across accounts?
• Logs: how do you centralise logs from your sprawling accounts so that this can feed into your incident management process?
• CI/CD: while the AWS Console is a great introduction to the AWS services, preparing accounts using the ClickOps approach is not scalable and will necessarily introduce risk as humans are in the loop. Instead, a GitOps approach to building cloud infrastructure is required. Together with a selected Infrastructure-as-Code (IaC) platform, a CI/CD workflow will automatically test, build and configure the infrastructure required by a new AWS account.
• Change management: most enterprises implement ITIL tooling such as Service Now to manage their IT changes. When a development team requests AWS accounts for their application, this will go through a change management process which usually includes one or more approvals stages. The architecture below describes how JIRA Service Desk can be integrated with AWS via the Service Catalog service:

• Backups and DR: with the mantra of “everything fails all the time” at the forefront, how should these requirements be implemented across multiple accounts?

AWS Organizations

Released in 2017, you can create a single AWS Organization and use policy-based management with Service Control Policies (SCPs) for multiple accounts. Using the AWS Organizations API, you can for example CreateAccount, CloseAccount and assign consistent metadata to accounts by using the TagResource API

AWS Single Sign-On (AWS SSO)

Integrated with AWS Organizations, AWS SSO is a service that makes it easy to centrally manage SSO access to multiple AWS accounts and business applications. Its support for SAML 2.0 allows AWS SSO to integrate with your on-premises IdP such as Azure AD as illustrated below.

AWS SSO provides not only seamless AWS Console access but also command line/programmatic access through automatically generated code snippets containing sts-generated temporary access keys as shown below.

Managing Logs for Multiple Accounts

There are two types of logs that infrastructure in our accounts will generate and by default, the log destination is the local account.

• AWS CloudTrail logs: API access logs
• CloudWatch: application and service logs.

In order to centralise our CloudTrail and CloudWatch logs, we can consolidate them in a dedicated log archive account. If using AWS Organizations, we can consider creating an organization trail to log data for all AWS accounts in your organization, kept in a separate account.

The log archive account’s S3 bucket will resemble the functionality of a WORM (Write Once, Read Many) drive in that while all accounts will log to this bucket, none will be able to modify/delete logs once written. The access to the log archive account will be strictly controlled and logged. Also, MFA delete should be enabled to prevent the accidental deletion of log files.

The Case for AWS Control Tower

In the above, I looked at the typical requirements of a multi-account environment and suggested individual solutions, most of which may be automated using respective service APIs. For example, using the Organizations API, we can invoke the CreateAccount action. However, combining and consolidating these solutions to create a landing zone solution is no easy task.

Customized Landing Zone Frameworks

In the past, there have been solutions published by AWS including the Customized Landing Zone Solution:

While the above solution was easily integrated into a GitOps workflow, the sheer number of moving parts created a lot of overhead for customers. The author remembers one of his customers spending a number of days troubleshooting a failed pipeline.

Enter AWS Control Tower

The successor to the Customized Landing Zone Solution, AWS Control Tower, was generally available in June 2019. As a managed service, AWS Control Tower removes the management overhead of previous solutions and provides an automated landing zone that deploys best-practices blueprints within an hour.

Features include:

• Account Factory: powered by AWS Service Catalog, allows simple provisioning of new AWS accounts with pre-approved account configurations.
• Guardrails:
  - Preventive and Detective
  - Mandatory and Optional

The value of having ready-made guardrails cannot be understated. For example, creating a preventative Service Control Policy (SCP) involves careful application of IAM policy logic and extensive testing to ensure you haven’t inadvertently created holes that may be exploited.

• Dashboard: continuous visibility into your AWS environment including the ability to check your OUs and accounts against guardrail compliance.

But…

Although AWS Control Tower does provide a great multi-account starter framework, out of the box it is not useful to the majority of organisations. Merely providing the facility to vend an AWS account is not enough. Accounts often require customisations around VPC CIDR/AZ allocation, custom IAM roles and guardrails. Also, AWS SSO cannot and does not automatically integrate with your IdP as part of the Control Tower deployment. This will need to be configured after the fact.

AWS recommend the Customizations Framework for Control Tower (CfCT) which uses AWS Control Tower lifecycle events to trigger the deployment of customisations to a newly vended account.

However, CfCT uses AWS native IaC with CloudFormation and this doesn’t help customers who’ve adopted TerraForm IaC.

Enter Terraform Account Factory (AFT)

The AFT Terraform module uses a similar approach to CfCT and uses a GitOps model to trigger account customisations upon a commit. Customers often ask how they can utilise readily-available CloudFormation templates published by AWS, e.g https://github.com/awslabs. Thankfully, Terraform has the aws_cloudformation_stack resource which allows the launching of CloudFormation templates from within a Terraform one.

Concluding remarks

Account micro-segmentation is a common pattern to reduce the blast radius of the resources within an account being compromised. It is also a great cost management boundary as the alternative is insisting upon and enforcing tagging of resources in a multi-application/environment account. A multi-account framework helps you automate best practices across your AWS estate and ensures consistency from a configuration management perspective.

AWS Control Tower is a managed service which takes away the undifferentiated heavy lifting associated with creating your own landing zone. It provides in less than one hour, an account vending solution and a sensible set of guardrails along with basic AWS SSO integration. Lifecycle events allow further customisation using solutions such as Account Factory for Terraform.

References:

https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html

https://docs.aws.amazon.com/controltower/latest/userguide/taf-account-provisioning.html