A Landing Zone is the concept of a pre-defined multi-account environment that allows you to securely onboard application workloads onto the cloud in an automated way. A good multi-account foundation reduces the cognitive load of different teams and allows the developers to move faster. It either blocks any misconfigurations by default or recovers from an issue without much effort. These foundations typically unlock two main use cases – migrating workloads from on -premises environments or net new development in the cloud. Therefore, the main goals here are as follows:
- Secure and compliant
- Scalable and resilient
- Flexible to future change
A good KPI to measure a Landing Zone’s maturity is – how long it takes to create a new AWS account and make it ready for hosting production workloads. There’s a lot that goes on in between, starting with account requests, approvals, provisioning, and actual usage, highlighting various challenges ranging from humans to technology and automation.
The term Landing Zone is often used, or misused, in different contexts, which can be confusing for users. Let’s go through four common patterns I’ve observed over the last few years:
- Landing Zone as a concept: This is the idea of a multi-account cloud foundation, as well as the tangible outcome that gets deployed in your AWS environment. It helps the organizations reap benefits from the cost segregation, security and access management, and reduced blast radius offered by AWS account boundaries. It promotes the idea of managing all infrastructure automation with code that is repeatable, easy to test, and automate. Throughout the chapter, we will be using the term landing zone for both the concept and the tangible foundational structure that represents this concept.
- Landing Zone as a solution: A solution is a pre-baked, ready-to-deploy implementation that fulfillsa particular need – in this case, a multi-account architecture – by leveraging a variety of AWS services. A few years back, AWS offered a publicly available gigantic CloudFormation template known as AWS Landing Zone (ALZ) that could be used by customers to deploy multiple services, accounts, and policies into their AWS organization. It gave them a solid enterprise-grade foundation to begin their AWS journey. It is no longer supported and deprecated in favor of a managed service called AWS Control Tower, which we will cover in more detail later in this chapter. Some examples of other solutions that are offered by AWS are Customizationsfor Control Tower (CfCT) and Account Factory for Terraform (AFT).
- Landing Zone as an AWS service: Solutions such as ALZ required a lot of customization to adapt to the unique needs of an organization. As it was completely managed with a CloudFormation template, it was not easy to maintain and operate, not to forget the missing AWS support that you would generally get with AWS services. To fill these gaps, and reduce the complexities involved with the use of ALZ, AWS launched a service – AWS Control Tower – that was based on the field experiences gathered from multiple enterprise customers and how they used the ALZ solution to architect a solid foundation that applications could be hosted on. Control Tower offers automation to create new accounts, baseline them with basic security resources, enforce governance controls, and much more. A lot of times, when using the term Landing Zone, the users tend to refer to services such as Control Tower instead. Landing Zone is a broader concept that the service implements (to some extent).
- Landing Zone as a reference to deployment orchestration frameworks: At its core, Landing Zone is a multi-account concept. Applying this concept to your AWS Organizations organization in practice requires deploying resources in multiple AWS accounts. Some organizations end up developing home-grown solutions using CloudFormation, CDK, or Terraform. Some orchestration frameworks are available as open source code on GitHub. Users might start referring to these as Landing Zones, but they are nothing more than deployment frameworks that can be leveraged to roll out resources in multiple accounts. They have their relevance, even when not used in the context of a Landing Zone.
Two commonly used open source frameworks are AWS Deployment Framework (ADF) and Service Catalog Tools.
Figure 11.1 highlights all the different entities and their relationship with the Landing Zone concept:
Figure 11.1 – Relationship between different entities and the Landing Zone concept
Note Even though some frameworks such as ADF have “AWS” in their name, they are not officially supported by the cloud provider as part of the enterprise support plans. This can be one of the criteria that companies might want to consider, or at least be aware of. On the other hand, the two solutions – AFT and CfCT – do come with official AWS support, just like other services. These solutions are maintained by the Control Tower service team.
We could dedicate an entire book to the development of a Landing Zone. An important callout is that this is an evolving thing. The ever-changing requirements of the organization will dictate new criteria and goals that have to be met by the Landing Zone design. To achieve this, services, solutions, and deployment frameworks will have to adapt. How you use these services and solutions is going to be largely driven by the unique needs and implementations within your organization. This is a reason why you will never come across an end-to-end implementation that can be adopted as-is. The services and solutions will always focus on the lowest common denominator that applies to the majority of enterprise use cases. Almost always, there is a customization layer that comes on top, to make it a complete solution that addresses your needs.
Therefore, the main priorities of this chapter are to introduce you to the key considerations of a Landing Zone, relevant AWS services, solutions, and frameworks. This will help you identify the areas that you should look into, as well as introduce you to deployment orchestration frameworks, for rolling out resources across multiple AWS accounts and regions. Equipped with this knowledge, you can come up with custom implementations or designs that work for you.