This post contains a cheat sheet summarising the key elements of the network setup you must choose to connect your Teradata VantageCloud Lake instance on Google Cloud with your account. It also describes the GCP services Teradata supports for the connections. Below, you can find an explanation of all of them.

Cheat Sheet for the Network options for VantageCloud Lake on GCP

You can download a high-resolution network cheat sheet for VantageCloud Lake on Azure in a repository in my GitHub account.

Network components in detail

Google connectivity Options Teradata supports for VaaS

On Prem-to-Cloud connection

Google Cloud Interconnect

Cloud Interconnect extends an on-premises network to Google’s network through a highly available, low-latency connection. So it is Teradata’s recommended option. Furthermore, its performance is more predictable than that of a Virtual Private Network (VPN).

There are two different flavours of Interconnect:

• Dedicated Interconnect provides direct physical connections between on-premises and Google’s networks.
• Partner Interconnect connects on-premises and Google’s networks through a supported service provider.

Note that you must procure and own the Cloud Interconnect, not Teradata.

Furthermore, you must use the Interconnect with either VPC Network Peering or VPN for the Cloud-to-Cloud connection, as Google does not support cross-tenant Cloud Interconnect.

Note that Teradata supports a Direct Interconnect between your on-prem site and the VaaS account.

VPN

Cloud VPN securely connects an on-premises network to a Virtual Private Cloud (VPC) network through an IPsec (Internet Protocol security encrypted tunnel) VPN connection in a single region. A VPN Gateway encrypts the traffic between the two, and another VPN Gateway decrypts it. Thus, the VPN protects your data as it travels over the internet.

Actually, the VPN is the only connectivity method that is encrypted at the route level by default.

You can use a VPN for the on-Premises-to-Cloud connection instead. However, remember that it has a lower bandwidth than an Interconnect and is less predictable in performance.

A virtual private network (VPN) can connect on-premises networks to the cloud, but it can also connect different VPCs within the cloud, different cloud service providers, and two instances of Cloud VPN to each other.

You may also configure application-level encryption on top of the IPsec route-level encryption (e.g., TLS 1.2 encryption for TTU drivers).

On a separate note, a VPN allows bidirectional traffic. You can secure your network by firewalling your site (on-prem data centre or GCP account).

Cloud-to-Cloud connection

We call the Teradata Lake account communication with your GCP account the “handshake”. It is your means to access your data, load more and consume it. Thus, this connection must:

1. Be secure,
2. Be fast and handle large amounts of data, and
3. Preserve the built-in parallelism in Vantage when possible. Letting the database handle the workload will improve its performance.

Private Service Connect

The Private Service Connect provides private connectivity between VPCs, GCP services, and on-premises networks without exposing traffic to the public internet or opening networks to one another.

Also, in the case of the Private Service Connect, the traffic between the virtual network and the service travels the Google backbone network.

The Private Service Connect lets you securely connect a VPC to Teradata VantageCloud Lake with a uni-directional traffic pattern. Thus, session traffic is initiated only from your side of the link, and VantageCloud Lake can’t start a connection back into your network.

Consequently, there is no need to configure firewall rules or special routing tables since the two sides of the network are not directly joined.

As for security, Private Service Connect does not encrypt traffic because it is a private circuit — data does not flow on the public Internet. You can configure application-level encryption to encrypt data over a Private Service Connect (e.g., TLS 1.2 encryption for TTU drivers).

On a separate note, if you want to use LDAP, which requires bi-directional traffic between your GCP account and the Vantage one, you must create a reverse Private Service Connect and manually set up the LDAP configuration in the Session Manager. They will allow VantageCloud Lake to initiate traffic into your network.

QueryGrid or Data Copy also need bidirectional traffic. They require two separate Private Service Connects, one for reverse traffic.

Additionally, if you need your Lake instance to contact one of your object stores with OTFs, you will require a reverse Private Service Connect. Note that if you require cross-cloud access, NOS and OTF requests will currently be gateway through the Valtix-controlled egress and ingress traffic, which may represent a bottleneck.

Public Internet

Notably, you can connect third-party applications and Viewpoint through the public internet. However, other solutions, such as QueryGrid or LDAP, must communicate with VantageCloud Lake through Private Service Connect.

To access your VantageCloud Lake account through the public internet, you must provide the source CIDR block to whitelist access in the Console. Note that Lake doesn’t allow whitelisting of 0.0.0.0/0 CIDR block.

Bear in mind that you won’t need to perform additional network changes if you allow the source to access the public Internet.

However, if you are accessing Lake outside your company network, you should use your company’s VPN to route traffic from the allowed CIDR block.

API Calls to NOS Buckets and OTFs

You can read (and write) with VantageCloud Lake from Google Cloud Storage through a Teradata feature called NOS (Native Object Storage) Reads (and Writes). Additionally, Teradata supports reading and writing from data stored in Open Table Format (OTF).

To access Cloud Storage, you have to use its APIs. The Cloud Storage API calls run through the public internet by default, protected with an HTTPS protocol.

To secure Cloud Storage connections, Teradata leverages Private Google Access to connect to Cloud Storage. Teradata configures the database’s virtual machines with internal IP addresses only (they don’t have public IPs) and has Public Google Access enabled.

Private Google Access means that when you call the Cloud Storage API from VantageCloud Lake, the connection will use the Cloud Storage API endpoint over Google’s private network backbone. Thus, data never transfers through the public internet when you use NOS Reads and Writes or OTFs from Teradata VantageCloud Lake. Note that Public Google Access protects the Cloud Storage API calls whether you access a Cloud Storage bucket in the same region as Lake or in a different one. However, if you access a bucket in another region, you will incur egress costs. You will also likely have a larger latency than when you access a bucket in the same region.

For your information, Google offers multiple options to route Cloud Storage traffic through its backbone instead of through the public Internet, including the one Teradata uses with VantageCloud — specifically, Private Google Access.

Main security elements in VantageCloud architecture

In terms of security, there are five key aspects of VantageCloud Lake architecture:

• Teradata configures the Compute Engine virtual machines that run the VantageCloud Lake instances with internal IP addresses only, i.e., they don’t have public IPs.
• These virtual machines’ Virtual Networks have Azure Private Endpoints enabled.
• NOS traffic initiated from these virtual machines goes to an Cloud Storage API endpoint.
• With Private Service Connect enabled, the Cloud Storage bucket will use an internal IP provided by the Teradata account, while Lake and the bucket are in the same region.
• Teradata configures VantageCloud Lake to use the HTTPS call by default.

You have all the details in the NOS Orange Book to read and write data in NOS storage.

Network & Encryption

All Teradata network connections can be encrypted. Some examples of connectivity encryption options are:

• Protocol transit encryption for SQLe (Quality of Protection [QOP] or TTU v17.10 + TLS).
• All HTTP interfaces will be HTTPS (such as Viewpoint).
• By default, all the SQLe traffic is encrypted with Teradata-provided cypher on the 1025 port and TLS1.2 certificate on the 443 port.

Teradata Clients (Teradata Tools and Utilities) are not specific to any Cloud Service Provider. However, when you consider the security of your connections, you can enable TLS on TTUs 17.10 and above. Moreover, you can enable Teradata generic encryption (256 bits) for TTUs 16.20 onwards.

Other Service Cloud Providers

You can also find posts and cheat sheets on connecting VantageCloud Lake on AWS and Azure in this blog.