VPC Peering

Introduction

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.

Use case

A shared resource VPC with satellite VPC's

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.

Once the peering request has been accepted a route is added to the route table of the requesting VPC and the accepting VPC which points towards the cidr block of the peer. And if there is no restrictive access list in place traffic is possible between the requesting VPC and the accepting VPC. 

A band of VPC's

Let's say you run a high traffic high risk app and need to guarantee a maximum availability. 

Requirements

Limits

• VPC peering connections are not possible between VPC's with matching or overlapping VPC CIDR blocks
• VPC peering connections are not transitive in the sense that VPC's will not automatically gain access to a 3rd VPC via a VPC that is peered with that 3rd VPC.
• VPC peering connections are only possible within a CloudStack region
• There is a maximum amount of pending VPC peering requests per VPC
• There is a maximum amount of active VPC peering connections
• There is an expiry time on the pending VPC peering requests

Procesflow

Domain model

Authorization

Implementation

• UI

• API
• Datamodel
• Marvin / Cloudmonkey

Network providers

• VMWare NSX
• OVS
• Physical (VLAN based)

Tests