Private Links for AWS and Azure

Private Links is a connectivity capability that provides a means of connecting webMethods Cloud to your private cloud on Amazon Web Services (AWS) or Microsoft Azure without exposing the network details of either side.

Private Links capability is available within the cloud provider’s infrastructure. It is secure by design and uses Transport Layer Security (TLS) at the wire-level to transparently encrypt all the traffic between two entities.

PrivateLinks for AWS

PrivateLinks in AWS provides private connectivity between two AWS Virtual Private Clouds (VPCs). The links establish a private and secure connection between the VPC of IBM and your VPC. After the PrivateLinks are set up, your VPC is not exposed to the internet and latency between the IBM infrastructure and your infrastructure is low.

PrivateLinks on AWS are regional and may not cross regions. When you have a PrivateLink to a VPC within the region in which you have a webMethods Cloud environment, then to cross to a different region, use either AWS VPC Peering or AWS Transit Gateway to transfer to your AWS cloud environment.

AWS based PrivateLinks do not rely on any of the following technologies:

VPC Peering
VPN
AWS Transit Gateways technique of merging parts
Exposure of webMethods Cloud and your network at the IP level

PrivateLinks utilize what AWS describes as a Hyperplane technique such that the IBM network and your network do not merge or require the use of Network Address Translation (NAT).

Private Links for Microsoft Azure

Microsoft Azure Private Links allow you to securely connect a consumer’s Azure Virtual Network (VNet) to the service provider’s VNet. The connection is private and secure, as the service provider’s VNet does not have to be exposed to the internet. Latency between the consumer and service provider is lower than a setup without Private Links.
To establish this connection, the service provider must create the Private Link Service, while the consumer needs to set up the Private Endpoint to connect to the Private Link Service.

Important

Private Links capability is available only if you are on the Enterprise Plus tier. For information and pricing of Enterprise Plus, contact your IBM Account Executive.

Advantages of Private Links

Private Links provide the following advantages over an internet based connection between VPCs.

	Internet based connection	PrivateLinks based connection
Performance	Poor performance Undefined data transfer speeds that maybe limited by AWS or Azure Undefined latency as going over the internet	High performance Up to 9X faster data transfer Latency reduced by 50-90% The variability in these numbers depends on whether it is Azure or AWS and the specific region to which Private Links are connected. For example, the connection speed between AWS Oregon region and AWS Virginia region is slower than within the same region, such as AWS Oregon to AWS Oregon.
Security	Requires internet-facing open listeners on your VPC. Complex security configuration.	No internet-facing open listeners required. Provides higher level of isolation especially for regulatory requirements.

Hub and Spoke Model

There are two ways in which you can obtain PrivateLinks for webMethods Cloud products:

Configure a dedicated instance of webMethods Cloud exclusively for you.
Configure a dedicated instance of webMethods Cloud runtime components, that provides sufficient isolation to offer PrivateLinks. This option follows a Hub and Spoke model.

Both solutions offer PrivateLinks, with cost being the big differentiator. The Hub and Spoke model is considerably cheaper than a completely dedicated setup.

Consider a Kubernetes cluster shared with multiple webMethods Cloud products. As a customer, you share this cluster with other customers. However, you might require isolation of your environment for the following reasons:

Cloud-to-Cloud and Cloud-to-on-premises connectivity
Run times execute your code in a shared cluster
Strict regulatory compliance requirements regarding usage of a shared VPC

In this scenario, both options allow you to use PrivateLinks. However, the Hub and Spoke architecture is the preferred choice, where the Hub hosts all your shared components or services, and the Spoke hosts all your dedicated components or services.

IBM provides you with a fast, high performance, high security PrivateLinks Hub and spoke model in the Enterprise Plus tier. For information and pricing of Enterprise Plus, contact your IBM Account Executive.

Benefits of the Hub and Spoke Model

Design time is separated from runtime, with the Hub hosting your design time and the Spoke hosting your runtime.
Control Plane is separated from Data Plane, with the Hub hosting your Control Plane and the Spoke hosting your Data Plane.
Your runtime execution engines have a dedicated spoke.
Your spoke is network isolated, and this facilitates the use of PrivateLinks.
- Your traffic is routed over a hyperscaler backbone, eliminating exposure to the public internet.
You do not require the hybrid agent.

The following example shows you a generic Hub and Spoke architecture with various webMethods Cloud products:

The router in the architecture diagram is described in the following sections.

Router

When you establish a PrivateLinks connection between your VPC (provider) and the webMethods Cloud VPC (consumer), it exposes the PrivateLink with the predefined DNS name link0.privatelink.

link0.privatelink functions like a wildcard CNAME, allowing you to add your chosen hierarchy as a prefix. There is no provision for custom DNS naming in this context, as the name link0.privatelink remains fixed.

