This Guidance demonstrates how to utilize advanced artificial intelligence (AI) capabilities within your existing Salesforce environment to gain more valuable insights about your customers. It allows you to seamlessly integrate the user-friendly interface of Salesforce with the powerful data storage and processing capabilities of AWS. With this Guidance, you can securely upload any type of document to store on AWS. AWS AI services will then automatically process those documents, converting audio and video to text, creating readable documents from images, extracting key details while redacting personal data, and analyzing visuals. By combining the strength of Salesforce with the advanced AI services of AWS, you can uncover deeper insights into your customers' needs, behaviors, and preferences—all within your existing Salesforce workflows.

Please note: [Disclaimer]

Architecture Diagram

[Architecture diagram description]

Download the architecture diagram PDF 

Well-Architected Pillars

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

  • This Guidance implements a modular, agile, and decoupled architecture that aligns with AWS operational best practices. For example, by using Amazon SNS topics, the Guidance can be decoupled, and you can add Lambda functions as needed. Additionally, AWS artificial intelligence (AI) services like Amazon Transcribe and Amazon Rekognition remove the need for you to manage machine learning (ML) models and infrastructure.

    Read the Operational Excellence whitepaper 
  • One of the core advantages of serverless architectures is that AWS manages the underlying infrastructure, including network security. This alleviates the burden of securing the network layer, allowing you to focus on securing your application and data. However, you are responsible for managing access control through AWS Identity and Access Management (IAM).

    By default, data stored in Amazon S3 is encrypted with Amazon S3 managed keys (SSE-S3), but it can also be encrypted using AWS KMS (SSE-KMS) or customer-provided encryption keys (SSE-C). Access to Amazon S3 is denied by default, and all public access is blocked. Amazon S3 access is authorized through IAM, allowing you to define access scope and permitted actions for services or users.

    Furthermore, this Guidance uses AWS STS in conjunction with a JSON Web Token (JWT) authorizer. This approach enhances security by eliminating the need to store hard-coded AWS access keys in Salesforce, which could potentially be compromised. Instead, Salesforce obtains temporary, limited-privilege IAM credentials from AWS STS, which are used to securely access and interact with Amazon S3.

    Read the Security whitepaper 
  • This Guidance implements a highly available network topology by using a serverless architecture that is deployed in a single Region and runs across multiple Availability Zones (AZs). This eliminates the risk caused by a rare, but possible, AZ failure.

    Application reliability is achieved by decoupling the application into individual components that focus on a single task, and Amazon SNS is essential for decoupling this architecture. If a subscribed endpoint is unavailable temporarily, Amazon SNS will retry delivering the message according to the retry policy. For messages that can't be delivered, Amazon SNS can target messages with a dead-letter queue (DLQ) to prevent message loss.

    Finally, Amazon CloudWatch monitors Lambda functions, and you can review reports on metrics such as the number of requests, invocation duration, and errors. This helps track the performance and health of the Lambda functions. If a function invocation fails due to an error, it will be automatically retried at least three times.

    Read the Reliability whitepaper 
  • Decoupling individual services allows each component to work independently and run in parallel. Using a serverless architecture, each Lambda function is provisioned with the right amount of RAM and CPU to perform its task. And using Amazon SNS allows for asynchronous invocation of resources, so once a job is complete, it is not waiting for a synchronous response.

    Read the Performance Efficiency whitepaper 
  • By using a serverless architecture, you only pay for what you use. Services like Lambda, Amazon SNS, or Amazon Rekognition only incur charges for the times that those services are invoked and used. Services like Amazon S3 incur charges for the amount of data that is actually used. And using serverless services allows the architecture to scale up and down to meet demand without having to overprovision resources.

    Read the Cost Optimization whitepaper 
  • Through right-sized, transient resources that avoid excess idling, this Guidance minimizes energy consumption and hardware waste. For example, rather than pre-provisioning servers that continually run even when unutilized, Lambda functions are invoked on-demand only when needed. Each function is individually configured with the optimal amount of memory and CPU capacity required to complete its designated task, avoiding over-provisioning of resources. By dynamically allocating just the right compute power when workloads arrive and terminating those resources after use, Lambda eliminates resource waste from idle servers.

    Read the Sustainability whitepaper 

Implementation Resources

The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.

[Content Type]


This [blog post/e-book/Guidance/sample code] demonstrates how [insert short description].


The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.

References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.

Was this page helpful?