That’s why you need a Landing Zone (even if you don’t know it yet!)

Welcome to our 3-article-series dedicated to the Landing Zone principle on AWS. In these blog posts, you'll understand why you should consider it before starting any project.

Today, we'll go through the definition, the basic concepts, and the guidelines and best practices to implement it the perfect way in your AWS Cloud environment. Let's start!

Interest in the Cloud is growing exponentially. On the one hand, the number of Cloud-native startups is growing exponentially. On the other hand, more and more traditional companies are also approaching this technology with modernization in mind. No matter the Cloud adoption maturity level, the company size, or the industry, it is essential for any organization to fully understand how to move in a world that is revolutionizing the typical on-premise infrastructure practices.

When approaching a Cloud Adoption path, any company - from tech startups starting from scratch in the Cloud to big enterprises that want to move their existing workloads or extend their data centers through a hybrid solution - needs as a first thing to define well-structured governance rules over all the aspects of the AWS environments. Anyway, due to time-to-market needs, new workload necessities, or imminent depletion of on-premise resources, it is common between companies to jump into the Cloud in a rush while postponing the setup of these areas.

But there is nothing more permanent than things born as “temporary”: that’s why it is good practice to adopt a consistent approach before starting any project on the Cloud in order to avoid the need to batten down the hatches.

The on-demand and agile nature of the Cloud allows DevOps to experiment fast and fail at an extremely low cost, but in order to achieve this safely, it is necessary to ensure the perfect balance between governance aspects and flexibility typical of Cloud environments to allow developers to experiment freely according to the Fail-Fast principle. 

What is a Landing Zone

Before setting up any server or public APIs on the Cloud, you should consider foundational aspects, including governance, compliance, cost-sharing, access management, networking configurations, and disaster recovery. Basically, this is the idea on which the Landing Zone concept is based. 

A Landing Zone is a common set of rules, best practices, configurations, objects, and appliances that define the configuration of the AWS environment within which corporate workloads can run consistently and well-governed.

The Landing Zone pillars are:

• Cloud access management and Cloud environments isolation;
• Costs control and sharing;
• On-prem to Cloud setup (hybrid Cloud solutions);
• Agile On-demand objects creation according to company’s compliance principles.

The Landing Zone is the main requirement on which the AWS Well-Architected Framework is based, and it must not be exempt from respecting it.

Implementing a Landing Zone, the right way

There are two different ways to implement a Landing Zone.

The first one is based on the use of AWS Control Tower, a fully managed AWS service that offers ready-to-use blueprints for the automatic deployment of a basic Landing Zone. AWS Control Tower allows you to automate aspects like accounts setup, security policies, and access rules creation based on best practices.

Deploying a Landing Zone using AWS Control Tower is a good way to start setting up your Cloud environments correctly. Anyway, this is a one-size-fits-all approach that brings many limits.

The second approach is based on a 100% custom design of the LZ structure working side by side with an AWS partner with deep expertise in designing, implementing, and managing advanced AWS Infrastructures and services.

As the Conway law (Melvin Conway), states: 

“Any organization that designs a system (...) will produce a design whose structure is a copy of the organization's communication structure”

Similarly, we can say that the more the Landing Zone reflects a company's internal structure and communication system, the better it will work, as it will be able to perfectly adapt to the dynamic nature of both the AWS ecosystem and the company's evolution. 

According to this approach, it is crucial to understand, for example, how many and which IT teams a company owns, the workloads and complexity, and the business perspectives and procedures. This knowledge will be the base on which a correct Cloud practice can be built.

Companies with small IT teams will probably need a Landing Zone that doesn’t add additional overhead while maintaining centralized control. Product-oriented tech startups handling modern and complex workloads, instead, will probably need a more structured control over access while keeping agility high. Companies stratified by many cores that want to consolidate and modernize themselves must have a solid and modular starting structure. 

In short, we can start from a basic model, but each scenario needs to translate its peculiarities.

This will be the starting point for our next articles in which we'll dive deep into each Landing Zone principle. We'll share our experience in building and deploying a successful Landing Zone for any kind of Cloud environment on AWS. Finally, we'll conclude our series by presenting you two examples of Landing Zone implementations in 2 different company structures (startup and enterprise). 

To conclude

In this article, we introduced the Landing Zone basic concepts by presenting its definition and introducing the two ways you can follow to implement it correctly.

Do your Cloud environments rely on a Landing Zone? In which other way do you keep control over your multi-account AWS environments? Give us your point of view! 

Read part two!

Resources:

• Landing Zone on AWS