From 284a1a583972d8fa26af3413f34f3d9a2294e662 Mon Sep 17 00:00:00 2001 From: mich-elle-luna Date: Thu, 10 Sep 2026 13:53:25 -0700 Subject: [PATCH 1/4] Document connecting to PrivateLink from on-premises The guide only covered consumers inside the consumer VPC and didn't explain that the console's public endpoint hostname resolves to the Redis-managed VPC address outside that VPC by design. A customer connecting from on-premises over Direct Connect read this as PrivateLink being broken (Zendesk 169592). Add a note on what the hostname resolves to and why, plus a "Connect from on-premises" section covering the resource endpoint's default DNS name, a CNAME to the public endpoint hostname, and a Route 53 Resolver inbound endpoint, with the TLS certificate-verification requirement that decides between them. --- .../operate/rc/security/aws-privatelink.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/content/operate/rc/security/aws-privatelink.md b/content/operate/rc/security/aws-privatelink.md index dbd1a3addd..1541e84011 100644 --- a/content/operate/rc/security/aws-privatelink.md +++ b/content/operate/rc/security/aws-privatelink.md @@ -181,6 +181,36 @@ You can connect to your database by using the database `private-dns-entry` and ` After you've connected to your database, you can view the connection details in the Redis Cloud console in your subscription's **Connectivity > PrivateLink** tab or by going to the [connection wizard]({{< relref "/operate/rc/databases/connect" >}}) for your database. The private endpoint will point to the PrivateLink VPC resource endpoint or service network that you created. +{{< note >}} +The connection wizard and other parts of the console show your database's [public endpoint]({{< relref "/operate/rc/databases/connect" >}}), which is different from the `private-dns-entry` the discovery script returns. The public endpoint hostname is publicly resolvable and, by default, returns your database's address inside the Redis-managed VPC. That's correct behavior, and it's what [VPC peering]({{< relref "/operate/rc/security/vpc-peering" >}}) and [Transit Gateway]({{< relref "/operate/rc/security/aws-transit-gateway" >}}) consumers rely on. For PrivateLink, that address is overridden only inside your consumer VPC, by the private hosted zone that AWS creates there. Resolving the public endpoint hostname from anywhere else — including from on-premises over Direct Connect or a VPN — returns the unreachable Redis-managed VPC address, not an error. Use the database's `private-dns-entry` from your consumer VPC, or see [Connect from on-premises](#connect-from-on-premises) if you're connecting from outside it. +{{< /note >}} + +## Connect from on-premises + +The private hosted zone that overrides the public endpoint hostname inside your consumer VPC doesn't extend to on-premises networks connected over Direct Connect or a VPN, even though they can reach the consumer VPC. Use one of the following approaches instead. + +Certificate verification decides which approach you need. Redis Cloud issues server certificates for its own hostnames, not for AWS-owned PrivateLink hostnames. If you use TLS, or expect to, your connection string must use the database's public endpoint hostname so that certificate verification succeeds, which means you need one of the two DNS-based approaches below. If you don't use TLS, you can connect directly with the resource endpoint's default DNS name. + +### Use the resource endpoint's default DNS name + +AWS documents this as a supported way to reach a resource endpoint from on-premises, not a workaround: + +> DNS requests from outside the VPC still return the private IP addresses of the resource endpoint's network interfaces. You can use these DNS names to access the resource from on premises, as long as you have access to the VPC that the resource endpoint is in, through VPN or Direct Connect. + +Find the resource endpoint's default DNS name in the AWS console, under the endpoint's details, and use it directly in your connection string. This requires no DNS configuration on either side, but it doesn't work with TLS, because the hostname doesn't match your database's certificate. + +### Add a CNAME to the public endpoint hostname + +If you want to keep using the database's public endpoint hostname, including with TLS, create a CNAME record in your own DNS that points the hostname to the resource endpoint's default DNS name. This needs one DNS record and no changes on the AWS or Redis Cloud side. + +Use a CNAME record, not an A record to the resource endpoint's network interface addresses. Those addresses aren't guaranteed to stay the same if the resource endpoint is recreated. + +### Use a Route 53 Resolver inbound endpoint + +For a fully AWS-native setup, create a [Route 53 Resolver inbound endpoint](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) in the consumer VPC and configure conditional forwarding from on-premises for your database's public endpoint domain. This also works with TLS, since it resolves the same public endpoint hostname your certificate expects. See [Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-aws-transit-gateway-with-aws-privatelink-and-amazon-route-53-resolver/) for the reference architecture. + +Route 53 Resolver endpoints are billed per elastic network interface per hour, with a two-interface minimum. See [Amazon Route 53 pricing](https://aws.amazon.com/route53/pricing/). This option costs more than a CNAME record, so it suits consumers of several PrivateLink services rather than a single database. + ## Disassociate connection To disassociate a PrivateLink connection: From ef2752d6d68e2bd07dc8ae6fa06f513e28bacc0e Mon Sep 17 00:00:00 2001 From: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com> Date: Fri, 11 Sep 2026 12:11:46 -0700 Subject: [PATCH 2/4] Update content/operate/rc/security/aws-privatelink.md Co-authored-by: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> --- content/operate/rc/security/aws-privatelink.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/operate/rc/security/aws-privatelink.md b/content/operate/rc/security/aws-privatelink.md index 1541e84011..f41ae929a9 100644 --- a/content/operate/rc/security/aws-privatelink.md +++ b/content/operate/rc/security/aws-privatelink.md @@ -187,7 +187,7 @@ The connection wizard and other parts of the console show your database's [publi ## Connect from on-premises -The private hosted zone that overrides the public endpoint hostname inside your consumer VPC doesn't extend to on-premises networks connected over Direct Connect or a VPN, even though they can reach the consumer VPC. Use one of the following approaches instead. +The private hosted zone that overrides the public endpoint hostname inside your consumer VPC doesn't extend to on-premises networks connected over Direct Connect or a VPN, even though they can reach the consumer VPC. The sections below describe other approaches that you can use instead. Certificate verification decides which approach you need. Redis Cloud issues server certificates for its own hostnames, not for AWS-owned PrivateLink hostnames. If you use TLS, or expect to, your connection string must use the database's public endpoint hostname so that certificate verification succeeds, which means you need one of the two DNS-based approaches below. If you don't use TLS, you can connect directly with the resource endpoint's default DNS name. From a8819425f09a6cd228b370bba11cd316a2367858 Mon Sep 17 00:00:00 2001 From: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com> Date: Fri, 11 Sep 2026 12:12:21 -0700 Subject: [PATCH 3/4] Update content/operate/rc/security/aws-privatelink.md Co-authored-by: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> --- content/operate/rc/security/aws-privatelink.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/operate/rc/security/aws-privatelink.md b/content/operate/rc/security/aws-privatelink.md index f41ae929a9..52509bd25b 100644 --- a/content/operate/rc/security/aws-privatelink.md +++ b/content/operate/rc/security/aws-privatelink.md @@ -195,6 +195,7 @@ Certificate verification decides which approach you need. Redis Cloud issues ser AWS documents this as a supported way to reach a resource endpoint from on-premises, not a workaround: +> [!NOTE] > DNS requests from outside the VPC still return the private IP addresses of the resource endpoint's network interfaces. You can use these DNS names to access the resource from on premises, as long as you have access to the VPC that the resource endpoint is in, through VPN or Direct Connect. Find the resource endpoint's default DNS name in the AWS console, under the endpoint's details, and use it directly in your connection string. This requires no DNS configuration on either side, but it doesn't work with TLS, because the hostname doesn't match your database's certificate. From 0e3db61a2f0873578bbef999349b50e3b194e583 Mon Sep 17 00:00:00 2001 From: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com> Date: Fri, 11 Sep 2026 12:12:43 -0700 Subject: [PATCH 4/4] Update content/operate/rc/security/aws-privatelink.md Co-authored-by: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> --- content/operate/rc/security/aws-privatelink.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/operate/rc/security/aws-privatelink.md b/content/operate/rc/security/aws-privatelink.md index 52509bd25b..0ec4066b2e 100644 --- a/content/operate/rc/security/aws-privatelink.md +++ b/content/operate/rc/security/aws-privatelink.md @@ -204,7 +204,7 @@ Find the resource endpoint's default DNS name in the AWS console, under the endp If you want to keep using the database's public endpoint hostname, including with TLS, create a CNAME record in your own DNS that points the hostname to the resource endpoint's default DNS name. This needs one DNS record and no changes on the AWS or Redis Cloud side. -Use a CNAME record, not an A record to the resource endpoint's network interface addresses. Those addresses aren't guaranteed to stay the same if the resource endpoint is recreated. +Add a CNAME record, not an A record to the resource endpoint's network interface addresses. Those addresses aren't guaranteed to stay the same if the resource endpoint is recreated. ### Use a Route 53 Resolver inbound endpoint