One of the first tasks to set up your AnyPoint Platform is the definition of your network architecture and in particular your virtual private cloud (VPC). Creating a VPC is a pretty straightforward process that can be done in a couple of minutes, you just need to provide the values for 4 parameters:
- Region
- CIDR block
- Environments
- Business groups
However, it is extremely important to understand these parameters and the implications of them in your network architecture, as not doing it properly can have a huge impact on the deployment of your apps. And sometimes, the first thing to understand is whether or not we need a VPC and why. During this series of blog posts we’ll cover all you need to know before creating your mule VPC.What is a Mule VPC?
Applications on CloudHub are run by one or more instances of Mule, what we call workers. Behind the scenes, each worker is a virtual machine (an AWS EC2 instance) that contains an OS, the Java virtual machine, the Mule Runtime, and your application.When no VPC has been created, these workers are deployed to a Global Worker Cloud, which is the public segment of the CloudHub network that corresponds to your subscription. Cloudhub will provide you with two DNS records for your app:
- <your-application>.region.cloudhub.io to access your application through the Shared Load Balancer
- mule-worker-<your-application>.region.cloudhub.io to access the worker directly
A VPC in Anypoint is a virtual, private, and isolated network segment that we can create within the MuleSoft infrastructure to host our CloudHub workers. Each Mule VPC:- Will get a dedicated range of private IP addresses for our workers.
- Will have its own firewall to secure access to the workers within it.
- Will span across all the availability zones of the AWS region where the VPC is created.
That sounds great but, why would I need all of that?Do I need a VPC?
Anypoint Platform comes with two VPCs, but this doesn’t mean the VPCs must be created to deploy your apps. As we mentioned earlier, a simple app can be published to the Global Workers Cloud to be called by public consumers. Let’s see, more specifically, what are the most common requirements for a VPC.Connectivity to your data center:
The apps that we'll deploy to CloudHub are integration apps or APIs, so in many cases these apps require access to private resources or backend systems hosted in your data center, either on-prem or in your cloud provider. To secure the access to your datacenter you can use any of the supported connectivity methods for CloudHub:- IPSec VPN
- AWS VPC peering
- AWS Direct Connect
Isolation:
When we connect your VPC to your data center, the VPC becomes part of your network, it becomes another segment of your network and as such you need to secure it, controlling the access to the VPC. That's what we do with a VPC firewall.There are many reasons to do that. Some examples:
- In some cases, the apps you'll deploy to your VPC might not be public. In that case, you need to prevent your applications in that VPC from being publicly accessible.
- In other cases, you'll have different types of traffic in your apps. For example it’s a good practice to isolate all the traffic between production and non production environments, so that non-production applications or systems cannot get access to any data in production.
- Another example could be differentiating traffic between business units in the same organization. For all these cases we can use Business Groups and create your VPC as a resource only available in that Business Group.
Custom domain for your apps:
As we’ve seen earlier, when you deploy an app in CloudHub, the DNS name of the app will be of the form application-name.region.cloudhub.io. However ,if you needed to publish your applications under a custom domain name, you'd need to use a dedicated load balancer, which is a CloudHub resource that needs to be deployed within a VPC.Custom certificates:
If you use a custom domain name for your public APIs it’s very likely you’ll want to provide a certificate for that domain name and enable HTTPS traffic. That’s another case for which we need a DLB and therefore a VPC.Mutual TLS:
Another use case to have a dedicated load balancer: when you need mutual authentication using certificates for your APIs. Some examples are Salesforce or Heroku Postgres databases.
Load balancer rate limits:
The shared load balancer is a shared resource for all customers. When the incoming traffic to your apps is quite high you might get errors as you probably are hitting the rate limit in that SLB. A dedicated load balancer is a resource that will be part of your VPC, and as such, it won’t be shared with other users. In addition, the DLB can be escalated so you can adapt your load balancer to accept your high volume of traffic.With this summary, we’ve covered most of the use cases in which we require a VPC to host our mule apps. But there can be more, I’m sure of that. Do you have one? Nevertheless, and this is my personal opinion, I’d always start by creating a VPC for my Mule apps, even though there was no initial requirement for that. It’s very likely that sooner or later we’ve come across any of the different requirements we’ve just been through, for instance, the need for connectivity to your data center. Having your VPC in place will save you from having to move them in the future.