Network planning

Go back to GCP Tutorials

In this tutorial we will learn and understand about Network planning.

Identify decision makers, timelines, and pre-work

As a first step in your VPC network design, identify the decision makers, timelines, and pre-work necessary to ensure that you can address stakeholder requirements. However, stakeholders might include application owners, security architects, solution architects, and operations managers. The stakeholders themselves might change depending on whether you are planning your VPC network for a project, a line of business, or the entire organization.

Consider VPC network design early

Make VPC network design an early part of designing your organizational setup in Google Cloud. Several design choices on an organizational level can’t be easily reversed later in the process. However, different VPC network configurations can have significant implications for routing, scale, and security. Careful planning and deep understanding of your specific considerations helps you to create a solid architectural foundation for incremental workloads.

Use clear naming conventions

Make your naming conventions simple, intuitive, and consistent. This ensures that administrators and end users understand the purpose of each resource, its location, and how it can differentiate from other resources. Further, consider the components illustrated in the following example when establishing your naming conventions:

• Firstly, Company name: Acme Company: acmeco
• Secondly, Business unit: Human Resources: hr
• Thirdly, Application code: Compensation system: comp
• Next, Region code: northamerica-northeast1: na-ne1, europe-west1: eu-we1
• Lastly, Environment codes: dev, test, uat, stage, prod

However, for other common networking resources, consider patterns like these:

• Firstly, VPC network
  syntax: {company name}-{description(App or BU)-label}-{environment-label}-{seq#}
  example: acmeco-hr-dev-vpc-1
• Secondly, Subnet
  syntax: {company-name}-{description(App or BU)-label}-{region/zone-label}
  example: acmeco-hr-na-ne1-dev-subnet
• Thirdly, Firewall rule
  syntax: {company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
  example: acmeco-hr-internet-internal-tcp-80-allow-rule
• Lastly, IP route
  syntax: {priority}-{VPC-label}-{tag}-{next hop}
  example: 1000-acmeco-hr-dev-vpc-1-int-gw

Addresses and subnets

Use custom mode VPC networks

When you start your first project, you begin with the default network, which is an auto mode VPC network named default. Auto mode networks automatically create subnets. And, corresponding subnet routes whose primary IP ranges are /20 CIDRs in each Google Cloud region using a predictable set of RFC 1918 address ranges. However, the default network also automatically includes some pre-populated firewall rules. Further, we recommend that enterprises use VPC networks in custom mode from the beginning for the following reasons:

• Firstly, custom mode VPC networks better integrate into existing IP address management schemes. Because all auto mode networks use the same set of internal IP ranges, auto mode IP ranges might overlap when connected with your on-premises corporate networks.
• Secondly, you can’t connect two auto mode VPC networks together using VPC Network Peering because their subnets use identical primary IP ranges.
• Thirdly, you can choose unique, descriptive names for custom mode subnets, making your VPC networks more understandable and maintainable.
• Lastly, when a new region is introduced, Google Cloud automatically creates a new subnet in an auto mode network. Custom mode VPC networks provide more flexibility for planning and avoiding overlapping addresses.

Deciding whether to create multiple VPC networks

Create a single VPC network per project to map VPC resource quotas to projects

Quotas are default constraints at the project level and can be raised by Google Cloud requesting additional quota. However, they are meant to protect you from unexpected resource usage. However, many factors might lead you to request increases. On the other hand, Limits most commonly apply within a VPC network and protect system resources in aggregate. Limits generally can’t be raised easily, although Google Cloud support and sales teams can work with you to increase some limits. Further, Google Support can increase some scaling limits, but there might be times when you need to build multiple VPC networks to meet your scaling requirements.

Create a VPC network for each autonomous team, with shared services in a common VPC network

Some large enterprise deployments involve autonomous teams that each require full control over their respective VPC networks. However, you can meet this requirement by creating a VPC network for each business unit, with shared services in a common VPC network.

Create VPC networks in different projects for independent IAM controls

A VPC network is a project-level resource with fine-grained, project-level identity and access management (IAM) controls, including the following roles:

• Firstly, networkAdmin
• Secondly, securityAdmin
• Thirdly, networkUser
• Lastly, networkViewer

VPC network overview

A Virtual Private Cloud (VPC) network is a virtual version of a physical network that implements inside of Google’s production network, using Andromeda. A VPC network provides the following:

• Firstly, provides connectivity for your Compute Engine virtual machine (VM) instances, including Google Kubernetes Engine (GKE) clusters and App Engine flexible environment instances.
• Secondly, offers native Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing.
• Thirdly, connects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments.
• Lastly, distributes traffic from Google Cloud external load balancers to backends.

VPC networks have the following properties:

• Firstly, VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone.
• Secondly, subnets are regional resources. Each subnet defines a range of IP addresses.
• Thirdly, traffic to and from instances can be controlled with network firewall rules. Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.
• Fourthly, resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
• Next, instances with internal IP addresses can communicate with Google APIs and services.
• Then, network administration can be secured by using Identity and Access Management (IAM) roles.
• After that, VPC networks can be connected to other VPC networks in different projects or organizations by using VPC Network Peering.
• Lastly, VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network.

Routes and firewall rules

Routes

They define paths for packets leaving instances (egress traffic). Routes in Google Cloud have two categories: system-generated and custom. However, every new network starts with two types of system-generated routes:

• Firstly, the default route defines a path for traffic to leave the VPC network. It provides general internet access to VMs that meet the internet access requirements. It also provides the typical path for Private Google Access.
• Secondly, a subnet route is for each of the IP ranges having link with a subnet. Every subnet has at least one subnet route for its primary IP range.

Dynamic routing mode

Each VPC network has an associated dynamic routing mode that controls the behavior of all of its Cloud Routers. Cloud Routers share routes to your VPC network and learn custom dynamic routes from connected networks when you connect your VPC network to another network. However, this is by using a Cloud VPN tunnel that uses dynamic routing, or by using Dedicated Interconnect or Partner Interconnect.

• Firstly, Regional dynamic routing is the default. In this mode, routes to on-premises resources learned by a given Cloud Router in the VPC network only apply to the subnets in the same region as the Cloud Router.
• Secondly, Global dynamic routing changes the behavior of all Cloud Routers in the network such that the routes to on-premises resources that they learn are available in all subnets in the VPC network, regardless of region.

Firewall rules

Firewall rules apply to both outgoing (egress) and incoming (ingress) traffic in the network. They also control traffic even if it is entirely within the network, including communication among VM instances. However, every VPC network has two implied firewall rules. One implied rule allows most egress traffic, and the other denies all ingress traffic. You cannot delete the implied rules, but you can override them with your own. Google Cloud always blocks some traffic, regardless of firewall rules; for more information, see blocked traffic.

Reference: Google Documentation, Doc 1

Go back to GCP Tutorials