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

This post presents a cheat sheet summarising the key elements of the network setup you must choose to connect your VaaS instance on AWS with your account. It also describes the AWS 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 AWS

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

Network components in detail

AWS Connectivity Options Teradata supports for VaaS

On Prem-to-Cloud connection

AWS Direct Connect

An AWS Direct Connect links an internal network to an AWS Direct Connect location over a standard Ethernet fibre-optic cable. One end of the cable is connected to one of your routers, the other to an AWS Direct Connect router. From this connection, you can create virtual interfaces to public AWS services (e.g., Amazon S3) or a VPC, bypassing internet service providers in the network path.

AWS Direct Connect is available starting at speeds of 50 Mbps and scaling up to 100 Gbps. Thus, you must know what bandwidth you’ll have to plan for migrations and regular operations with VantageCloud Enterprise on AWS.

There are two types of AWS Direct Connect connections:

• Dedicated Connection: A physical Ethernet connection associated with a single customer. Available port speeds are 1 Gbps, 10 Gbps, and 100 Gbps.
• Hosted Connection: A physical Ethernet connection that an AWS Direct Connect Partner (e.g., Megaport) provisions on behalf of a customer. Available port speeds range from 50 Mbps to 10 Gbps.

Every type of connection has different limitations:

• Dedicated Connections support up to 50 Virtual Interfaces (VIFs) and one Transit VIF (interface to a Transit Gateway).
• Hosted Connections support only one VIF of any type. You may find it challenging to design a workaround for this limitation in a complex architecture with multiple Vantage systems.

Regarding encryption, the AWS Direct Connect 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 a Direct Connect, you can:

• Configure application-level encryption (e.g., TLS 1.2 encryption for TTU drivers),
• Deploy an AWS Site-to-Site VPN over the Direct Connect to create an IPsec-encrypted tunnel, or
• Leverage MACsec for Layer 2 encryption over a Dedicated Direct Connect . – Only available in specific locations and at high bandwidths, consult AWS documentation.

Consider that Teradata can initiate traffic over a Direct Connect into your network. Thus, to secure this connection, you should place a firewall in either the co-location data centre or the on-premises customer data centre.

AWS 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 they have connected their computing devices directly to the private network.

So, an AWS Site-to-Site VPN can connect on-premises networks to the cloud. It can also attach two cloud service providers. Additionally, it can link different VPCs within the cloud (although the Teradata CloudOps team does not approve this pattern).

While you can use an AWS Site-to-Site VPN for the On Prem-to-cloud connection, it has a lower bandwidth than an AWS ExpressRoute, and 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. AWS 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 “handshake” the communication between the Teradata VaaS account and your AWS account, and 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.

AWS Transit Gateway

An AWS Transit Gateway is a network transit hub that you can use to interconnect your VPCs, vendor VPCs, VPNs, and on-premises networks, all through one central hub. The Transit Gateway simplifies the network topology and reduces complex peering relationships. It acts as a cloud router – each new connection is only made once.

AWS recommends this method for interconnecting multiple VPCs, VPNs, and Direct Connects.

So an AWS Transit Gateway (TGW) is a hub and spoke design that enables bi-directional traffic between connected networks. In other words, a Teradata VPC can initiate traffic back into your network. Thus, to secure your account, you must use:

• Route Tables: You can segment the network by creating multiple TGW route tables (similar to VRFs on-prem).
• NACLs/ Security Groups/ Firewalls: Teradata has a “deny by default” policy in their VPCs. You define what you allow in and out. You can configure NACLs, Security Groups, and/or firewalls in any network attached to the TGW.
• Inspection VPC attached to TGW: All traffic entering the TGW is first inspected in a dedicated VPC.

As for encryption, a Transit Gateway does not encrypt traffic because it is a private circuit (i.e., data does not flow over the public internet). You can configure application-level encryption to encrypt data over a Transit Gateway (e.g., TLS 1.2 encryption for TTU drivers).

VPN

Otherwise, you can also use a VPN for the handshake, even though it has lower bandwidth than Transit Gateway and performs less predictably.

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

AWS PrivateLink

AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-premises networks without exposing traffic to the public internet or opening networks to one another.

PrivateLink endpoints appear inside the customer network with private IPs as if they are a part of their internal network. I.e., the traffic between the virtual network and the service travels the AWS backbone network.

Unlike the Transit Gateway, the VPN and the Direct Connect, the AWS PrivateLink lets you securely connect a VPC to Teradata VantageCloud Enterprise with a uni-directional traffic pattern. Thus, session traffic is initiated only 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 AWS PrivateLink was not designed for MPP systems like Teradata. PrivateLink negatively impacts VantageCloud Enterprise’s capacity to balance the workload. Unless you apply a workaround on all your workloads, you will suffer a performance degradation of the queries running within Teradata.

As for security, PrivateLink 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 AWS account and the Vantage one, such as LDAP, Query Grid, or Data Mover, you must create additional PrivateLinks (sometimes referred to as “Reverse PrivateLinks” or “Customer PrivateLinks”). They will allow Teradata to initiate traffic into your network.

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

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

Direct Connect with Hoterd Private Virtual Interfaces (VIF ) or with VPN Gateway

This option is ideal for connecting your on-prem data centre to the Vantage account with fewer network hops.

It is easy to configure and support, but you would need a separate path for cloud-to-cloud traffic.

NOS Reads

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

To access an S3 bucket, you have to use its APIs. The AWS S3 API calls run through the public internet by default.

Teradata leverages AWS Gateway VPC Endpoints to secure the connections to AWS S3 buckets 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 Gateway Endpoints enabled. Thus, when you call the S3 API from Teradata VantageCloud Enterprise, both the bucket and Enterprise in the same region, the traffic will travel through the AWS backbone network. I.e., data never transfers through the public internet when you use NOS Reads and Writes from Teradata VantageCloud Enterprise into an S3 bucket in the same region as Enterprise.

Note that the S3 endpoint and the Gateway Endpoint are regional resources. So, the S3 API calls always run on the public internet if you access an S3 bucket in a region different from Vantage. You will also incur egress costs with cross-region reads as per the AWS Pricing Calculator. Furthermore, you will likely have a larger latency than when you access a bucket in the same region.

Incidentally, when you copy DSA Backups or Snapshots from a bucket within the Vantage account and another bucket, you also use AWS S3 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’ VPCs have AWS Gateway VPC Endpoints enabled.
• NOS traffic initiated from these virtual machines stays within Teradata’s Virtual Network and goes to an AWS S3 API endpoint.
• With Gateway Endpoints enabled, the AWS S3 API endpoint IP will resolve to an internal address, 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 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 can either provide an RFC 1918 CIDR range or 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 if you ask Teradata to provide the IPs, the Teradata CIDR Range could be publicly routable, even though 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 it up, all ingress and egress traffic from/ to external components to Vantage components can be encrypted using TLS negotiation with supported clients (TTU drivers) using TLS 1.2.

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

Regarding encryption keys, you must use AWS KMS to manage them for both AWS-Managed Keys and Customer Managed Keys (CMK).

In the particular case of CMK, they are generated in your AWS project. However, they will be used in a Teradata-owned AWS project, where the Vantage system will be provisioned per the contractual agreement for the VaaS service. So you must exchange the certificates with Teradata for them to access the necessary keys.

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 Azure one.

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

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.