Improve Agentforce information safety with Personal Join for Salesforce Information Cloud and Amazon Redshift – Half 3

Information safety is a excessive precedence, notably as organizations face growing cybersecurity threats. Sustaining the safety of buyer information is prime precedence for AWS and Salesforce. With AWS PrivateLink, Salesforce Personal Join eliminates frequent safety dangers related to public endpoints. Salesforce Personal Join now works with Salesforce Information Cloud to maintain your buyer information safe when utilizing with key providers like Agentforce.

In Half 2 of this sequence, we mentioned the structure and implementation particulars of cross-Area information sharing between Salesforce Information Cloud and AWS accounts. On this publish, we talk about find out how to create AWS endpoint providers to enhance information safety with Personal Join for Salesforce Information Cloud.

Resolution overview

On this instance, we configure PrivateLink for an Amazon Redshift occasion to allow direct, personal connectivity from Salesforce Information Cloud. AWS recommends that organizations use an Amazon Redshift managed VPC endpoint (powered by PrivateLink) to privately entry a Redshift cluster or serverless workgroup. For particulars about finest practices, seek advice from Allow personal entry to Amazon Redshift out of your consumer purposes in one other VPC.

Nevertheless, some organizations may want to make use of PrivateLink managed by themselves—for instance, a Redshift managed VPC endpoint just isn’t but out there in Salesforce Information Cloud, and it is advisable handle your PrivateLink connection. This publish focuses on the answer to configure self-managed PrivateLink between Salesforce Information Cloud and Amazon Redshift in your AWS account to ascertain personal connectivity.

The next structure diagram reveals the steps for establishing personal connectivity between Salesforce Information Cloud and Amazon Redshift in your AWS account.

To arrange personal connectivity between Salesforce Information Cloud and Amazon Redshift, we use the next assets:

Stipulations

To finish the steps on this publish, you will need to have already got Amazon Redshift working in a personal subnet and have the permissions to handle it.

Create a safety group for the Community Load Balancer

The safety group acts as a digital firewall. The one visitors that reaches the occasion is the visitors allowed by the safety group guidelines. To boost the safety posture, you solely need to permit visitors to Redshift situations. Full the next steps to create a safety group in your Community Load Balancer (NLB):

1. On the Amazon VPC console, select Safety teams within the navigation pane.
2. Select Create safety group.
3. Enter a reputation and outline for the safety group.
4. For VPC, use the identical digital personal cloud (VPC) as your Redshift cluster.
5. For Inbound guidelines, add a rule to permit visitors to ingress the listening port 5439 on the load balancer.

6. For Outbound guidelines, add a rule to permit visitors to your Redshift occasion.

7. Select Create safety group.

Create a goal group

Full the next steps to create a goal group:

1. On the Amazon EC2 console, beneath Load balancing within the navigation pane, select Goal teams.
2. Select Create goal group.
3. For Select a goal kind, choose IP addresses.

4. For Protocol: Port, select TCP and port 5436 (in case your Redshift cluster runs on a unique port, change the port accordingly).
5. For IP tackle kind, choose IPv4.
6. For VPC, select the identical VPC as your Redshift cluster.
7. Select Subsequent.

8. For Enter an IPv4 tackle from a VPC subnet, enter your Amazon Redshift IP tackle.

To find this tackle, navigate to your cluster particulars on the Amazon Redshift console, select the Properties tab, and beneath Community and safety settings, broaden VPC endpoint connection particulars and duplicate the personal tackle of the community interface. When you’re utilizing Amazon Redshift Serverless, navigate to the workgroup dwelling web page. The Amazon Redshift IPv4 addresses may be positioned within the Community and safety part beneath Information entry once you select VPC endpoint ID.

9. After you add the IP tackle, select Embrace as pending beneath, then select Create goal group.

Create a load balancer

Full the next steps to create a load balancer:

1. On the Amazon EC2 console, select Load balancers within the navigation pane.
2. Select Create load balancer.
3. Select Community.
4. For Load balancer identify, enter a reputation.
5. For Scheme, choose Inner.
6. For Load balancer tackle kind, choose IPv4.
7. For VPC, use the VPC that your goal group is in.

8. For Availably Zones, choose the Availability Zone the place the Redshift cluster is working.
9. For Safety teams, select the safety group you created within the earlier step.
10. For Listener particulars, add a listener that factors to the goal group created within the final step:
    1. For Protocol, select TCP.
    2. For Port, use 5439.
    3. For Default motion, select Redshift-TargetGroup.
11. Select Create load balancer.

Be sure that the registered targets within the goal group are wholesome earlier than continuing. Additionally make it possible for the goal group has a goal for all Availability Zones in your AWS Area or the NLB has the Cross-zone load balancing attribute enabled.

Within the load balancer’s safety setting, make it possible for Implement inbound guidelines on PrivateLink visitors is off.

Create an endpoint service

Full the next steps to create an endpoint service:

1. On the Amazon VPC console, select Endpoint providers within the navigation pane.
2. Select Create endpoint service.
3. For Load balancer kind, select Community.
4. For Accessible load balancers, choose the load balancer you created within the final step
5. From Supported Areas, choose a further area if Information Cloud isn’t hosted in the identical AWS area because the Redshift occasion.  For extra settings go away Acceptance required.

If that is chosen, later, when the Salesforce Information Cloud endpoint is created to hook up with the endpoint service, you’ll need to come back again to this web page to just accept the connection. If not chosen, the connection might be constructed instantly.

6. For Supported IP tackle kind, choose IPv4.
7. Select Create.

Subsequent, it is advisable permit Salesforce principals.

8. After you create the endpoint service, select Enable principals.
9. In one other browser, navigate to Salesforce Information Cloud Setup.
10. Below Exterior Integrations, entry the brand new Personal Join menu merchandise.
11. Create a brand new personal community path to Amazon Redshift.

12. Copy the principal ID.

13. Return to the endpoint service creation web page.
14. For Principals so as to add, enter the principal ID.
15. Copy the endpoint service identify.
16. Select Enable principals.

17. Return to the Salesforce Information Cloud personal community configuration web page.
18. For Route Title, enter the endpoint service identify.
19. Select Save.

The route standing ought to present as Allocating.

When you opted to just accept connections within the earlier step, you’ll now want to just accept the connection from Salesforce Information Cloud.

20. On the Amazon VPC console, navigate to the endpoint service.
21. On the Endpoint connections tab, find your pending connection request.

22. Settle for the endpoint connection request from Salesforce Information Cloud.

Navigate to the Salesforce Information Cloud setup and wait 30 seconds, then refresh the personal join route so the standing reveals as Prepared.

Now you can use this route when making a reference to Amazon Redshift. For extra particulars, seek advice from Half 1 of this sequence.

Amazon Redshift federation PrivateLink failover

Now that we now have mentioned find out how to configure PrivateLink to make use of with Personal Join for Salesforce Information Cloud, let’s talk about Amazon Redshift federation PrivateLink failover eventualities.

You’ll be able to select to deploy your Redshift clusters in three completely different deployment modes:

• Amazon Redshift provisioned in a Single-AZ RA3 cluster
• Amazon Redshift provisioned in a Multi-AZ RA3 cluster
• Amazon Redshift Serverless

PrivateLink depends on a buyer managed NLB linked to service endpoints utilizing IP tackle goal teams. The goal group has the IP addresses of your Redshift occasion. If there’s a change in IP tackle targets, the NLB goal group have to be up to date to the brand new IP addresses related to the service. Failover conduct for Amazon Redshift will differ primarily based on the deployment mode you utilize.

This part describes PrivateLink failover eventualities for these three deployment modes.

Amazon Redshift provisioned in a Single-AZ RA3 cluster

RA3 nodes help provisioned cluster VPC endpoints, which decouple the backend infrastructure from the cluster endpoint used for entry. Once you create or restore an RA3 cluster, Amazon Redshift makes use of a port inside the ranges of 5431–5455 or 8191–8215. When the cluster is ready to a port in one among these ranges, Amazon Redshift mechanically creates a VPC endpoint in your AWS account for the cluster and attaches community interfaces with a personal IP for every Availability Zone within the cluster. For the PrivateLink configuration, you employ the IP related to the VPC endpoint because the goal for the frontend NLB. You’ll be able to establish the IP tackle of the VPC endpoint on the Amazon Redshift console or by doing a describe-clusters question on the Redshift cluster.

Amazon Redshift is not going to take away a community interface related to a VPC endpoint until you add a further subnet to an present Availability Zone or take away a subnet utilizing Amazon Redshift APIs. We suggest that you just don’t add a number of subnets to an Availability Zone to keep away from disruption. There could be failover eventualities the place extra community interfaces are added to a VPC endpoint.

In RA3 clusters, the nodes are mechanically recovered and changed as wanted by Amazon Redshift. The cluster’s VPC endpoint is not going to change even when the chief node is changed.

Cluster relocation is an elective function that enables Amazon Redshift to maneuver a cluster to a different Availability Zone with none lack of information or adjustments to your purposes. When cluster relocation is turned on, Amazon Redshift may select to relocate clusters in some conditions. Specifically, this occurs the place points within the present Availability Zone stop optimum cluster operation or to enhance service availability. You can even invoke the relocation operate in circumstances the place useful resource constraints in a given Availability Zone are disrupting cluster operations. When a Redshift cluster is relocated to a brand new Availability Zone, the brand new cluster has the identical VPC endpoint however a brand new community interface is added within the new Availability Zone. The brand new personal tackle ought to be added to the NLB’s goal group to optimize availability and efficiency.

Within the case {that a} cluster has failed and might’t be recovered mechanically, you need to provoke a restore of the cluster from a earlier snapshot. This motion generates a brand new cluster with a brand new DNS identify, connection string, and VPC endpoint and IP tackle for the cluster. You must replace the NLB with the brand new IP for the VPC endpoint of the brand new cluster.

Amazon Redshift provisioned in a Multi-AZ RA3 cluster

