Deploying workloads within an established network boundary is fundamental to ensure workload isolation in cloud environments. The typical best practice has been to use distinct cloud accounts and VPCs/VNets to isolate the different types of workloads. While this approach works well and enables network segmentation, it has also led to IPv4 address exhaustion, especially in large enterprises where different teams and business units compete for the limited IPV4 address space. With the depletion of available IPv4 addresses, enterprises are now facing the challenge of efficiently allocating and managing their IP address space.
Customer Pain: IPv4 address space is running out
During a recent project, I worked with an enterprise customer who raised concerns about the depletion of their IPv4 address pool. To streamline their application deployment process and ensure faster time-to-market, they adopted a self-service model. As a part of this model, the teams could request the creation of VPCs/VNets with the desired number of IPv4 addresses, which would be allocated as long as address space was available. While this model gave them agility and enough flexibility, it also resulted in wasted IPv4 address space as teams would often end up requesting for more address space than required.
They mentioned that they are exploring various solutions to address this issue including the use of a Shared VPC model. The Shared VPC approach would allow their different teams to utilize a common VPC thus relatively reducing their IPv4 address consumption. However, this approach poses another challenge of establishing the network boundaries and controlling the traffic across the subnets of the Shared VPC. Considering, the different teams will be sharing the subnets from the same VPC, the customer wanted to ensure the isolation between the subnets owned by the different teams unless specified otherwise by a policy. And they sought guidance on how Prosimo can help architect around this problem.
Shared VPCs provide an appealing solution for conserving IPv4 address space in organizations. Nevertheless, the challenge lies in effectively isolating traffic between subnets owned by different teams. While cloud service providers offer basic methods such as Security Groups, Network ACLs, and Firewall Rules to restrict traffic, these solutions often lack flexibility, are complex to manage at scale and only work for certain use cases. This is where Prosimo comes into play, providing a solution to do effective micro-segmentation.
Micro-Segmentation – What and Why
In order to understand how Prosimo handles micro-segmentation, let us first discuss the platform components and a few other concepts.
Platform Components
Prosmo’s full-stack platform has three main architectural components.
- A SaaS-based control plane.
- A datapath component called Prosimo Edge is deployed in customers’ own cloud (AWS/Azure/GCP/Private) account
- Prosimo Connectors deployed, as an optional component, in the VPC or VNet to evaluate the policy and make the routing decisions
Flexible Network Object
Prosimo’s Network object is a flexible construct that represents your subnets/VPCs/VNets in the Prosimo fabric. A Prosimo network object could either consist of a single subnet from within a VPC or a VNet or a collection of subnets across VPCs or VNets.
How micro-segmentation works with Prosimo’s Full Stack platform
With this background, let us understand how Prosimo handles network micro-segmentation within a VPC or a VNet through an example. For the purposes of this blog, we will use the below architecture diagram. In the diagram, we have a Shared VPC with 2 subnets assigned to two different Business Units. These subnets could be either in the same AWS Account or across two different AWS Accounts.
Network Onboarding
- Onboard the BU01 Subnet as BU01 Network on the Prosimo dashboard
- Onboard the BU02 Subnet as BU02 Network on the Prosimo dashboard
- During the Network onboarding, you can choose any of the listed options (VPC Peering, Transit Gateway, Private Link, VPN) for connecting the Shared VPC to the Prosimo Edge VPC. Prosimo can ingest your existing chosen networking construct or orchestrate a new one based on your environment. In this case, we will choose an existing Transit Gateway to connect this Shared VPC to the Prosimo Edge VPC
- During the Network Onboarding, Prosimo will deploy connectors in the Shared VPC subnets for local policy evaluation. The connectors are automatically deployed in High Availability mode across Availability Zones. The connectors are also deployed behind the Gateway Load Balancer orchestrated by Prosimo and are in an autoscaling group to handle scaling requirements
- In addition to this, Prosimo will also update the Route Tables attached to the subnets to ensure that traffic between the subnets flows through the Prosimo Connectors
Policy Configuration
- Configure a policy (Allow or Deny) to control the traffic between the two subnets. In this example, we will use a Deny policy
- Prosimo’s policy configuration allows a much more granular control by allowing or restricting traffic on just certain ports and protocols
In summary, the Shared VPCs coupled with a practical micro-segmentation approach could really go a long way in helping enterprises better to manage the IPv4 address space in cloud environments.
