Deciding size of Anypoint VPC

Written by:
Published on November 22, 2019

Deciding size of Anypoint VPC

This is part two of the three blog series on Anypoint VPC. You can checkout other two blogs like What is Anypoint VPC(Virtual Private Cloud)? and Connecting Anypoint VPC to Customer On-Premise.

In this blog we will try to explore all the aspects around sizing of Anypoint VPC with relevant examples.

Why consider Sizing at all?

Sizing your VPC is the most crucial step in setting up a VPC. VPC creation is a one time process and once a VPC is created, its size cannot be modified. If there is a need to modify size of a VPC after it has been created, the only option is to create a new VPC with latest requirements and migrate everything from old to new(not something anyone would prefer). Therefore while creating a VPC, sizing should be done after due diligence.

What is Sizing of a VPC and What is CIDR Range?

VPC is at its very core, is a set of workers(servers) running in a closed(protected) environment. All these workers inside a VPC are uniquely identified by an IP address. Sizing a VPC in simple terms is deciding which and how many IPs should be there that will get allocated to workers.

To come up with this range of IPs, something called CIDR(Classless Inter Domain Routing) range is used. CIDR is a set of Internet protocol (IP) standards that is used to create unique identifiers for networks and individual devices. Getting into details of CIDR is out of scope for this blog but a simple example can help understand how it works.


  • Total number of IPs : 4
  • Starting IP:
  • Last IP:

We will understand the entire process with a detailed example later in this blog.

Approaching VPC Sizing

There are various factors to consider while sizing a VPC. Some of the crucial ones are:

Number of servers(workers) needed

The most critical factor in sizing a VPC is the number of applications that are supposed to run inside it. Since every application would run on one worker, the number of workers could be equal to the number of applications that are to run. Sounds simple? Well there are more things to consider. One needs to find answer to questions like:

  • What if there is a need to run one application on multiple worker for high availability?
  • How many extra workers will be needed to re-deploy an application to guarantee zero downtime.
Number of environments that will reside within the VPC

The parameter which should never be ignored is the last one. One VPC might be used for entire non-prod, in such cases there can be three environments within the VPC like Dev, Test and Stage. This would mean that the same application for which 2 workers were needed, will now take 6 workers(2 per environment).

Predicting the future

While its highly impossible to predict future precisely, but an estimated view of growth can be thought of in the IT world. Migration of VPC is not an easy task and it is a waste of resources and valuable time if the VPC runs out of space every six months. VPCs when created, should be sized by keeping in mind the future requirement of at least three years in the future to get real value out of such a big exercise.

Preferred Design

A lot of organizations do not want their production and non-production code to run side by side in the same environment. Usually there are two VPCs created, one for production and one for all non-production applications and environments. Organizations which have specific need might also create a VPC for every environment like Dev, Test, Stage and Prod.

Understanding by an Example

A CIDR range of for would mean that mask bits are 24 resulting in 256 IPs. Then the 256 IP addresses will range:

  • First
  • Last

Concept of CIDR calculation might look a bit complicated at first, but there are numerous websites which help calculate this range. What one has to look for while calculating this is how many IPs will be required by VPC.

Lets see how the IPs in a VPC are put to use. For example, lets assume there is a VPC created with a CIDR range of /24 which would mean there are 256 IPs available. Following is the IP distribution:

UsageNumber of IPs Left
One IP is reserved for network and one for broadcast(256-2)=254
Remaining IPs will be divided into 4 availability zone for HA(High Availability)(254/4)=63
Each application needs two workers for High availability when being redeployed(63/2)=31
Total Number of applications that can be deployed31

Which shows /24 subnet can have maximum of 31 applications. Not to forget the this number will be further divided when split into various environments like Dev, Test, Stage and Prod.

Ideal recommendation for any mid-large sized organization is /16 range which gives a total of 65536 IP addresses. With this recommendation it can be thought of that having 65536 IPs would shoot the cost up high, but its noteworthy to know that MuleSoft will only charge an organization for the active workers running in production and not for the ones not in use.

Wrapping it up!

Since VPC creation is a one time process that takes huge amount of effort to redo, thought process should be to do it right in the very first attempt. Sizing the VPC plays a major role in getting things right when it comes to VPC.

Thanks for reading! And we would love to hear your suggestions and comments!

One Reply to “Deciding size of Anypoint VPC”

Leave a Reply

Your email address will not be published. Required fields are marked *

Other Blog Posts

Other Blog Posts

MuleSoft Meet up at Reading (Virtual)

A Virtual meetup was organized by Integral Zone on 30th September, 2021. The meet up was attended by a number of participants across the globe. There were two keynote speakers who spoke on two different topics: Building asynchronous REST APIs at scale. By Kalidass M, Director of Engineering at Integral Zone Why automated code quality …

Read more

Mulesoft Development Fundamentals: Dataweave Best Practices

‘MuleSoft development fundamentals’ is a blog series that takes you through various aspects of MuleSoft development from “How to structure your Mule code” to “Things to cater to when you deploy to production”. We would love to share our expertise with the Community, having worked with several MuleSoft Enterprise clients. Please find all the blogs …

Read more

IZ Analyzer – Scanning API Projects

In an API and microservices world, the quality of the deliverable becomes paramount – since a weak link can break the whole chain. In the previous blog posts, we had seen how Mulesoft code implementations could be quality tested in an automated manner with IZ Analyzer. Now with API Analyzer plugin, APIs can be quality …

Read more