When you design your landing zone, you must choose a network design that worksfor your organization. This document describes four common network designs, andhelps you choose the option that best meets your organization's requirements,and your organization's preference for centralized control or decentralizedcontrol. It's intended for network engineers, architects, and technicalpractitioners who are involved in creating the network design for yourorganization's landing zone.

This article is part of a series aboutlanding zones.

Choose your network design

The network design that you choose depends primarily on the followingfactors:

• Centralized or decentralized control: Depending on yourorganization's preferences, you must choose one of the following:
  • Centralize control over the network including IP addressing,routing, and firewalling between different workloads.
  • Give your teams greater autonomy in running their ownenvironments and building network elements within their environmentsthemselves.
• On-premises or hybrid cloud connectivity options: All the networkdesigns discussed in this document provide access from on-premises to cloudenvironments throughCloud VPN orCloud Interconnect. However,some designs require you to set up multiple connections in parallel, whileothers use the same connection for all workloads.
• Security requirements: Your organization might require trafficbetween different workloads in Google Cloud to pass throughcentralized network appliances such asnext generation firewalls (NGFW). This constraint influencesyour Virtual Private Cloud (VPC) network design.
• Scalability: Some designs might be better for your organization than others, basedon the number of workloads that you want to deploy, and the number ofvirtual machines (VMs), internal load balancers, and other resources thatthey will consume.

Decision points for network design

The following flowchart shows the decisions that you must make to choose thebest network design for your organization.

The preceding diagram guides you through the following questions:

1. Do you requireLayer 7 inspection using network appliances between different workloads inGoogle Cloud?
   • If yes, seeHub-and-spoke topology with centralized appliances.
   • If no, proceed to the next question.
2. Do many of your workloads require on-premises connectivity?
   • If yes, go to decision point 4.
   • If no, proceed to the next question.
3. Can your workloads communicate using private endpoints in a serviceproducer and consumer model?
   • If yes, seeExpose services in a consumer-producer model with Private Service Connect.
   • If no, proceed to the next question.
4. Do you want to administer firewalling and routing centrally?
   • If yes, seeShared VPC network for each environment.
   • If no, seeHub-and-spoke topology without appliances.

This chart is intended to help you make a decision, however, it can often bethe case that multiple designs might be suitable for your organization. In theseinstances, we recommend that you choose the design that fits best with your usecase.

Network design options

The following sections describe four common design options. We recommend option1 for most use cases. The other designs discussed in this section arealternatives that apply to specific organizational edge-case requirements.

The best fit for your use case might also be a network that combines elementsfrom multiple design options discussed in this section. For example, you can useShared VPC networks in hub-and-spoke topologies for better collaboration, centralizedcontrol, and to limit the number of VPC spokes. Or, you mightdesign most workloads in a Shared VPC topology but isolate a smallnumber of workloads in separate VPC networks that only exposeservices through a few defined endpoints usingPrivate Service Connect.

• The on-premises network is spread across two geographical locations.
• The on-premises network connects through redundantCloud Interconnect instances to two separate Shared VPCnetworks, one for production and one for development.
• The production and development environments are connected to bothCloud Interconnect instances with differentVLAN attachments.
• Each Shared VPC has service projects that host the workloads.
• Firewall rules are centrally administered in the host project.
• The development environment has the same VPC structure as theproduction environment.

By design, traffic from one environment cannot reach another environment.However, if specific workloads must communicate with each other, you can allowdata transfer through controlled channels on-premises, or you can share databetween applications with Google Cloud services likeCloud Storage orPub/Sub.We recommend that you avoid directly connecting separated environments throughVPC Network Peering, because it increases the risk of accidentally mixingdata between the environments. Using VPC Network Peering between largeenvironments also increases the risk of hittingVPC quotas around peering and peering groups.

For more information, see the following:

• Shared VPC overview
• Shared VPC architecture in the enterprise foundations guide
• Reference architecture in VPC design best practices
• Network stage for Terraform example foundation usingCloud Foundation toolkit

To implement this design option, seeCreate option 1: Shared VPC network for each environment.

Option 2: Hub-and-spoke topology with centralized appliances

This network design uses hub-and-spoke topology. A hub VPCnetwork contains a set of appliance VMs such as NGFWs that are connected to thespoke VPC networksthat contain the workloads. Traffic between the workloads, on-premises networks,or the internet is routed through appliance VMs for inspection and filtering.

Use this design when the following is true:

• You require Layer 7 inspection between different workloads or applications.
• You have a corporate mandate that specifies the security appliancevendor for all traffic.

Avoid this design when the following is true:

• You don't require Layer 7 inspection for most of your workloads.
• You want workloads on Google Cloud to not communicate at all witheach other.
• You only need Layer 7 inspection for traffic going to on-premisesnetworks.

The following diagram shows an example implementation of this pattern.

The preceding diagram shows the following:

• A production environment which includes a hub VPC network andmultiple spoke VPC networks that contain the workloads.
• The spoke VPC networks are connected with the hubVPC network by using VPC Network Peering.
• The hub VPC network has multiple instances of a virtualappliance in amanaged instance group. Traffic to the managed instance group goes throughan internal passthrough Network Load Balancer.
• The spoke VPC networks communicate with each other throughthe virtualappliances by using static routes with the internal load balancer as thenext hop.
• Cloud Interconnect connects the transit VPC networksto on-premises locations.
• On-premises networks are connected through the sameCloud Interconnects using separate VLAN attachments.
• The transit VPC networks are connected to a separate network interfaceon the virtual appliances, which lets you inspect and filter all traffic toand from these networks by using your appliance.
• The development environment has the same VPC structure as theproduction environment.
• This setup doesn't use source network address translation (SNAT). SNATisn't required because Google Cloud usessymmetric hashing. Formore information seeSymmetric hashing.

By design, traffic from one spoke network cannot reach another spoke network.However, if specific workloads must communicate with each other, you can set updirect peering between the spoke networks using VPC Network Peering, or youcan share data between applications with Google Cloud services likeCloud Storage or Pub/Sub.

To maintain low latency when the appliance communicates between workloads, theappliance must be in the sameregion as the workloads. If you use multipleregions in your cloud deployment, you can have one set of appliances and one hubVPC for each environment in each region. Alternatively, you can usenetwork tags with routes to have all instances communicate with the closest appliance.

Firewall rules can restrict the connectivity within the spoke VPC networks thatcontain workloads. Often, teams who administer the workloads also administerthese firewall rules. For central policies, you can usehierarchical firewall policies.If you require a central network team to have full control over firewall rules, consider centrallydeploying those rules in all VPC networks by using aGitOps approach.In this case, restrict the IAM permissions to only thoseadministrators who can change the firewall rules. Spoke VPCnetworks can also be Shared VPC networks if multiple teams deploy in thespokes.

In this design, we recommend that you use VPC Network Peering to connect thehub VPC network and spoke VPC networks because itadds minimum complexity.However, the maximum number of spokes is limited by the following:

• The limit onVPC Network Peering connectionsfroma single VPC network.
• Peering group limits such as the maximum number of forwarding rules forthe internal TCP/UDP Load Balancing for each peering group.

If you expect to reach these limits, you can connect the spoke networks throughCloud VPN. Using Cloud VPN adds extra cost and complexity andeach Cloud VPN tunnel has a bandwidth limit.

For more information, see the following:

• Hub and spoke transitivity architecture in the enterprise foundations guide
• Hub and spoke with Network Virtual Appliance (NVA) as part of theFabric FAST framework
• Terraform hub-and-spoke transitivity module as part of theexample foundation

To implement this design option, seeCreate option 2: Hub-and-spoke topology with centralized appliances.

Option 3: Hub-and-spoke topology without appliances

This network design also uses a hub-and-spoke topology, with a hubVPC network that connects to on-premises networks and spokeVPC networks that contain theworkloads. Because VPC Network Peering is non-transitive, spoke networkscannot communicate with each other directly.

Use this design when the following is true:

• You want workloads or environments in Google Cloud to notcommunicate with each other at all using internal IP addresses, but you dowant them to share on-premises connectivity.
• You want to give teams autonomy in managing their own firewall androuting rules.

Avoid this design when the following is true:

• You require Layer 7 inspection between workloads.
• You want to centrally manage routing and firewall rules.
• You require communications from on-premises services to managed servicesthat are connected to the spokes through another VPC Network Peering,because VPC Network Peering is non-transitive.

The following diagram shows an example implementation of this design.

The preceding diagram shows the following:

• A production environment which includes a hub VPC network andmultiple spoke VPC networks that contain the workloads.
• The spoke VPC networks are connected with the hubVPC network by using VPC Network Peering.
• Connectivity to on-premises locations passes throughCloud Interconnect connections in the hub VPCnetwork.
• On-premises networks are connected through theCloud Interconnect instances using separate VLAN attachments.
• The development environment has the same VPC structure as theproduction environment.

