Deploying HashiCorp Boundary for secure remote access to AWS resources
Australian engineering teams running workloads in the AWS Sydney region (ap-southeast-2) often wrestle with a familiar pain point: contractors in Perth need to reach a private RDS cluster in Melbourne, while developers working from home in Brisbane require short-lived database access without long-lived SSH keys floating around. HashiCorp Boundary addresses that friction by replacing network tunnels with identity-aware, brokered sessions.
For Australian organisations, this approach maps cleanly onto local compliance expectations. The Notifiable Data Breaches scheme under the Privacy Act 1988 pushes teams toward auditable access paths, and APRA-regulated entities must demonstrate controls aligned with CPS 234. Boundary's session capture and credential injection features give operators concrete evidence to show auditors, without bolting on yet another logging stack.
Why Boundary differs from traditional remote access
Boundary treats remote access as an identity problem rather than a network problem. Engineers authenticate once to a controller, then request access to logical targets such as a database, an EC2 instance, or an internal HTTP service. The controller checks the user's identity, grants a short-lived session, and brokers the credentials so the target never sees the user's long-term secret.
This model sidesteps several habits that have aged poorly. Shared SSH keys on jump boxes, static VPN passwords, and over-broad security groups all become unnecessary. A Melbourne-based DBA can connect to a production Aurora cluster through a Boundary worker in the same VPC, without holding the database password at all. The worker injects the credential for the duration of the session and revokes it when the session ends.
Comparing remote access options for AWS
Teams evaluating Boundary often compare it against familiar alternatives. The summary below shows where each approach fits in an AWS-centric environment.
| Capability | HashiCorp Boundary | Traditional VPN | AWS SSM Session Manager | SSH bastion host |
|---|---|---|---|---|
| Protocol coverage | SSH, RDP, HTTP/S, TCP | All IP traffic | SSH, RDP (Windows) | SSH only |
| Credential exposure | Brokered, never held by user | User holds | IAM-scoped, no key sharing | User holds private key |
| Audit detail | Per-session command capture | Connection logs | CloudTrail and Session Manager logs | Limited to SSH events |
| Time to provision access | Minutes (policy update) | Hours (firewall plus VPN config) | Minutes | Hours to days |
| Client footprint | Boundary CLI, Desktop, or web | Vendor VPN client | AWS CLI plus SSM Agent | Standard SSH client |
| Fit for contractors | Strong (time-bound roles) | Weak | Strong | Weak |
The comparison explains why teams handling sensitive workloads lean toward Boundary: closer to AWS-native tooling than a VPN, but more flexible than relying solely on Session Manager.
Anatomy of a Boundary deployment on AWS
A production deployment typically separates three concerns: controllers, workers, and targets. Controllers hold the policy database and API; workers run inside target VPCs and form outbound tunnels to the controller; targets reference AWS resources such as RDS endpoints, EC2 instances via SSH, or internal HTTP services fronted by a load balancer.
For resilience, most Australian teams run two or three controllers across multiple AZs in ap-southeast-2. Workers deploy as EC2 instances or ECS tasks, with IAM instance profiles granting permission to fetch credentials from AWS Secrets Manager or SSM Parameter Store when a session begins. Targets are defined in HCL configuration or via the API, binding each resource to a role that maps to your IdP groups.
Walking through the installation steps
Start by provisioning a Boundary controller cluster in a dedicated VPC or shared services account. The community edition runs as a single binary, but production deployments typically use HCP Boundary or self-host with an external Postgres backend. Terraform modules from the HashiCorp community cover most of this and integrate well with existing landing zone code common in finance and government accounts.
Next, deploy workers in each VPC containing a target. Workers only need outbound HTTPS to the controller and IAM permission to retrieve secrets. Once registered, define host sets matching your private subnets, then build targets with the relevant ports (5432 for Postgres, 3389 for RDP, 22 for SSH). Bind each target to a role tied to your IdP groups via OIDC.
Finally, publish the controller behind a TLS endpoint and distribute the Boundary CLI or Desktop client. For contractors, the web-based session launcher avoids local installs entirely.
Operational realities for Australian engineering teams
Australian conditions shape a few practical decisions. Latency from Perth or Hobart to ap-southeast-2 can be noticeable, so place workers in the same region as the targets they serve rather than centralising them in a single hub VPC. Engineers in regional centres often rely on asymmetric NBN connections, which affects how comfortable RDP sessions feel and pushes teams toward text-based SSH targets where possible.
Compliance teams will look for alignment with the ACSC Essential Eight and, for critical infrastructure, SOCI Act obligations. Boundary's admin role can be restricted to break-glass accounts, while day-to-day operations run through scoped grants with short TTLs. The Australian Cyber Security Centre's guidance on privileged access management maps neatly onto Boundary's grant flows.
The real audit value shows up in incident response. Session recordings capture every command run over SSH or every byte exchanged over an HTTP target, stored in S3 with Object Lock for tamper resistance. Sydney and Melbourne SOCs can replay sessions when investigating alerts, much like endpoint forensics. For organisations already operating defence-in-depth, Boundary complements network-layer tooling such as the DefensePro ransomware traffic detection approach covered elsewhere on this site — one protects the path in, the other inspects what flows through.
Recommendations for a production Boundary rollout in AWS
- Run at least two controllers across distinct AZs in ap-southeast-2, with an external Postgres backend for durability.
- Place workers in every VPC holding a target, keeping traffic intra-region to minimise latency for users outside Sydney.
- Integrate the controller with your existing IdP via OIDC and map IdP groups directly to Boundary roles.
- Forward session recordings to an S3 bucket with versioning, Object Lock, and KMS encryption.
- Treat Boundary admin as a break-glass role; day-to-day changes go through scoped grants with short TTLs.
- Test failover regularly by terminating a controller and confirming workers reconnect without dropping sessions.
- Combine Boundary with network-layer protections, since identity-aware access does not replace traffic inspection or DDoS mitigation.