Contact Us 1-800-596-4880
  1. Homepage
  2. CloudHub

  3. CloudHub Networking Guide

CloudHub Networking Guide

This guide is for cloud deployments using the cloud-based version of Runtime Manager. See Deployment Options for information about different deployment scenarios.

Overview

CloudHub provides a variety of tools to architect your integrations and APIs so they are maintainable, secure, and scalable. This guide covers the basic network architecture, DNS, and firewall rules.

CloudHub Network Overview
Figure 1. The image shows the CloudHub components: Load Balancer, Virtual Private Cloud, and the DNS records of the Mule workers.

See the sections below for information about load balancing and DNS records. For information about VPC, see Virtual Private Cloud.

Load Balancing

CloudHub provides a load balancing service for all integrations. You can use the default load balancing service or obtain a dedicated load balancer.

The CloudHub load balancing service does round robin load distribution across workers, which allows workers to scale linearly as they receive more requests. The load balancing service also provides transparent switchover when an application is upgraded. See Manage Applications on CloudHub.

Each application deployed on CloudHub has a CNAME record that refers to the load balancer, for example myapp.region.cloudhub.io. Mule apps deployed in CloudHub must listen on host 0.0.0.0 and to either the HTTP port (8081) or to the HTTPS port (8082).

The following ports are assigned on the Mule worker:

  • http.port is set to 8081

  • https.port is set to 8082

The load balancer then forwards requests to the assigned ports on the Mule worker. Forwarded traffic still uses HTTP and HTTPS protocols, which means it can’t listen for HTTPS on ${http.port} or plain HTTP on ${https.port}.
You must reference these ports using the reserved properties ${http.port} and ${https.port} respectively. CloudHub services can then dynamically allocate a port at deployment time.

Here is an example of a Mule configuration that exposes an HTTPS endpoint:

<http:listener-config name="HTTP_Listener_Configuration" protocol="HTTPS" host="0.0.0.0" port="${https.port}" doc:name="HTTP Listener Configuration" >
		<tls:context name="TLS_Context_Custom_Keystore" doc:name="TLS Context">
			<tls:key-store type="jks" path="server.jks" keyPassword="keypassword" password="storepassword" alias="cloudhubworker" />
		</tls:context>
</http:listener-config>
On the Mule worker, the CloudHub load balancer automatically proxies the http.port :80 to port :8081 for HTTP and the https.port :443 to :8082 for HTTPS.
If other values for http.port and https.port are specified in the mule-app.properties file, these are overwritten at deployment time.

For each request a client makes through CloudHub’s load balancer (myapp.region.cloudhub.io), the load balancer maintains two connections. One connection ​is from​ the client and one is to your worker. For each connection, the load balancer manages an idle timeout of 300 seconds that is triggered when no data is sent over ​either​ connection. If no data is sent or received during this time period, the load balancer closes ​both connections.

For connections that take longer than 300 seconds to process from either side, consider handling the processing asynchronously.

DNS Records

The following DNS records for your applications are exposed when they are deployed to CloudHub:

myapp.region.cloudhub.io

Load balancer. Ports 80 and 443 forward to ${http.port} and ${https.port} respectively.

mule-worker-myapp.region.cloudhub.io

The external IP address of the Mule workers. Public HTTP services are exposed on: ${http.port} and ${https.port}

mule-worker-internal-myapp.region.cloudhub.io

The internal IP address of the Mule workers. The IP addresses for this DNS record are accessible only within a customer’s private Anypoint VPC. These IP addresses are not accessible for workers running in the MuleSoft shared VPC. Internal HTTP services are exposed on: ${http.private.port} and ${https.private.port}. The default assigned ports are 8091 and 8092 respectively, and cannot be changed.

In certain situations, you may want to know an application’s internal IP addresses, for example:

  • When communicating with the worker directly within the customer’s Anypoint VPC without sending data over the public internet

  • When setting up your own load balancer

You can access these IP addresses through the mule-worker-internal-myapp.region.cloudhub.io record from within the Anypoint VPC. If you access the workers directly, any load distribution benefits from the CloudHub load balancing layer are lost.

IP Ranges and Static IPs

CloudHub IP addresses are chosen from the Amazon EC2 IP pool. For a list of these ranges, see Amazon AWS IP Address Ranges API. The download link in that page will retrieve a dynamically generated JSON representation of all ranges that include the region. These ranges can change without notice, so you should update this information regularly.

CloudHub supports allocating a static IP for applications so that they can be allowlisted for other services. To enable a static IP for your application, go to the Static IPs tab in the application settings page on the Runtime Manager UI, then enable the Use Static IP checkbox. By default, you are allocated a number of static IPs equal to twice the number of Production vCores in your subscription. To increase this limit, contact MuleSoft Help Center.

