This document provides steps and guidance to implement your chosen networkdesign after you reviewDecide the network design for your Google Cloud landing zone.If you have not already done so, reviewLanding zone design in Google Cloud before you choose an option.

These instructions are intended for network engineers, architects, andtechnical practitioners who are involved in creating the network design for yourorganization's landing zone.

Network design options

Based on your chosen network design, complete one of the following:

• Create option 1: Shared VPC network for each environment
• Create option 2: Hub-and-spoke topology with centralized appliances
• Create option 3: Hub-and-spoke topology without appliances
• Create option 4: Expose services in a consumer-producer model with Private Service Connect

Create option 1: Shared VPC network for each environment

If you have chosen to create theShared VPC network for each environment in "Decide the network design for your Google Cloud landing zone", follow thisprocedure.

The following steps create a single instance of a VPC. When youneed multiple instances of a VPC, such as for development andproduction environments, repeat the steps for each VPC.

Limit external access by using an organization policy

We recommend that you limit direct access to the internet to only the resourcesthat need it. Resources without external addresses can still access many GoogleAPIs and services through Private Google Access. Private Google Accessis enabled at the subnet level and lets resources interact with key Googleservices, while isolating them from the public internet.

For usability, the default functionality of Google Cloud lets users createresources in all projects, as long as they have the correct IAM permissions. Forimproved security, we recommend that you restrict the default permissions forresource types that can cause unintended internet access. You can then authorizespecific projects only to allow the creation of these resources. Use theinstructions atCreating and managing organization policies to set the following constraints.

Restrict Protocol Forwarding Based on type of IP Address

Protocol forwarding establishes a forwarding rule resource with an external IPaddress and lets you direct the traffic to a VM.

TheRestrict Protocol Forwarding Based on type of IP Address constraintprevents the creation of forwarding rules with external IP addresses for theentire organization. For projects authorized to use external forwarding rules,you can modify the constraint at the folder or project level.

Set the following values to configure this constraint:

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Custom
• Policy type: Deny
• Custom value:IS:EXTERNAL

Define allowed external IPs for VM instances

By default, individual VM instances can acquire external IP addresses, whichallows both outbound and inbound connectivity with the internet.

Enforcing theDefine allowed external IPs for VM instances constraintprevents the use of external IP addresses with VM instances. For workloads thatrequire external IP addresses on individual VM instances, modify the constraintat a folder or project level to specify the individual VM instances. Or,override the constraint for the relevant projects.

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Deny All

Disable VPC External IPv6 usage

TheDisable VPC External IPv6 usage constraint, when set toTrue,prevents the configuration of VPC subnets with external IPv6 addresses for VMinstances.

• Applies to: Customize
• Enforcement: On

Disable default network creation

When a new project is created, a default VPC is automatically created. This isuseful for quick experiments that don't require specific network configurationor integration with a larger enterprise networking environment.

Configure theSkip default network creation constraint to disable defaultVPC creation for new projects. You can manually create the default networkwithin a project, if needed.

• Applies to: Customize
• Enforcement: On

Design firewall rules

Firewall rules let you allow or deny traffic to or from your VMs based on aconfiguration you define.Hierarchical firewall policies are implemented at the organization and folder levels, and network firewallpolicies are implemented at the VPC network level in the resource hierarchy.Together, these provide an important capability to help secure your workloads.

Regardless of where the firewall policies are applied, use the followingguidelines when designing and evaluating your firewall rules:

• Implement least-privilege (also referred to as microsegmentation)principles. Block all traffic by default and only allow the specifictraffic you need. This includes limiting the rules to only the protocolsand ports you need for each workload.
• Enable firewall rules logging for visibility into firewall behavior andto use Firewall Insights.
• Define a numbering methodology for allocating firewall rule priorities.For example, it's best practice to reserve a range of low numbers in eachpolicy for rules needed during incident response. We also recommend thatyou prioritize more specific rules higher than more general rules, toensure that the specific rules aren't shadowed by the general rules. Thefollowing example shows a possible approach for firewall rule priorities:

Firewall rule priority range	Purpose
0-999	Reserved for incident response
1000-1999	Always blocked traffic
2000-1999999999	Workload-specific rules
2000000000-2100000000	Catch-all rules
2100000001-2147483643	Reserved

