Understanding Prosimo Multi-Cloud Network Foundation
From a Cloud Network Engineer Point of View
Introduction
At Prosimo, we always find ways to help our customers looking to build a consistent cloud networking foundation for connecting their workloads, networks, and VPCs/VNETs across regions and clouds in the most simplistic and scalable way. Coming from a Cloud Networking and DevOps background, I know that we always look for ways to find a solution that not only addresses the use cases and immediate pain my organization is trying to address but also gets things working in semi-prod or staging environment to show the value the platform can bring. Considering all the angles, especially for our fraternity of Cloud networking architects, we are very excited with our recent announcement about Prosimo Multi-Cloud Networking (MCNF) Foundation, a completely free platform tier aimed at aiding businesses tackle connectivity difficulties within and across the clouds without the hassle.
First, let’s identify the primary issue propelling the demand for MCN solutions in the market. Both the network and cloud platform teams within organizations need to stay abreast with the needs of their application, DevOps, and security teams, who are searching for flexible solutions to connect, protect, and observe their applications, developed internally or consumed as-a-service from Cloud Service Providers. These actions need to be performed regardless of the hosting location or method for the apps: they could be on any cloud platform (AWS, Azure, GCP, OCI, Alicloud, Datacenter), use any hosting model (IaaS, PaaS, SaaS, VM-based, K8s, etc.), or employ any access method depending on the use case (Public, Private, Business Partner apps, IP ranges). Simultaneously, these teams must balance these requirements while keeping cloud costs and operational complexities under control. Now the question is, how do you facilitate the app/DevOps teams to utilize the cloud efficiently without dealing with all the hassles of setting up the Layer 3 connectivity and segmentation across VPC/VNET and network boundaries, route table management, and day-n operational overhead?
The Goal
The answer lies in Prosimo MCN Foundation. This solution is designed to provide you with a hassle-free experience, enabling your teams to utilize the cloud efficiently while eliminating the tedious setup and management tasks.
In this blog, we will cover how you can best utilize the Prosimo MCN Foundation offering to easily discover and onboard your cloud networks, orchestrate connectivity using cloud-native constructs, segmentation, and IaC to help with automation and, most importantly, visibility and troubleshooting to identify and resolve issues quickly. The primary goal is to help you understand and appreciate the free Prosimo Multi-Cloud Networking (MCN) solution. By the end of your reading journey, our aim is for you to be motivated to experiment with building your own ‘cloud-native Cloud Network’ using MCN.
As you engage with the content, you’ll gain insights into operating within a cloud-native framework. We want you to feel confident in taking those initial steps and experiencing the benefits firsthand.
By exploring the topics covered, you’ll be empowered to experiment and create your Cloud Network. The core message is simple: Prosimo is here to simplify your cloud networking experience. From testing to implementation, you’ll discover how Prosimo can seamlessly fit into your MCN needs.
Our ultimate mission is to help you realize the value of Prosimo MCN through hands-on experience. So, let’s dive into the world of cloud networking with a focus on learning and application.
MCN Foundation's Deployment Use Cases
There are five key use cases that can be achieved through an MCN solution. In the following sections, we will explore how Prosimo effectively addresses these use cases using the MCN Foundation offering.
Use Case 1:
Build Multi-Cloud Transit for brown and greenfield deployments
Use Prosimo Visual Transit Builder to Discover and Build the Network Foundation for Multi-Cloud.
Cloud Service Providers (CSPs) offer a wide range of networking constructs and tools to facilitate the creation of Layer 3 underlay connectivity across VPCs/VNets. However, constructing a global cloud underlay network using these constructs remains a complex and challenging task due to the following reasons:
- Diverse Networking Constructs: Each CSP has its own unique set of networking constructs, making it necessary to have a comprehensive understanding of each construct and how they interact with one another when building a global cloud underlay network.
- Manual Configuration: Cloud administrators are required to access each CSP’s cloud console and navigate through multiple steps and tabs to attach a single VPC or VNet. This time-consuming and repetitive process must be repeated for each region and VPC/VNet that needs to be connected. Similarly, removing a VPC/VNet from the global underlay network involves following the same multi-step process.
Once you’ve signed up for the MCN Foundation account and provisioned Prosimo, the initial step is to link your cloud subscription to the Prosimo Dashboard. To do this, you’ll be connecting VPCs/VNets along with their respective subnets. This process is made easy and efficient through Prosimo’s cloud-native approach.
Using Prosimo’s Visual Transit feature, you can establish cloud underlay networks in a straightforward manner. This involves utilizing familiar cloud-native networking tools like AWS Transit Gateway (TGW), Azure Virtual WAN, and VPC/VNet Peering. All you need to do is choose your cloud provider and the specific region, and you can effortlessly connect VPCs/VNets, creating the desired cloud underlay structure for your connectivity needs. This entire setup can be accomplished within minutes, streamlining the process and reducing complexity.
Prosimo Visual Transit - Key Benefits
Here are the key benefits of Prosimo’s Visual Transit feature:
- Consistent Network Architecture: With Prosimo, you can build a consistent network architecture across different regions and cloud platforms. This ensures a unified and standardized approach to your network design, making it easier to manage and maintain.
- Zero Complexity: Prosimo eliminates the complexity associated with configuring and managing underlay networks. While using native networking constructs from each cloud provider, Prosimo abstracts the underlying details and presents a user-friendly interface.
- Unified Control Plane: Unlike other methods that require navigating through multiple consoles and tabs, Prosimo provides a single unified control plane. This means you can efficiently build attachments and peerings for your cloud underlay, spanning multiple regions and clouds, all within one intuitive interface.
By offering these features, Prosimo’s Visual Transit ensures seamless connectivity across cloud platforms, simplifies network management, and enables you to create a robust cloud underlay that meets your specific needs. With Visual Transit, you can build the transit in brownfield or greenfield scenarios and keep the deployment set ready with your desired changes without making actual modifications to production configs during peak hours. Once the config changes have been approved using Deployment Audit details, you can schedule the deployment in the change management window to minimize interruption to production traffic.
Use Case 2:
Discover and onboard Cloud Resources at scale (VPC/VNets and Subnets)
Use a Simple Click-through Guide to onboard your Networks
Building Layer 3 connectivity between VPCs/VNets across accounts and CSPs can be a complex and time-consuming process. Cloud admins often find themselves navigating through multiple steps and tabs across different CSP and MCN platform consoles. Additionally, they need privileged access to each CSP account where the relevant VPC/VNets are deployed. This repetitive task adds to the complexity and inefficiency of the process.
With Prosimo’s Discovery-led capability, you can effortlessly onboard your VPCs/VNets and subnets to Prosimo Transit. Once you’ve selected the desired cloud account, Prosimo takes care of automatically discovering all the VPCs/VNets and associated subnets across different regions. Once the discovery is launched, you can choose the specific subnets/VPCs/VNets you wish to onboard. Based on the selection, Prosimo will automatically populate the essential details required for the successful onboarding of the selected networks. As part of this process, Prosimo also ensures that the VPC/VNets/TGW/Virtual WAN Hub Route Tables are updated with the appropriate routes to enable routing between the onboarded networks. For example, in the below architecture, we will use Prosimo’s discovery-led onboarding to seamlessly onboard these networks and build connectivity between the AWS VPC 1 and Azure VNet
Diagram 1 – (Multi-cloud Topology)
The following picture shows the discovery-led network onboarding process for AWS VPC1. With a simple click-through process, Prosimo discovers the VPC that you want to onboard to the Prosimo fabric and, during the process, also configures and updates the Route Tables.
Diagram 2 (Discovery-led Network Onboarding)
Use Case 3:
Network Segmentation and Policy Control
Network Object and Network Groups
When designing an enterprise architecture, network segmentation plays a vital role in maintaining a secure and organized environment. In the cloud, it is typically achieved by segregating cloud workloads in different subnets/VPCs/VNets across various CSP accounts. While the aforementioned approach offers numerous advantages, it also presents certain limitations and operational challenges. For instance, consider a production environment that is distributed across multiple VPCs/VNets and encompasses multiple regions and cloud accounts. In the scenario where you need to enforce a security policy within your production environment, it becomes cumbersome to apply the policy consistently across these subnets/VPCs/VNets, regions, and cloud accounts.
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. You can use this flexible network object to represent your various environments.
For example, production workloads spread across 10 VPCs in a given region in AWS can be represented by a single Network object called Network1 in Prosimo. Once Network1 is onboarded, you can assign a policy to this single network object instead of applying it to 10 different VPCs that are part of it. For example, you can apply a simple 5-tuple policy to Network1 that will automatically direct all the traffic to/from Network1 to the target Networks in the same or different cloud (optionally through your firewalls. In addition to that, you can also group the various network objects into network groups and directly apply policy to these network groups. This greatly simplifies the process of applying consistent policies across various environments, cloud regions, and accounts.
Example of Network1 object with multiple Subnets in it selected from a VPC
Use Case 3a:
Network Policy Control
Use Network authorization policies to segment traffic between subnets within and across the Cloud
One of the common challenges organizations face is applying consistent segmentation policies that span a variety of logical abstractions (AWS Accounts, Azure Subscriptions, VPC’s, VNets, etc.). Prosimo greatly simplifies this process by allowing users to apply stateful firewall rules that enforce user-defined boundaries without the need to mix and match disparate components that are unique to the individual clouds.
Let’s explore a few ways to build these policies for your cloud network segments.
- Source/Target Mapping
- Network ACL
- Combination rules
Option 1: Source/Target Mapping
The easiest way to build policy is to specify source/target networks. In this way, only the source networks are allowed to initiate traffic, but responses from the target network are allowed. Imagine I have a network in AWS that needs to connect to a network in Azure. I could specify the AWS networks as the “Source Networks” in the policy “Match Conditions”, and then add the Azure networks as the target in the “Select Targets” section.
Using this approach, you could define a 1:1 policy for every network you onboard into Prosimo.
Source/Target Shared Lifecycle
PROS
- Simplified view for seeing which networks communicate as a whole
- Easy to align to a deployment stage (prod, dev, etc.)
CONS
- Requires extra policy for connections outside of shared policy
- Individual policy definition can become large
Option 2: Network ACL
Using Network ACL’s (5-Tuple) as a way to segment network traffic is a more advanced approach that allows for allow/deny to be done at individual port, protocol, and source/destination network or endpoint. Let’s say we want to allow traffic between 2 endpoints (10.0.1.10 and 10.0.2.10) in 2 different subnets (10.0.1.0/24 and 10.0.2.0/24) that are part of the same network (10.0.0.0/20). Using a Network ACL, we could write a rule to allow source IP: 10.0.1.10 and 10.0.2.10 on any source port, to any target port, using any protocol, to destination IP 10.0.1.10 and 10.0.2.10. We would then add the network as the target in the policy rule.
If this was the only policy attached to that network, then only those 2 endpoints would be able to communicate. You could further restrict by adding ports and protocols to the same rule set.
Network ACL
PROS
- Very granular control
- Well-known approach to segmenting traffic
CONS
- Harder to use for those not familiar with networking
- Can become complicated quickly
- Harder to understand what can talk to what by looking at policy
Option 3: Combination Rules
You can combine source/target mapping and Network ACL’s in the same or separate policy rule sets. Both approaches have strengths and weaknesses, but combining the 2 can yield powerful results.
Let’s say we have created a policy for source/target mapping allowing the BU01 network to access Database-Network-1. Although this works, our infosec team wants to ensure only certain ports can be accessed from BU01’s network. Since this network is used to support various databases, and we have been told MSSQL, MySQL, PostgreSQL, Oracle, and MongoDB are all supported, we will simply add the database ports to this existing source/target policy by adding a Network ACL match condition. The final policy would look like this: Allow BU01 network access to Database-Network-1 only on TCP ports 1433 (MSSQL), 1521 (Oracle), 3306 (MySQL), 5432 (PostgreSQL), and 27017 (MongoDB). Now the only access allowed from BU01 to Database-Network-1 is traffic to those databases. All other communication would be blocked in the Prosimo overlay network. Additionally, since this is a source/target mapping, only BU01 can initiate traffic.
Combination Rules:
PROS
- Allows simplified access with more granular control when required
- Easy to allow only a subset of traffic types (port/protocol/etc)
CONS
- Could end up with many policies that are very similar
Use Case 4:
Visibility and Troubleshooting
Cloud network engineers face a multitude of challenges related to network visibility and troubleshooting in the cloud. As an example, let’s say you are working in a hybrid cloud environment that combines services from two different cloud providers, along with an on-premise data center. This makes the network landscape a little complex, and understanding the interactions between these various components can be a huge challenge. At some point, users start experiencing intermittent connectivity issues with a key application hosted on one of the cloud platforms. Now, you need to troubleshoot this issue, but due to the nature of cloud services, you don’t have direct control or visibility over the underlying network infrastructure. The usual network analysis tools they would use in an on-premise setup can’t be used. Meanwhile, to get the level of detailed, real-time network visibility needed to diagnose the problem, you may have to use additional cloud services, such as logging or monitoring tools. However, these tools generate large volumes of data, which can be costly in a cloud environment where storage and data processing are metered.
Addressing these challenges often requires a combination of effective tools, well-defined processes, and deep knowledge of both networking and the specific cloud environment in use and to mitigate these challenges, organizations often spend on advanced network monitoring tools designed for the cloud, investing in AI and machine learning to automate and enhance observability and implementing best practices for cloud network management which itself becomes a very cost-heavy initiative.
Prosimo’s unique ability to sit in the datapath of all traffic enables you to get rich visibility at all layers (L4-7) depending on the endpoint, which includes hop-by-hop flow analysis and latency/performance metrics. With Transit 360, you can map your network architecture with operational visibility for each segment and cloud-native constructs. Troubleshooting tools like Cloud Tracer provides a unified view of end-to-end tracing across region, clouds, and data center workloads.
Example of Cloud Tracer highlighting an issue for specific hop
Use Case 5:
IaC/Terraform and Orchestration of Cloud Native Constructs
As the type of work for infrastructure administrators and engineers changes, it is important to evolve with modern deployment practices. Infrastructure as Code (IaC) is a core component for managing cloud workloads. Distributed teams leveraging IaC tools for their deployments have been the norm for some time now, but networking has lagged behind due to complex interdependencies. Imagine a core network infrastructure team who deploys an AWS Transit Gateway, route tables, firewall, and security groups in a shared infrastructure account. Doing this all with an IaC tool like Terraform yields good repeatable results, but when it comes time to delegate access outward to dev teams and BUs, new challenges are introduced.
Take, for example, a scenario where 1 BU handles its own deployments for an application and leverages a shared transit gateway for access. In this scenario, those teams will need to coordinate in order to attach their networks to the transit. If things are not properly controlled even when granted approval, it still may not be possible due to conflicts with IP addressing or security. This is where using Prosimo as an overlay network supports more advanced and greatly simplified connectivity, especially when using Terraform.
Using the same example as above, but this time with Prosimo providing the SDN layer. Using the following Terraform code as an example, this same BU would simply provision as they normally would, only this time, there is nothing else required. As Prosimo handles all of the same and cross-cloud orchestration, individual teams can own their own networking while still integrating with the larger corporate network without requiring access to that network.
Let’s look at a sample Terraform deployment to onboard a network in AWS using a TGW to bring traffic to a set of Prosimo connectors running in an infrastructure VNet.
Here is a sample main.tf
And here is the matching variables.tf
In this deployment, we define the cloud region, the connectivity type, the VPC ID, the subnets inside the VPC we want to onboard, a policy for access, and a Prosimo Connector config that is shared among multiple networks, as noted by the “Infra VPC” designation.
At first glance, this may not seem too different from a Terraform file deploying natively into AWS, but it’s all of the back-end tasks that are handled here that make this extremely valuable. If I were defining a matching config with Terraform to create a VPC, TGW, and update security groups, it likely would appear similar, but that isn’t the end. What else does this network need to access? Which other route tables do I need to propagate? Are they in accounts to which I have access? What about other parts of the network like VNets in Azure, or VPCs in GCP, or even networks on-premises? What about crossing security boundaries? How much effort is needed to properly segment this new network, and how much can I do vs requiring other touchpoints from other teams?
All of this is easily solved when using Prosimo as the overlay since all of those other tasks are automated and orchestrated by the back-end fabric and SaaS control plane. To get started with the Prosimo Terraform Provider, you can learn more here: https://registry.terraform.io/providers/prosimo-io/prosimo/latest
MCN Foundation. Build fully cloud-native networking in less than 7 minutes.
Ready to start?
