What is the best way to integrate Salesforce with AWS?

There is no single best way; it depends on what you are moving. For near-real-time events, Salesforce Event Relay to Amazon EventBridge needs no middleware. For no-code data sync, Amazon AppFlow moves data both ways. For analytics without duplicating data, Data Cloud zero-copy queries Amazon Redshift in place. Large files belong in S3, heavy compute in Lambda, and any of these can run privately over AWS PrivateLink.

How do I stream Salesforce events to AWS?

Use Salesforce Event Relay, which subscribes to Platform Events and Change Data Capture and relays them to Amazon EventBridge with no custom integration app. Salesforce creates the EventBridge partner event source, and you route events from there to Lambda or other AWS services. EventBridge API Destinations can send events back into Salesforce, so the flow is bidirectional.

What is zero-copy between Salesforce Data Cloud and AWS?

Zero-copy lets Salesforce Data Cloud query data in Amazon Redshift in place, without copying it: an external object holds the metadata while the rows stay in Redshift. It also works in reverse, sharing unified Data Cloud data back out to Redshift without a copy. At Dreamforce 2026, Salesforce extended this to AWS Glue-managed Iceberg tables and Amazon Aurora.

Do I need middleware to connect Salesforce and AWS?

Often no. Event Relay to EventBridge and Amazon AppFlow are both native, managed paths that need no middleware app. Middleware or a custom pipeline earns its place when the transformation is complex, the volume is very large, or you are orchestrating across many systems, not just Salesforce and AWS.

How do I keep Salesforce to AWS traffic off the public internet?

Use Salesforce Private Connect, which builds a private bidirectional link to your AWS account over AWS PrivateLink. Traffic between Salesforce and AWS services, including Data Cloud to Redshift, stays on private networking with no exposed IPs. This is the standard pattern for healthcare, financial services, and public-sector workloads.

Can AWS AI models write results back into Salesforce?

Yes. A model on AWS, such as Claude on Amazon Bedrock or a SageMaker model, can run inference and write the result back to a Salesforce record through the API or Data Cloud, usually triggered by a Lambda. If you are using Claude, the deployment and governance choices matter, and we cover them separately.

Salesforce to AWS Integration: 6 Patterns That Hold Up

The short version

There is no single Salesforce to AWS integration. The right choice depends on direction and intent: real-time events, bulk data, zero-copy analytics, file storage, compute, or private networking.
For events, Salesforce Event Relay streams Platform Events and Change Data Capture straight to Amazon EventBridge, with no middleware app to build or maintain.
For analytics, Data Cloud can query Amazon Redshift in place through zero-copy federation, and share unified data back out, so neither side has to duplicate the data.
Salesforce Private Connect, built on AWS PrivateLink, is the layer that keeps all of these off the public internet for regulated workloads.

There Is No Single 'Salesforce to AWS Integration'

The question we hear most is 'how do we connect Salesforce to AWS,' and it is the wrong one. The right question is what you are moving and in which direction: an event, a batch of records, a query, a file, a compute job. Each has a pattern that fits, and forcing the wrong one is where integrations rot.

This guide walks the six patterns that actually hold up in production, what each is for, and the honest caveat on each. Read it as a menu, not a sequence.

Pattern 1: Event Streaming with Event Relay and Amazon EventBridge

This is the pattern most teams should reach for first, because it needs no middleware. Salesforce Event Relay subscribes to Platform Events and Change Data Capture and relays them straight to Amazon EventBridge, with Salesforce creating the partner event source for you. You configure it through EventRelayConfig, not a custom client feeding Kinesis.

It is bidirectional. Events flow out to EventBridge to trigger Lambda, Step Functions, or downstream AWS services, and EventBridge API Destinations can call back into Salesforce. Reach for this when you want near-real-time reactions to record changes without running an integration service you have to keep alive.

The caveat: Event Relay is event-shaped. It is the wrong tool for moving millions of historical rows or for a nightly analytics load, which is what the next two patterns are for.

Pattern 2: No-Code Data Movement with Amazon AppFlow

Amazon AppFlow is AWS's managed, no-code connector for moving data between Salesforce and AWS, in both directions, on a schedule or on a trigger. It lands Salesforce data in S3 or Redshift for analytics, and pushes data back into Salesforce, without you writing transfer code.