Configure hierarchical firewall policies

Hierarchical firewall policies let you create and enforce a consistent firewall policy across yourorganization. For examples of using hierarchical firewall policies, seeHierarchical firewall policy examples.

Define hierarchical firewall policies to implement the following network accesscontrols:

• Identity-Aware Proxy (IAP) for TCP forwarding. IAP for TCPforwarding is allowed through a security policy that permits ingresstraffic from IP range 35.235.240.0/20 for TCP ports 22 and 3389.
• Health checks for Cloud Load Balancing. The well-known ranges thatare used for health checks are allowed.
  • For most Cloud Load Balancing instances (including InternalTCP/UDP Load Balancing, Internal HTTP(S) Load Balancing, External TCPProxy Load Balancing, External SSL Proxy Load Balancing, and HTTP(S)Load Balancing), a security policy is defined that allows ingresstraffic from the IP ranges 35.191.0.0/16 and 130.211.0.0/22 for ports80 and 443.
  • For Network Load Balancing, a security policy is defined thatenables legacy health checks by allowing ingress traffic from IP ranges35.191.0.0/16, 209.85.152.0/22, and 209.85.204.0/22 for ports 80 and 443.

Configure your Shared VPC environment

Before implementing a Shared VPC design, decide how to share subnets withservice projects. You attach a service project to a host project. To determinewhich subnets are available for the service project, you assign IAM permissionsto the host project or individual subnets. For example, you can choose todedicate a different subnet to each service project, or share the same subnetsbetween service projects.

1. Create a new project for the Shared VPC. Later in this process, this project becomes the hostproject and contains the networks and networking resources to be sharedwith the service projects.
2. Enable the Compute Engine API for the host project.
3. Configure Shared VPC for the project.
4. Create thecustom-mode VPC network in the host project.
5. Create subnets in theregion where youplan to deploy workloads. For each subnet, enablePrivate Google Access to allow VM instances without external IP addressesto reach Google services.

Configure Cloud NAT

Follow these steps if the workloads in specific regions require outboundinternet access—for example, to download software packages or updates.

1. Create a Cloud NAT gateway in theregions whereworkloads require outbound internet access. You cancustomize the Cloud NAT configuration to only allow outbound connectivityfrom specific subnets, if needed.
2. At a minimum,enable Cloud NAT logging for the gateway to logERRORS_ONLY. To include logs for translationsperformed by Cloud NAT, configure each gateway to logALL.

Configure hybrid connectivity

You can use Dedicated Interconnect, Partner Interconnect, or Cloud VPN toprovide hybrid connectivity to your landing zone. The following steps create theinitial hybrid connectivity resources required for this design option:

1. If you're using Dedicated Interconnect, do the following. If you'reusing Partner Interconnect or Cloud VPN, you can skip these steps.
   1. Create aseparate project for the physical interconnect ports.
   2. Enable the Compute Engine API for the project.
   3. Create Dedicated Interconnect connections.
2. For eachregion whereyou're terminating hybrid connectivity in theVPC network, do the following:
   1. Create two Dedicated or PartnerVLAN attachments,one for each edge availability zone. As part of this process, you selectCloud Routers and create BGP sessions.
   2. Configure the peer network (on-premises or other cloud) routers.

Configure workload projects

Create a separate service project for each workload:

1. Create a new project to function as one of the service projects for the Shared VPC.
2. Enable the Compute Engine API for the service project.
3. Attach the project to the host project.
4. Configure access toall subnets in the host project orsome subnets in the host project.

Configure observability

Network Intelligence Center provides a cohesive way to monitor, troubleshoot,and visualize your cloud networking environment. Use it to ensure that yourdesign functions with the desired intent.

The following configurations support the analysis of logging and metricsenabled.

• You mustenable the Network Management API before you can run Connectivity Tests. Enabling the API is required to usethe API directly, the Google Cloud CLI, or the Google Cloud console.
• You mustenable the Firewall Insights API before you can perform any tasks using Firewall Insights.

Next steps

The initial configuration for this network design option is now complete. Youcan now either repeat these steps to configure an additional instance of thelanding zone environment, such as a staging or production environment, orcontinue toDecide the security for your Google Cloud landing zone.

Create option 2: Hub-and-spoke topology with centralized appliances

