Continuing our series of posts on Enterprise Infrastructure capabilities, featured in a dedicated tab within the Blueprint dashboard, this post explores the Pega Cloud Advanced Networking.
Most conversations about cloud connectivity stop at “can we reach it?” For regulated clients, the harder questions come next: what can reach out from it, and can we predict where it enters from? Pega Cloud Advanced Networking is the licensed add-on that answers both. It is available on Pega Cloud 3, and can run alongside Pega Cloud Secure Connect or as a standalone add-on.
What it means
Advanced Networking is not a connectivity method — it is a control layer on top of whatever connectivity you already use. Secure Connect gets you a private path into Pega Cloud. Advanced Networking decides how traffic is segmented and routed once that path exists. Think of it as the difference between having a door and having a badge reader on it.
It exists for one reason: enterprises whose security and compliance posture cannot be satisfied by default-open outbound access and rotating cloud IP ranges.
What it does
Two capabilities, licensed together.
Client-managed outbound access control. When enabled, all client-specific outbound connections from a Pega Cloud environment are denied by default. You then explicitly allow the endpoints each environment may reach — up to 100 distinct integration endpoints per environment. This gives you real segmentation between production and non-production (your dev environment simply cannot call your production payment gateway), and it is genuine data exfiltration protection: an unauthorized destination cannot be configured, not merely discouraged.
Static inbound IP addresses. Dedicated, persistent IP addresses for your Pega Cloud environments, shared across them. Four things follow:
• Outbound access rules: you can write granular rules inside your own network pointing at known, fixed targets.
• Fine-tuned routing: over Direct Connect, Google Peering, or a Cloud Exchange, you can route to a specific Pega location rather than an entire IaaS region.
• Improved performance: the addresses are provisioned from locations close to your end users, so traffic enters the cloud network at the quickest point of entry.
• Simplified management: configure network settings once and rely on them staying consistent.
How it works
Operationally, this runs through change requests, not a self-service console.
To allow an outbound endpoint, raise a Change Request ticket in My Support Portal listing the subnet(s), IP address(es), and/or publicly resolvable DNS name(s) the environment should reach — each with its corresponding port number. For example: pega.com, port 443; 44.33.22.11/32, ports 22 and 443; 72.73.74.0/24, port 1533. Removals go through the same ticket. Pega communicates progress within the ticket and confirms when the change is live.
Static inbound IP addresses follow the same pattern: one Change Request, specifying which environment you want them enabled for.
What to remember
• Default-deny is the headline. Turning on outbound access control will break integrations you have not inventoried. Map every outbound dependency per environment before enabling it, not after.
• The 100-endpoint ceiling is per environment — generally ample, but worth checking against clients with sprawling integration estates.
• It is a licensed add-on with a ticket-driven workflow. Engage the Pega account representative to license it, and build change lead time into migration and integration plans rather than assuming same-day self-service.
• Pega Cloud 3 only, and it pairs naturally with Secure Connect options such as Direct Connect Public VIF or Cloud Exchange.
Technical documentation: Pega Cloud Advanced Networking