After a static IP has been allocated for your application, the IP address is visible in the Static IPs tab in the application settings. For more information about static IPs, see Static IPs Tab Settings.

Static IP addresses are not supported for private IP addresses inside an Anypoint VPC.

Sometimes firewalls or infrastructure settings don’t let Mule runtime engines reach the Runtime Manager’s public services. This might be an issue when registering a Mule, or when starting it and registering it to work with Runtime Manager.

If you need to allow the IP addresses for the communication between the Runtime Manager Agent and the Runtime Manager console, see Ports, IP Addresses, and Hostnames to Allow.

You can assign Static IP to applications with multiple workers. However, it is not possible to pre-allocate static IPs for multiple workers. In case of multiple workers, IP addresses are automatically allocated.

Regional Services

Depending on what region you deploy your application in, the DNS record and the load balancer for your integration may change. The following table summarizes what DNS records are available for your application in each region:

Region Name Region Example DNS Record

US Control Plane Regions

US East (N. Virginia)

us-e1

myapp.us-e1.cloudhub.io

US East (Ohio)

us-e2

myapp.us-e2.cloudhub.io

US West (N. California)

us-w1

myapp.us-w1.cloudhub.io

US West (Oregon)

us-w2

myapp.us-w2.cloudhub.io

Canada (Central)

ca-c1

myapp.ca-c1.cloudhub.io

South America (Sao Paulo)

br-s1

myapp.br-s1.cloudhub.io

Asia Pacific (Singapore)

sg-s1

myapp.sg-s1.cloudhub.io

Asia Pacific (Sydney)

au-s1

myapp.au-s1.cloudhub.io

Asia Pacific (Tokyo)

jp-e1

myapp.jp-e1.cloudhub.io

EU (Ireland)

ir-e1

myapp.ir-e1.cloudhub.io

EU (Frankfurt)

de-c1

myapp.de-c1.cloudhub.io

EU (London)

uk-e1

myapp.uk-e1.cloudhub.io

MuleSoft Government Cloud

US Gov West

usg-w1.gov

myapp.usg-w1.gov.cloudhub.io

EU Control Plane Regions

EU (Ireland)

ir-e1.eu1

myapp.ir-e1.eu1.cloudhub.io

EU (Frankfurt)

de-c1.eu1

myapp.de-c1.eu1.cloudhub.io

Note that DNS records are unique to each control plane. Though the EU control plane supports some of the same regions that the U.S. control plane supports, the DNS records are different. For more on the EU control plane, see About the EU Control Plane.

Deploying to a region also affects your internal and external worker DNS address. For example, if you are using the US control plane and deploy to the Ireland region, the DNS records for internal and external IP addresses are mule-worker-myapp.ir-e1.cloudhub.io and mule-worker-internal-myapp.ir-e1.cloudhub.io.

Firewall Rules and Port Access

The only two ports exposed externally are ${http.port} and ${https.port} (by default 8081 and 8082 respectively). If you want to access other ports, you can do so through the Anypoint Virtual Private Cloud (Anypoint VPC) offering.

Additional ports can be opened inside the Anypoint VPC, for example, for JMX based monitoring. Refer to the Firewall Rules section in Anypoint VPC documentation.

Dedicated Load Balancing Configurations

In some cases, you may want to set up a custom load balancing layer for your Mule workers, for example, if you want to provide a custom domain name or SSL certificates.

Traffic can be routed from your load balancer to CloudHub workers through the internal or external DNS record for your workers. This record contains an IP address for every worker in the application. It is recommended that you set your DNS timeout to between 20-60 seconds so that any DNS changes are propagated quickly and minimize impact.

You can set your own dedicated load balancer after configuring your own Anypoint VPC.

Avoid Public Discoverability for Applications on CloudHub

If you have Anypoint VPC and a CloudHub dedicated load balancer, you can prevent your applications hosted in CloudHub from being publicly accessible:

  1. Remove the Anypoint VPC firewall rule for ports 8081 and 8082 using:

    1. The Firewall Rules tab in your Anypoint VPC management center. Remove both rules with source Anywhere (0.0.0.0/0) and ports 8081 and 8082.

    2. The Anypoint Platform CLI. Run the cloudhub vpc firewall-rules remove command with the index 1 and 3.

  2. Create an allowlist in your dedicated load balancer with the IP addresses you want to authorize.

If you don’t have a CloudHub dedicated load balancer, performing the first step is sufficient to ensure that applications deployed in your Anypoint VPCs are not publicly accessible.

See Also