If you have chosen to create thehub-and-spoke topology with centralized appliances in "Decide the network design for your Google Cloud landing zone", follow thisprocedure.

The following steps create a single instance of a VPC. When youneed multiple instances of a VPC, such as for development andproduction environments, repeat the steps for each VPC.

Limit external access by using an organization policy

We recommend that you limit direct access to the internet to only the resourcesthat need it. Resources without external addresses can still access many GoogleAPIs and services through Private Google Access. Private Google Accessis enabled at the subnet level and lets resources interact with key Googleservices, while isolating them from the public internet.

For usability, the default functionality of Google Cloud lets users createresources in all projects, as long as they have the correct IAM permissions. Forimproved security, we recommend that you restrict the default permissions forresource types that can cause unintended internet access. You can then authorizespecific projects only to allow the creation of these resources. Use theinstructions atCreating and managing organization policies to set the following constraints.

Restrict Protocol Forwarding Based on type of IP Address

Protocol forwarding establishes a forwarding rule resource with an external IPaddress and lets you direct the traffic to a VM.

TheRestrict Protocol Forwarding Based on type of IP Address constraintprevents the creation of forwarding rules with external IP addresses for theentire organization. For projects authorized to use external forwarding rules,you can modify the constraint at the folder or project level.

Set the following values to configure this constraint:

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Custom
• Policy type: Deny
• Custom value:IS:EXTERNAL

Define allowed external IPs for VM instances

By default, individual VM instances can acquire external IP addresses, whichallows both outbound and inbound connectivity with the internet.

Enforcing theDefine allowed external IPs for VM instances constraintprevents the use of external IP addresses with VM instances. For workloads thatrequire external IP addresses on individual VM instances, modify the constraintat a folder or project level to specify the individual VM instances. Or,override the constraint for the relevant projects.

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Deny All

Disable VPC External IPv6 usage

TheDisable VPC External IPv6 usage constraint, when set toTrue,prevents the configuration of VPC subnets with external IPv6 addresses for VMinstances.

• Applies to: Customize
• Enforcement: On

Disable default network creation

When a new project is created, a default VPC is automatically created. This isuseful for quick experiments that don't require specific network configurationor integration with a larger enterprise networking environment.

Configure theSkip default network creation constraint to disable defaultVPC creation for new projects. You can manually create the default networkwithin a project, if needed.

• Applies to: Customize
• Enforcement: On

Design firewall rules

Firewall rules let you allow or deny traffic to or from your VMs based on aconfiguration you define.Hierarchical firewall policies are implemented at the organization and folder levels, and network firewallpolicies are implemented at the VPC network level in the resource hierarchy.Together, these provide an important capability to help secure your workloads.

Regardless of where the firewall policies are applied, use the followingguidelines when designing and evaluating your firewall rules:

• Implement least-privilege (also referred to as microsegmentation)principles. Block all traffic by default and only allow the specifictraffic you need. This includes limiting the rules to only the protocolsand ports you need for each workload.
• Enable firewall rules logging for visibility into firewall behavior andto use Firewall Insights.
• Define a numbering methodology for allocating firewall rule priorities.For example, it's best practice to reserve a range of low numbers in eachpolicy for rules needed during incident response. We also recommend thatyou prioritize more specific rules higher than more general rules, toensure that the specific rules aren't shadowed by the general rules. Thefollowing example shows a possible approach for firewall rule priorities:

Firewall rule priority range	Purpose
0-999	Reserved for incident response
1000-1999	Always blocked traffic
2000-1999999999	Workload-specific rules
2000000000-2100000000	Catch-all rules
2100000001-2147483643	Reserved

Configure hierarchical firewall policies

Hierarchical firewall policies let you create and enforce a consistent firewall policy across yourorganization. For examples of using hierarchical firewall policies, seeHierarchical firewall policy examples.

Define hierarchical firewall policies to implement the following network accesscontrols:

