A dedicated landing zone optimized for cloud-native workloads enables quick onboarding and efficient operations.

Most organizations embarking on a cloud journey want to leverage the cloud to take advantage of cloud-native services. A cloud-native landing zone allows application teams to do just that, while staying within well-defined guardrails established by the cloud foundation team.

Cloud-native landing zones typically cater to application teams that want to develop workloads designed for the cloud, be it newly developed applications or applications undergoing refactoring to take advantage of the cloud. Such application teams typically possess some level of cloud skills and the cloud foundation team can generally expect to delegate a reasonable degree of responsibilities for deploying and securing their applications to them.

From our experience, cloud proficiency can vary a lot between different application teams inside an organization. This usually becomes very evident once the “first movers” have onboarded to the cloud and the “early majority” of internal workloads starts seriously considering moving to the cloud as well. Cloud foundation teams should thus be careful to calibrate expectations accordingly during Shared Responsibility Model Alignment for the cloud-native landing zone.

Best Practices for Designing and Building a Cloud-Native Landing Zone

Start with a Minimal Set of Guardrails

A cloud-native landing zone enables a lot of freedom - at the expense of delegating a lot of responsibilities to application teams. Cloud foundation teams should thus implement at least the minimal set of guardrails as described below:

• A Resource Hierarchy along with a Tenant Provisioning process defines how the cloud foundation team provides cloud tenants to application teams

• Service and Location Restrictions should define the cloud services and locations that application teams are allowed to use. A minimal implementation for a cloud-native landing zone should whitelist allowed cloud locations, deny access to 3rd party marketplaces but otherwise take a liberal stance on allowed services.

• Resource Configuration Policies should define a small set of policies to restrict “known dangerous” configurations like unencrypted storage at rest or public object storage buckets

• Resource Authorization Management can start with a very basic open landing zone design leveraging built-in policies (e.g. Owner Role on Azure)

• Centralized audit logs are essential to support incident analysis for questions like “who deleted the production database on monday morning”? Audit logs are especially critical to keep around any resources that fall into shared responsibilities.

• Chargeback via consumption cost allocation is an important organizational counterweight to the freedom offered by a cloud-native landing zone. Application teams can deploy what you want as long as they responsibly secure it and pay their bill.

This set of guardrails is the absolute minimum that the cloud foundation team should include in a cloud-native landing zone. There are many solutions, some also officially maintained by cloud providers, that include these capabilities out of the box. You can find some implementations listed at the bottom of this page.

The Cloud Evolves - Your Guardrails Will Too

While all of the capabilities to set guardrails described above are essential to start a solid cloud-native landing zone design, we observe that the most successful cloud foundation teams adopt an iterative approach when it comes to defining the exact “shape” of the guardrail. For example. it’s all too easy to get lost in the myriad of options the foundation teams has to define Resource Configuration Policies object storage buckets. As long as the documented shared responsibility model clearly places responsibility into the lap of application teams, it’s sufficient that the cloud foundation team prevents only the most egregious misconfigurations like. buckets publicly exposed to the internet.

Cloud Foundation teams should thus plan on evolving the shape of their guardrails as cloud adoption in the organization grows. A good Incident Management Process with root cause analysis and retrospectives can provide important insights into policies that the team should enforce (see Resource Configuration Policies) or monitor (see Resource Configuration Scanning) going forward. Cloud foundation teams should thus define the landing zone using infrastructure as code and automate its deployment using suitable tools.

A “Hands off” Landing Zone Is Better Than Shadow IT

Many cloud foundation teams struggle whether they need to include Virtual Network Service and On-Premise Network Connection capabilities into their v1 cloud-native landing zone. From our experience, designing and delivering these services can be a major roadblock for cloud foundation teams that are building their first landing zone and have little prior experience with delivering core infrastructure services.

While your organization’s mileage may vary, we often see cloud foundation teams starting on a slightly brownfield cloud landscape. Many organizations start their cloud journey with “lighthouse” projects building on the cloud long before the inception of the cloud foundation team. When designing a landing zone, it’s thus often tempting for the team to try and deliver a “one-size-fits-all” landing zone that can cover these usually quite sophisticated application teams as well as application teams just starting out.

From our experience it’s worthwhile to offer a minimal “hands off” cloud-native landing zone to these application teams to bring them under management by the cloud foundation, while not interfering with their established workloads and processes. This “hands-off” cloud-native landing zone is also a good migration target for any shadow IT workloads the team discovers on the cloud along the way.

To deliver a “hands off” landing zone, it’s typically sufficient to leverage the landing zone “MVP” implementing the minimal set of guardrails described in the section above. With this approach the cloud foundation team can rapidly deliver a cloud-native landing zone MVP equal to a “hands off” Landing Zone 1.0 and then iterate on a separate path to a cloud-native landing zone 1.0 while already servicing productive workloads.

Related Tools

• Azure LZ Terraform module - ES

  Implements sufficient capabilities to implement a minimal cloud-native landing zone.

  Learn More
• collie-cli

  Collie supports developing your own cloud foundations quickly from reusable bundles that offer out-of-the-box IaC implementations of cloud native landing zones.

  Learn More
• GCP CFT - Example Foundation

  Implements sufficient capabilities to implement a minimal cloud-native landing zone.

  Learn More

Did this page help you?