By design, traffic from one spoke network cannot reach another spoke network.However, if specific workloads must communicate with each other, you can set updirect peering between the spoke networks using VPC Network Peering, or youcan share data between applications with Google Cloud services likeCloud Storage or Pub/Sub.

This network design is often used in environments where teams act autonomouslyand there is no centralized control over firewall and routing rules. However,the scale of this design is limited by the following:

• The limit onVPC Network Peering connections from a single VPC network

• Peering group limits such as the maximum number of forwarding rules for theinternal passthrough Network Load Balancer for each peering group

Therefore, this design is not typically used in large organizations that havemany separate workloads on Google Cloud.

As a variation to the design, you can use Cloud VPN instead ofVPC Network Peering. Cloud VPN lets you increase the number ofspokes, but adds abandwidth limit for each tunnel and increases complexity and costs. When you usecustom advertised routes,Cloud VPN also allows for transitivity between the spokes withoutrequiring you to directly connect all the spoke networks.

For more information, see the following:

• Hub-and-spoke network architecture
• Hub-and-spoke architecture in the enterprise foundations guide
• Hub and spoke with VPC Peerings as part of theFabric FAST framework
• NCC Hub and spoke as part ofFabric FAST framework

To implement this design option, seeCreate option 3: Hub-and-spoke topology without appliances.

Option 4: Expose services in a consumer-producer model with Private Service Connect

In this network design, each team or workload gets their own VPCnetwork, which can also be a Shared VPC network. Each VPCnetwork is independently managed and usesPrivate Service Connect to expose all the services that need to be accessed from outside theVPC network.

Use this design when the following is true:

• Workloads only communicate with each other and the on-premisesenvironment through defined endpoints.
• You want teams to be independent of each other, and manage their own IPaddress space, firewalls, and routing rules.

Avoid this design when the following is true:

• Communication between services and applications uses many differentports or channels, or ports and channels change frequently.
• Communication between workloads uses protocols other than TCP or UDP.
• You require Layer 7 inspection between workloads.

The following diagram shows an example implementation of this pattern.

The preceding diagram shows the following:

• Separate workloads are located in separate projects and VPCnetworks.
• A client VM in one VPC network can connect to a workload inanother VPC network through aPrivate Service Connect endpoint.
• The endpoint is attached to aservice attachment in the VPC network where the service islocated. The service attachment can be in a different region from theendpoint if the endpoint is configured forglobal access.
• The service attachment connects to the workload throughCloud Load Balancing.
• Clients in the workload VPC can reach workloads that arelocated on-premises as follows:
  • The endpoint isconnected to a service attachment in a transit VPCnetwork.
  • The service attachment is connected to the on-premises networkusing Cloud Interconnect.
• An internal Application Load Balancer is attached to the service attachment and uses ahybrid network endpoint group to balance traffic load between the endpointsthat are located on-premises.
• On-premises clients can also reach endpoints in the transitVPC networkthat connect to service attachments in the workload VPCnetworks.

For more information, see the following:

• Publish managed services using Private Service Connect
• Access published services through endpoints

To implement this design option, seeCreate option 4: Expose services in a consumer-producer model with Private Service Connect.

Best practices for network deployment

After you choose the best network design for your use case, we recommend implementing the following best practices:

• Use custom mode VPC networks and delete the default network to have better control over your network'sIP addresses.

• Limit external access by using Cloud NAT for resources that need internet access and reducingthe use of public IP addresses to resources accessible throughCloud Load Balancing. For more information, seeAlternatives to using an external IP address.

• If you use Cloud Interconnect, make sure that you follow therecommended topologies fornon-critical orproduction-level applications.Use redundant connections to meet the SLA for the service. Alternatively,you can connect Google Cloud to on-premises networks throughCloud VPN.

• Enforce the policies introduced inlimit external access by using an organization policy to restrict direct access to the internet from your VPC.

• Usehierarchical firewall policies to inherit firewall policies consistently across your organization or folders.

• FollowDNS best practices for hybrid DNS between your on-premises network and Google Cloud.

For more information, seeBest practices and reference architectures for VPC design.

What's next

• Implement your Google Cloud landing zone network design
• Decide the security for your Google Cloud landing zone (next document in this series).
• ReadBest practices for VPC network design.
• Read more aboutPrivate Service Connect.