Using AWS Privatelink to connect enterprise resources to Pega Cloud
Using AWS Privatelink to connect enterprise resources to Pega Cloud
Introduction
AWS PrivateLink provides reliable, encrypted, fast connectivity between SaaS providers like Pega Cloud and resources located in client-managed AWS VPCs, without the need to traverse a public connection. Additionally, the use of AWS PrivateLink eliminates the risk of IP address conflicts between networks on either side of the connection.
While PrivateLink is ideal for making connections between endpoints within AWS, you can use a client-managed AWS VPC as a transit VPC to provide resources outside of AWS with access to or from Pega Cloud.
This document provides guidance on benefits and design options for clients who are interested in leveraging Pega Cloud PrivateLink integration capabilities for communication with external systems. Use this pattern to create a cloud-native, isolated, intelligent routing hub that you can use to connect a broad set of resources to your Pega Cloud. Pega does not provide specific guidance to address the complexities of your enterprise network configuration.
Usage note: Throughout this document, "transit VPC" refers to a client-managed, AWS VPC with inbound and outbound PrivateLink connections to Pega Cloud. This transit VPC can route traffic to or from Pega Cloud applications, based on controls you implement.
Diagram key: Color blocks have been used in the diagrams below to outline areas of responsibility.
Prerequisites
Review current AWS documentation, since AWS may add capabilities or change their default service behaviors at any time.
Benefits
This design offers the flexibility of allowing you to choose your preferred method of connecting to your transit VPC, while retaining the advantages that PrivateLink provides for intra-AWS connectivity, particularly when the integration target is an as-a-Service provider like Pega. You retain full control and responsibility over the connections you make from external networks to your transit VPC.
Key Benefits of this design pattern:
- Centralized Ingress and Egress between trusted and 3rd party networks
- Traffic inspection such as IDS and IPS to provide additional security
- Layer 7 routing and filtering
- Resolution of non-publicly resolvable DNS names
- Traffic mirroring for advanced connection troubleshooting
- Ability to re-use this “connection hub” transit VPC for other similar integrations
Overview of extending PrivateLink connectivity to Pega Cloud
The following diagram illustrates the basic design of PrivateLink connectivity to your Pega Cloud applications:
The following diagram extends the basic design to illustrate that your transit VPC can provide access to resources both within and outside of AWS:
Connect from diverse locations and connection types
Depending on your requirements, you may choose to provide access to your Pega Cloud applications through your transit VPC from different external locations using a variety of connection types.
Location types
Different external locations may warrant different connectivity and security requirements. The location types that can drive your requirements include:
- Remote user
- Datacenter
- Corporate network or branch office
- Third party provider network (for example, non-Pega as-a-Service solutions)
- Other AWS VPCs
Connection types
Your transit VPC gives you the ability to configure different connection types while maintaining a common method of forwarding those connections to your Pega Cloud applications using PrivateLink connections. The connection types that can drive your requirements include:
- Internet
- Site-to-site VPN
- Direct Connect private VIF
- AWS Transit Gateway (TGW) attachments
As an example of a diverse combination of location and connection types, you can establish a VPN with a branch office, a Direct Connect private VIF with a datacenter facility, an AWS TGW attachment to a separate AWS VPC, and internet access for end users:
Inbound Design Options
Definition: Inbound (ingress) traffic is traffic originating from users and other service consumers, connecting to your Pega Cloud applications.
Inbound connectivity is a common use case, since end users are typical consumers of Pega Cloud services, and they are not likely to have a direct presence in an AWS VPC.
You can use two methods to provide users with external access to your Pega applications through PrivateLink:
- Direct access - Connect to your Pega application by sending traffic directly to your PrivateLink endpoint.
- Direct inbound connections to a your PrivateLink endpoint are only possible over a private connection: the endpoints resolve to private IP addresses that are only reachable from within your transit VPC or over networks that are connected to that VPC using a private connection like a site-to-site VPN.
- With this model options for access control and inspection within your transit VPC are limited to the capabilities of the endpoint itself (for example, you can configure AWS security groups on the endpoint).
- Through a forwarding device - Connect to your Pega application by sending traffic through an intermediate device, such as a load balancer or reverse proxy, running within your transit VPC, which has been configured to forward traffic to your PrivateLink endpoint.
- Inbound connections through a forwarding device are possible over a public or private connection.
- With this model you can take advantage of enhanced features on the intermediate device like access control and traffic inspection.
As an example of both inbound access options, you can provide direct access to your Pega applications over a private connection for one set of users and configure a forwarding device for a second set of users.
Outbound Design Options
Definition: Outbound (egress) traffic is integration traffic, which is initiated by your Pega Cloud application to access data and processes on enterprise systems such as email servers or webservice providers.
Outbound connectivity is a common use case, since modern enterprise data and systems often reside in diverse locations.
You can use two methods to provide your Pega Cloud applications with access to systems located outside of your transit VPC:
- Direct access - Configure your external systems directly as targets on the Network Load Balancer (NLB) in your transit VPC that receives outbound traffic over PrivateLink.
- Access between the NLB and its targets can be either over a private or a public connection.
- With this model options for access control and inspection within your transit VPC are limited.
- Through a forwarding device - Connect to your external systems by sending traffic through an intermediate device such as a load balancer or reverse proxy running within your transit VPC. You can use this forwarding device as the local target of your integration traffic, then forward that traffic to one or more external destination systems.
- Access between the intermediate device and integration endpoints can be either over a private or a public connection.
- With this model you can take advantage of added features like access control and inspection on the intermediate device.
As an example of both outbound access options, you can provide direct access to some external systems using the network load balancer in your transit VPC and configure a forwarding device for access to other external systems.
Inter-region connectivity
AWS PrivateLink connections are only supported between VPCs in the same AWS region. However, if you already have services in an AWS VPC in a different region from your Pega Cloud applications and you need to connect those services to Pega Cloud, take advantage of AWS TGW support for inter-region peering with your transit VPC to bridge this gap.
Note: As with any design that spans a wide geographical area, performance and latency factors may apply, and should be reviewed before you implement this approach.
As discussed above, your transit VPC can be used to provide access to Pega Cloud from resources in a separate AWS VPC. While you have many different options for connecting your two AWS VPCs, AWS TGW is often an ideal choice. The diagram below illustrates a single region configuration.
When the VPC containing your services is in a different AWS region from your Pega Cloud applications, you can configure your transit VPC in the same region as Pega Cloud, and establish PrivateLink connections between your transit VPC and Pega Cloud. You can then use AWS TGW to inter-region peering to establish end-to-end connectivity. The high level actions needed are as follows:
- Provision an AWS TGW in each of your regions
- Create an inter-region peering connection between your two AWS TGWs
- Create VPC attachments from each region's AWS TGW to your VPC in that region
- Configure the appropriate routing to allow traffic flow
The diagram below illustrates the high-level components and connections required to achieve inter-region connectivity.
You can also use this design to connect external networks to the most appropriate regional AWS TGW. The diagram below illustrates some possible ways of connecting your datacenter to your AWS-based components.
Results
After you implement this design pattern, you can leverage AWS PrivateLink and other forms of connectivity such as the public internet or AWS Direct Connect to facilitate secure and reliable connections between your external users and systems and your Pega Cloud applications.
One significant benefit of this connectivity model is your ability to establish a centralized point of ingress and egress for Pega Cloud applications traffic. By using a transit VPC you can perform layer 7 routing and filtering, intrusion detection and prevention, and traffic mirroring; You can also use your transit VPC to establish a perimeter that creates clear lines of demarcation between your enterprise systems and as-a-Service providers.