When you purchase a Teradata VantageCloud Enterprise instance on the Azure Cloud Platform (Azure) as a managed service (VaaS), Teradata provisions your instance in its own project within a Teradata account on Azure.

This post presents a cheat sheet summarising the key elements of the network setup that you must choose to connect your VaaS instance on Azure with your account, and the Azure services Teradata supports for the connections. Additionally, you can find below an explanation of all of them.

Cheat Sheet for the Network options for VaaS on Azure

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

Network components in detail

Azure Connectivity Options Teradata supports for VaaS

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, 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 to a VNet, bypassing internet service providers in the network path.

ExpressRoute is customers’ primary method 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 Enterprise 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 the cost of the Gateway will depend on the Stock Keeping Unit (SKU) you choose for the individual Gateway.

Alternatively, you can route traffic from an ExpressRoute to VantageCloud Enterprise directly or through a VNet Peering connection, a VWAN or an Azure Private Link instead.

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 doesn’t support this later pattern.

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).
As for bi-directional traffic, Teradata can initiate traffic over a Site-to-Site VPN into your network. Thus, securing this connection through a firewall in your on-premise data centre would be best.

Cloud-to-Cloud connection

We call the Teradata VaaS 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, as your workload will perform better by letting the database handle the workload.

VNet Peering

Virtual network peering enables you to seamlessly connect two or more Virtual Networks in Azure. The Virtual Networks appear as one for connectivity purposes.

As you know, the traffic between virtual machines in peered Virtual Networks uses the Microsoft backbone infrastructure. Like traffic between virtual machines in the same network, Microsoft only routes VNet Peering traffic through Microsoft’s private network.

Azure supports the following types of peering:

• Virtual network peering: Connect Virtual Networks within the same Azure region.
• Global virtual network peering: Link Virtual Networks across Azure regions.

Since a VNet Peering joins two VNets together to act as one larger network, bi-directional traffic flows between both Vnets. Thus VantageCloud Enterprise can initiate connections into your network. So the VNets must have unique CIDR ranges to avoid IP conflicts and routing issues.

To secure access to resources in a VNet, you can create Route Tables and Network Security Groups (NSGs) to limit IP and port access.

• Route Tables: They segment a network by creating one route table per subnet within the virtual network.
• Network Security Groups / Firewalls
  • Teradata has a policy of “deny by default” in our VNets – you define what in and out traffic to allow.
  • You can configure Network Security Groups and/or firewalls in your Vnets.

Furthermore, Microsoft doesn’t encrypt the VNet Peering; its traffic only travels over Azure’s private internal network and is never exposed to the internet. However, if you want to encrypt data over VNet Peering, you can configure application-level encryption (e.g., TLS 1.2 encryption for TTU drivers).

VWAN

Azure Virtual WAN is a networking service that simplifies network architecture by offering a mesh network topology with transitive network connectivity among spokes. I.e., it is a managed service provided by Microsoft that brings networking, security, and routing functionalities together to give a single operational interface.

From the perspective of Teradata VantageCloud Enterprise, VWAM has the same characteristics discussed for the Vnet Peering.

Cloud VPN

Otherwise, you can also use a VPN for the handshake, even though it has lower bandwidth than VNet Peering and its performance is less predictable.

See the Azure Site-to-Site VPN above for more details.

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.

Unlike Vnet Peering, VWAN and the VPN, Azure Private Link lets you securely connect a VNet to Teradata VantageCloud Enterprise with a uni-directional traffic pattern. Thus, you start the session traffic from your side of the link, and Teradata 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.

However, the Azure Private Link was not designed for MPP systems like Teradata. Private Link negatively impacts VantageCloud Enterprise’s capacity to balance the workload. Unless you apply a workaround on all your workloads, you will suffer performance degradation of the queries running within Teradata.

As for security, Private Link does not encrypt traffic because it is a private circuit. I.e., 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 a solution that requires bi-directional traffic between your Azure account and the Vantage one, such as LDAP, Query Grid, or Data Mover, you must create additional Private Links. They will allow Teradata to initiate traffic into your network.

Additionally, QueryGrid can leverage bridge nodes to aggregate traffic and reduce the number of Private Links. However, this architecture requires that you deploy a server in your VPC.

