Introduction
In today’s cloud-native architectures, secure and efficient connectivity between your Virtual Private Cloud (VPC) and IBM Cloud services is critical. IBM Cloud’s Virtual Private Endpoint (VPE) for VPC enables private connectivity to supported IBM Cloud services without exposing traffic to the public internet. This approach enhances security, reduces latency, and simplifies compliance.
In the realm of VPC hub-and-spoke DNS-sharing topologies, VPEs have been deployed in the Hub VPC for centralized services like IAM, Container Registry and Cloud Object Storage (COS) and VPEs for instance-based services like databases in shared/spoke VPCs. The Hub VPC manages DNS resolution for multiple shared VPCs. While this model works well for centralized control, certain workloads demand localized connectivity for performance and granular access control. Enter Local-Access VPEs - a new capability designed to meet these needs.
VPEs in DNS Hub and Sharing Topology
Before diving into local-access VPEs, let’s understand the DNS sharing topology with Cloud Object Storage service as an example:
- DNS Hub VPC: Acts as the central DNS resolver and hosts the primary VPE for the COS service S3 endpoint.
- DNS Shared VPC: Connects to the hub VPC for DNS resolution and route COS service S3 endpoint traffic through the hub VPE.
Key Benefits:
- Direct Connectivity: Data traffic flows locally between the shared VPC and the service endpoint, avoiding hub traversal through the transit gateway.
- Granular Access Control: Bind VPEs to individual COS buckets using resource bindings, combined with Context-Based Restrictions (CBR), security groups, and ACLs.
- Improved Performance: Reduced latency by eliminating extra network hops.
- Enhanced Security: Isolated paths for specific resources within your DNS-sharing topology.
Planning considerations
When deploying local-access VPEs:
- Ensure a hub VPC VPE exists for the service endpoint before creating local-access VPEs.
- Each DNS-shared VPC can have one local-access VPE per service endpoint with resource bindings to multiple resources (e.g. COS buckets).
- Resource bindings must be unique across the topology.
- Update Context Based Restrictions(CBR) and security group rules to allow traffic to the service endpoint from the DNS-shared VPC and restrict access from DNS-Hub VPC.
DNS sharing modes
The updated DNS sharing modes when creating VPE Gateways are as below.
- Primary: Allows the VPE gateway's service endpoint to be shared with the hub VPC's DNS resolver for name resolution.
- Per-resource binding: Allows the VPE gateway to have resource bindings to service endpoint resource (e.g. COS bucket) and share the service resource endpoint with hub VPC's DNS resolver for name resolution.
- Disabled: does not allow the VPE gateway's service endpoints to be shared for DNS name resolution.
How to Use Local-Access VPEs
You can create local-access VPEs through:
- IBM Cloud Console: Navigate to Infrastructure > Network > Virtual Private Endpoint Gateways > select your DNS-Shared VPC > Share DNS mode as “Per-resource binding”. Note: The Hub VPC VPE must be created with “Primary” as the Share DNS mode prior to creating the DNS-Shared VPC VPE. See IBM Cloud docs for more details.
- CLI: Use
ibmcloud is endpoint-gateway-create with --dns-resolution-binding-mode see the VPC CLI reference for more details.
- API or Terraform: Automate provisioning for scale. See API docs and getting started with Terraform
You can create Resource bindings through:
- IBM Cloud Console: Navigate to Virtual Private Endpoint Gateways > local-access VPE Gateway created as mentioned earlier > Resource bindings > Create resource binding. See IBM Cloud docs for more details.
- CLI: Use
ibmcloud is endpoint-gateway-resource-binding-create see the VPC CLI reference for more details.
- API or Terraform: See API docs and getting started with Terraform
Summary of Local-Access VPE Features
Think of local-access VPEs as your optimized access and security enhancer in DNS-sharing environments:
- Private, localized connectivity for service endpoint resources.
- Granular resource bindings for bucket-level access, restrictions enforced using CBRs.
- Flexible deployment options (Console, CLI, API, Terraform).
- Improved latency and security posture for sensitive workloads.
Why It Matters
For enterprises adopting multi-VPC architectures, local-access VPEs strike the perfect balance between centralized DNS management and localized performance optimization. They empower you to design secure, efficient, and compliant network topologies tailored to your application needs.