Topics In Demand
Notification
New

No notification found.

Simplifying AWS environments with AWS Landing Zone and Control Tower
Simplifying AWS environments with AWS Landing Zone and Control Tower

September 24, 2021

351

0

A lot has been spoken and written about the cloud and the advantages it offers. However, with all these benefits, there are some complexities that one needs to deal with; the major one is the separation of resources based on the use case.

In AWS, an account is the only logical boundary for permissions. An uncoupled account structure is necessary to achieve isolation of billing, resource limit, and authorization by limiting the blast radius. To tackle this situation of the accrescent number of workloads and clutter with increased complexity in managing and maintaining the environments, AWS came up with a solution known as Landing Zone (LZ). In Landing Zone, AWS combines the best practices to launch a multi-account architecture.

The initial version of multi-account deployment was not through a service but via an AWS version of IAC known as CloudFormation Templates (CF templates). As mentioned by AWS, this procedure required a certain level of expertise and was not to be taken up by a novice engineer. It required a certain level of understanding of AWS architecture and the organization's needs.

Later, AWS also released another solution, Control Tower, which would take the hassle out of the equation and allow engineers to set up their LZ with relative ease. But the trade-off in this situation was less customizability. Although both the solutions aimed to resolve the same bottleneck, they had some differences in their approach. For the LZ, an organization can get in touch with an AWS engineer who can provide tailor-made CF templates at a certain cost or allow its own experienced engineers to work on them. On the other hand, the Control Tower will only provide you with the options present on the console, drastically dropping the complexity and customization level.

Let's see what both have to offer in detail.

Control Tower 

The idea behind the Control Tower is to reduce operational overhead and provide a dashboard for ease of configuring accounts. There are many prerequisites to be fulfilled for setting up an AVM. The Control Tower automates most of that but at the cost of customization. The number of accounts also changes as the Control Tower creates only three accounts in its initiating run. The three accounts are master, audit, and log archive, and the security baseline is configured on each account. Launching of new accounts is possible through the Control Tower dashboard itself. You can also onboard existing accounts to a Control Tower implementation. The Control Tower automatically configures the Security baseline and guardrails on the account and allows onboarding only when the account is compliant. Non-compliance of accounts is usually the result of the existing security practices, which might interfere with the new guardrails being implemented or inaccurate access provisioning.

PowerPoint
Description automatically generated with medium confidence

Source: https://aws.amazon.com/blogs/apn/reducing-the-cost-of-managing-multiple-aws-accounts-using-aws-control-tower/

AWS Landing Zone Architecture

It is crucial to launch the AWS-landing-zone-initiation CloudFormation template to deploy the LZ on your AWS account. The initiation template creates an AWS LZ configuration S3 bucket, configuration zip file (manifest file), code pipeline, and step functions. The default LZ implementation deploys an SSO with an AWS SSO directory and allows access management for users and groups to the AWS accounts. Deploying the AWS LZ will also deploy a security baseline to the core accounts and any new accounts created afterward.

AWS Landing Zone solution incorporates an initial security baseline that builds and implements a customized account security baseline for your organization. The initial security baseline includes the following settings:

  • One CloudTrail trail is created in each account and configured to send logs to a centrally managed Amazon Simple Storage Service (Amazon S3) bucket in the log archive account.
  • AWS config rules for monitoring MFA, root account login, security groups, EBS, RDS, S3, etc.
  • Security notification architecture
  • GaurdDuty findings

A picture containing timeline
Description automatically generated

Source: https://aws.amazon.com/solutions/implementations/aws-landing-zone/

AWS multi-account architecture for LZ

AWS Landing Zone is an orchestration framework. It provides your foundational AWS environment a baseline to get started with data security, governance, multi-account architecture, identity and access management, logging, and network design. It saves time by automating an environmental setup for secure and scalable workloads while implementing an initial security baseline by creating core accounts and resources. It provides users with add-ons like active directory integration or ELK stack for monitoring the logs.

Account architecture:

The LZ is launched in the AWS organization account, which is the only payer account. Best practice suggests not deploying workloads and is only used for creating new accounts, security control policies, and organization-wide tagging policies. Organization Unit (OU) is a logical group of accounts. LZ automatically creates one core OU, which contains three accounts for specific purposes. The three accounts are:

  • Shared services account: This account hosts resources used by multiple accounts like AWS-managed active directory or Git solutions.
  • Security account: This is the master guard duty account for the organization. It provides cross-account auditor(read-only) and admin (full access) roles into each member's accounts.
  • Log archive account: Each account contains config rules to send a copy of all AWS CloudTrail and AWS config log files to a centralized S3 bucket. These logs can be used for compliance or investigations related to account activity or can be pushed to an observability system for visualization.

Application OU can be created by the users as per requirement and usually group accounts pertaining to one use case.

Automatic Vending Machine

Automatic Vending Machine (AVM) is an automated process that uses Service Catalog, CloudFormation, AWS Organization, and Lambda to create a new account in AWS Organization with standard baselines and guardrails. The security baseline is deployed through AWS CloudFormation Stack sets for every new account created by the AVM. AWS Landing Zone leverages AWS Service Catalog to grant administrators permissions to create and manage AWS Landing Zone products. The AVM is updated through the code pipeline, which is created through the initiation template. By updating the manifest file in the S3 bucket, you can trigger the pipeline which deploys the respective changes for the AVM. The AVM uses AWS organization APIs with lambdas to create new accounts and add them to the organization.

Graphical user interface
Description automatically generated with medium confidence

Source: https://aws.amazon.com/solutions/implementations/aws-landing-zone/#

In the end, you might settle with the question, which one should you use? So, the answer is, it depends. The AWS Control Tower and AWS Landing Zone help organizations set up and manage secure multi-account AWS environments. If you are new to AWS and willing to start from scratch, it is better to use AWS Control Tower. Moreover, if you need a configurable Landing Zone with customization options and control, go ahead with the AWS Landing Zone. We hope this was helpful, Happy Coding!


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.