Currently connecting multiple VPC's together can basically be achieved by using inter VPC routing via PrivateGateways or via VPN tunnels.
The current method of enabling inter-VPC's routing connectivity between VPC's in CloudStack (4.6) is via a PrivateGateway and adding one or multiple static route(s). Creating a privategateway however is not available/permitted for domain admins or non-admin users by the API. This puts a burden on the root-admins to enable a PrivateGateway on VPC's that a user has created. Another aspect is that domain admins or non-admin users of subdomains in CloudStack do not always have the right information, such as gateway address, vlan, and ip, to use a create privategateway function even if users would be allowed to.
From a usability and efficiency perspective it also does not make sense to require cloud users to a) provide this information, and b) to have to enable a PrivateGateway and to add a static route on each VPC to be connected while a single request per connection to connect VPC X to Y and perhaps Z to X could suffice.
This design aims to propose a more functional, and for the user more simplified and efficient way of connecting multiple VPC's. The functionality would be called VPC Peering and would aim to provide a simple yet powerful interface for users to connect 2 or more VPC's to each other that effectively creates layer 3 reachability between VPC's over private ip space.
Imagine a VPC containing company wide shared resources such as a active directory, fileservers, or other supporting systems that are managed by department Office IT for instance. Now let's say you have a trading platform VPC which is managed by an IT sourcing provider and then there's a VPC which contains finance applications which is managed by yet another 3rd party and all VPC's live in the same zone.
The 2 VPC's: trading, and finance need to access services in the office IT VPC but should not be allowed to reach each other's services. The owners of the trading and finance VPC's can then create a VPC Peering request towards the office IT VPC. The owner of the office IT VPC can then choose to accept or reject the peering request.
Let's say you run a high traffic high risk app and need to guarantee maximum availability and you've built 3 VPC's each containing services that together form a geo cluster. Each VPC in this circle must be able to reach services in the other VPCs. In this example each VPC will have 2 VPC peering connections.
Marvin