For outbound traffic from webMethods Cloud, it is recommended to establish a dedicated VPC designed to serve as a bridge between webMethods Cloud and your systems. Within this bridge, a router manages the flow of traffic from webMethods Cloud to your resources. Additionally, the bridge functions as a secure zone, offering the option for you to implement firewalls or virus scanners between webMethods Cloud and your systems.

In all scenarios, the router is the key component of interfacing between webMethods Cloud and your resources. The router performs the following tasks:

Demultiplexes HTTP(s) requests and routes them to the appropriate resources on your side.
Provides a port forwarding capability for TCP/UDP traffic, inclusive where appropriate, remapping to the destination port.
Terminates TLS/mTLS traffic coming from webMethods Cloud. It is recommended to terminate the TLS/mTLS traffic in the router.
Where necessary, the router creates the upstream TLS/mTLS connections.

Demultiplexing of incoming HTTP(s) requests and routing them to appropriate resources is probably the most important task of the router when dealing with HTTP(s) and is the real role of an L7 Router. The naming of the upstream resources is important as an algorithm must be implemented for the demultiplexing activity.

Setting up a Connection using PrivateLinks

This section explains how to set up a connection using PrivateLinks. You can have one PrivateLinks for the outbound connection, and another for the inbound connection. The outbound PrivateLinks connection connects the IBM VPC to your VPC, and the inbound PrivateLinks connection connects your VPC to the IBM VPC.

To obtain PrivateLinks, contact your IBM Account Executive. PrivateLinks capability is available only with the Enterprise Plus tier.

The owner of a service is the service provider. A service provider creates an endpoint service to make the service available in a region. The service provider specifies a Network Load Balancer (NLB) when creating an endpoint service. The load balancer receives requests from the service consumers and routes them to your service. The endpoint service of the service provider is not available to service consumers, so the AWS Principal needs to be provided. A service consumer creates a VPC endpoint to connect the VPC to an endpoint service.

Traffic from your VPC is sent to an endpoint service using a connection between the VPC endpoint and the endpoint service. Traffic between a VPC endpoint and an endpoint service stays within the AWS network, avoiding exposure to the public internet. The service provider adds permissions so that service consumers can access the endpoint service. The service consumer initiates the connection and the service provider accepts or rejects the connection request.

Configuring PrivateLinks for AWS

This section provides information on how to set up and configure outbound and inbound AWS PrivateLinks.

Prerequisites

Create a VPC in each region where you have webMethods Cloud environments as specified in your contract.
Your AWS VPC must be in the same region as the webMethods Cloud AWS VPC.
Create a load balancer with three availability zones. Ensure that you enable cross-zone load balancing. To enable cross-zone load balancing, in your load balancer attached to the VPC endpoint service, go to Attributes, and select the Cross-zone load balancing option.
Verify that IBM has set up the spoke that contains your environments and products.

Configuring AWS PrivateLinks for outbound traffic from webMethods Cloud

This section provides information on how to set up the Outbound AWS PrivateLinks from webMethods Cloud to your infrastructure.

In this scenario, you are the service provider and IBM is the service consumer. After you create an endpoint service, the IBM VPC endpoint then connects to your endpoint service.

Provide the service name and private DNS name configured for the Service endpoint. The private DNS name is not mandatory. IBM provides the AWS account principal allowed to connect the endpoint service and you have to accept the endpoint connection.

Access to all resources over the PrivateLink in your environment is over the following DNS name:

<customer_server_name>.link0.privatelink

where <customer_server_name> is defined by you to represent each of your service endpoints. <customer_server_name> can have any level of complexity that is a valid hostname.

Examples:

ora-finance.link0.privatelink – Simple hostname for an Oracle RDBMs
myService.production.acme.com.link0.privatelink – REST Service accessed using an FQDN (Fully Qualified DNS Name)

Outbound AWS PrivateLinks Configuration

Create the Service endpoint.
- See the AWS Documentation for information on how to create a service endpoint.
- For the option Require acceptance for endpoint, select Acceptance required.
- For the option Supported IP address types, select IPV4 or Both IPV4 and IPV6.
- Go to Allow principals and add the AWS Principal arn:aws:iam::707972782358:root.
- To manage permissions for your endpoint service using the console, see the AWS Documentation.
Open a support incident with IBM support to setup the outbound PrivateLinks. Provide the name of the AWS endpoint service and the ports to be exposed for your load balancer.
IBM sends a request to connect to your endpoint service.
The request is received within the master account console of your cloud provider.
Accept the connection request from IBM.
To accept or reject a connection request using the console, see the AWS Documentation.

Note

When setting up private links for outbound connections where IBM needs to connect to your VPC/VNet, and if you have a strict firewall policy that restricts connections from other IPs, IBM will provide the private outbound endpoint IP addresses. Ensure that you add the private outbound endpoint IP addresses to your allowed list.

