Infrastructure and Application Landing Zones on HCP [HashiConf]

In this blog post I will lay out an opinionated approach to building infrastructure and application landing zones on HCP together with self-managed Nomad and Consul clusters.

In this post you can expect to learn about what I refer to as infrastructure landing zones, application landing zones, how these are realized on HCP, and what the benefits to your organization are if you implement these ideas.

A need to simplify cloud infrastructure management

#

Before I discuss what I mean by infrastructure and application landing zones on HCP I want to describe a problem that I see in the industry. This is a problem of cloud complexity that hinders many organizations from achieving their full potential.

This problem was also highlighted in the 2025 Cloud Complexity Report released by HashiCorp on September 10, 2025¹. This report has many interesting findings, but a striking statistic is that 97% of respondents report they are struggling with cloud infrastructure.

After thinking about this number for a short while I realized that in my own experience it is really 100%. Every organization has challenges with managing cloud infrastructure, but the struggle can manifest itself in many ways.

How do we deal with cloud complexity? One common approach is to implement cloud landing zones in your environment.

Cloud landing zones

#

Cloud service providers have understood that customers need structure, and structure won’t happen by itself.

For this purpose, the cloud service providers have introduced their version of a cloud landing zone. The general idea is the same: help customers achieve a structured cloud environment that can scale along with their cloud service footprint.

Amazon Web Services (AWS) describe landing zones this way²:

A landing zone is a well-architected, multi-account AWS environment that is scalable and secure.

This is a starting point from which your organization can quickly launch and deploy workloads and applications with confidence in your security and infrastructure environment.

Building a landing zone involves technical and business decisions to be made across account structure, networking, security, and access management in accordance with your organization’s growth and business goals for the future.

A landing zone on AWS consists of multiple AWS-accounts. It is a starting point (a base layer) where you go on to deploy your actual applications. It is about laying the foundation for shared pieces like networking, security and access management, and it sets up rules and guardrails (governance) for everything running inside of the landing zone.

Microsoft Azure describe landing zones this way³:

An Azure landing zone is an environment that follows key design principles across eight design areas. These design principles accommodate all application portfolios and enable application migration, modernization, and innovation at scale.

An Azure landing zone uses subscriptions to isolate and scale application resources and platform resources.

Subscriptions for application resources are called application landing zones, and subscriptions for platform resources are called platform landing zones.

The landing zone description from Microsoft differentiates between application landing zones and platform landing zones.

A landing zone is an environment following given design recommendations (the eight design areas are billing/tenant, identity, resource organization, networking, security, management, governance, automation/DevOps).

On Azure you have many landing zones (platform and application), together making up your full cloud environment on Azure. This is closer to what I will describe as infrastructure and application landing zones later in this blog post.

Finally, Google Cloud Platform describe landing zones this way⁴:

Landing zones help your enterprise deploy, use, and scale Google Cloud services more securely. Landing zones are dynamic and grow as your enterprise adopts more cloud-based workloads over time. […]

A landing zone spans multiple areas and includes different elements, such as identities, resource management, security, and networking.

This description is closer to what we saw from AWS yet they discuss landing zones in plural.

These three landing zone descriptions have many similarities. However, the following is clear:

• The actual implementation of landing zones on each platform is different since these are fundamentally different platforms. For instance, networking concepts are similar across AWS and Azure but even something as simple as subnets work completely different on these two platforms.
• Landing zones are primarily constructs in the domain of your platform engineers. They contain the high-level design of your cloud environment, like the virtual network and identity management. They put up governance and guardrails for your developers, but does little to help them provision application infrastructure.

Remember that we most likely also have an on-premises environment (or some form of private cloud) to account for, further complicating the picture.

In conclusion: cloud landing zones brings structure for your platform engineers but does almost nothing for your developers.

Even if your organization use a single cloud provider and implement cloud landing zones according to all the rules there is another big issue you have to face: a proliferation of cloud services.

A proliferation of cloud services

#

As a cloud engineer or developer facing the cloud⁵ you are struck by a proliferation of available cloud services. Do you want to build and host a website for your organization? Great! Select one of the hundreds⁶ of options available to you.

Many applications deployed to the cloud follow a simple pattern: a frontend⁷, a backend, and a data storage solution (e.g. a database).

This description likely accounts for the majority of what runs in the cloud today. This is definitely true for most of the customers I have worked for as a consultant.

Another takeaway from my experience as a consultant is that organizations are moving to a hybrid and multi-cloud reality. Some are already there, and have been for a while. Going all in on a single cloud provider (or a single private cloud environment) is no longer a viable idea (if it ever was).

Yet, the number of developers who don’t care about cloud infrastructure far outnumbers the number of platform engineers⁸. These are the developers who want to write source code, not configure cloud infrastructure.