It can run privately over AWS PrivateLink, so the transfer never touches the public internet. Choose AppFlow when the job is a straightforward data sync and you would rather configure than build. When the transformation gets complex or the volume gets very large, a purpose-built pipeline usually wins.

Pattern 3: Zero-Copy Analytics with Data Cloud and Amazon Redshift

The pattern that surprises people is the one where no data moves at all. Salesforce Data Cloud, now branded Data 360, can query data sitting in Amazon Redshift in place through zero-copy federation. A data stream creates an external object that holds only the metadata, while the rows stay in Redshift.

It runs both ways, which most write-ups blur. Federation pulls Redshift data into Data Cloud's reach without copying it, and sharing pushes unified Data Cloud data back out to Redshift, again without a copy, using AWS Glue Data Catalog and Redshift Spectrum underneath. At Dreamforce 2026, Salesforce widened this to AWS Glue-managed Apache Iceberg tables and Amazon Aurora.

Choose zero-copy when the goal is analytics or a unified view and duplicating the data would be the real cost, in storage, in sync lag, and in governance. We cover the Salesforce side of this in Data Cloud and Agentforce.

Pattern 4: File and Storage Offload with Amazon S3

Salesforce file storage is expensive, and large binaries do not belong in it. The common pattern is to keep documents, media, and attachments in Amazon S3 and reference them from Salesforce, so the CRM holds the record and S3 holds the bytes.

This is a well-worn build with real tradeoffs around access control and previews. We wrote the step-by-step in the AWS S3 and Salesforce integration guide. Choose it when storage cost or large-file handling is the pain, not when you need the file's contents queryable inside Salesforce.

Pattern 5: Compute and AI Offload with AWS Lambda and Bedrock

Some work does not belong inside a Salesforce transaction: heavy processing, document parsing, model inference. The pattern is to hand that work to AWS, usually a Lambda triggered by the API or by an EventBridge event, and write the result back into Salesforce through the API or Data Cloud.

AI is the fast-growing case here. A Claude or SageMaker model on AWS runs the inference and returns a value to the record. If that model is Claude on Amazon Bedrock, the governance choices matter, and we laid them out in Claude on Amazon Bedrock for Salesforce. Choose this pattern when the workload is a system process rather than a live user interaction.

Pattern 6: Private Networking with Private Connect and AWS PrivateLink

This one is not a data pattern, it is the layer underneath the others for regulated data. Salesforce Private Connect builds a fully managed, bidirectional private link between your Salesforce org and your AWS account on AWS PrivateLink, so traffic never crosses the public internet and there are no exposed IPs.

It carries private API callouts from Salesforce to AWS services, and private Data Cloud to Redshift links, over a network load balancer and VPC endpoints. Reach for it when a compliance boundary, in healthcare, financial services, or the public sector, makes public-internet transit a non-starter. It is the pattern we default to for that class of client.

How to Choose

Match the pattern to what you are actually moving.

Real-time reactions to record changes: Event Relay to Amazon EventBridge.
Scheduled or triggered data sync, no code: Amazon AppFlow.
Analytics or a unified view without duplicating data: Data Cloud zero-copy with Redshift.
Large files and storage cost: Amazon S3 offload.
Heavy processing or AI inference: AWS Lambda and Bedrock, writing back to Salesforce.
Any of the above under a compliance boundary: Salesforce Private Connect on AWS PrivateLink.

Most real architectures combine three or four of these. The mistake is not mixing them, it is picking one pattern and bending every job to fit it.

Where to Start

Cloudsheer runs both sides of this join: a verified Salesforce Consulting Partner and a working AWS practice, so the same team owns the CRM and the cloud it talks to. That is the whole point of our AWS practice, and it is why the integration is designed around the business process, not bolted on after.

If you are weighing these patterns for a real project, a scoping call is the fastest way to map them to your data and your constraints. You can also browse our Salesforce integrations for the connector-level guides, or read Claude on Amazon Bedrock for Salesforce for the AI side of the same story.

Salesforce to AWS Integration: The Patterns That Actually Hold Up