Connecting Your AWS VPC to Pega Cloud Privately: When PrivateLink Fits, and When It Doesn't
Connecting Your AWS VPC to Pega Cloud Privately
In this post, let's understand AWS PrivateLink for a Pega Cloud environment. We'll follow one customer's home loan application from the bank's website to a Pega case, hop by hop. Along the way it answers one question: how does a bank's AWS VPC reach Pega Cloud without the public internet? The answer is AWS PrivateLink, which Pega offers as Pega Cloud Secure Connect. It only works for one kind of caller, and the home loan shows you which.
The default is the internet
Out of the box, you reach Pega Cloud over the internet. New Pega Cloud 3 environments block public inbound access by default, and Pega Support can open inbound and outbound allow lists for you. That works, but the path is still public.
One request, hop by hop
Take a customer applying for a home loan on the bank's AEM site. The bank runs its side in a VPC in Sydney (ap-southeast-2).
1. AEM to API Gateway. AEM calls the bank's API Gateway over HTTPS. AWS WAF, an authoriser and throttling sit in front of it.
2. API Gateway to Lambda. API Gateway passes the request to a Lambda function in a private subnet. The subnet has no route to the internet.
3. Lambda to the interface endpoint. The Lambda function gets an OAuth token from Pega using client credentials, then sends the create-case call to the interface endpoint's private address in the bank's VPC.
4. The endpoint to Pega. The interface endpoint reaches Pega's endpoint service through PrivateLink. The traffic stays on the AWS network. Pega creates the case, and the case ID returns the same way.
Where the private path starts and stops
Look at who called whom in that request. There were three possible callers:
- the customer's browser, which lives on the internet
- the Lambda function, a server the bank runs in AWS
- Pega itself, if it ever needs to call back into a bank system
Only the Lambda function went private. PrivateLink covers hop 4 alone. The customer's browser and AEM reach Pega through the bank's API in hops 1 and 2, because neither sits inside the bank's VPC. A callback from Pega would be a different direction, and PrivateLink is one way.
Why a Lambda function, and not API Gateway calling Pega directly? A REST API private integration uses a VPC link to a load balancer in your own account, not to another account's endpoint service. API Gateway also can't fetch an OAuth token for you. A small function in the private subnet handles both, and keeps the client secret out of the request path.
When PrivateLink fits
| Who calls whom | Private with PrivateLink? | What to use |
|---|---|---|
| A bank service in an AWS VPC calls Pega | Yes | Interface endpoint to Pega's endpoint service (Pega Cloud Secure Connect) |
| Many bank accounts plus on-premises call Pega | Yes, through one place | Hub VPC: VPN and Direct Connect land centrally, Pega is reached through PrivateLink |
| Bank address ranges clash with Pega's | Yes | PrivateLink doesn't care about overlapping CIDRs. Peering does |
| A customer's browser calls Pega directly (Web Embed) | No | Route through the bank's own API |
| AEM as a Cloud Service calls Pega | No | AEM's advanced networking offers flexible port egress, a dedicated egress IP or VPN. Call Pega through the bank's API Gateway |
| Pega calls a bank system | Other direction | PrivateLink is one way. Confirm the outbound pattern with Pega |
Bigger estates: hub and spoke
Most banks run more than one AWS account. Pega recommends hub and spoke: VPN and Direct Connect land in a hub VPC, the spoke accounts connect through it, and one PrivateLink connection from the hub reaches Pega. Because PrivateLink exposes one service rather than joining two networks, overlapping address ranges between the bank and Pega don't block it. They would block VPC peering.
Private is not secure on its own
A private path still needs locks. In the home loan flow, four of them do most of the work:
Endpoint acceptance. An endpoint service can require acceptance, so only the connection requests the provider accepts can reach it. Pega's endpoint service should accept only the bank's endpoint, so no other VPC can reach the home loan service.
Security group. The security group on the interface endpoint controls which resources in the VPC can reach it. Let only the home loan Lambda function in.
OAuth client credentials. Pega supports the OAuth 2.0 client credentials grant. Map the client to a dedicated, least-privilege operator, and keep the secret in AWS Secrets Manager.
AllowedStartingFields. In DX API v2, the AllowedStartingFields data transform limits which fields a create-case request can set. Anything not listed is not set at creation, so a home loan case starts with only the fields the bank expects.
Before you build, confirm three things with Pega
The public documentation doesn't settle these, so confirm them with Pega Support or the current docs for your Pega version:
- The exact DX API v2 create-case path for your version.
- How Pega Cloud handles calls from Pega to the bank (the outbound direction).
- Whether Pega's endpoint service offers a private DNS name for its hostname. This affects DNS and TLS in step 3.
Takeaway
Share the service, not the network. Then prove who's calling. In the home loan, that meant one private hop from the bank's Lambda function to Pega, and the bank's own API for everything that started on the internet.
More explainers at ssmone.cloud.