Do you really need a landing zone?

If you've ever worked on a cloud computing project, chances are you've heard of a "landing zone."

But what is it, and do you really need one? That's what we are going to explore in this article.

A landing zone… what is that??

A landing zone is a concept you'll hear mostly in the context of cloud computing projects. It's a reference architecture designed to provide a secure, compliant, governed, and controlled environment for your workloads.

This allows you to establish a solid foundation of governance, compliance, security, and control that will benefit all your workloads accelerating innovation while ensuring organizational flexibility.

• Accelerating innovation… but how? Because you don’t have to implement security, governance, or compliance controls within your workloads. These are implemented at the landing zone level. While you may need to implement additional controls on certain workloads, your landing zone will ensure that no compromises have been made around the workload itself if you do nothing.
• Ensuring organizational flexibility… really?! Yes, a landing zone allows an organization to be flexible, resilient and responsive, both for major developments and when integrating new needs or complying with market standards. This flexibility is achieved through modularity (in particular the establishment of environments isolated per team and over which these teams have almost total control); the ability to deploy types of services according to need and independently of the needs of other teams or departments; the automation of deployments; and finally, the centralization of governance to ensure compliance and consistency of the cloud environment.

A landing zone… for what purpose??

A landing zone helps address the following challenges in your cloud adoption:

• Cloud governance: through centralized control of resources, standardization of configurations, application of policies, compliance with regulatory requirements.
• Integrated security: through segmentation, securing communications, identity and access management (RBAC), continuous monitoring, isolation of environments (prod, dev, test).
• Cost optimization: through cost management via clear distribution between business lines, using the appropriate services and right-sizing them, limitation of costly data transfers thanks to optimized network topology.
• Agility: through rapid adaptation to growth, organizational changes, and technological changes.

To achieve this, a set of cloud services must be deployed and configured, such as one or more firewalls, VPNs, a SIEM, domain controllers, a log ingestion and analysis tool, a monitoring solution, an alerting solution, identity and access management tools, network monitoring tools, backup and DR tools, a policy implementation and enforcement solution, etc.

But wait a minute... a landing zone can be expensive!

Yes, a landing zone isn't free. Depending on the adopted topology and setup, it can cost anywhere from a few dozen dollars to several thousand dollars per month!

Is it expensive, though? It's all relative. Let's say your landing zone costs $4,000 per month. But thanks to it, your data and workloads are protected and backed up. In your eyes, is data theft worth saving these $4,000 (with all the bad press and the loss of customer trust and possibly market share)? Whatever your answer is, you have your answer 😉.

So, we can think of landing zone costs like insurance costs: we don't like paying them, but we're glad to have that insurance in case things go wrong😊.

An important thing to keep in mind regarding landing zone costs is that these costs are generally passed on to the consuming lines of business, either as an equal split (i.e., the landing zone costs are divided by the number of business units consuming it) or based on a pro rata usage (although the latter might be more difficult to assess).

Landing zones topologies

In the previous section, you heard me refer to landing zone topologies. But what are they?

A landing zone topology refers to how the cloud architecture and components are organized, segmented, and interconnected to meet business needs. The topology therefore defines the logical structure of the cloud environment, resource segmentation, network flows, access rules, and overall governance.

Each provider offers different topologies (via their Cloud Adoption Framework). These topologies reflect the most common needs for different business sizes and complexities. On the Microsoft side, the best-known are "Hub-and-Spoke" and "Virtual WAN."

As an example, here's what the Hub-and-Spoke topology may look like:

A landing zone, how do we set it up?

As with any cloud workload, there are different ways to set up a landing zone.

It's possible to set it up through click-click in your preferred cloud platform's portal, but this isn't the most recommended method because it's manual, prone to errors and leaves no trace (i.e., it's difficult or impossible to track who did what and in what order).

Cloud providers also provide what they call "accelerators" for setting up a landing zone, either automatically or semi-automatically. These accelerators work very well as long as they align with the topologies offered by these providers (usually via their Cloud Adoption Frameworks). However, customizing these accelerators for specific needs can be complex, particularly because they require a learning curve.

The final option (the one that offers the greatest degree of flexibility and customization) is to develop your code yourself. This is referred to as an "infrastructure as code" approach, in which you script your cloud infrastructure using a technology specifically designed for this purpose. Several technologies exist, and you've probably already heard the name of one of them. These include Terraform, Bicep, Pulumi, Ansible, CloudFormation, ARM Templates, and more.

Finally, note that in a corporate context, the implementation of the landing zone is the responsibility of a dedicated team, generally called the "cloud platform team," which works closely with the CCoE (Cloud Center of Excellence) to define it.

A landing zone is a living organism!

Rest assured, it's neither an alien nor a zombie! 😁

However, a landing zone is a very living organism. We saw earlier that a landing zone can have different topologies. What we didn't mention is that it evolves to adapt to changing business needs. One of the most common examples in the Azure world (but this remains true for other cloud platforms) is evolving the landing zone to adopt AI or AVS (Azure VMWare Solution) services.

Note that it's not just the landing zone topology that may need to evolve. In some cases, this evolution may involve authorizing new services (or restricting those that are no longer used), or implementing new compliance controls, resulting from changes in regulations in your industry. This is why it's recommended to use an “infrastructure as code” approach when implementing a landing zone, as it facilitates its evolution while keeping track of the changes made.

Oh! And one more thing... Just as a landing zone is alive, so is the code used to implement it. Whether you use an accelerator provided by your cloud provider of choice or have developed your own code, remember to periodically (at least once a year) review and update it according to new standards and APIs, if applicable.

I use the cloud for personal needs. Do I still need a landing zone?

In that case, you certainly don't need a full-fledged, complex landing zone.

However, for the sound management of your cloud environment, you still need to implement minimal governance, which consists of having security policies in place, budgets set up, MFA configured and enabled, assigning only the required RBACs, and monitoring to ensure security and control of your cloud environment without the complexity of a corporate landing zone.

Now onto you: do you think a landing zone is useful?