Network design

Private Path service for VPC

The Private Path service is used to associate the Private Path network load balancer to the service endpoint virtual private endpoint (VPE) that the client, in this case the IBM Cloud SaaS, will use to access the load balanced workloads. In this pattern, the load balanced workloads are running on-premises. The association between the VPE and the Private Path NLB is controlled by an authorization mechanism that is implemented in the Private Path service. Policies can be set globally or per IBM Cloud account ID to automatically accept or reject requests.

Connectivity from SaaS VPC to Private Path NLB - Virtual Private Gateway and VPE

A VPE is used to provide access from the VPC to the Private Path NLB.

Only a Private Path service can use a Private Path NLB. Access to the Private Path NLB is allowed only through the VPE gateway that is associated to it after the connection request is approved.

A VPE is only reachable from the VPC where it is deployed. This means that for this pattern, the VPE is located in the VPC where the IBM Cloud SaaS offering is running (“SaaS VPC” in the reference architecture diagram).

Each “client” of an IBM Cloud service that targets the same on-premises service uses its own VPE and can target the same Private Path NLB.

Private Path NLB

The Private Path NLB is a regional, highly available, and highly scalable load balancer. Supported load balancing methods are round-robin and weighted round-robin.

The Private Path NLB can use IBM Cloud VSIs or an IBM Cloud Application Load Balancer (ALB) as backend pool members. To be able to reach resources located outside of IBM Cloud through a Private Path NLB, an ALB must be used as a Private Path NLB backend pool member.

When an application load balancer is used as a pool member, no other members can be attached to that pool. Several backend pools can be defined, each targeting different ALBs, thus allowing to use a single Private Path NLB to provide access to on premises target servers.

Connectivity from the Private Path NLB to on premises resources – ALB

An application load balancer is necessary to allow the Private Path NLB to reach on-premises resources.

The ALB allows you to add servers that are located outside of IBM Cloud as backend pool members by their IP address. Private Path currently supports only the Transmission Control Protocol (TCP). In this pattern, the backend pool members are the target server that is located in the customer’s on-premises data center.

Connectivity between customer’s IBM Cloud VPC and customer’s on-premises data center

To allow the ALB to reach the on-premises target servers, connectivity must be established between the customer’s IBM Cloud VPC and the customer’s on-premises data center hosting the target resources.

Direct Link allows a private connectivity between the customer’s on-premises data center and the customer’s IBM Cloud VPC, enabling the Private Path service running in the customer’s IBM Cloud VPC to reach the customer’s application that runs in their on-premises data center without exposing traffic to the public internet.

As a best practice, two direct links are provisioned and the Border Gateway Protocol (BGP) autonomous systems (AS) path prepend capability is configured on them to provide redundancy and automatic failover. In this pattern, the direct links terminate directly on the IBM Cloud VPC, as this pattern is focuses on providing only IBM® SaaS to on-premises services connectivity.

As an alternative, you can use IBM Cloud site to site VPN for VPC service, which replaces the private connectivity that is provided by the direct link with an encrypted tunnel over the public internet. However, validation of this approach isn't in scope for this pattern.

Domain Name Services (DNS)

Private Path service uses a private Domain Name System (DNS) to associate human friendly names with IP addresses. Private DNS zones are resolvable only on IBM Cloud, and only from explicitly permitted networks in an account. To learn more, see Getting started with IBM Cloud DNS Services.

You must choose a DNS FQDN for your service that clients can use. This domain is configured in consumer private DNS, but you are expected to prove ownership of the FQDN in public DNS, which requires you to take some steps with your DNS provider. For more information, see Registering and verifying ownership of service endpoints (FQDNs).