Themeshed pattern is based on establishing a hybrid network architecture.That architecture spans multiple computing environments. In these environments,all systems can communicate with one another and aren't limited to one-waycommunication based on the security requirements of your applications.This networking pattern applies primarily totiered hybrid,partitioned multicloud,orbursting architectures. It's also applicable tobusiness continuity design to provision a disaster recovery (DR) environment in Google Cloud. In allcases, it requires that you connect computing environments in a way that alignwith the following communication requirements:

• Workloads can communicate with one another across environmentboundaries using private RFC 1918 IP addresses.
• Communication can be initiated from either side. The specifics of thecommunications model can vary based on the applications and securityrequirements, such as the communication models discussed in the designoptions that follow.
• The firewall rules that you use must allow traffic between specific IPaddress sources and destinations based on the requirements of theapplication, or applications, for which the pattern is designed. Ideally,you can use a multi-layered security approach to restrict traffic flows ina fine-grained fashion, both between and within computing environments.

Architecture

The following diagram illustrates a high level reference architecture of themeshed pattern.

• All environments should use an overlap-free RFC 1918 IP address space.
• On the Google Cloud side, you can deploy workloads intoa singleor multiple shared VPCs or non-shared VPCs. For other possible designoptions of this pattern, refer to the design variations that follow. Theselected structure of your VPCs should align with the projects andresources hierarchy design of your organization.
• The VPC network of Google Cloud extends to othercomputingenvironments. Those environments can be on-premises or in another cloud.Use one of thehybrid and multicloud networking connectivity options that meet your business and application requirements.

• Limit communications to only the allowed IP addresses of your sourcesand destinations. Use any of the following capabilities, or a combinationof them:

  • Firewall rules orfirewall policies.

  • Network virtual appliance (NVA) with next generation firewall(NGFW) inspection capabilities, placed in the network path.

  • Cloud Next Generation Firewall Enterprise with intrusion prevention service (IPS) to implement deep packetinspection for threat prevention without changing the network design orrouting.

Variations

Themeshed architecture pattern can be combined with other approaches to meetdifferent design requirements, while still considering the communicationrequirements of the pattern. The pattern options are described in the following sections:

• One VPC per environment
• Use a centralized application layer firewall
• Microservices zero trust distributed architecture

One VPC per environment

The common reasons to consider the one-VPC-per-environment option are asfollows:

• The cloud environment requires network-level separation of the VPCnetworks and resources, in alignment with your organization'sresource hierarchy design.If administrative domain separation is required, it can also be combinedwith a separate project per environment.
  • To centrally manage network resources in a common network andprovide network isolation between the different environments, use ashared VPC for each environment that you have in Google Cloud, such as development, testing, andproduction.
• Scale requirements that might need to go beyond theVPC quotas for a single VPC or project.

As illustrated in the following diagram, the one-VPC-per-environment design letseach VPC integrate directly with the on-premises environment or other cloudenvironments using VPNs, or a Cloud Interconnect with multipleVLAN attachments.

The pattern displayed in the preceding diagram can be applied on a landing zonehub-and-spoke network topology.In that topology, a single (or multiple) hybrid connection can be shared withall spoke VPCs. It's shared by using a transit VPC to terminate both the hybridconnectivity and the other spoke VPCs. You can also expand this design by addingNVA with next-generation firewall (NGFW) inspection capabilities at the transitVPC, as described in the next section, "Use a centralized application layerfirewall."

Use a centralized application layer firewall

If your technical requirements mandate considering application layer (Layer 7)and deep packet inspection with advanced firewalling capabilities that exceedthe capabilities of Cloud Next Generation Firewall, you can use an NGFW appliance hosted inan NVA. However, that NVA must meet the security needs of your organization. Toimplement these mechanisms, you can extend the topology to pass allcross-environment traffic through a centralized NVA firewall, as shown in thefollowing diagram.

You can apply the pattern in the following diagram on the landing zone design byusing ahub-and-spoke topology with centralized appliances:

As shown in the preceding diagram, The NVA acts as the perimeter security layerand serves as the foundation for enabling inline traffic inspection. It alsoenforces strict access control policies. To inspect both east-west andnorth-south traffic flows, the design of a centralized NVA might includemultiple segments with different levels of security access controls.

Microservices zero trust distributed architecture

When containerized applications are used, the microservices zero trustdistributed architecture discussed in themirrored pattern section is also applicable to this architecture pattern.

The key difference between this pattern and the mirrored pattern is that the communication model betweenworkloads in Google Cloud and other environments can be initiated fromeither side. Traffic must be controlled and fine-grained, based on theapplication requirements and security requirements usingCloud Service Mesh.

Meshed pattern best practices

• Before you do anything else, decide on yourresource hierarchy design,and the design required to support any project and VPC. Doing so can helpyou select the optimal networking architecture that aligns with thestructure of your Google Cloud projects.
• Use azero trust distributed architecture when using Kubernetes within your private computing environment andGoogle Cloud.
• When you use centralized NVAs in your design, you should define multiplesegments with different levels of security access controls and trafficinspection policies. Base these controls and policies on the securityrequirements of your applications.
• When designing a solution that includes NVAs, it's important to considerthe high availability (HA) of the NVAs to avoid a single point of failurethat could block all communication. Follow the HA and redundancy design andimplementation guidance provided by theGoogle Cloud security vendor that supplies your NVAs.
• To provide increased privacy, data integrity, and a controlledcommunication model, expose applications through APIs using API gateways,likeApigee andApigee hybrid with end-to-end mTLS. You can also use asharedVPC with Apigee in the sameorganization resource.
• If the design of your solution requires exposing a Google Cloudbased application to the public internet, consider the designrecommendations discussed inNetworking for internet-facing application delivery.
• To help protect Google Cloud services in your projects, and tohelp mitigate the risk of data exfiltration, use VPC Service Controls tospecify service perimeters at the project or VPC network level. Also, youcanextend service perimeterstoa hybrid environment over an authorized VPN or Cloud Interconnect.For more information about the benefits of service perimeters, seeOverview of VPC Service Controls.
• Review thegeneral best practices for hybrid and multicloud networking patterns.

If you intend to enforce stricter isolation and more fine-grained accessbetween your applications hosted in Google Cloud, and in otherenvironments, consider using one of thegated patterns that are discussed in the other documents in this series.