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 Enterprise 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 Enterprise 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 Enterprise to the cloud, the guide also includes Terraform modules to automate large portions of the infrastructure provisioning and software installation.
Audience
This document is 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 deploy your Boundary Enterprise infrastructure, operators should refer to Boundary: Operating Guide for Adoption. Using this Operating Guide, Boundary Enterprise operators learn how to integrate with identity providers, configure secure user access, centralize credential management, and more.
Supported versions
This version of the guide relates to 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 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
We expect a single team, often referred to as the Platform Team, to handle the tasks in this guide. However, a successful Boundary Enterprise deployment requires collaboration across multiple organizational functions. The Platform Team needs to work with other teams, such as networking or security for tasks such as IP allocation or certificate management. If hosting infrastructure on a public cloud, consolidate these responsibilities within a unified cloud team. The platform team should thoroughly review this Solution Design Guide to identify any teams they may rely on or need approval from for key deployment tasks. It is essential to designate a project lead to oversee the deployment process and ensure clear communication and coordination with all relevant teams and functions.