Accessing Google Cloud APIs via Google Partner Interconnect and Megaport

With the emergence of new and innovative cloud computing technologies, companies have the ability to drive digital transformation initiatives with completely different economics, pace, and scale.

Cloud applications are changing rapidly to support these strategies, with the increased adoption of micro-services based architectures, typically utilising containers and container orchestration.

Traditional on-premises block storage and file storage is now evolving into object storage with databases provided as a service in the cloud and applications running on fleets of compute instances that are elastically adapting to workload and demand.

Cloud is a resource that is of crucial importance to enterprises worldwide and can really transform a business from its core. But, how can cloud work hand in hand with a traditional data centre – which is typically more rigid and static and still supports parts of the application and business processes?

Cloud providers have developed various technologies for hybrid networking that enable streamlined connectivity between cloud and on-premise environments. In this article, we’ll focus on Google Cloud’s hybrid connectivity portfolio which offers additional services like Private Google Access for on-premises hosts. This feature enables Google Cloud customers to access Google APIs and Services via a Cloud Interconnect from on-premises data centres with Private IP addresses. Traditionally, these APIs could only be accessed over the public internet.

Existing Solutions for Private and Public Interconnection

Interconnection technologies from cloud providers are capable of extending on-premises networks to provide access to both public and private services. However, access to public services such as object storage typically requires enterprises to allow access to the internet either through NAT, proxies or exposing them directly with a public IP.

Peering directly with the cloud provider (or via an Internet Exchange such as the Mega-IX) is an alternative option, but these operations still carry certain requirements.

A public service is defined as a service that is accessible over the internet via a public IP address. Conversely, a private service is accessible over a dedicated circuit, and is usually addressed via an IP address in the RFC1918 range.

Google Cloud has a rich portfolio of hybrid connectivity options ranging from private connections to VPNs and direct peering options. Customers have five options (or six, if we consider the public internet as well) to interact with Google Cloud resources, and the type of services they want to connect to normally governs the type of access needed.

If the customer requires enterprise-grade connection to their Google VPC, using private IP addressing, either Dedicated or Partner Interconnect, as well as Cloud VPN, are all suitable options.

If the requirement is to connect to public services, accessed through Google Cloud public IPs, such as G Suite, Google APIs, Search, or Google App Engine, then Direct Peering or Carrier Peering is available.

So what happens when an on-premises server needs to access both services in a Google Cloud VPC but also Google APIs, for example? Now, the solution is easier than ever.

Google Cloud customers can now directly access Google Cloud services and APIs through the Private Google Access for on-premises feature. This means that Google APIs and services can now be reached by on-premises hosts privately and securely through a Cloud VPN or a Cloud Interconnect connection.

For a better understanding, let’s have a look at a real use case scenario and give a couple of important recommendations on what should be configured to make this work.

Setup and Configuration

• You can connect to Megaport from over 400 enabled locations, and we have on-ramp locations to Google Cloud Platform (GCP) in: Australia, Canada, Germany, Hong Kong, Netherlands, Singapore, USA and United Kingdom. Please refer to Megaport Documentation for a detailed explanation on how to order a Megaport and how to create the Virtual Cross Connect (VXC) to Google.

• Configure a Border Gateway Protocol (BGP) session between your on-premises router and the Google Cloud Router.

BGP is used for dynamic exchange of routing information between the GCP VPC and your on-premises environment.

• On GCP, use the Cloud Router custom route advertisement to advertise the restricted Google APIs IP address to your on-premises environment.

The IP address range is 199.36.153.4/30 and is a special public IP address range  that is accessible only by the on-premises hosts that can reach your VPC network through private/internal IP addresses, using Google Cloud Partner Interconnect.
You can do this by adding a custom route advertisement using the Google Cloud Router.

• You should also set up and configure a DNS so that traffic to Google APIs resolves to the Restricted Google APIs IP range. There are different options in here: Google gives some configuration details about BIND and Cloud DNS. In this example, we’ve used BIND on the on-premises host, with a forwarder to a Private Zone set up on Google Cloud DNS.

• To test the scenario, we’ve run cURL from the on-premises server. From the on-premises machine, we tried to access the object in the Google Cloud Bucket, and as can be seen below, the file was accessible and the Restricted APIs IP was used.

Integrating on-premises environments into Google Cloud Platform and giving access to Public Resources to those hosts without an external IP address can now be easily achieved using Megaport and Private Google Access for on-premises, giving enterprises yet another option to get the most out of their IT environments in the most flexible way.

(As a full step-by-step configuration guide goes beyond the scope of this document, we recommend having a look at the very detailed Google Cloud Platform how-to article.)

For more info on building a hybrid set-up with to Google Cloud Platform, get in touch with the Megaport team here.

Contributor:
Michael Hanline – Google Cloud Customer Engineer, Networking