There is an obvious discrepancy here between what is needed (a simple application architecture), what is offered (hundreds or thousands of cloud services), and what is desired from the developer perspective (writing code).

What a solution can look like

#

To summarize, the problem we want to solve has two components:

1. Cloud complexity at the organization level, and
2. Cloud complexity at the developer level.

The solution to this problem is not to apply less control and to give developers more freedom.

The solution is to use a unified approach to cloud infrastructure management. This involves standardizing on the set of tools that are used across your full environment, and to provide infrastructure abstractions for your developers.

A generic solution to a unified approach to cloud infrastructure management involves a number of components:

• Infrastructure management: you need a way to manage the lifecycle of your infrastructure through automation across your full environment.
• Secrets management: your applications and systems require secrets. Secrets can be key/value pairs, API-keys, TLS certificates, temporary database credentials, and more. You must be able to manage secrets across all environments in a unified way.
• Network connectivity: your applications seldom live in complete isolation. There is a need to connect services and users together, and to connect different environments together (on-premises datacenters and cloud environments).
• Image management: you need to understand and document your application dependencies and have a base layer of images that your applications are ultimately built upon.
• Compute orchestration: your applications will ultimately run somewhere, and no matter where they run the experience should be the same. From the perspective of the application it should not make any difference if it is hosted on-premises or in the cloud.
• Source code management: all of the components discussed above should be managed as code. This is the ultimate unification of your full cloud infrastructure environment. All changes are performed through code, giving you a built-in audit trail.

We can arrange and combine these components to form what I call infrastructure landing zones and application landing zones.

Infrastructure landing zones

#

Infrastructure landing zones provide developers with components for provisioning cloud infrastructure, build application images, manage application and platform secrets, securely connect services and applications together and to access these services themselves.

The infrastructure landing zone is a collection of raw building blocks that provide the necessary capabilities to build robust cloud infrastructures. Developers working within an infrastructure landing zone interacts with all of these components as needed through source code (infrastructure as code).

The cloud landing zones we discussed above would ultimately be built on top of an infrastructure landing zone.

Application landing zones

#

Application landing zones provide developers with the same underlying components as in the infrastructure landing zones, with the addition of a compute platform where applications run. The big difference is that all of these components are abstracted away from the developer. The developer interacts solely with what they know best: a git repository for application source code.

A spectrum of landing zone abstractions

#

Infrastructure and application landing zones make up the two extremes on a spectrum of possible landing zone implementations.

At the lower end of the spectrum you have developers who enjoy most of the challenges faced by platform engineers. They write software, but they are equally happy to set up networking and to configure the compute platforms where their software will run. These developers do not benefit from a deeper abstraction. This end of the spectrum represents the infrastructure landing zone.

At the upper end of the spectrum you have developers who want to write the JavaScript code to make your corporate website a success, optimize SQL-queries for your online bread shop, and reimplement all of your backends in Rust to finally get rid of all memory-leaks. These developers care about the code, but could not care less about where this code runs. These developers benefit from a deeper abstraction. This end of the spectrum represents the application landing zone.

In between these two extremes there could be additional levels of abstraction. We will not consider exactly what these could look like in this blog post, we will focus on the extremes.

Both types of landing zones are designed and built by cloud architects, platform engineers, and security engineers. Governance and guardrails are implemented and enforced just like for cloud landing zones.

An optional, but beneficial component for both types of landing zones (not visible in the illustrations below) is developer self-service. Developers should be able to order a landing zone of their choice and have it provisioned within minutes. This removes friction that is commonly encountered in ticket-based environments.

Infrastructure and application landing zones on your favorite cloud service provider

#

The infrastructure and application landing zones discussed above can be realized on any of the major cloud providers using native services from each provider.

For instance, on Microsoft Azure you can:

• Use Azure Bicep for infrastructure as code and provisioning cloud infrastructure.
• Use Azure networking services for connectivity (service-to-service and human-to-machine access).
• Use Azure Key Vault for secrets management.
• Use Azure Kubernetes Service for compute orchestration.
• Use Azure VM image builder for VM images and Azure Container Registry for Docker images.

Likewise, on AWS you can:

• Use AWS CloudFormation (or CDK) for infrastructure as code and provisioning cloud infrastructure.
• Use AWS networking services for connectivity (service-to-service and human-to-machine access).
• Use AWS Secrets Manager for secrets management.
• Use AWS Elastic Kubernetes Service for compute orchestration.
• Use AWS EC2 image builder for VM images and AWS Elastic Container Registry for Docker images.

However, this is a bad idea if your organization use more than a single cloud service provider.

