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.

Important
If you need consultation or guidance on setting up private links beyond the information provided in this documentation, contact your IBM Sales Account Representative, who will help you connect with IBM Expert Services. IBM cannot configure your infrastructure; you will need a certified network engineer or cloud security engineer, or an equivalent expert in AWS and Microsoft Azure, to take care of the configuration.

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).

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.

Note
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.

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:

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:

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

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

The router shown in the architecture diagram is explained in the following section.

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:

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.

Configuring PrivateLinks for AWS

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

Important
If you need consultation or guidance on setting up private links beyond the information provided in this documentation, contact your IBM Sales Account Representative, who will help you connect with IBM Expert Services. IBM cannot configure your infrastructure; you will need a certified network engineer or cloud security engineer, or an equivalent expert in AWS and Microsoft Azure, to take care of the configuration.

Prerequisites

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.

  1. Create an endpoint service.

    • See the AWS Documentation for information on how to create an endpoint service.
    • 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.
  2. 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.

  3. A request is sent to connect to your endpoint service. The request is received within the master account console of your cloud provider.

    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).
  4. 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.

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.
  1. 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.
  2. IBM creates an endpoint service for webMethods Cloud specific to your spoke and provides the endpoint service name.

  3. You create the VPC endpoint to connect to the webMethods Cloud endpoint service.

  4. 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.

Important
If you need consultation or guidance on setting up private links beyond the information provided in this documentation, contact your IBM Sales Account Representative, who will help you connect with IBM Expert Services. IBM cannot configure your infrastructure; you will need a certified network engineer or cloud security engineer, or an equivalent expert in AWS and Microsoft Azure, to take care of the configuration.

Prerequisites

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

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.

  1. 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.
  2. Open a support incident with IBM support and 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)
  3. webMethods Cloud connects 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
  • 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.
  • 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.

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.

  1. 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.
  2. 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.

  3. You create the private endpoint to connect to the webMethods Cloud endpoint service. See the Azure Documentation for details.

  4. IBM accepts your endpoint connection request. The connection is established and you can validate the connection.

Frequently Asked Questions

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.

[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.

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

We can have a single private link for a VPC.

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.

Yes

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.

Yes

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.