• Identity-Aware Proxy (IAP) for TCP forwarding. IAP for TCPforwarding is allowed through a security policy that permits ingresstraffic from IP range 35.235.240.0/20 for TCP ports 22 and 3389.
• Health checks for Cloud Load Balancing. The well-known ranges thatare used for health checks are allowed.
  • For most Cloud Load Balancing instances (including InternalTCP/UDP Load Balancing, Internal HTTP(S) Load Balancing, External TCPProxy Load Balancing, External SSL Proxy Load Balancing, and HTTP(S)Load Balancing), a security policy is defined that allows ingresstraffic from the IP ranges 35.191.0.0/16 and 130.211.0.0/22 for ports80 and 443.
  • For Network Load Balancing, a security policy is defined thatenables legacy health checks by allowing ingress traffic from IP ranges35.191.0.0/16, 209.85.152.0/22, and 209.85.204.0/22 for ports 80 and 443.

Configure your VPC environment

The transit and hub VPC networks provide the networking resources to enableconnectivity between workload spoke VPC networks and on-premises or multi-cloudnetworks.

1. Create a new project for transit and hub VPC networks. Both VPC networks are part of the sameproject to support connectivity through the virtual network appliances.
2. Enable the Compute Engine API for the project.
3. Create the transit custom mode VPC network.
4. In the transit VPC network,create a subnet in the regions where you plan to deploy the virtual network appliances.
5. Create the hub custom mode VPC network.
6. In the hub VPC network,create a subnet in the regions where you plan to deploy the virtual network appliances.
7. Configureglobal or regional network firewall policies to allow ingress and egress traffic for the network virtual appliances.
8. Create a managed instance group for the virtual network appliances.
9. Configure the internal TCP/UDP load balancing resources for the transit VPC. This load balancer is used for routing traffic fromthe transit VPC to the hub VPC through the virtual network appliances.
10. Configure the internal TCP/UDP load balancing resources for the hub VPC. This load balancer is used for routing traffic from thehub VPC to the transit VPC through the virtual network appliances.
11. Configure Private Service Connect for Google APIs for the hub VPC.
12. Modify VPC routes to send all traffic through the network virtual appliances:
    1. Delete the0.0.0.0/0 route with next-hopdefault-internet-gateway from the hub VPC.
    2. Configure a new route with destination0.0.0.0/0 and anext-hop of the forwarding rule for the load balancer in the hub VPC.

Configure Cloud NAT

Follow these steps if the workloads in specific regions require outboundinternet access—for example, to download software packages or updates.

1. Create a Cloud NAT gateway in theregions whereworkloads require outbound internet access. You cancustomize the Cloud NAT configuration to only allow outbound connectivityfrom specific subnets, if needed.
2. At a minimum,enable Cloud NAT logging for the gateway to logERRORS_ONLY. To include logs for translationsperformed by Cloud NAT, configure each gateway to logALL.

Configure hybrid connectivity

You can use Dedicated Interconnect, Partner Interconnect, or Cloud VPN toprovide hybrid connectivity to your landing zone. The following steps create theinitial hybrid connectivity resources required for this design option:

1. If you're using Dedicated Interconnect, do the following. If you'reusing Partner Interconnect or Cloud VPN, you can skip these steps.
   1. Create aseparate project for the physical interconnect ports.
   2. Enable the Compute Engine API for the project.
   3. Create Dedicated Interconnect connections.
2. For eachregion whereyou're terminating hybrid connectivity in theVPC network, do the following:
   1. Create two Dedicated or PartnerVLAN attachments,one for each edge availability zone. As part of this process, you selectCloud Routers and create BGP sessions.
   2. Configure the peer network (on-premises or other cloud) routers.
   3. Configure custom advertised routes in the Cloud Routers forthe subnet ranges in the hub and workload VPCs.

Configure workload projects

Create a separate spoke VPC for each workload:

1. Create a new project to host your workload.
2. Enable the Compute Engine API for the project.
3. Configure VPC Network Peering between the workload spoke VPC and hub VPC with the following settings:
   • Enable custom route export on the hub VPC.
   • Enable custom route import on the workload spoke VPC.
4. Create subnets in the regions where you plan to deploy workloads. For each subnet, enablePrivate Google Access to allow VM instances withonly internal IPaddresses to reach Google services.
5. Configure Private Service Connect for Google APIs.
6. To route all traffic through the virtual network appliances in the hubVPC, delete the0.0.0.0/0 route with next-hopdefault-internet-gatewayfrom the workload spoke VPC.
7. Configureglobal or regional network firewall policies to allow ingress and egress traffic for your workload.