Amazon Redshift helps Multi-AZ deployments for provisioned RA3 clusters. By utilizing Multi-AZ deployments, your Redshift information warehouse can proceed working in failure eventualities when an sudden occasion occurs in an Availability Zone. A Multi-AZ deployment deploys compute assets in two Availability Zones, and these compute assets may be accessed by a single endpoint. Within the case of a failure of the first nodes, Multi-AZ clusters will make secondary nodes main and deploy a brand new secondary stack in one other Availability Zone. The next diagram illustrates this structure.

Multi-AZ clusters deploy VPC endpoints that time to community interfaces in two Availability Zones, which ought to be configured as part of the NLB goal group. To configure the VPC endpoints within the NLB goal group, you may establish the IP addresses of the VPC endpoint utilizing the Amazon Redshift console or by doing a describe-clusters question on the Redshift cluster. In a failover situation, VPC endpoint IPs is not going to change and the NLB doesn’t require an replace.

Amazon Redshift is not going to take away a community interface related to a VPC endpoint until you add a further subnet in to an present Availability Zone or take away a subnet utilizing Amazon Redshift APIs. We suggest that you just don’t add a number of subnets to an Availability Zone to keep away from disruption.

Amazon Redshift Serverless

Redshift Serverless supplies managed infrastructure. You’ll be able to carry out the get-workgroup question to get the workgroup’s VpcEndpoint IPs. IPs ought to be configured within the goal group of the PrivateLink NLB. As a result of it is a managed service, the failover is managed by AWS. Through the occasion of an underlying Availability Zone failure, the workgroup may get a brand new set of IPs. You’ll be able to often question the workgroup configuration or DNS document for the Redshift cluster to verify if IP addresses have modified and replace the NLB accordingly.

Automating IP tackle administration

In eventualities the place Amazon Redshift operations may change the IP tackle of the endpoint wanted for Amazon Redshift connectivity, you may automate the replace of NLB community targets by monitoring the outcomes for cluster DNS decision, utilizing describe-cluster or get-workgroup queries, and utilizing an AWS Lambda operate to replace the NLB goal group configuration.

You’ll be able to periodically (on a schedule) question the DNS of the Redshift cluster for IP tackle decision. Use a Lambda operate to check and replace the IP goal teams for the NLB. For an instance of this resolution, see Hostname-as-Goal for Community Load Balancers.

For legacy DS2 clusters the place the IP tackle of the chief node have to be explicitly monitored, you may configure Amazon CloudWatch metrics to watch the HealthStatus of the chief node. You’ll be able to configure the metric to set off an alarm, which alerts an Amazon Easy Notification Service (Amazon SNS) matter and invokes a Lambda operate to reconcile the NLB goal group.

For backup and restore patterns, you may create a rule in Amazon EventBridge triggered on the RestoreFromClusterSnapshot API motion, which invokes a Lambda operate to replace the NLB with the brand new IP addresses of the cluster.

For a cluster relocation sample, you may set off an occasion primarily based on the Amazon Redshift ModifyCluster availability-zone-relocation API motion.

Conclusion

On this publish, we mentioned find out how to use AWS endpoint providers to enhance information safety with Personal Join for Salesforce Information Cloud. If you’re at the moment utilizing the Salesforce Information Cloud zero-copy integration with Amazon Redshift, we suggest you observe the steps supplied on this publish to make the community connection between Salesforce and AWS safe. Attain out to your Salesforce and AWS help groups in the event you want extra help to implement this resolution.

Concerning the authors

Yogesh Dhimate is a Sr. Accomplice Options Architect at AWS, main know-how partnership with Salesforce. Previous to becoming a member of AWS, Yogesh labored with main firms together with Salesforce driving their trade resolution initiatives. With over 20 years of expertise in product administration and options structure Yogesh brings distinctive perspective in cloud computing and synthetic intelligence.

Avijit Goswami is a Principal Options Architect at AWS specialised in information and analytics. He helps AWS strategic clients in constructing high-performing, safe, and scalable information lake options on AWS utilizing AWS managed providers and open supply options. Outdoors of his work, Avijit likes to journey, hike, watch sports activities, and take heed to music.

Ife Stewart is a Principal Options Architect within the Strategic ISV section at AWS. She has been engaged with Salesforce Information Cloud during the last 2 years to assist construct built-in buyer experiences throughout Salesforce and AWS. Ife has over 10 years of expertise in know-how. She is an advocate for variety and inclusion within the know-how area.

Mike Patterson is a Senior Buyer Options Supervisor within the Strategic ISV section at AWS. He has partnered with Salesforce Information Cloud to align enterprise targets with progressive AWS options to attain impactful buyer experiences. In his spare time, he enjoys spending time along with his household, sports activities, and out of doors actions.

Drew Loika is a Director of Product Administration at Salesforce and has spent over 15 years delivering buyer worth by way of information platforms and providers. When not diving deep with clients on what would assist them be extra profitable, he enjoys the acts of creating, rising, and exploring the good outdoor.