GCP – Design Cross-Cloud Network VPC Network Peering with NVAs and Regional Affinity

Inserting security into your network design may involve the use of a network virtual appliance (NVA). The flexibility of the Cross-Cloud Network to support these configurations means enterprises can extend existing security aspects from hybrid connections into the cloud for a consistent experience. In this blog we will look at a reference architecture for hub and spoke communication using NVA within a single region.

Regional affinity

Enterprises may have specific requirements around low latency, data residency, and resource optimization. Regional affinity keeps resources and networking traffic between services in the same region. The possible trade off is the lack of regional failover where traffic is re-routed to another region in the event of any failure. These considerations must be kept in mind while designing the setup based on your enterprise’s requirements. Review the Google Cloud regional deployment archetype document for more on regional deployments.

The Cross-Cloud Network

The Cross-Cloud Network provides you with a set of functionality and architectures that allows any-to-any connectivity. Google’s software-defined global backbone provides excellent capabilities to connect your distributed applications. Google has built its network with multi-shards, Protective ReRoute (PRR), and autonomous networking to support its global scale.

Design pattern example

To understand how to think about setting up your network for NVA with VPC Network Peering in a regional design, let’s look at the design pattern.

The network comprises an External network (on-prem and other clouds) and Google Cloud networks (Internet access VPC, routing VPC, services-access VPC, managed services VPC,  workload VPCs).

The traffic flow 

This design utilizes the following services to provide an end-to-end solution.

• Cloud Interconnect – (Direct, Partner, Cross-Cloud) To connect connect from your on-prem or other clouds to the Routing VPC

• HA VPN – To connect from services-access VPC to routing VPC and export custom routes from managed services network

• Internal Passthrough Network Load balancers – These frontend the NVAs.

• Network Virtual Appliances  – These are compute resources that perform a special function.

• Untagged policy-based route – Applies to all traffic 

• Skip policy-based route – Skips policy based routes and uses VPC routing

• VPC Network Peering –  To connect from workload VPC to Routing VPC

• Private services access – To connect to managed services privately in the services access VPC

• Private Service Connect – To expose services in the producer network to be consumed in the services access VPC

• Network Connectivity Center VPC spokes – To allow communication between workload VPC’s if necessary

The following diagram illustrates packet flows:

In the diagram, the orange line shows flows between the external network (on-prem and other clouds) and the Google Cloud services-access VPC network.

• The traffic flows over the Interconnect and follows routes learned from the external Cloud Router in the routing VPC.

• The routing VPC directly uses an untagged policy-based route to direct traffic to the Internal Passthrough NLB. Traffic is examined and the NVA uses a skip policy-based route on exiting traffic

• Traffic follow the custom routes to the services-access VPC over the VPN connection

• The return traffic follows the same traffic flows toward the On-Premises over the Cloud Interconnect

In the diagram, the blue line shows flows between the external network (on-prem and other clouds) and the Google Cloud workload VPC network 1.

• The traffic flows over the Interconnect and follows routes learned from the external Cloud Router in the routing VPC.

• The routing VPC directly uses an untagged policy-based route to direct traffic to the Internal Passthrough NLB. Traffic is examined and the NVA uses a skip policy-based route on exiting traffic.

• Traffic follows the subnet routes to the workload VPC network 1 over the VPC Network Peering connection.

• The return traffic follows the same traffic flows toward the On-Premises over the Cloud Interconnect

In the diagram, the pink line shows flows between Google Cloud workload VPC network 1 and the Google Cloud services-access VPC network.

• Traffic originating in the workload VPC network follows a policy-based route that is programmed to direct the flow to the internal Passthrough Network Load Balancer in front of the NVAs in the routing VPC network

• The traffic is examined and uses a skip policy-based route assigned on traffic leaving an NVA to skip the untagged policy-based route and follow VPC routing. 

• Traffic follows a dynamic route over from the HA VPN tunnels to the services-access VPC network.

• The return traffic follows the same flow back through the routing VPC and the NVAs toward the Workload VPC network.

To understand the all the specific details on traffic flow and considerations, read the VPC Network Peering Cross-Cloud Network with NVAs and regional affinity guide on the Google Cloud Architecture Center.

Next steps

Take a deeper dive into cross-cloud networking and read more on Network Security Integrations  and the Cross-Cloud Network.

• Network Security Integration overview

• Cross-Cloud Network for distributed applications 

Want to ask a question, find out more or share a thought? Please connect with me on Linkedin.