A VPC is a virtual network where your CloudHub applications reside.
A VPN is a method of connecting a VPC to an external network, for example, to an on-premise datacenter.
VPCs do not provide connectivity to or from CloudHub by themselves. A connection must be configured in addition to the VPC. For example, a VPN could be implemented between a CloudHub VPC and your datacenter.
Please refer to About VPC Connectivity Methods for more information.
This depends on when you initially configure your VPC.
For new VPCs after November 2018, see Anypoint VPN
For VPCs before November 2018, see Request VPC Connectivity to Your Network. To request changes to this type of VPN, complete the VPC discovery form and attach it to a Support case.
Note: The SLA for changes to an existing VPN is 5 business days after the VPC discovery form has been completed, returned and reviewed by our engineers, though it may be completed sooner.
Each MuleSoft VPC supports up to 48 active peering connections.
A single VPC may also support multiple VPN connections (depending on the VPN capacity allocated to your account).
For example, you create a VPN to the first datacenter, another VPN to the second datacenter, and a peering connection to an AWS VPC.
Note: Each VPN connection requires a VPN licence. Each peering connection is included in the VPC license.
Each VPC is independent, so connections must be created on a per VPC basis. However, a Transit Gateway can be used to share Direct Connect, VPC Peering, and AWS Site-to-Site VPN connections.
The CIDR block assigned to a VPC should come from a private address space, and should not overlap with any ranges assigned to other VPCs, or your corporate network. By using a subnet that does not conflict with another area of the network, you can create a connection from multiple MuleSoft VPCs to the same on-premise network.
For new VPNs after November 2018, BGP is supported. Refer to Anypoint VPN for more information.
For VPNs before November 2018, BGP is not supported. If you wish to use BGP routing, please contact support to discuss the migration to Anypoint VPN.
On the MuleSoft side, VPN connections configured after November 2018 will be Route-Based.
There is no requirement for the remote endpoint to also be Route-Based. Refer to Anypoint VPN for more information.
For new VPNs after November 2018, HA is a configurable option. Refer to Anypoint VPN for more information.
For VPNs before November 2018, HA is not available. If you require HA connections, please contact support to discuss the migration to Anypoint VPN.
There are no hard bandwidth limits, but connectivity may be subject to constraints imposed by the underlying network.
This applies to both traffic to and from the Anypoint Platform.
Cloudhub doesn't support more than three name servers, but this shouldn't give you an issue. It's standard for a regular DNS implementation to contain only two or three DNS servers.
The remote name servers are expected to serve exactly the same zone information, in fact if they don't, it causes issues, so multiple nameservers really only exist to provide redundancy. If you have domain names that are needed to resolve through different name servers that are not configured on Cloudhub, the expected behaviour is to add the domain name to a nameservers that you own and redirect the queries to the authoritative nameservers that can offer a response.
MuleSoft's recommendation is for customers to run their own benchmarking. Results of benchmarking may vary from customer to customer, and from application to application, due to a wealth of variables, such as but not limited to:
Yes, you would need to create a VPC for the parent business group and a VPN tunnel for the parent business group. Both can be shared to the child business group. Please bear in mind that a VPC created at a business group level can only be shared with the immediate child business group, but not upwards to a parent business group or a business group that's two levels down from the business group where the VPC was created in.
001118963

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.