Introduction
Why use HashiCorp validated designs?
HashiCorp Validated Designs (HVD) provide practitioners with opinionated guidance for achieving production-grade deployments of Boundary Enterprise. These designs are purpose-built for delivering foundational Boundary use cases, with a baseline level of architectural and operational maturity. They draw on the field experiences of Solutions Engineers and Solutions Architects working with Boundary customers.
This solution design guide provides customers with access to an opinionated reference architecture, including key design decisions and the rationale behind them. Where applicable, the guide identifies modular design components that customers can adjust to align with organizational and/or regulatory requirements without compromising the overall integrity of the implementation. For customers deploying Boundary to the cloud, the guide also includes Terraform modules to automate large portions of the infrastructure provisioning and software installation.
Audience
This document is intended primarily for practitioners (including platform, networking, identity, and information security teams) looking to deploy Boundary Enterprise clusters on-premises or in cloud infrastructure.
After using the solution design guide to successfully deploy your Boundary Enterprise infrastructure, Boundary operators should refer to Boundary: Operating Guide for Adoption. Using this Operating Guide, Boundary operators learn how to integrate with identity providers, configure secure user access, centralize credential management, and more.
Document structure
| Document section | Purpose |
|---|---|
| Architecture | Describes the components that make up this validated design for Boundary Enterprise. |
| Detailed design | Expands on the architecture to provide more detail on each component of the architecture. Carefully review this section to identify all technical and personnel requirements before moving on to implementation. |
| Deploying Boundary Enterprise | Describes more general steps to install Boundary Enterprise as well as the supporting infrastructure detailed in the previous sections. |
| Deploying Boundary Enterprise in AWS using Terraform | Installation of Boundary Enterprise using our validated Terraform modules for AWS. |
| Deploying Boundary Enterprise in Azure using Terraform | Installation of Boundary Enterprise using our validated Terraform modules for Azure. |
| Deploying Boundary Enterprise in GCP using Terraform | Installation of Boundary Enterprise using our validated Terraform modules for GCP. |
Supported versions
This version of the guide has been validated with the following versions of Boundary Enterprise:
- Boundary Enterprise 0.17.x+ent
Language and definitions
This documentation intentionally uses technology agnostic terminology, however there are some terms which do not translate perfectly between the cloud providers. The following are the definitions of terms this document uses.
| Term | Definition |
|---|---|
| Region | A physical location in a distinct geographic area containing one or more availability zones (AZ). |
| Availability zone (AZ) | An availability zone (AZ) is a single network failure domain that hosts part or all of a Boundary Enterprise cluster. Examples of availability zones include: an individual datacenter
|
| Public subnet | A network accessible by users. |
| Private subnet | A network used by applications and services, but not directly accessible by users. |
Organizational requirements
Most tasks outlined in this guide will be handled by a single team responsible for deploying shared infrastructure services, often referred to as the platform team. However, a successful Boundary Enterprise deployment requires collaboration across multiple organizational functions. The platform team will likely need to work with other teams, such as networking, information security, or identity teams, for tasks like IP allocation, certificate management, defining identity roles and permissions, or managing DNS hosted zones and records. If the infrastructure is hosted on a public cloud, these responsibilities may be consolidated within a unified cloud team. The platform team should thoroughly review this solutions design guide to identify any teams they may rely on or need approval from for key deployment tasks. It's essential to designate a project lead to oversee the deployment process and ensure clear communication and coordination with all relevant teams and functions.