Direct Connect and Cloud Exchange solve the problem of getting from your data centre to Pega Cloud. PrivateLink solves a different one: you are already in AWS, and you would rather the traffic never left it. It is the option AWS itself recommends for connecting to SaaS providers when both ends of the conversation live in AWS.
What it means
AWS PrivateLink lets Pega Cloud Secure Connect establish connectivity between Pega Cloud and your existing AWS VPC without traversing a public connection at all. Traffic stays inside the AWS network.
Two properties follow from that, and they are the reason clients choose it. Security: the traffic does not leave AWS. Reliability: the connection is architecturally simple, and simple things break less. There is a third benefit that rarely gets mentioned until it matters — PrivateLink eliminates the risk of IP address conflicts between networks on either side of the connection, which is a recurring headache in merged or acquired estates.
What it does
- High availability and throughput: two endpoints, giving optimal throughput in line with AWS maximum bandwidth limits per endpoint.
- Traffic stays in AWS where your policy requires it.
- Low maintenance compared with circuit-based options — there is no physical connection to own.
- No IP conflicts between the two networks.
It also reaches beyond AWS: PrivateLink Endpoint Services can carry connectivity between Pega Cloud and enterprise resources that sit outside AWS.
Shared PrivateLink ingress. A newer capability worth knowing about. Instead of one endpoint per environment, you can consolidate ingress to multiple environments through a single PrivateLink endpoint, in two tiers — Production and Non-Production. A client cluster can have one shared Prod and one shared Non-Prod configuration. It reduces the endpoint sprawl and lets you apply allow-list settings across many environments at once.
How it works
Both directions run through a cloud-change request in My Support Portal, and both are genuinely collaborative — Pega does its half, you do yours, and the ticket stays open until the connection verifies.
- Outbound (Pega Cloud → your VPC). You configure your organisation’s PrivateLink Endpoint Service first, including the network load balancer. Raise the ticket with the Service name. Pega replies with the ARN of the Pega Cloud principal, which you add to your Endpoint Service permissions. Update the ticket, Pega raises a connection request, you accept it, Pega verifies access and closes the ticket.
- Inbound (your VPC → Pega Cloud). Raise the ticket with the AWS account ID of the VPC, naming one or more environments. Pega configures each and returns a Service name per environment. You create the endpoint in your VPC, ideally across two Availability Zones, and set the security group to allow inbound and outbound HTTPS on port 443. Confirm in the ticket, Pega activates and verifies.
What to remember
- PrivateLink does not support DNS resolution. This surprises people. For outbound connections you must either configure a private DNS name for your Endpoint Service, or create multiple Endpoint Services mapping to your backend services. Plan this before raising the ticket.
- One inbound connection per environment by default — mycorp-dt1 and mycorp-dt2 are separate connections — unless you use shared ingress.
- Availability Zones must line up. For HA, your Endpoint Services need to exist in at least two of the same AWS Availability Zones as your Pega Cloud.
- Same region by default, with cross-region supported only within Pega Cloud deployment regions.
- Shared ingress has trade-offs: it is subject to AWS bandwidth limits for a single endpoint, all connections inherit the same security rules, and it does not support Enhanced Disaster Recovery.
- The Pega Cloud SFTP service supports PrivateLink inbound connections too.
Technical documentation: Private connectivity using AWS PrivateLink
Related: Connect enterprise resources to Pega Cloud with AWS PrivateLink