Inbound AWS PrivateLinks to webMethods Cloud

Set up the inbound AWS PrivateLinks when you need to connect applications hosted on-premises or in your private cloud, to invoke APIs or integrations within webMethods Cloud.

Here, you set up the inbound AWS PrivateLinks from your infrastructure to webMethods Cloud. webMethods Cloud is the service provider, you are the service consumer, and your VPC endpoint connects to the webMethods Cloud endpoint service.

Note

To connect to an endpoint service as the service consumer, see the AWS Documentation.

Open a support incident with IBM support to set up the inbound PrivateLink and provide the following information:
- AWS Principal for the AWS Account that connects to webMethods Cloud endpoint service.
- The DNS suffix to be used to access webMethods Cloud. Access should be based on:
```
<tenant-name>.<customer-defined-suffix>
```
  Note
  
  The tenant-name must be the IBM webMethods iPaaS tenant name created during tenant provisioning.
  Examples of customer-defined-suffix: webmethods.acme.com, or acme.com, or any valid custom domain, which you own.
IBM creates an endpoint service for webMethods Cloud specific to your spoke and provides the endpoint service name.
You create the VPC endpoint to connect to the webMethods Cloud endpoint service.
IBM accepts your endpoint connection request.

Note

If you need separate PrivateLinks for different environments, plan to procure additional spokes in Enterprise Plus tier. For information and pricing of Enterprise Plus, contact your IBM Account Executive.

Configuring Private Links for Microsoft Azure

This section provides information on how to set up and configure outbound and inbound Microsoft Azure Private Links. See Introduction to Azure Private Link to learn how Azure Private Link enables private connectivity to Azure services.

Prerequisites

Create a VNet in each region where you have webMethods Cloud environments as specified in your contract.
Create an Azure Standard Load Balancer before creating the Azure Private Link service. See the Azure Documentation for information on how to create a standard load balancer.
Verify that IBM has set up the spoke that contains your environments and products.

Note

Private Endpoints can connect to Azure PaaS resources across Azure regions. See the Regions and IP Addresses page for the supported regions.

Configuring Azure Private Links for outbound traffic from webMethods Cloud

This section provides information on how to set up the outbound Azure Private Links from webMethods Cloud to your infrastructure.

In this scenario, you are the service provider and webMethods Cloud is the service consumer. After you create an Azure Private Link service, the webMethods Cloud VNet private endpoint connects to your Azure Private Link service.

Provide the Azure resource URL or the globally unique named moniker called alias to IBM support for webMethods Cloud to create the VNet endpoint connection. The Azure account subscription ID used by webMethods Cloud is provided in the following section for adding in the subscription based access section while configuring an Azure Private Link Service.

Access to all resources over the Private Link in your environment is over the following DNS name:

<customer_server_name>.link0.privatelink

where <customer_server_name> is defined by you to represent each of your service endpoints.
<customer_server_name> can have any level of complexity that is a valid hostname.

Examples:

ora-finance.link0.privatelink – Simple hostname for an Oracle RDBMs
myService.production.acme.com.link0.privatelink – REST Service accessed using an FQDN (Fully Qualified DNS Name)

Outbound Azure Private Links Configuration

Create the Private Link service. See the Azure Documentation for more details.
The following are the key points to configure:
- Setup an Azure Standard Load Balancer before setting up an Azure Private Link service. See the Azure Documentation for information on how to create a standard load balancer.
- Configure Network Address Translation (NAT) IP addressing appropriately for your environment.
- In the Access security section, select Restricted by subscription for the Who can request access to your service? option. Add your subscription with Auto-approve set to No.
- Complete the confirmation as per your corporate requirements.
Open a support incident with IBM support and provide the Azure resource URL or the globally unique named moniker called alias for webMethods Cloud to create the VNet endpoint connection.
webMethods Cloud will connect to your Private Link Service requesting approval to connect. The approval is under your Private Link > Settings > Private endpoint connections. Select Approve and then select Yes.

Note

If you need separate Private Links for different environments, plan to procure additional spokes in Enterprise Plus tier. For information and pricing of Enterprise Plus, contact your IBM Account Executive.

Inbound Azure Private Links to webMethods Cloud

Set up the inbound Azure Private Links when you need to connect applications hosted on-premises or in your private cloud, to invoke APIs or integrations within webMethods Cloud. Here, you set up the inbound Azure Private Links from your infrastructure to webMethods Cloud. webMethods Cloud is the service provider and you are the service consumer.

Open a support incident with IBM support to set up the inbound Private Link and provide the following information:
- The DNS suffix to be used to access webMethods Cloud.
  The access should be based on:
```
<tenant-name>.<customer-defined-suffix>
```
Note