Configure observability

Network Intelligence Center provides a cohesive way to monitor, troubleshoot,and visualize your cloud networking environment. Use it to ensure that yourdesign functions with the desired intent.

The following configurations support the analysis of logging and metricsenabled.

• You mustenable the Network Management API before you can run Connectivity Tests. Enabling the API is required to usethe API directly, the Google Cloud CLI, or the Google Cloud console.
• You mustenable the Firewall Insights API before you can perform any tasks using Firewall Insights.

Next steps

The initial configuration for this network design option is now complete. Youcan now either repeat these steps to configure an additional instance of thelanding zone environment, such as a staging or production environment, orcontinue toDecide the security for your Google Cloud landing zone.

Create option 3: Hub-and-spoke topology without appliances

If you have chosen to create thehub-and-spoke topology without appliances in "Decide the network design for your Google Cloud landing zone", follow thisprocedure.

The following steps create a single instance of a VPC. When youneed multiple instances of a VPC, such as for development andproduction environments, repeat the steps for each VPC.

Limit external access by using an organization policy

We recommend that you limit direct access to the internet to only the resourcesthat need it. Resources without external addresses can still access many GoogleAPIs and services through Private Google Access. Private Google Accessis enabled at the subnet level and lets resources interact with key Googleservices, while isolating them from the public internet.

For usability, the default functionality of Google Cloud lets users createresources in all projects, as long as they have the correct IAM permissions. Forimproved security, we recommend that you restrict the default permissions forresource types that can cause unintended internet access. You can then authorizespecific projects only to allow the creation of these resources. Use theinstructions atCreating and managing organization policies to set the following constraints.

Restrict Protocol Forwarding Based on type of IP Address

Protocol forwarding establishes a forwarding rule resource with an external IPaddress and lets you direct the traffic to a VM.

TheRestrict Protocol Forwarding Based on type of IP Address constraintprevents the creation of forwarding rules with external IP addresses for theentire organization. For projects authorized to use external forwarding rules,you can modify the constraint at the folder or project level.

Set the following values to configure this constraint:

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Custom
• Policy type: Deny
• Custom value:IS:EXTERNAL

Define allowed external IPs for VM instances

By default, individual VM instances can acquire external IP addresses, whichallows both outbound and inbound connectivity with the internet.

Enforcing theDefine allowed external IPs for VM instances constraintprevents the use of external IP addresses with VM instances. For workloads thatrequire external IP addresses on individual VM instances, modify the constraintat a folder or project level to specify the individual VM instances. Or,override the constraint for the relevant projects.

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Deny All

Disable VPC External IPv6 usage

TheDisable VPC External IPv6 usage constraint, when set toTrue,prevents the configuration of VPC subnets with external IPv6 addresses for VMinstances.

• Applies to: Customize
• Enforcement: On

Disable default network creation

When a new project is created, a default VPC is automatically created. This isuseful for quick experiments that don't require specific network configurationor integration with a larger enterprise networking environment.

Configure theSkip default network creation constraint to disable defaultVPC creation for new projects. You can manually create the default networkwithin a project, if needed.

• Applies to: Customize
• Enforcement: On

Design firewall rules

Firewall rules let you allow or deny traffic to or from your VMs based on aconfiguration you define.Hierarchical firewall policies are implemented at the organization and folder levels, and network firewallpolicies are implemented at the VPC network level in the resource hierarchy.Together, these provide an important capability to help secure your workloads.

Regardless of where the firewall policies are applied, use the followingguidelines when designing and evaluating your firewall rules:

• Implement least-privilege (also referred to as microsegmentation)principles. Block all traffic by default and only allow the specifictraffic you need. This includes limiting the rules to only the protocolsand ports you need for each workload.
• Enable firewall rules logging for visibility into firewall behavior andto use Firewall Insights.
• Define a numbering methodology for allocating firewall rule priorities.For example, it's best practice to reserve a range of low numbers in eachpolicy for rules needed during incident response. We also recommend thatyou prioritize more specific rules higher than more general rules, toensure that the specific rules aren't shadowed by the general rules. Thefollowing example shows a possible approach for firewall rule priorities:

Firewall rule priority range	Purpose
0-999	Reserved for incident response
1000-1999	Always blocked traffic
2000-1999999999	Workload-specific rules
2000000000-2100000000	Catch-all rules
2100000001-2147483643	Reserved

Configure hierarchical firewall policies

Hierarchical firewall policies let you create and enforce a consistent firewall policy across yourorganization. For examples of using hierarchical firewall policies, seeHierarchical firewall policy examples.

Define hierarchical firewall policies to implement the following network accesscontrols:

• Identity-Aware Proxy (IAP) for TCP forwarding. IAP for TCPforwarding is allowed through a security policy that permits ingresstraffic from IP range 35.235.240.0/20 for TCP ports 22 and 3389.
• Health checks for Cloud Load Balancing. The well-known ranges thatare used for health checks are allowed.
  • For most Cloud Load Balancing instances (including InternalTCP/UDP Load Balancing, Internal HTTP(S) Load Balancing, External TCPProxy Load Balancing, External SSL Proxy Load Balancing, and HTTP(S)Load Balancing), a security policy is defined that allows ingresstraffic from the IP ranges 35.191.0.0/16 and 130.211.0.0/22 for ports80 and 443.
  • For Network Load Balancing, a security policy is defined thatenables legacy health checks by allowing ingress traffic from IP ranges35.191.0.0/16, 209.85.152.0/22, and 209.85.204.0/22 for ports 80 and 443.

Configure the hub VPC environment

The hub VPC provides the networking resources to enable connectivity betweenworkload spoke VPC networks and on-premises or multi-cloud networks.

1. Create a new project for the hub VPC network.
2. Enable the Compute Engine API for the project.
3. Create the hubcustom mode VPC network.
4. Configure Private Service Connect for Google APIs for the hub VPC.

Configure hybrid connectivity

You can use Dedicated Interconnect, Partner Interconnect, or Cloud VPN toprovide hybrid connectivity to your landing zone. The following steps create theinitial hybrid connectivity resources required for this design option:

1. If you're using Dedicated Interconnect, do the following. If you'reusing Partner Interconnect or Cloud VPN, you can skip these steps.
   1. Create aseparate project for the physical interconnect ports.
   2. Enable the Compute Engine API for the project.
   3. Create Dedicated Interconnect connections.
2. For eachregion whereyou're terminating hybrid connectivity in theVPC network, do the following:
   1. Create two Dedicated or PartnerVLAN attachments,one for each edge availability zone. As part of this process, you selectCloud Routers and create BGP sessions.
   2. Configure the peer network (on-premises or other cloud) routers.
   3. Configure custom advertised routes in the Cloud Routers forthe subnet ranges in the hub and workload VPCs.

Configure workload projects

Create a separate spoke VPC for each workload:

1. Create a new project to host your workload.
2. Enable the Compute Engine API for the project.
3. Configure VPC Network Peering between the workload spoke VPC and hub VPC, with the following settings:
   • Enable custom route export on the hub VPC.
   • Enable custom route import on the workload spoke VPC.
4. Create subnets in the regions where you plan to deploy workloads. For each subnet, enablePrivate Google Access to allow VM instances withonly internal IPaddresses to reach Google services.
5. Configure Private Service Connect for Google APIs.

Configure Cloud NAT

Follow these steps if the workloads in specific regions require outboundinternet access—for example, to download software packages or updates.

1. Create a Cloud NAT gateway in theregions whereworkloads require outbound internet access. You cancustomize the Cloud NAT configuration to only allow outbound connectivityfrom specific subnets, if needed.
2. At a minimum,enable Cloud NAT logging for the gateway to logERRORS_ONLY. To include logs for translationsperformed by Cloud NAT, configure each gateway to logALL.

Configure observability

Network Intelligence Center provides a cohesive way to monitor, troubleshoot,and visualize your cloud networking environment. Use it to ensure that yourdesign functions with the desired intent.

The following configurations support the analysis of logging and metricsenabled.

• You mustenable the Network Management API before you can run Connectivity Tests. Enabling the API is required to usethe API directly, the Google Cloud CLI, or the Google Cloud console.
• You mustenable the Firewall Insights API before you can perform any tasks using Firewall Insights.

Next steps

The initial configuration for this network design option is now complete. Youcan now either repeat these steps to configure an additional instance of thelanding zone environment, such as a staging or production environment, orcontinue toDecide the security for your Google Cloud landing zone.

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

