CloudHub is the cloud-based iPaaS component of Anypoint Platform. Applications on MuleSoft Cloudhub are run by one or more instances of Mule, called workers. Each worker is a dedicated instance of Mule that runs your integration application. In the default configuration, all cloud-based workers reside in a multi-tenant public cloud, balanced by a publicly accessible shared load balancer.
Anypoint Virtual Private Cloud (VPC) grants you a logically private and isolated network dedicated to host your cloud-based worker instances. For example, the most common setup has one isolated network for your production environment, and another for your non-productions environments, which can be development and testing. You can use shared or dedicated load balancers to connect to your workers from the internet. The shared load balancer is outside your VPC and the dedicated load balancer is part of your VPC.
In this blog, we will look at the configurations and features of Anypoint VPCs — including securing your cloud workers by adding firewall rules, associating business groups/environments, configuring DNS servers, CIDR block sizing, and connectivity.
Shared Load Balancer outside your VPC
Dedicated Load Balancer within your VPC
VPC region
You can create your Anypoint VPC inside any of the available CloudHub regions.
Regions have up to four availability zones for high availability and disaster recovery. Availability zones are geographically distributed within a region and spaced for best insulation and stability in the event of a natural disaster.
The recommended region to use might vary depending on how you connect to your Anypoint VPC. If you are using a VPN tunnel, you might want to choose the VPC region closest to your data center.
However, if you are peering with your private AWS VPC, you need to create your Anypoint VPC in the same AWS region.
VPC CIDR block size
Determine the Classless Inter-Domain Routing (CIDR) block size and range for the VPC. The smallest network subnet block you can assign for Anypoint VPC is /24 (provides 256 IP addresses) and the largest /16 (provides 65,536 IP addresses). VPC cannot be resized once the VPC is configured and applications are deployed, so it’s important to size the VPC large enough to accommodate enough IPs for all services and instances (keeping in mind high availability and zero downtime). The address space reserved by MuleSoft workers should not conflict with address space in customer data centers if you want to connect it with your VPC.
When you create an Anypoint VPC, the range of IP addresses for the network must be specified in the form of a CIDR block, using CIDR notation.
To calculate the proper sizing for your Anypoint VPC, know that the number of dedicated IP addresses is not the same as the number of workers you have deployed.
For each worker deployed to CloudHub, the following IP assignment takes place:
- For better fault tolerance, the VPC subnet may be divided into up to four availability zones.
- A few IP addresses are reserved for infrastructure.
- At least two IP addresses per worker to perform at zero-downtime deployments.
Due to this structure, the smallest network subnet block you can assign for your Anypoint VPC is /24 and the largest /16.
It is a good practice to have different VPC for production and non-production environments. Depending on how many non-production environments you are configuring within the same VPC, consider how many APIs and their replicas you will deploy in each environment within the VPC, account for two IP addresses per worker to perform at zero-downtime deployments, this will help in deciding the size of the CIDR. The safe rule of thumb for deciding the size of your Anypoint VPC subnet is to calculate 10X the maximum number of expected apps to deploy per environment in the VPC.
Associating business group and environments to VPC
Place the VPC in Anypoint Organization in a business group within your main organization. Usually, create the VPC in your overarching organization and then it can be shared with different business groups.
As an organization administrator, you can create an Anypoint VPC and share it with any business group within your main organization.
However, once the Anypoint VPC is inherited by a business group, only the administrator of said business group can operate the Anypoint VPC. For example, an Anypoint Organization administrator or a business group owner can create or update an existing Anypoint VPC (owned or inherited) to make it the default for either the region, the environment, or both.
However, if such an association already exists, it’s overwritten by the requested Anypoint VPC.
If no business group association is specified, or if your organization does not have any business groups, the ownership of Anypoint VPC remains associated with the main organization. The organization under which the VPC is created is the VPC owner and this organization’s administrator is the only one who can share the Anypoint VPC.
Anypoint VPCs can only be shared vertically from the main organization to one of its business groups, or from a business group to one of its child business groups. You cannot share an Anypoint VPC created by a business group with another business group that is at the same level or higher in the hierarchy.
It is recommended that you create your Anypoint VPC in your main organization, and share it with the other business groups.
Optionally, select an environment to which to bind Anypoint VPC. If you don’t select an environment, all applications deployed to the selected region are associated with this Anypoint VPC. Don’t associate Anypoint VPC with a design environment. You can deploy apps to the design environment only from Design Center, not from Runtime Manager.
VPC firewall rules
Configure your own VPC firewall rules to allow specific IP ranges and ports to reach your workers. Before you implement firewall rules, or make changes to existing rules, you should fully understand all security implications.
By default, all traffic to your VPC is blocked unless it’s explicitly allowed in a firewall rule. When you create an Anypoint VPC, four firewall rules are created by default:
- Two rules to allow inbound connections from within your local Anypoint VPC through ports 8091 and 8092. These firewall rules allow traffic from within the Anypoint VPC to reach your workers through ports 8091 and 8092. These are the only ports used by your CloudHub-dedicated load balancer to proxy all external communications to your workers.
- Two rules to allow inbound connections from anywhere through ports 8081 and 8082. These rules allow traffic from any host to reach your workers through ports 8081 and 8082. These ports are used by CloudHub shared load balancer to proxy external requests to your workers. You can remove these rules if you don’t want your internal workers to be reached by the publicly accessible load balancer.
Firewall rules are inbound and use the following parameters:
- Type: Protocol type, for example, TCP
- Source: Source IP address
- Port Range: The only two ports exposed externally are 8081 (http.port) and 8082 (https.port). You can use this parameter to open additional ports inside the VPC.
Adding internal DNS and private domains to VPC
You can specify custom private domains by adding the IP address and domain name for your network. When you provide private domains, your worker resolves them using your private DNS, so you can still use the internal hostnames of your private network (make sure your applications call the backend resources by FQDN). Identify the applications that need static IPs, as one VPC provides only two static IPs.
Connecting your VPC to your data center
You can connect on-premises data centers through a secured VPN tunnel, or a private AWS VPC through VPC peering, or by using AWS Direct Connect.
- IPsec tunnel
You can use an IPsec tunnel with network-to-network configuration to connect your on-premises data centers to Anypoint VPC. An IPsec VPN tunnel is generally the recommended solution for VPC to on-premises connectivity, as it provides a standardized, secure way to connect. This method also integrates well with existing IT infrastructure, such as routers and appliances. To create an Anypoint VPN connection to your network, see Anypoint VPN.
- VPC peering
VPC peering provides a connection between two VPCs. In this case, it pairs your private Amazon VPC directly to your Anypoint VPC. This enables you to route traffic between the two VPCs so they can communicate as though they are in the same network. To use VPC Peering, your AWS and Anypoint VPCs must be located in the same region.
- Direct Connect
This method establishes a dedicated network connection from your on-premise data center using your Amazon account to your Anypoint VPC. This enables you to create a hosted virtual interface to attach to your Anypoint VPC. Establish Direct Connect connections to your AWS account or your partner’s AWS account and the Anypoint VPCs must be located in the same region. Direct Connect gateways are not supported. Direct Connect requires the use of the Border Gateway Protocol (BGP) for dynamic routing.
For high availability, use multiple Direct Connect connections from different AWS Direct Connect Locations.
Conclusion
I hope this helps you get started using VPCs in our cloud-based environments where IT teams can host applications to take advantage of various features. This includes using a dedicated load balancer, configuring firewall rules, and setting your private DNS server for internal network routing from a single, unified platform. For more information on VPCs, check out our documentation on Anypoint VPC.
