Amazon Redshift Private Link

Introduction

Rivery is a multi-tenant SaaS platform that offers secure and efficient connectivity to various AWS services, including Redshift, while keeping traffic within the AWS network, avoiding exposure to the public internet.
Since Redshift is an AWS resource, it's advisable to establish the connection within the AWS backbone to enhance security, maintain full control over traffic, and achieve optimal network performance and cost efficiency.

This document explains the process of connecting Rivery to an AWS Redshift cluster residing in an external AWS account, utilizing the Redshift cluster endpoint through PrivateLink.

Provisioning a Redshift Endpoint

AWS Redshift offers a "built-in PrivateLink" option, which is the most recommended method for connecting to a Redshift cluster. This method ensures secure and private connectivity without exposing data to the internet.

Redshift Endpoint Requirements:

• Applicable only for RA3+ cluster types.
• Requires enabling the “cluster relocation” option. For details on relocating your cluster, refer to Amazon's documentation on Relocating your cluster.
• Ensure that general limitations on creating a cluster endpoint are met. You can review these in the AWS Redshift documentation: Cluster Endpoint Considerations.

Steps to Provision a Redshift Endpoint:

1. Access Redshift Console: Navigate to the Redshift Console and select the desired cluster.
   

2. Cluster Properties: Under the Properties tab, scroll down to Grant Accounts and select Grant Access.
   

3. Grant Access: In the Grant Access window, provide Rivery's AWS account ID and choose the option to grant access to all VPCs.

4. Endpoint Creation: Please submit a support ticket to the Rivery Support team, requesting them to create an endpoint on their side that will be used to establish a connection to your Redshift cluster.
5. Obtain Endpoint Details: Rivery will provide the endpoint details required for your Rivery connection configuration.

Provisioning a Redshift Interface-Type PrivateLink

An alternative and recommended approach is to provision a Redshift Interface-Type PrivateLink. This method exposes an endpoint service to the Redshift Cluster Network Interface (NI), allowing for secure communication within the AWS network.

Network Interface Behavior in a Multi Availability Zones Deployment

• Primary and Secondary Availability Zones:

• Initially, a single Network Interface (NI) is associated with the primary Availability Zones. If a failover occurs, and the cluster switches to a secondary Availability Zones, a new NI is created for the new Availability Zones.

• The original NI IP address remains functional, and the new NI IP address can be added to the Target Group. It's crucial to update the Network Load Balancer (NLB) to incorporate the corresponding Availability Zones.

• Persistent Network Interfaces:

• Once created, the NIs are expected to remain the same for their respective AZs, even after failovers. However, while this behavior has been observed in testing, it is not officially documented by AWS.

Steps to Provision Redshift Interface-Type PrivateLink:

1. Access Redshift Console: Select the desired Redshift cluster in the AWS Redshift Console.
   

2. Use IP Addresses from Network Interfaces: Under Properties, use the IP addresses from the Redshift cluster’s Network Interfaces. While IPs listed in the Node IP addresses section will work, they are more likely to change.

3. Follow AWS PrivateLink Guidelines: Refer to the Rivery documentation on AWS PrivateLink to complete the process. Based on internal testing, it is noted that there is no need to provision a DNS update Lambda for Redshift as required in some AWS documentation, although this is not guaranteed by AWS.