As we approach the new year the role of cloud computing continues to grow. Nearly every organization runs one or more workloads in the cloud. Sometimes the road to this milestone was a bit bumpy. Several aspects helped those organizations to navigate their journey. Often these companies developed a so-called Cloud landing zone as the foundation for their cloud activities. In this article, we’ll explore what a cloud landing zone is and why you need one in large organizations. Cloud landing zones help your DevOps teams boost their success.
Setting the scene
Prior to the in-depth topics we will explore a bit later, it’s important to understand what a landing zone actually is. Based on the three major cloud providers, these are the definitions of them:
- Azure: An Azure landing zone is an environment that follows key design principles across eight design areas.
- AWS: A landing zone is a well-architected, multi-account AWS environment that is scalable and secure.
- Google Cloud: Landing zones help your enterprise deploy, use, and scale Google Cloud services more securely.
These definitions share some aspects in common: environment, the right design principles, scalability & security. Teams need to deploy their applications onto a well-established and carefully designed landing zone to make things easier for them. Every type of application is supported and the landing zone helps to grow the number of initiatives of the organization.
Platform versus application landing zones
Many cloud providers differentiate platform- as well as application landing zones. Platform landing zones contain shared services that are offered to application teams which let their applications consume them. One of the main reasons for this segregation is operational efficiency. Platform landing zones are set up and maintained by one or more central teams (sometimes dedicated to a set of services) whereas application landing zones can be managed using different approaches. A central team which manage them, an application team can manage them, or a combination of both. It’s up to you to decide what works best.
What if not
Before making any investments, it’s crucial to understand what can go wrong if you do not create a solid landing zone for your teams.
- Cloud consumers require different accounts for DEV, TEST, ACCEPTANCE as well as PRODUCTION environments. Without having these in place, all resources will be mixed up. Compliance issues will popup very quick. Avoid this at all costs.
- Controls are limited: a production environment requires stricture security policies compared to a DEV environment in which teams can experiment more freely.
- Not having a landing zone in place will lead to deployment chaos: resources are not tagged and thus can’t be tracked, monitored, and audited properly. Cloud bills can’t be directed to the right users and this also provides challenges in terms of ownership, etc.
As you can see, landing zones are a necessity for every self-respecting company.
Key components
Every landing zone consists of several key components that need to be in place before any team can deploy their applications on top of it. Often, these key components are managed centrally and from an organizational point of view, it’s impractical to let all teams handle them individually.
Accounts
It all starts with the accounts (also called tenants) level. If your organization requires strong isolation of workloads, data auditing activities, or administrative isolation of workloads you need multiple accounts. This is also the case for security. Separation of accounts helps to keep workloads secure, especially to keep the blast radius small in case of a security breach.
In Azure, you can create multiple tenants, per team or application. AWS lets you configure a complete organizational hierarchy whereas Google Cloud provides organization resources.
Payment
You also need to configure a billing account (remember: pay as you go or another method) which gets billed every month. In large organizations, the invoice can be dispatched to sub-accounts that represent a team or workload. This way, DevOps teams are accountable for what they create. It’s highly undesired if all teams attach their credit card to their subscription so this should be handled centrally.
Resource groups
In Azure, for example, it’s possible to fetch the monthly cloud bills based on what has been deployed in a so-called resource group. It’s like a container in which teams provision their resources. Don’t be fooled: sometimes Azure creates a “managed resource group” based on the service you create. For example, in AKS. This managed resource group needs to be linked to your team as well. If every team deploys its applications to a single resource group and tags it accordingly, it’s pretty easy to track all costs per team.
Network
Your cloud efforts are useless if you don’t have a solid network design in place before your first workloads are deployed. Your network acts as the backbone of anything that happens next. This is true for any cloud strategy you choose: pure public cloud services from a single cloud provider, hybrid-cloud setups in which the network connects your on-prem data center to public cloud resources as well as multi-cloud that might even require cloud to cloud connectivity.
Domain names and DNS
Every team that offers internal or external services should enable their service(s) through a domain name. Internal services require a (sub)domain to be part of the domain structure of the company. This also requires proper DNS management. Having a central approach to acquiring these is vital to speed up and keep things under control. You don’t want domain names to be taken by multiple teams which then need to compete with each other to claim ownership.
DNS management should be handled by the landing zone team that also ensures aspects like routing, MX services as well and redirects are handled properly. These aspects need to be automated for developer teams or offered in a self-service way to ease the pain for them. For sure, these need to be in place before the first workloads land on the landing zone.
Central or not?
Teams should not design there cloud network on their own since this leads to inefficient, insecure, and difficult-to-control solutions. Suppose you have to maintain a site2site VPN connection for every application, you have a hard time keeping them all in good shape. How would you monitor the connection itself, make sure teams use the best encryption protocols as well, and keep their private keys secure?
Despite the costs, for large organizations, it’s better to have a single, yet dedicated connection such as an Express route, Direct Connect, or Private Service Interconnect. This type of connection also requires a “think firewall” which intercepts all traffic and makes sure there are no ways to bypass it.
Virtual Networks
On a higher level, teams need to have their very own “virtual network” which is dedicated to their workloads. In AWS, teams can have their own VPC (Virtual Private Network) whereas in Azure, they have their own “Virtual Network”. Both are elementary services that consist of multiple resources such as Network Security Groups, Access Control Lists, (Virtual) IP Addresses as well as Routing Tables. Often you don’t want to let team create their Virtual Networks since these require proper security settings that should be equal to all teams. This was already true for network segments in the on-prem data center. In the cloud, this is no different.
Sometimes, this gives problems deploying Commercial Of The Shelve (COTS) applications which create and configure the Virtual Network for you. These types of setups are not always suited to fit an enterprise approach. Customizing the deployment setup or having these software packages to be deployed in an existing Virtual Network is not always easy or possible at all. So this is a very important aspect to take into account when selecting tools for your enterprise.
Isolated identities
Teams should be separated based on accounts, networks, and other aspects. Think of having your identities separated as well. Individual developers require the same type of identities to develop their applications to suit their needs. However, their applications require identities bound to their workloads. Specific components that together form the intended workload also require identities that have only the permissions needed to carry out their tasks.
Landing zones should contain a single identity management solution such as Azure Active Directory or the IAM-related services of AWS that serve all teams. A federated authentication provider helps to offload this service to a third party (service). You don’t want every team to implement their own private solutions which results in uncontrollable shadow IT. It’s a great advantage that many cloud providers only offer a single central service to handle identities.
Governance and compliance
From a governance and compliance perspective, a landing zone is also more convenient compared to individual setups. Security policies that act as guardrails are implemented for multiple teams at once. Perhaps segregated by the classification of workloads or other arguments. Having the right tags and auditing policies in place helps to ease the burden of conducting (internal) audits of workloads. This is true for application components as well as infrastructure resources.
From a governance perspective, the landing zone provides clear segregation of who owns which resource and thus also who uses it (or not). Therefore, it also helps to control the carbon footprint (don’t let Virtual Machines run while not needed).
Last but not least, separate environments help to set limits in terms of which resources are allowed to be used by teams and which are not. For example, set up a sandbox environment in which teams can only use certain types of resources that are relatively cheap to use. Hook up the limits with actual budget controls to keep your Cloud bills under control.
Wrap up
Landing zones help to streamline how developer teams can utilize the public cloud. They offer benefits in terms of controlled access, clear governance, compliance, and security. Account management, networking setup as well as central user management, and payment-related configuration need to be part of the landing zone. Most cloud providers differentiate between a “platform landing zone” and an “application landing zone”. Although setting up a landing zone takes time, the pros greatly outweigh the cons. I hope this article gives a good summary of which aspects to take into account when designing and operating a landing zone.