Finally, you may also need multiple Private Links to address routing limitations to route the traffic properly, such as with Viewpoint (port 443) and Editor (port 443).

NOS Reads

You can read (and write) with VaaS from Azure Blob Storage through a Teradata feature called NOS (Native Object Storage) Reads (and Writes).

To access Blob Storage, you have to use its APIs. The Azure Blob Storage API calls run through the public internet by default.

Teradata leverages Virtual Network service endpoints to secure Blob Storage 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, when you call the Blob Storage API from Teradata VantageCloud Enterprise, both the bucket and Enterprise in the same region, the traffic will travel through the Azure backbone network. I.e., data never transfers through the public internet when you use NOS Reads and Writes from Teradata VantageCloud Enterprise into a Blob Storage bucket in the same region as Enterprise.

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

Nevertheless, Teradata enables a Global Endpoint while provisioning your VaaS instance. So, the traffic does not leave the Microsoft backbone independently from where data is read during the deployment.

On a separate note, as per the Azure Pricing Calculator, there are no egress costs, in general, to read from the Blob Storage buckets, but Azure charges based on reads and writes, as well as 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 APIs. Therefore, the discussion in this section about where the traffic goes when you read from buckets also applies to this scenario. For example, when you use the Cross-Site and Cross-Region Restores.

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

• Teradata configures the Compute Engine virtual machines that run the VantageCloud database 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 API endpoint.
• With Private Endpoints enabled, the Blob Storage bucket will use an internal IP provided by the Teradata account, while Enterprise and the bucket are in the same region.
• Teradata configures VantageCloud Enterprise to use the HTTPS call by default.

If you want to read and write data in NOS storage, you have all the details in the NOS Orange Book.

CIDR Ranges

CIDR (Classless Inter-Domain Routing) is a method for allocating IP addresses. For example, if we have 10.0.0.0/31, it represents an IP range where:

• 31 is a prefix we use to calculate the number of consecutive IPs.
• Range calculation: IPs: 10.0.0.0 and 10.0.0.1.

You must negotiate a CIDR range with Teradata to connect Vantage with your network. You must provide an RFC 1918 CIDR range. Alternatively, you can ask Teradata to provide it (Teradata owns a large CIDR space which is not public). But before allocating a CIDR range, Teradata must confirm the size for a specific environment.

Consider that the Teradata CIDR Range could be publicly routable if you ask Teradata to provide the IPs. However, it is privately routed over a VPC network peering connection or a VPN tunnel.

In any case, ensure that the IP addresses will never conflict with any other of your addresses.

Network & Encryption

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

• Protocol transit encryption for SQL-E (Quality of Protection [QOP] or TTU v17.10 + TLS).
• All HTTP interfaces will be HTTPS (such as Viewpoint).
• If you set up TLS negotiation with supported clients (TTU drivers) using TLS 1.2, you encrypt all ingress and egress traffic from/ to external components to Vantage components.

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.

You must use Azure Key Vault to manage encryption keys for both Platform-Managed Keys (PMKs) and Customer Managed Keys (CMK).

In the particular case of CMK, you generated in your Azure project. These keys must be used in a Teradata-owned Azure project, where the Vantage system will be provisioned. So you must create a key within a key-vault and share the key-vault with Teradata.

To learn more about VantageCloud Enterprise’s encryption keys, read the post Teradata Enterprise: Ins and Outs of the Encryption Keys.

Other Service Cloud Providers

You can also find in this blog a post and its cheat sheet to connect VantageCloud Enterprise as a Service to a GCP or an AWS account.

This article was updated on 19 July 2023 to add the link to the post about the network options for VantageCloud Enterprise on AWS.

This post was updated on 25 September 2023 to revise the ports in the cheat sheet.

I updated this post on 2 October 2023 to correct the NOS Read section. Teradata uses Service Endpoint to protect the Blob Storage API calls, not Private Endpoints, as I previously said. I corrected the diagram accordingly.

I updated this article again on 26 December 2023 to add a link to the post Teradata Enterprise: Ins and Outs of the Encryption Keys.

I included the comment that the traffic in Azure always runs within the backbone for the NOS reads during the deployment on 17 June 2024.