Google Cloud Interconnect Overview

The first step when establishing connectivity to Google Cloud is to set up a Virtual Private Cloud (VPC).

Google Cloud’s VPC is a private, managed virtual network that connects VM instances, Google Kubernetes Engine (GKE) clusters, and the Google App Engine flexible environment.

Manageable
You have control over the VPC similar to what you would have in a physical network. You can configure routing, firewall rules, peering, protocol forwarding, and more.
IP address configuration
To minimize disruption, you can bring your existing public IP addresses to Google Cloud. You can apply your pre-existing IP addresses for VMs, GKE nodes, load balancers, and cloud NAT.
You can also define new static IP addresses (both private and public) and configure IP ranges for subnets.
Global, cross-regional connectivity
Traditionally, virtual cloud environments have been bound by regions. For example, if you have a virtual environment running in US West-1 and another in US East-1, these environments can’t communicate with each other without additional configuration. This typically means setting up VPN gateways to transfer data across the open internet, resulting in additional overhead and higher latency.

However, a Google VPC is global; all traffic within the VPC stays on Google’s network backbone. For example, a user can send data from a VM running in US East-1 to a repository running in Europe West-1 without traversing the public internet or requiring a VPN gateway.

For more information, see Google’s Virtual Private Cloud documentation.

Reaching the VPC

While Google’s network architecture can handle all traffic within the VPC, you still need a way to connect to the VPC itself.

You can reach your VPC using the following:

  • Header row
    • Col1
    • Col2
  • r1

    • Cloud Interconnect

      • Dedicated
      • Partner
      • High performance, high availability, high volume.
      • Bypasses public internet.
      • Allows encryption at the application level.
      • Allows private-to-private (RFC1918) connections.
      • Supports Private Google Access for on-premises (extended service and API access).
      • Requires Google Cloud.
      • Google Cloud Router compatibility.
      • Does not include G Suite access.
      • Connections from 50 Mbps to 100 Gbps
      • Both are available through PacketFabric cloud connectivity.
  • r2
    • Cloud VPN
      • Lower performance, lower volume, lower cost.
      • Sends encrypted traffic over public internet.
      • Allows private-to-private (RFC1918) connections.
      • Requires tunneling and shared keys.
      • Supports Private Google Access for on-premises (extended service and API access).
      • Requires Google Cloud.
      • Google Cloud Router compatibility.
      • Does not include G Suite access.
      • Connections from 1.5 Gbps to 3.0 Gbps.
  • r3

    • Peering

      • Does not require Google Cloud, but does support Google Cloud.
      • Not compatible with Google Cloud Router.
      • Does not support Private Google Access for on-premises.
      • Does not support RFC1918 connections.
      • Includes G Suite access.

Cloud Interconnect: Partner vs. Dedicated

Once you have determined that Cloud Interconnect is your preferred option, your next step is to decide whether you want a Dedicated or Partner Interconnect.

The primary difference between the two is that on a dedicated connection, you own and fully control the interconnect. You are issued an LOA, and use that to establish a cross connect to a PacketFabric port in the on-ramp facility.

Whereas on a partner connection (PacketFabric Hosted cloud connection), multiple customers might share the interconnect. You are not issued an LOA; PacketFabric already has cross connect established.

For more information on the differences between Hosted and Dedicated connections, see Hosted vs. Dedicated Connections.