tenant-name must be the IBM webMethods iPaaS tenant name created during tenant provisioning.
Examples of customer-defined-suffix are webmethods.acme.com, or acme.com, or any valid custom domain, which you own.
IBM creates a private link service for webMethods Cloud specific to your spoke, and provides the private link service name along with the globally unique named moniker called alias.
You create the private endpoint to connect to the webMethods Cloud endpoint service. See the Azure Documentation for details.
IBM accepts your endpoint connection request. The connection is established and you can validate the connection.

Frequently Asked Questions

How do I configure Private Links for AWS and Microsoft Azure?

See the Configuring PrivateLinks for AWS and Configuring Private Links for Microsoft Azure sections for information on how to configure Private Links.

What is the endpoint policy that webMethods Cloud will configure to authenticate the connection?

The connection acceptance for the first time is a manual activity that IBM approves once your setup is complete.

Should we have a separate spoke for each tenant for more security?

You can opt for different spokes for prod and non prod to separate prod from non-prod environments, but the same level of security can be achieved using a single private link.

Can a single spoke offer network isolation between various environments?

There is a namespace isolation between the environments although they are part of the same network. In case network isolation is needed, then there should be separate spokes per environment.

In our non prod environment, we have three tenants in one spoke and only one single endpoint (PL) to be created. Can I use the following hostname conventions? There will be a total of nine targets connecting through the same endpoint. Is this correct?

[tenant-name].[service].io.is.abc.com
Tenant name: abcdev/abcqa/abcpreprd
Service:  agw/int/mft

Yes, all these can connect through the same endpoint.

How does the routing work if we need to connect to webMethods Cloud for outgoing traffic from multiple components in each environment? What endpoint address or private DNS can we use for this purpose?

The routing is based on the hostname. By default, webMethods Cloud uses [tenantname].private.[primary-domain]. For example, abc.private.aw-us.webemethods.io.
IBM also supports custom domain for this case but it should follow the required convention.

I understand we can have an additional inbound private link dedicated to only IBM webMethods Managed File Transfer traffic. Does IBM webMethods Managed File Transfer support custom DNS and use the same naming convention? Can I use the following hostname conventions?

[tenant-name].mft.io.is.abc.com<br>
Tenant name: abcdev/abcqa/abcpreprd

Yes, IBM webMethods Managed File Transfer supports custom DNS, and the above naming convention is correct. However, it needs a separate domain, for example, [tenant-name].mft.io.is.abc.com cannot be the same for IBM webMethods Integration and IBM webMethods Managed File Transfer. You will require [tenant-name].mft.io.is.abc.com for IBM webMethods Managed File Transfer and [tenant-name].wmio.io.is.abc.com for IBM webMethods Integration.

Is there a way to prevent invoking a different host from the webMethods Cloud side compared to internally at the customer’s end? Could a split DNS setup be possible where the customer can create DNS entries in various landscapes that resolve to the Private Link host? For example, abc.test.xyz.nl would be a CNAME to the Private Link host where internally it would resolve correctly.

Yes, it is possible for Inbound to webMethods Cloud from the customer’s VPC.

Can we connect different VPCs using the same Private Link?

We can have a single private link for a VPC.

Does IBM webMethods Managed File Transfer inbound need a separate Private Link?

If you have IBM webMethods Managed File Transfer, there will be an additional inbound private link dedicated to just the IBM webMethods Managed File Transfer traffic.

For API Management customers on v11.0, will there be an additional outbound private link to access ElasticSearch?

Yes

Once I open a service incident for creating a private link (inbound or outbound), what is the duration I can expect to have the private link successfully working?

Due to the manual approval processes involved with inbound and outbound private links, it usually requires around two days to complete.

Would changes at the customer’s side, for example, adding a port to the NLB for another back end service, require a change at webMethods Cloud?

For outbound use cases from webMethods Cloud to the customer’s VPC, the customer must specify the port they want to use for receiving the traffic. All the ports provided by the customer will be enabled on webMethods Cloud.

A customer wants to expose endpoints over Private Link to another network. Can a setup be done where the customer offers a VPC endpoint that is connected to an NLB that will then connect directly to other targets through port based routing, in particular to an ALB behind the NLB?

Yes

Is there a limit on how many Private Links can be set up at the webMethods Cloud side?

One private link can be setup for Inbound and one for Outbound, although there is no limitation in terms of the number of endpoints.

Do we always need a router?

There are some scenarios where a router is redundant as the NLB can handle the task. For example, a router is not needed if using only TCP/UDP based protocols.

Can we use an ALB/CLB as a router?

Yes.

We are using Kubernetes (K8s). Do we need a separate router?

You can use the K8s Ingress (controller) as the router to access resources in your K8s environment.

Can we use Path Based Routing?

Yes, this is a solution for a HTTP(s) Router (L7 Router). However, the challenge arises when dealing with the intricacies of demultiplexing the path.