From a platform engineering perspective you have to maintain multiple different sets of landing zones (both infrastructure and application). Each cloud service provider means one set of landing zones to build. This is in addition to the cloud landing zones you should design and build to begin with.

From a developer perspective each set of landing zones will support different features and require different tools to work with.

Infrastructure and application landing zones on HCP

#

A key strength of using the HashiCorp portfolio of services to build infrastructure and application landing zones is that it can look the same no matter what cloud provider you are targeting. Even if you target multiple cloud providers and your own private cloud environment, the design remains the same.

In the following sections we go through the layers of the landing zones expressed in the context of HashiCorp services.

Self-service with Waypoint

#

The common entrypoint for all types of landing zones is HCP Waypoint. Self-service is an optional component for landing zones, but a requirement if you want to offer frictionless experience for developers.

HCP Waypoint is a layer on top of Terraform no-code modules. You can build multiple different variants of landing zones, each based on a Terraform module containing one or more of the components discussed above.

A developer requesting a new landing zone signs in to HCP and visits Waypoint, selects the desired landing zone templates and creates an instance (an application) from the template. Minutes later the landing zone is provisioned and ready to be used.

Infrastructure with Terraform and Packer

#

Terraform makes up the bottom layer of each type of landing zone. In fact, Terraform manages close to everything that the landing zone consists of. This makes Terraform the single most important pieces of all landing zones.

The only exception is image standardization and management which is handled by Packer. Packer plays an important role in providing standardized base images for different types of compute platforms (VMs, containers, etc). These base images comes with necessary components preinstalled, e.g. Consul client agents and Vault agents.

HCP Terraform is the entrypoint for managing each landing zone. Each landing zone maps to one workspace on HCP Terraform. Each workspace is configured with credentials to work with all other components of the landing zone (e.g. Vault, Consul, etc) as well as any remote platforms (e.g. Azure, AWS, etc). There is no need for developers to set up these connections, everything comes as part of the landing zone.

Developers working in an infrastructure landing zone will spend time on HCP Terraform, while this is fully automated and abstracted away for developers working in the application landing zone.

Network connectivity with Consul and Boundary

#

Consul (self-hosted Consul Enterprise) is used as the service-to-service connectivity layer across all of your cloud environment and beyond. Consul works the same across any cloud provider and on-premises infrastructure, including native functionality for certain cloud services (e.g. AWS Lambda).

By default, each landing zone (infrastructure and application) is assigned its own Consul namespace. We assume there is no cross-namespace communication required in most cases, but if required this is managed through infrastructure as code with Terraform as any other change.

Boundary (HCP Boundary and self-hosted Boundary workers) is used for privileged human-to-machine access management where required. By default this is an exception, and no access to production resources is configured out of the box. Each landing zone is set up with a project on HCP Boundary and Boundary workers are provisioned automatically to relevant network partitions (e.g. cloud providers or on-premises). This allows access for any resource should the need arise.

Secrets management with Vault

#

Vault (HCP Vault Dedicated) is the secrets management component for platform and application secrets. Each landing zone is provided with a Vault namespace, possibly with standard auth methods and secret engines pre-configured. The HCP Terraform workspace for each landing zone is configured with OIDC connection allowing full administration of the Vault namespace.

Some secrets management components are centralized in a platform namespace, e.g. common auth methods, common PKI solutions, etc.

Compute orchestration with Nomad

#

Nomad (self-hosted Nomad Enterprise) is the compute platform for anything provisioned to an application landing zone. Nomad is not part of the infrastructure landing zone by default, but is available if required.

Nomad runs on virtual machine environments where required. It works the same across all cloud service providers and on-premises environments. From the end-user perspective it does not matter where the Nomad clients are located, the functionality is the same.

Source code management

#

HCP does not offer a specific service for source code management but integrates with the most popular services (e.g. GitHub, GitLab, Bitbucket, Azure DevOps).

Since everything in the landing zone should be managed through infrastructure as code with Terraform it is important that each landing zone comes with git repositories that works as the main entrypoint for all developers.

For application landing zones the infrastructure repository should not be managed except for rare situations. Instead, git repositories with application source code should be the main entrypoint. This repository comes with an hello-world type application as a template, and with CI/CD components that handle building and publishing new application versions.

Metadata for each new application version is published to the HCP Packer registry, and the Terraform configuration for the underlying application landing zone uses the HCP Packer registry data source to read the latest available version image.

Benefits of an opinionated approach to landing zone design

#

HCP together with HCP Terraform⁹ has all the necessary pieces to build infrastructure and application landing zones that work and behave the same across cloud service providers and on-premises environments.

Some of the benefits that this approach on HCP and HCP Terraform brings are:

• Managing everything as code with Terraform means all changes go through the same workflow. Implement the change in code, submit a pull-request and request a review or use a pair/mob programming approach, and merge the change into the main branch. Your full cloud environment is documented as code and you have a full history of all changes. Terraform has providers for Vault, Consul, Boundary, Nomad, HCP Terraform, HCP, as well as your cloud service providers and more. This allows you to truly manage everything as code.
• HCP Terraform orchestrates all changes to your infrastructure. Each landing zone is provisioned with an accompanying HCP Terraform workspace connected to an infrastructure Git repository. All changes pushed to this repository triggers a run in the HCP Terraform workspace. The workspace is configured with credentials and connections to all target systems, including Vault, Consul, Nomad, Boundary, cloud providers (AWS/Azure/GCP), and more. Once a team gets their workspace they can immediately start provisioning infrastructure in all these target systems.
• HCP Packer stores metadata for all images in your environment. These images include container images, virtual machine images, and more. Centralizing this metadata allows you to get a unified view of all your dependencies. Even the underlying platform (your Consul servers, Nomad servers and clients, etc) are sourced from this HCP Packer registry. Each application landing zone comes with its own HCP Packer bucket where metadata for that application is stored. Packer itself is used in building images, providing a unified experience for all target platforms (Linux, containers, and more) using the same language as Terraform.
• Abstracting the network layer using Consul and Boundary streamlines how cloud resources on AWS/Azure/GCP are configured. You can easily standardize what network ports should be open between different network segments (e.g. 8601) to allow services in the Consul service mesh to communicate with each other no matter where they are. You allow and deny traffic using intentions in Consul managed through Terraform.
• Vault provides a unified interface for secrets management. This allows you to manage secrets in the same way no matter where they are intended to be used. Vault also integrates with cloud provider secrets management systems in case this is a requirement for a service or application.
• Boundary abstracts how resources are accessed by a human. You can lock down network access to sensitive targets, but still reach them securely through Boundary. Boundary also integrates with Vault to abstract secrets management, allowing a frictionless experience in connecting to targets. This is an important part of application landing zones where you do not want a leaky abstraction forcing developers to interact with multiple underlying systems in order to connect to a given resource.
• Nomad orchestrates workloads across your Nomad cluster. This cluster can span across on-premises and cloud environments, unifying how applications run in all environments. Nomad integrates with Consul and Vault to connect services together and securely provide secrets to applications. Your platform should include Nomad clusters running in all of your environments, either standalone or consolidated as one cluster. The applications running in your application landing zones run in a managed namespace of Nomad, giving your platform engineers an overview of all applications. You should make Nomad accessible for infrastructure landing zones as well, through Waypoint add-ons.
• Waypoint allows you to build self-service for your developers, greatly improving the speed at which teams can get started managing cloud infrastructure and deploy applications. The most important part of Waypoint is the templates that are a layer on top of HCP Terraform no-code modules. However, you can also extend the applications through add-ons and actions. For application landing zones, Waypoint is the only other system that the developers interact with apart form their Git repository.

While all landing zone types comes with the above benefits, the extra benefits of application landing zones are:

• Faster time to market: developers who are uncomfortable with platform engineering tasks (e.g. cloud infrastructure) can select a path that does not involve these tasks. The developer can provision an application landing zone and work only on the application code. This reduces the time to market drastically.
• Reduced risk and built-in compliance: application landing zones are based on templates that are built with security and compliance from the start. These landing zones require fewer moving pieces, severely reducing associated risks. Giving developers complete freedom comes at a price and drastically increases your cloud footprint and attack surface. Through opinionated infrastructure and application landing zones you can avoid this situation.
• Improved scalability: self-service provisioning of landing zones means any developer can provision landing zones and get started developing applications easily. No queues, no waiting times.

Conclusions

#

Have we solved cloud complexity now?

Infrastructure and application landing zones on HCP provide a unified approach to cloud infrastructure management across cloud providers and on-premises.

For the organization, a unified approach to cloud infrastructure leads to reduce tool sprawl and system fragmentation. Less tools mean simplified management and stronger security. Providing a standardized set of landing zones means your platform engineering footprint is smaller and more manageable.

For the individual developer, cloud infrastructure abstractions and self-service let developers choose their preferred level of cloud complexity. The cloud complexity is abstracted away through the opinionated approach to application architecture that underlies the application landing zone. If this abstraction feels too restrictive you can design additional landing zone abstractions (remember the landing zone spectrum) tailored for different types of developers. This leads to improved developer experience, reduced cognitive load, and greater autonomy.

This approach works, but cloud complexity can’t be solved by tools alone - there is also the issue of people! That issue is for another day.

Thanks for reading.