If you have chosen toexpose services in a consumer-producer model with Private Service Connect for your landing zone, as described in "Decide the network design for yourGoogle Cloud landing zone", follow this procedure.

The following steps create a single instance of a VPC. When youneed multiple instances of a VPC, such as for development andproduction environments, repeat the steps for each VPC.

Limit external access by using an organization policy

We recommend that you limit direct access to the internet to only the resourcesthat need it. Resources without external addresses can still access many GoogleAPIs and services through Private Google Access. Private Google Accessis enabled at the subnet level and lets resources interact with key Googleservices, while isolating them from the public internet.

For usability, the default functionality of Google Cloud lets users createresources in all projects, as long as they have the correct IAM permissions. Forimproved security, we recommend that you restrict the default permissions forresource types that can cause unintended internet access. You can then authorizespecific projects only to allow the creation of these resources. Use theinstructions atCreating and managing organization policies to set the following constraints.

Restrict Protocol Forwarding Based on type of IP Address

Protocol forwarding establishes a forwarding rule resource with an external IPaddress and lets you direct the traffic to a VM.

TheRestrict Protocol Forwarding Based on type of IP Address constraintprevents the creation of forwarding rules with external IP addresses for theentire organization. For projects authorized to use external forwarding rules,you can modify the constraint at the folder or project level.

Set the following values to configure this constraint:

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Custom
• Policy type: Deny
• Custom value:IS:EXTERNAL

Define allowed external IPs for VM instances

By default, individual VM instances can acquire external IP addresses, whichallows both outbound and inbound connectivity with the internet.

Enforcing theDefine allowed external IPs for VM instances constraintprevents the use of external IP addresses with VM instances. For workloads thatrequire external IP addresses on individual VM instances, modify the constraintat a folder or project level to specify the individual VM instances. Or,override the constraint for the relevant projects.

• Applies to: Customize
• Policy enforcement: Replace
• Policy values: Deny All

Disable VPC External IPv6 usage

TheDisable VPC External IPv6 usage constraint, when set toTrue,prevents the configuration of VPC subnets with external IPv6 addresses for VMinstances.

• Applies to: Customize
• Enforcement: On

Disable default network creation

When a new project is created, a default VPC is automatically created. This isuseful for quick experiments that don't require specific network configurationor integration with a larger enterprise networking environment.

Configure theSkip default network creation constraint to disable defaultVPC creation for new projects. You can manually create the default networkwithin a project, if needed.

• Applies to: Customize
• Enforcement: On

Design firewall rules

Firewall rules let you allow or deny traffic to or from your VMs based on aconfiguration you define.Hierarchical firewall policies are implemented at the organization and folder levels, and network firewallpolicies are implemented at the VPC network level in the resource hierarchy.Together, these provide an important capability to help secure your workloads.

Regardless of where the firewall policies are applied, use the followingguidelines when designing and evaluating your firewall rules:

• Implement least-privilege (also referred to as microsegmentation)principles. Block all traffic by default and only allow the specifictraffic you need. This includes limiting the rules to only the protocolsand ports you need for each workload.
• Enable firewall rules logging for visibility into firewall behavior andto use Firewall Insights.
• Define a numbering methodology for allocating firewall rule priorities.For example, it's best practice to reserve a range of low numbers in eachpolicy for rules needed during incident response. We also recommend thatyou prioritize more specific rules higher than more general rules, toensure that the specific rules aren't shadowed by the general rules. Thefollowing example shows a possible approach for firewall rule priorities:

Firewall rule priority range	Purpose
0-999	Reserved for incident response
1000-1999	Always blocked traffic
2000-1999999999	Workload-specific rules
2000000000-2100000000	Catch-all rules
2100000001-2147483643	Reserved

Configure hierarchical firewall policies

Hierarchical firewall policies let you create and enforce a consistent firewall policy across yourorganization. For examples of using hierarchical firewall policies, seeHierarchical firewall policy examples.

Define hierarchical firewall policies to implement the following network accesscontrols:

• Identity-Aware Proxy (IAP) for TCP forwarding. IAP for TCPforwarding is allowed through a security policy that permits ingresstraffic from IP range 35.235.240.0/20 for TCP ports 22 and 3389.
• Health checks for Cloud Load Balancing. The well-known ranges thatare used for health checks are allowed.
  • For most Cloud Load Balancing instances (including InternalTCP/UDP Load Balancing, Internal HTTP(S) Load Balancing, External TCPProxy Load Balancing, External SSL Proxy Load Balancing, and HTTP(S)Load Balancing), a security policy is defined that allows ingresstraffic from the IP ranges 35.191.0.0/16 and 130.211.0.0/22 for ports80 and 443.
  • For Network Load Balancing, a security policy is defined thatenables legacy health checks by allowing ingress traffic from IP ranges35.191.0.0/16, 209.85.152.0/22, and 209.85.204.0/22 for ports 80 and 443.

Configure the VPC environment

The transit VPC provides the networking resources to enable connectivitybetween workload spoke VPC networks and on-premises or multi-cloud networks.

1. Create a new project for the transit VPC network.
2. Enable the Compute Engine API for the project.
3. Create the transitcustom mode VPC network.
4. Create a Private Service Connect subnetineach region where you plan to publish services running in your hub VPC oron-premises environment. ConsiderPrivate Service Connect subnet sizing when deciding your IP addressing plan.
5. For each on-premises service you want to expose to workloads running inGoogle Cloud, create an internal HTTP(S) or TCP proxy load balancerandexpose the services using Private Service Connect.
6. Configure Private Service Connect for Google APIs for the transit VPC.

Configure hybrid connectivity

You can use Dedicated Interconnect, Partner Interconnect, or Cloud VPN toprovide hybrid connectivity to your landing zone. The following steps create theinitial hybrid connectivity resources required for this design option:

1. If you're using Dedicated Interconnect, do the following. If you'reusing Partner Interconnect or Cloud VPN, you can skip these steps.
   1. Create aseparate project for the physical interconnect ports.
   2. Enable the Compute Engine API for the project.
   3. Create Dedicated Interconnect connections.
2. For eachregion whereyou're terminating hybrid connectivity in theVPC network, do the following:
   1. Create two Dedicated or PartnerVLAN attachments,one for each edge availability zone. As part of this process, you selectCloud Routers and create BGP sessions.
   2. Configure the peer network (on-premises or other cloud) routers.

Configure workload projects

Create a separate VPC for each workload:

1. Create a new project to host your workload.
2. Enable the Compute Engine API for the project.
3. Create acustom-mode VPC network.
4. Create subnets in the regions where you plan to deploy workloads. For each subnet, enablePrivate Google Access to allow VM instances withonly internal IPaddresses to reach Google services.
5. Configure Private Service Connect for Google APIs.
6. For each workload you're consuming from a different VPC or youron-premises environment,create a Private Service Connect consumer endpoint.
7. For each workload you're producing for a different VPC or youron-premises environment,create an internal load balancer and service attachment for the service.ConsiderPrivate Service Connect subnet sizing when deciding your IP addressing plan.
8. If the service should be reachable from your on-premises environment,create a Private Service Connect consumer endpoint in the transit VPC.

Configure Cloud NAT

Follow these steps if the workloads in specific regions require outboundinternet access—for example, to download software packages or updates.

1. Create a Cloud NAT gateway in theregions whereworkloads require outbound internet access. You cancustomize the Cloud NAT configuration to only allow outbound connectivityfrom specific subnets, if needed.
2. At a minimum,enable Cloud NAT logging for the gateway to logERRORS_ONLY. To include logs for translationsperformed by Cloud NAT, configure each gateway to logALL.

Configure observability

Network Intelligence Center provides a cohesive way to monitor, troubleshoot,and visualize your cloud networking environment. Use it to ensure that yourdesign functions with the desired intent.

The following configurations support the analysis of logging and metricsenabled.

• You mustenable the Network Management API before you can run Connectivity Tests. Enabling the API is required to usethe API directly, the Google Cloud CLI, or the Google Cloud console.
• You mustenable the Firewall Insights API before you can perform any tasks using Firewall Insights.

Next steps

The initial configuration for this network design option is now complete. Youcan now either repeat these steps to configure an additional instance of thelanding zone environment, such as a staging or production environment, orcontinue toDecide the security for your Google Cloud landing zone.

What's next

• 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.