AWS PrivateLink Overview

Some builds and tests need things that live inside your network: a private package registry, an internal artifact store, a staging API, a feature-flag service. AWS PrivateLink lets Revyl reach those services privately, over the AWS backbone, without a VPN, VPC peering, or any public ingress on your side.

​

When to use it

If your service is already reachable from the internet and protected by authentication, an IP allowlist is the simpler option.

​

How it works

You are the service provider and Revyl is the service consumer, in AWS PrivateLink terms.

1. You put the service behind an internal Network Load Balancer (NLB) and publish it as a VPC endpoint service.
2. You allow Revyl’s AWS account to connect to that endpoint service, and nothing else.
3. Revyl creates an interface VPC endpoint for your service in Revyl’s AWS account. You approve the connection request.
4. Revyl’s egress gateway routes traffic for your hostnames from your Revyl workloads to that endpoint.

Connections are one way. Revyl can open connections to the listeners on your NLB; nothing in your VPC is reachable beyond those listeners, and nothing in Revyl’s network becomes reachable from yours.

​

Security model

​

Regions and Availability Zones

Revyl’s PrivateLink consumer runs in us-west-2.

• Same region (recommended). Host your endpoint service in us-west-2.
• Another region. AWS supports cross-region PrivateLink. Add us-west-2 to your endpoint service’s supported Regions and tell Revyl the service’s home region. Expect inter-region data transfer charges and some added latency. Cross-region endpoints need no zone alignment, so keep your NLB in at least two zones of its own region and skip the usw2-az2 requirements below.

Revyl’s interface endpoint runs in one Availability Zone: usw2-az2. Availability Zone names such as us-west-2a map to different physical zones in each AWS account, so match on the AZ ID, not the name. For a service in us-west-2, your NLB must have a subnet in usw2-az2; Revyl cannot create its endpoint otherwise. Keep subnets in your other zones too, for your own clients.

​

Cross-zone load balancing

For a service in us-west-2, every Revyl connection enters your NLB through its usw2-az2 node. AWS wires an interface endpoint to the load balancer node in the same zone, so this entry point does not move. With cross-zone load balancing off (the NLB default), each NLB node sends traffic only to targets in its own zone. For Revyl that means:

• Only your usw2-az2 targets serve Revyl. All Revyl load lands on them, however many healthy targets you run in other zones.
• No healthy targets in usw2-az2 means a blackhole. Revyl’s connections time out while the service looks healthy to your other clients.
• DNS failover does not help. When a zone has no healthy targets, the NLB removes that zone’s IP from its own DNS name. Revyl’s endpoint never resolves that name, so its traffic keeps arriving at the usw2-az2 node. The NLB only fails open to all zones once every zone is unhealthy.

With cross-zone load balancing on, the usw2-az2 node spreads Revyl’s connections across healthy targets in every enabled zone. A zone that empties during a deploy or scale-in no longer takes Revyl down with it. AWS bills regional data transfer for traffic that crosses zones.

​

Fronting an Application Load Balancer

You can register an existing ALB as the NLB’s target (an alb target group). It works, but there is a second load balancer in the path, and its zone behaviour stacks on top of the NLB’s.

• The ALB must be enabled in usw2-az2. AWS recommends keeping cross-zone load balancing off on an NLB that fronts an ALB, and you cannot change the attributes of an alb target group. So the usw2-az2 NLB node forwards only to the ALB’s usw2-az2 node. If the ALB has no node there, the result is the same blackhole as above.
• ALB target groups with cross-zone off turn imbalance into errors. Each ALB node then uses only its own zone’s targets. Every Revyl request hits your usw2-az2 targets: a few targets there run hot and slow, and an empty or fully unhealthy usw2-az2 returns 503 for every Revyl request.
• ALB cross-zone on (the default) trades errors for latency. Requests are balanced across all zones, but many cross a zone boundary after already passing through two load balancers.
• Results depend on where traffic enters. Your other clients arrive through every zone, while Revyl arrives through one. A zone imbalance among your targets can show up as slow responses or 503s for Revyl alone, while your dashboards look healthy.
• The NLB balances connections, not requests. It picks a path once per TCP connection. Long-lived keep-alive or HTTP/2 connections stay on that path until they close, so adding targets or fixing a zone does not move traffic that is already flowing. Idle connections close after the NLB’s TCP idle timeout (350 seconds by default), and pooled clients see them as resets.

If you register service targets on the NLB directly, the whole ALB layer and its zone behaviour drop out of the path. Do this whenever you don’t need the ALB’s layer 7 routing.

​

What is supported

​

Next steps