When you want to get to creating, debugging, and deploying, it helps to start on the right foot. Landing zones help teams hit the ground running, collaborate, stay compliant, and keep operations under control as projects grow. They're a true mainstay of multi-account and multi-project architectures.
Why are landing zones so helpful—no matter whether you're running workloads in Google Cloud, AWS, or Azure? How can you implement one of your own in Google Cloud using Terraform?
Mineiros CEO Sören Martius answered these questions and more in this webinar. He had many insights to share based on his experience working with dozens of advanced cloud setups per week — no mean feat. Here's a recap of what he had to say and some links to more resources.
Getting to know landing zones
Sören started with the basics: What is a landing zone? As he puts it, they're blueprints for cloud environments, yet they defy one-size-fits-all definitions.
Landing zones pop up time and again in many different hyperscaler variants, like Microsoft Azure, Amazon AWS, and Google Cloud. Their popularity — and tough-to-pin-down nature — are somewhat related: The same flexibility that makes landing zones effective as customizable project launch pads means there's no universal rule.
Despite this, considering the topic from a component/design perspective can help flesh things out. Sören points out that while the composition of most landing zones reflects factors like an organization's maturity and needs, there are some common threads worth examining.
What should landing zones achieve?
One of your big goals should be to drive your cloud adoption strategy in the most productive direction: As you grow, you want to set the tone for how teams will work together and uphold your preferred security controls.
Defining the purpose in this organic way leads to a workable core value proposition: Abstracting away complexity and giving engineering and development teams everything they need to get started quickly and securely — without straying too far from the self-service ideal.
Creating a landing zone is an intentional act of describing an opinionated, reusable pattern. In the process, you ensure security and reliability by default: Proven patterns promote infrastructure best practices and leave teams to concentrate on delivering services and applications — the activities that produce more business value.
The benefits: why teams love landing zones
There are many reasons to use landing zones. Sören stressed these as some of the most advantageous:
- You can speed up delivery and make self-service safer: Landing zones let teams self-service as they provision new projects, environments, and infrastructure for workloads.
- Workflows become more reliable: Landing zones shorten the entire software delivery lifecycle while simultaneously elevating quality.
- Teams can dive into work knowing the security and compliance aspects are taken care of: Creating landing zones lets you build a dependable foundation that streamlines requirements management. For instance, you might use custom landing zones to preconfigure certain settings if you wanted your teams to self-service create accounts for an AWS or Google Cloud project.
- You can enforce safe, appropriate least-privileged service access: With landing zones, you can leverage infrastructure-as-code to implement Identity and Access Management (IAM). It's a handy alternative to common practices like overusing Basic Roles in Google cloud or relying on permissions and long-living credentials.
- You can master cost management — and reduction: Common financial use cases for landing zones might include setting budgets for specific departments in a Google Cloud organization or setting up alerts that notify key stakeholders when you reach thresholds.
- Landing zones centralize network design and oversight: Your teams may be highly skilled, but that doesn't mean you should just dump ownership of network management on their shoulders. Landing Zones relieve them of some responsibility by letting you use tools like Google Cloud's shared VPC to set standards using a centralized project that serves as the inspiration for others. Even better, assigning this work to a dedicated team makes it easier to stay agile.
The typical landing zone lifecycle
This all sounds nice, but let's not forget, good landing zones don't come predefined — you've got to tailor them to your needs. So how long will it take?
Developing a landing zone follows the same lifecycle as developing a product, and Sören says most landing zone teams work like product teams. In general, you can expect a team of 3 to 5 people to take anywhere from 3 to 6 months to develop a minimum viable product.
Why can't you reap the rewards right away? Landing zones' comprehensive nature is a double-edged sword: Most organizations have to do a lot of work to align with governance requirements. Landing zones are also iterative and meant to keep evolving in step with your growth.
Technologies and components: landing zone design
The next things to ask yourself are what you'll build your landing zone with — the specific technologies — and what you'll include in it — the cloud services and developer-focused features.
For this example, Sören chose to focus on Google Cloud, citing its up to 60 percent faster build speeds. While AWS offers more services, Google Cloud can still cross the most common ones off your wishlist, such as containers and Kubernetes support. Based on his experience, building on Google Cloud tends to be the most straightforward.
Most major cloud providers offer recommendations on implementing enterprise-grade landing zones. The problem, Sören said, is that these guides rarely explain the good stuff, like how to get the job done with infrastructure as code, jump scalability hurdles, or enable developer self-service.
Infrastructure-as-Code
Using infrastructure-as-code principles to drive changes with configuration files makes sense for this problem. Since landing zones undergo gradual development lifecycles, you want something that lets you version, reuse, and share resource configurations. It also helps that most IaC frameworks accommodate tracking changes to reduce repetition.
The alternative to IaC — using GUIs to configure settings, also known as "ClickOps" — is a poor second. It's slow, error-prone, bogged down in inefficient trial-and-error processes, and impossible to reuse.
ClickOps is also highly susceptible to operational failures: You can't roll back bad configs or generate super-convenient audit trails. You might even have trouble keeping things running if your "god mode" source of knowledge jumps ship.
IaC helps solve these problems. You can speed things up using automation, reuse and enhance code, maintain more accurate, comprehensive docs, and access full change histories anytime. Not only is it easier to check for errors and roll back what doesn't work, but you can also boost reliability with testing, static code analysis, and reviews.
Picking effective tools: Terraform and Terramate
When it comes to infrastructure automation and workflow composition, Terraform is by far the leading open-source tooling, and its use of versionable declarative configuration files is a huge plus. This setup makes it easy to establish more consistent workflows while you provision and manage infrastructure.
Terraform includes the concept of stacks — infrastructure collections that the Cloud Development Kit for Terraform synthesizes into dedicated configurations. To help you keep up, Sören's team has released an open-source tool called Terramate, which is meant to manage different stacks and minimize data duplication. Definitely take a look at the examples and learning materials in the Terramate repo or on the Mineiros blog.
Getting started with a Google Cloud landing zone built in Terraform
What components should you consider when building a Google Cloud landing zone? In addition to making life as easy as possible for your devs — i.e., enabling teams to review Terraform plans in PRs, providing easily consumable APIs, etc.—Sören recommended focusing your efforts on a few critical areas:
Resource management
This doesn't just mean billing and budgets. Resource management also accounts for your organizational structure, such as how you set up organizations, folders, and projects.
One important tool that Google Cloud users need to be aware of is the project lien, which blocks projects from being deleted sans approval. Project liens also highlight a smart design philosophy: keeping your projects and liens in different stacks to avoid losing everything.
Access management
Choose components that let you create and manage identity groups, use IAM service accounts, and work with external identity providers securely.
Networking
Your network should do its job quietly in the background, and your devs should get the benefits without too much direct intervention. Build your landing zone to set clear firewall rules, enforce logging standards, and harmonize common cloud service configurations.
Observability and post mortem
Your developers shouldn't have to configure audit logging or other observability functions for every project. Use your landing zone to standardize logging practices, implement asset inventorying, and set up helpful tools like the Google Cloud Security Command Center.
Security and compliance
This is where you'll implement security practices worth following, like least privilege access. You'll also want to think about compliance, like how your landing zone will uphold frameworks like SOC2, ISO27001, HIPAA, PCI, or CIS Benchmarks for Google Cloud.
Shared resources
Finally, your landing zone should streamline interactions with shared resources, like Kubernetes clusters or artifact registries. Abstracting these fundamentals away can make for a more consistent developer experience.
Final Thoughts
Sören wrapped up by sharing a demo project that upheld these basic principles: It split the landing zone's components into independent stacks, included liens to protect projects from deletion, and used config files to generate reusable terraform code.
Landing zones are an effective tool for establishing design and engineering patterns your teams can follow with ease. To learn more about how they look in action, check out the complete webinar video.
