Cross-Cloud Network for distributed applications

Last reviewed 2025-01-30 UTC

Cross-Cloud Network enables an architecture for the assembly ofdistributed applications. Cross-Cloud Network lets youdistribute workloads and services across multiple cloud and on-premisesnetworks. This solution provides application developers and operators theexperience of a single cloud across multiple clouds. This solution uses and alsoexpands theestablished uses of hybrid and multicloudnetworking.

This guide is intended for network architects and engineers who want to designand build distributed applications on Cross-Cloud Network. Thisguide provides you with a comprehensive understanding ofCross-Cloud Network design considerations.

This design guide is a series that includes the following documents:

The architecture supports regional and global application stacks, and it'sorganized in the following functional layers:

  • Network segmentation and connectivity: involves theVirtual Private Cloud (VPC) segmentation structure and IP connectivity acrossVPCs and to external networks.
  • Service networking: involves the deployment of application services,which are load balanced and made available across projects andorganizations.
  • Network security: enables the enforcement of security for intra-cloud andinter-cloud communications, using both built-in cloud security and networkvirtual appliances (NVAs).

Network segmentation and connectivity

Segmentation structure and connectivity is the foundation of the design. Thefollowing diagram shows a VPC segmentation structure, which youcan implement by using either a consolidated or segmented infrastructure. Thisdiagram doesn't show the connections between the networks.

VPC segmentation structure for Cross-Cloud Network design

This structure includes the following components:

  • Transit VPC: Handles external network connections androuting policies. This VPC can also provide connectivity between other VPCs.
  • Services access VPCs: Contain access points to different services. The service access points in these VPCs can be reached from other networks.
  • Managed services VPCs: Contain services produced byother entities. The services are made accessible to applications running inVPC networks by using Private Service Connect orprivate services access.
  • Application VPCs: Contain the workloads that make up thesoftware services that your organization creates and hosts itself.

Your choice of segmentation structure for the application VPCsdepends on the scale of application VPCs required, whether youplan to deploy perimeter firewalls in Cross-Cloud Network orexternally, and the choice of central or distributed service publication.

Cross-Cloud Network supports the deployment of regionalapplication stacks and global application stacks. Both of theseapplication resiliency archetypes are supported by the proposed segmentationstructure with the inter-VPC connectivity pattern.

You can achieve inter-VPC connectivity with Network Connectivity Center or by usinga combination of VPC Network Peering and HA VPN hub-and-spoke patterns.

The design of the DNS infrastructure is also defined in the context of thesegmentation structure, independent of the connectivity pattern.

Service networking

Different applicationdeploymentarchetypes lead to different patterns forservice networking. For Cross-Cloud Network design, focus ontheMulti-regional deploymentarchetype, in which anapplication stack runs independently in multiple zones across two or moreGoogle Cloud regions.

A multi-regional deployment archetype has the following features that are usefulfor Cross-Cloud Network design:

  • You can use DNS routing policies to route incoming traffic to the regionalload balancers.
  • The regional load balancers can then distribute the traffic to theapplication stack.
  • You can implement regional failover by re-anchoring the DNS mappings ofthe application stack with aDNS failover routingpolicy.

An alternative to the multi-regional deployment archetype would be theglobaldeployment archetype, in which asingle stack is built on global load balancers and spans multiple regions.Consider the following features of this archetype when working withCross-Cloud Network design:

  • The load balancers distribute traffic to the region that's nearest to theuser.
  • The internet-facing frontends are global, but the internal-facingfrontends are regional with global access, so you can reach them infailover scenarios.
  • You can use geolocation DNS routing policies and DNS health checks on theinternal service layers of the application stack.

How you provide access to managed published services depends on the service thatneeds to be reached. The different private reachability models are modularizedand orthogonal to the design of the application stack.

Depending on the service, you can use Private Service Connect orprivate services access for private access. You can build an applicationstack by combining built-in services and services published by otherorganizations. The service stacks can be regional or global to meet yourrequired level of resiliency and optimized access latency.

Network security

For workload security, we recommend that you usefirewallpolicies from Google Cloud.

If your organization requires additional advanced capabilities to meet securityor compliance requirements, you can incorporate perimeter security firewallsby inserting Next-Generation Firewall (NGFW) Network Virtual Appliances (NVAs).

You can insert NGFW NVAs in a single network interface (single-NIC mode) or overmultiple network interfaces (multi-NIC mode). The NGFW NVAs can support securityzones or Classless Inter-Domain Routing (CIDR)-based perimeter policies.Cross-Cloud Network deploys perimeter NGFW NVAs by using atransit VPC and VPC routing policies.

What's next

Contributors

Authors:

Other contributors:

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-01-30 UTC.