VPCs (VMNet on Azure) are the core components of cloud networking within public cloud. A VPC is a completely isolated network (comprised of sub-networks) from other cloud tenants and even other VPCs within the same account. Connecting VPCs together is a core component of cloud networking and can be done through VPC Peering, Cloud VPN, or private mpls connections.
However, there are a couple of terms to be aware of when discussing VPCs and networking in the cloud. Regions are a grouping of data centers within a similar geographical region. Zones or availability zones are a specific data center within a region.
VPCs (Azure VMNets) on AWS and Azure cannot span multiple regions and subnets cannot span multiple zones. However, in GCP a VPC is global meaning that it can span multiple geographical areas. Additionally, subnets in GCP can span multiple zones within a region but cannot span multiple regions.
This allows for global infrastructure to be deployed without having to use VPC peering to allow connectivity between regions reducing the complexity of the network configuration.
Connectivity between different VPCs and on-prem resources can be accomplished in a variety of ways. VPC peering can be used to connect two VPCs between each other that exist within the same or different cloud account.
VPC peering essentially creates a private high bandwidth connection between VPCs leveraging the CSPs backbone network. Additionally, network bandwidth charges will be lesser since the VPC peer traffic will not count as internet bandwidth. However, there are some limitations to be aware of when using VPC peering.
- Transitive VPC traffic is not allowed (cannot use hub and spoke topology).
- The subnets within the two peered VPCs cannot overlap.
- All networks in a VPC will be propagated to the other VPCs route tables and VPC local subnets cannot be filtered. Firewall rules must be used to restrict access.
All Cloud Providers provide a Cloud VPN service that can be used to connect on-prem and other cloud environments to an existing VPC. Cloud VPN is a standard IPsec lan-to-lan vpn implementation similar to vpns that would be configured on on-prem firewalls and wan routers. These VPNs can be configured a route-based or policy-based.
However, route-based is the recommended approach because policy-based VPNs with multiple active proxy-ids (multiple subnets) can result in an unstable connections. The route-based option allows you to simply route subnets to a virtual tunnel interface next-hop but only uses one pair of proxy-ids (0.0.0.0/0 for both ends).
Cloud VPN can also be used to connect multiple VPNs together to circumvent limitations of VPC peering such as creating a transitive VPC. BGP can be used with Cloud VPN to exchange routes and for redundancy. Using BGP for route exchange is highly recommended over static routes. Static routing are an alternative but require manual changes to failover vpn endpoints.
Instance Based VPN
Additionally, IPsec VPNs can also be terminated on compute instances. This might be required if a dynamic vpn technology such as DMVPN is leveraged. The major CSPs support the use of firewall and router virtual appliances. Examples of this would be Palo Alto virtual firewalls or Cisco Cloud Services routers (CSR). The VPC route tables must be modified to point to the terminating VPN instance similar to a static route implementation of Cloud VPN.
Private MPLS Connection
Another more reliable method for connecting on-prem and cloud environments is to use a dedicated private connection. Each major CSP has it’s own product name for this configuration on their platform, (GCP Cloud Interconnect, AWS DirectConnect, Azure ExpressRoute) but they essentially operate the same.
They are typically MPLS circuits. The customer will need to place a router to terminate their end of the connection in the CSPs point of presence. Then the CSP and the cloud customer will validate peering configurations after connectivity has been physically established.
Some cloud server providers support a direct connection to the CSP or allow the connection to be facilitated through a service provider like AT&T or Level3.
To summarize, all major cloud providers implement networking using their own software overlay network with different limitations. Interconnecting VPCs can be very simple or complicated depending on the desired cloud networking topology.
VPC peering is recommended but a full mesh is required between VPCs. Finally, connecting on-prem to public cloud is no different that connecting on-prem to any other third party environment. It can be accomplished using IPsec site to site VPN tunnels terminated using the CSPs native VPN service or on an firewall/router instance within a VPC.
Private MPLS connections can also be used providing superior reliability and possibly improved bandwidth depending on the CIR (committed information rate) from the provider.
If you interested in more Public Cloud articles then click here!