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 Azure with your account. It also describes the Azure 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 Azure

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

Azure Connectivity Options for VantageCloud Lake

On Prem-to-Cloud connection

Azure ExpressRoute

Azure ExpressRoute links an internal network to an Azure ExpressRoute location over a standard Ethernet fibre-optic cable. One end of the cable is connected to your router in your data centre, and the other to an Azure ExpressRoute router. From this connection, you can create virtual interfaces directly to public Azure services (e.g., Blob Storage, Azure Data Lake Storage, etc.) or a VNet, bypassing internet service providers in the network path.

ExpressRoute is the primary method customers use to connect on-prem networks to their Azure networks. It is also Teradata’s preferred option because it provides higher bandwidth and more predictable performance than a VPN.

Azure ExpressRoute is available at speeds starting at 50 Mbps and scaling up to 10 Gbps. Thus, you must know what bandwidth you’ll have to plan for migrations and regular operations with VantageCloud Lake on Azure.

Furthermore, you can connect multiple ExpressRoute circuits to a VNet if you need more than 10 Gbps connectivity. – The default limit is 10, and you can achieve up to 100 Gbps.

On a separate note, you can connect an ExpressRoute Gateway to the VNet, which allows traffic to flow between the edge router and the individual Vnet.

The speeds that the Gateway allows, the number of circuits it can support, and its cost will depend on the Stock Keeping Unit (SKU) you choose for the individual Gateway.

Alternatively, you can directly route traffic from an ExpressRoute to VantageCloud Lake or through an Azure Private Link.

Regarding security, Azure ExpressRoute does not encrypt traffic by default because it is a private circuit. I.e., data does not flow over the public internet.

To encrypt data over an ExpressRoute, you can:

• Configure application-level encryption (e.g., TLS 1.2 encryption for TTU drivers),
• Deploy an Azure VPN over the ExpressRoute to create an IPsec-encrypted tunnel, or
• Leverage MACsec for Layer 2 encryption over an ExpressRoute Direct connection (only available in specific locations and at high bandwidths).

Consider that Teradata can initiate traffic over an ExpressRoute into your network. Thus, to secure this connection, you should place a firewall in either the co-location data centre (e.g., Equinix) or the on-premises customer data centre.

Azure Site-to-Site VPN

A Virtual Private Network (VPN) extends a private network across a public network. It enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network.

So, an Azure Site-to-Site VPN can connect on-premises networks to the cloud, attach two cloud service providers, and link different VNets within the cloud. Nevertheless, Teradata does not support these two last patterns.

While you can use an Azure Site-to-Site VPN for the On Prem-to-cloud connection, it has a lower bandwidth than an Azure ExpressRoute. Moreover, its performance is less predictable since it runs over the public internet.

Regarding security, a VPN is the only connectivity method encrypted at the route level by default. Azure Site-to-Site VPNs support Internet Protocol security (IPsec) encrypted tunnels. Also, you can 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, Site-to-Site VPNs allow bidirectional traffic. Thus, it would be best to secure this connection through a firewall in your on-premise data centre.

Cloud-to-Cloud connection

We call the Teradata Lake account communication with your Azure 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.

Azure Private Link

The Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database). It also lets you access Azure-hosted customer-owned or partner services over a private endpoint in your virtual network.

Also, in the case of the Azure Private Link, the traffic between the virtual network and the service travels the Microsoft backbone network.

Azure Private Link lets you securely connect a VNet to Teradata VantageCloud Lake with a uni-directional traffic pattern. Thus, you start the session traffic 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 Link 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 Link (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 Azure account and the Vantage one, you must create additional Private Links (sometimes referred to as “Reverse Private Links” or “Customer Private Links”). They will allow VantageCloud Lake to initiate traffic into your network.

QueryGrid or Data Copy also need bidirectional traffic. However, Teradata configures them on your behalf in the VantageCloud Lake account with bridge nodes instead of Reverse Private Links. The bridge nodes allow aggregating traffic and reducing the number of Private Links. This architecture requires that you deploy a server in your VPC.

Additionally, if you need your Lake instance to contact one of your object stores with OTFs, you will require a reverse Private Link. 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 Link.

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 Azure Blob Storage and ADLS Gen2 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 Blob Storage, you have to use its APIs. By default, the Azure Blob Storage API calls run through the public Internet.

Teradata leverages Virtual Network service endpoints to secure Blob Storage and ADLS Gen2 connections with its VantageCloud systems. Additionally, Teradata configures the database’s virtual machines with internal IP addresses only (they don’t have public IPs). They also have service endpoints enabled. Thus, the traffic will travel through the Azure backbone network when you call the Blob Storage and ADLS Gen2 API from Teradata VantageCloud Lake, with the bucket and Lake in the same region. I.e., data never transfers through the public internet when you use NOS Reads and Writes from Teradata VantageCloud Lake into a Blob Storage or ADLS Gen2 bucket in the same region as Lake.

Note that the Blob Storage, ADLS Gen2 and VNet service endpoints are regional resources. So, the Blob Storage and ADLS Gen2 API calls always run on the public internet if you access a bucket in a region different from VantageCloud Lake. You will also likely have a larger latency than when you access a bucket in the same region.

On a separate note, as per the Azure Pricing Calculator, reading from the Blob Storage or ADLS Gen2 buckets generally does not incur egress costs, but Azure charges based on reads and writes, among other factors.

Incidentally, when you copy DSA Backups or Snapshots from a bucket within the Vantage account and another bucket, you also use Azure Blob Storage or ADLS Gen2 APIs. Therefore, the discussion in this section about where the traffic goes when you read from buckets also applies to this scenario.

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 Azure Bob Storage or ADLS Gen2 API endpoint.
• With Private Endpoints enabled, the Blob Storage oe ADLS Gen2 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 GCP in this blog.

I updated this article on 25 July 2024 to add the link to the post about network configuration for VantageCloud Lake on GCP.