#1 Auto mode network or custom network

When creating a VPC network you currently have two options which are an auto mode or custom mode network. Auto mode networks automatically populate a subnet in each region from the 10.128.0.0/9 IPv4 address range. This type of network can be used for isolated VPCs that would not be connecting directly to other auto mode VPC networks.

When connecting your VPCs together, if they have the same IP addresses you will run into the problem of overlapping addresses. This can occur if you connect two auto mode VPC networks together. If you plan to connect your VPC network to other environments, it is recommended to use custom mode networks in production. This gives you the ability to plan and control your IP addressing and firewall rules.

#2 – Shared VPC or VPC Network Peering

Google Cloud allows you to connect different VPC networks together on the platform by using a shared VPC or VPC network peering design. You should consider which option works best for you at the start.

Shared VPC allows you to set up a host project and connect service projects to it.

The security foundations blueprint uses a Shared VPC network architecture for its sample architecture. Administration is centralized and responsibilities can be delegated to service projects. This capability allows network administrators to manage IP addressing, firewall rules and other routing configuration for the environment.

VPC Network Peering allows you to connect between 2 VPC networks. This feature supports different organizations and projects in Google Cloud. The peerings are 1-1 and not transitive. An example of how it works is as follows: VPC B is connected to VPC A and C. VPC C and A are not directly connected therefore they cannot communicate with each other across VPC B.

VPC network peering also has some limitations including a max number of peering to a VPC network as 25.

Some sample architectures using VPC network peering are a Hub-and-spoke network architecture or architectures using centralized network appliances.

#3 – VPN or no VPN

Depending on the requirements you may choose to use virtual private networks (VPNs) internally or externally. Cloud VPN is easy to set up and cheaper than other external interconnect options. It can be configured in a high availability (HA) configuration. The bandwidth available per tunnel is 3GBit/s, but you can combine multiple tunnels to reach a higher bandwidth.

#4 – Which Interconnect (dedicated or partner)

Both of these options require some work from your internal team and the service providers teams. You should consider when you would actually need your interconnect to be functional because this work may have timed SLAs which can affect delivery. In addition to that there are several other things you can consider when making your choice.

• General considerations
  • Do you have equipment in the colocation facility or not?
  • How much bandwidth do you need?
  • Do you need a SLA?
  • Where to terminate the connection in your VPC? e.g Terminate on a project dedicated to interconnects, or terminate directly on production VPC. This may be something to consider if you have a project that disappears quickly and you want to avoid having to reprovision a new connection everytime.
• Other tricky considerations
  • The total cost. e.g. Google cost, service provider cost

You can see a high level of comparisons in this document’s Compare Cloud Interconnect solutions section and also you can check out Patterns for connecting other cloud service providers with Google Cloud.

#5 – Organization policy and VPC service controls

Organization policies are very helpful ways to administer activities within your cloud network. The organization policy service allows organization policy administrators the ability to configure constraints at all levels of the resource hierarchy. There are constraints that apply to compute engine and networking which can make security and administration much easier. An example of one such constraint is the constraints/compute.vmExternalIpAccess. This allows you to specify the VMs that can use external IPs.

VPC service controls allow you to establish a service perimeter to control access to your resources in Cloud services like BigQuery or Cloud Storage. These restrict certain actions and add additional security to your VPCs.

#6 – Bring your own IP (BYOIP)

This capability allows you to bring external IP addresses you already own and use them for your services in Google Cloud. If this option is something you want to do please consider the time it may take to get the IPs transferred across so that you have them available for when you need to use them. Check out the planning your deployment section to get some more insights.

#7 – DNS

DNS is another major element in network design. Depending on how your DNS is set up you may have to add additional configuration when resolving queries for your cloud and on-prem environments. Cloud DNS is very flexible and can support various zone forwarding options that can be configured to support your environment needs. Google Cloud also has some DNS best practices that may be worth considering for your designs.

#8 – Limit external IP address usage

External IP addresses are internet routable and allow direct connection to your resources. Limiting the use of external IP addresses should be considered to help provide additional security. There are several services that allow you to connect to your private network from the internet. A few of these are:

• Cloud NAT. This allows internal resources to access the internet through a NAT gateway.
• Load Balancers. These have public-facing anycast IP addresses and direct traffic to the connected backend resources.
• Identity Aware proxy (IAP). This allows only authorized user access to the permitted resources.

#9 – IP address management

IP addresses should be unique on connected networks. If you are going to be connecting your VPCs, on-prem and other clouds you need to manage your IP ranges. Managing IPs may require some additional effort or even an IP Address Management (IPAM) tool. This tool can make management of your IPs easier as you scale.

Large Kubernetes deployments require many IPs. In those environments IP address management is very important. Here are a few IP address management strategies that you can consider for GKE.

#10 – How does failure look in my environment

What are the availability requirements and BCP requirements for the organization? Depending on the nature of the service, high availability (HA) may be a key factor.

The question of how failure looks will help you determine how to design for anticipated failure based on the business requirements. If high availability is not an issue then the design would be much different from an environment where HA is a top requirement.

You may have to do additional configuration using Cloud DNS, multiregion design and autoscaling options to meet these needs. A trade off for this can be cost but cost can be controlled in HA design architectures. There is a disaster recovery (DR) planning guide that can be helpful for review.

Additional tip

In addition to the 10 tips above it may also be wise to consider the future expansion of the business. Some examples are acquisitions, scaling of the current environment, launching new products, connecting to on-prem and other clouds. Whenever you expand a network, IP addressing and routing comes into play.  You should consider questions like:

• Do I need to communicate between new VPC networks, on-prem, or other networks?
• Do I have enough IP addresses for my services?
• How many systems will I be exposing externally?
• Do I know what my free addresses look like?
• How many routes can my Cloud router support via BGP?

Most companies have strategic plans which should determine the actions the company takes and its growth objectives. These tips should be a good starting point to gain information in regard to planning for future expansion.

To learn more about designing on Google Cloud check out the following:

• Documentation: Design your network infrastructure
• Documentation: Secure your network
• Documentation: Optimize cost networking