Feature comparison

  • Header row
    • Feature
    • Dedicated
    • Dedicated via PacketFabric
    • Partner via PacketFabric
  • R1
    • Use
      • Your data needs require a 10 Gbps or 100 Gbps connection (supporting variable VLAN sizes from 50 Mbps).
      • You can physically connect to Google in one of their on-ramp locations.
      • You prefer to work directly with Google and install and maintain your own hardware.
      • Best for high bandwidth use cases, and for maximum control and security.
      • Your data needs require a 10 Gbps or 100 Gbps connection (supporting variable VLAN sizes from 50 Mbps).
      • You are not able to physically connect to Google in one of their on-ramp locations.
      • You do not want to install and maintain your own hardware in the on-ramp facility.
      • Best for high bandwidth use cases, and for maximum control and security.
      • Your data needs are less than 10 Gbps or no more than 50 Gbps.
      • You are unable to physically connect to Google in one of their on-ramp locations.
      • You do not want to install and maintain your own hardware in the on-ramp facility.
      • Best for variable bandwidth usage patterns, and rapid or unpredictable bandwidth growth.
  • R1

    • Capacity

    • 10 Gbps and 100 Gbps interconnects.

      VLAN attachments from 50 Mbps to 50 Gbps.

    • PacketFabric supports connections from 50 Mbps to 10 Gbps.

  • R3

    • Hardware

    • You are responsible for installing equipment in one of Google’s supported colocation facilities.

      Equipment must meet Google’s technical requirements. You are also responsible for all your hardware maintenance and software upgrades.

    • PacketFabric equipment is already in place, pre-patched, and meets requirements. We are responsible for all maintenance and upgrades on Google-facing hardware.

  • R2
    • Set up
    • You must connect at one of Google’s colocation facilities.
    • You can set up a cross connect to PacketFabric at any of our POPs, and then select one of our on-ramp locations from which to connect to Google.
  • R4

    • Locations

    • Google is present in over 20 facilities across North America, as well as colocation facilities in Europe, South America, Asia, and Australia.

      See Google’s colocation facility list.

    • You can connect to PacketFabric at any one of our locations (see our location list).

      For your Dedicated Interconnection you can choose from our 10 U.S.-based and 2 international dedicated on-ramp locations.

      See below.

    • You can connect to PacketFabric at any one of our locations (see our location list).

      Then you can select from our 9 U.S.-based and 2 international partner on-ramp locations.

      See below.

  • R6

    • Pricing

    • See Google’s Dedicated Interconnect pricing.

    • You are responsible for all Google Dedicated Interconnect costs. These are paid directly to Google.

      PacketFabric charges a monthly recurring cost based on capacity, service term, and metro/long-haul usage. You are also responsible for the cross-connect fee between our equipment and yours (one-time cost).

      See Dedicated Cloud Connectivity Pricing.

    • For Partner Interconnects, Google charges based on capacity and egress traffic. You are responsible for paying these costs directly to Google. See Google’s Partner Interconnect pricing.

      PacketFabric charges a monthly recurring cost based on capacity, service term, and metro/long-haul usage. You are also responsible for the cross-connect fee between our equipment and yours (one-time cost).

      See Hosted Cloud Connectivity Pricing.

  • R9
    • Terms
    • Month-to-month for the interconnect. VLAN attachments are billed hourly.
    • PacketFabric offers month-to-month, 12 month, 24 month, and 36 month service terms.
    • Month-to-month.
  • R5

    • SLA**

    • Google provides an end-to-end SLA for redundant services.

      They do not extend their SLA to single interconnects (see note below).

    • Google’s SLA covers the PacketFabric-to-Google connection.

      PacketFabric’s SLA covers our connection back to your source port. It does not cover the cross connect between your equipment and ours.

  • R4
    • ASN
    • Set your Google Cloud Router to a private ASN (64512 - 65534, 4200000000 - 4294967294).
    • Set your Google Cloud Router to ASN 16550.
  • R4
    • BGP
    • You must configure BGP on your on-premises routers and Google Cloud Routers.
  • R4
    • MTU
    • Google allows a maximum of 1440 bytes.
  • R4
    • LAG/LACP
    • Google requires that all connections are set up as a LAG (link aggregation group).

**SLA NOTE: Google does not extend their uptime SLA to Dedicated Interconnect customers who only want a single interconnect, or to Partner Interconnect customers who only want a single VLAN attachment.

If eligible, any financial credits granted under the Google uptime SLA are handled directly between you and Google.

For more information, see the Google Interconnect SLA.

Locations

Google Cloud Interconnects as part of a custom network

The simplest Google Cloud Interconnect network is a one-to-one connection between your on-premises router and your VPC.

For example:

However, PacketFabric allows a wide array of possible combinations. Once the required cross connects are in place, you can instantly build, remove, and modify connections.

Multiple source ports

You can extend virtual circuits from multiple source ports, in multiple locations, and with different capacities, to any of your Google Interconnects.

NOTE: The illustration above would likely be Hosted connections. However, you could also create a single Dedicated on-ramp port and provision multiple virtual circuits from different on-premises locations.

Multiple virtual private clouds

You can reach multiple VPCs through a single interconnect or through multiple interconnects (not shown).

Multiple services

You can also connect multiple services to each source port.

For example, you can provision a combination of Hosted and Dedicated Interconnects, and connect to other cloud service providers such as AWS and Azure. You can also connect PacketFabric marketplace providers directly to your cloud environment.

Updated on 15 Dec 2021