Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

EUM Social → SNS → Lambda → DynamoDB → Amplify inbox

0

Hello AWS Team,

We are building a custom agent-facing WhatsApp inbox/dashboard and would like:

  1. Validation that our design aligns with AWS best practices for AWS End User Messaging – Social (WhatsApp), and
  2. Help with setup issues in an AWS sample we are using as a reference.

We are not using Pinpoint In-App Messaging.

We have reviewed these AWS Builder solutions and sample:

Important constraint:
Amazon Connect is not available for our workload in our required India Region, so we cannot use it as our agent console. Instead, our front end is a custom React application using Amplify (Amplify Gen 2 + Amplify UI). We still want to follow recommended patterns for EUM Social, SNS, Lambda, and DynamoDB.

Our current architecture

  • Channel: AWS End User Messaging – Social (WhatsApp) (EUM Social) with one or more WABAs and numbers.
  • Inbound/events: EUM Social publishes inbound messages and delivery/read/failure events to an Amazon SNS topic.
  • Processing: SNS → Lambda for normalization and routing.
  • Storage: Amazon DynamoDB for:
    • Conversations and messages,
    • Delivery/status events,
    • WABA/phone/tenant metadata.
  • Front end:
    • Amplify Gen 2 (code-first) for data models and backend functions/APIs (Lambda).
    • React + Amplify UI inbox for agents (conversation list, message thread, statuses, filters).

We are comfortable with implementation; we mainly need confirmation that this design is appropriate for EUM Social on WhatsApp and advice on a few design and setup points.

  1. EUM Social → SNS → Lambda → DynamoDB pattern

Our inbound path is:

EUM Social (WhatsApp) → SNS → Lambda → DynamoDB → Amplify APIs → React/Amplify UI

Questions:

  • Is this pattern recommended/supported by the EUM Social service for:

    • Capturing inbound WhatsApp messages, and
    • Capturing delivery/read/failure events?

  • What delivery semantics should we assume (e.g., at-least-once, possible reordering), and how should we handle idempotency?
    Which IDs in the EUM Social payload (message ID, conversation ID, etc.) should be treated as canonical for:

    • Deduplication in DynamoDB, and
    • Grouping messages and events into conversations?
  1. SNS volume, fan-out, DLQs
  • Are there important quotas/limits specific to EUM Social → SNS (per account, Region, WABA, or number) that we should monitor or request increases for?
  • For EUM Social events, is a standard SNS topic the usual recommendation, or are there scenarios where FIFO SNS is preferred (for strict per-conversation ordering)?
  • For downstream processing, is AWS’s recommended approach:
    • SNS → Lambda directly, or
    • SNS → SQS → Lambda for buffering/backpressure and independent retries?
  • Any guidance on:
    • Configuring DLQs and retries (SNS DLQ vs Lambda DLQ vs SQS DLQ), and
    • Which CloudWatch metrics/alarms you suggest for this integration?
  1. DynamoDB: multi-number / multi-WABA / multi-tenant

We support:

  • Multiple tenants (our customers),
  • Multiple WABAs per tenant,
  • Multiple phone numbers per WABA.

Current design:

  • One multi-tenant DynamoDB table per environment (e.g. Messages).
  • Partition key like tenantId#wabaId#phoneNumber, with sort keys and indexes for conversations, inbox views, and recency/status queries.

Questions:

  • Is this single multi-tenant table pattern appropriate for this use case, or would you recommend separate tables per tenant/WABA/other boundary?
  • In EUM Social payloads, which fields are best for:
    • Partition keys (conversation/session),
    • Idempotency keys,
    • Joining messages, events, and customer entities?
  1. Amplify + React inbox (real-time & security)

Because Amazon Connect is not available in our India Region, we use Amplify Gen 2 + React/Amplify UI as the agent console.

Questions:

  • For near real-time updates (new messages, delivery/read statuses), which pattern do you recommend:

    • AppSync GraphQL + subscriptions on top of DynamoDB,
    • API Gateway WebSockets, or
    • Another approach commonly used with EUM Social + DynamoDB?

  • Security-wise, our plan is:

    • Only backend Lambdas (Amplify functions) call EUM Social APIs.
    • The React client calls only our authenticated APIs/GraphQL resolvers (never directly to EUM Social).
      Is this the recommended integration model?

  • Any guidance on multi-tenant authorization with Amplify + DynamoDB so that:

    • Agents only see conversations for their tenant,
    • Optionally scoped further by WABA/number/team?
  1. WhatsApp Connect sample: setup issue

We are also trying to deploy the sample:

Even though we cannot use Amazon Connect in production in our Region, we want to understand and reuse the EUM Social + backend patterns (events, media/voice notes handling) and adapt them to our Amplify front end.

We are currently hitting deployment/setup issues following the documented steps (the stack does not complete as expected, and the solution is not functional). We can provide specific error messages/logs if needed.

Questions:

  • Is this sample known to be up-to-date and compatible with current versions of EUM Social, Amazon Connect (where supported), and related services?
  • Are there any known issues, missing steps, or required manual tweaks in the Builder/README instructions?
  • Is there an updated branch or installation guide we should use instead of main?

What we need

We are not asking for custom code. We are asking for:

  • Confirmation that our EUM Social → SNS → Lambda → DynamoDB → Amplify design (with Amplify front end, since Amazon Connect is not available in our India Region) follows AWS-recommended patterns for a custom WhatsApp inbox, and
  • Practical guidance on:
    • Any recommended adjustments (e.g., adding SQS/EventBridge, changing data model), and
    • How to resolve or work around current deployment issues with the “WhatsApp integration with Amazon Connect (with voice notes)” sample.

Thank you for your help.

Topics
Application IntegrationFront-End Web & MobileInternet of Things (IoT)Compute
Tags
Amazon Simple Notification Service (SNS)AWS End User MessagingAWS AmplifyAWS Lambda
Language
English

asked 10 months ago167 views

1 Answer
0

AWS End User Messaging Social with Custom WhatsApp Inbox

Architecture Validation

Your proposed architecture (EUM Social → SNS → Lambda → DynamoDB → Amplify APIs → React/Amplify UI) is a valid approach for building a custom WhatsApp inbox without Amazon Connect. This pattern aligns with AWS best practices for handling WhatsApp messaging through AWS End User Messaging Social.

EUM Social → SNS → Lambda → DynamoDB Pattern

This pattern is indeed recommended and supported by the EUM Social service for capturing both inbound WhatsApp messages and delivery/read/failure events. AWS End User Messaging Social is designed to publish messages and events to SNS topics, which can then trigger Lambda functions for processing.

For delivery semantics, you should assume at-least-once delivery with possible reordering. For idempotency, you should implement deduplication logic in your Lambda function using the message IDs provided in the EUM Social payload. Store these IDs in DynamoDB to prevent duplicate processing.

SNS Volume, Fan-out, and DLQs

Standard SNS topics are typically sufficient for EUM Social events. FIFO SNS would only be necessary if strict ordering per conversation is critical to your application logic.

For more resilient processing, consider using SNS → SQS → Lambda instead of SNS → Lambda directly. This pattern provides better buffering, backpressure handling, and independent retry capabilities.

For monitoring and error handling:

  • Configure DLQs at both the SQS and Lambda levels
  • Set up CloudWatch alarms for metrics like delivery failures, throttling events, and DLQ message counts
  • Monitor SNS delivery success rates and Lambda execution errors

DynamoDB: Multi-tenant Design

Your single multi-tenant table approach with partition keys like tenantId#wabaId#phoneNumber is appropriate for this use case. This design follows DynamoDB best practices for multi-tenant applications.

For EUM Social payloads:

  • Use conversation/session IDs from the payload for partition keys
  • Message IDs are ideal for idempotency keys
  • Customer phone numbers and WABA IDs can be used for joining messages, events, and customer entities

Amplify + React Inbox (Real-time & Security)

For near real-time updates, AppSync GraphQL with subscriptions on top of DynamoDB is the recommended approach when using Amplify. This provides a seamless real-time experience for your agent console.

Your security approach is correct:

  • Backend Lambdas should be the only components calling EUM Social APIs
  • The React client should only interact with authenticated APIs/GraphQL resolvers
  • Never expose EUM Social APIs directly to the client

For multi-tenant authorization with Amplify + DynamoDB:

  • Use Cognito user pools with custom attributes to store tenant information
  • Implement authorization logic in your GraphQL resolvers or API Gateway authorizers
  • Apply tenant-based filtering in your queries to ensure agents only see their tenant's data

WhatsApp Connect Sample Setup Issues

The sample you're referencing is designed to work with Amazon Connect, which may explain some of the deployment issues you're encountering since you're planning to adapt it to work without Connect. Some components may need significant modification to work with your Amplify-based approach.

If you're experiencing specific deployment issues with the sample, you might need to:

  1. Check for any region-specific dependencies in the CloudFormation templates
  2. Verify that all required permissions and IAM roles are correctly configured
  3. Ensure that your AWS account has the necessary service quotas and limits

Since you're planning to use only the EUM Social + backend patterns from this sample, you may need to extract and adapt those components rather than deploying the entire solution.
Sources
Automatización de flujos de trabajo con WhatsApp usando AWS End User Messaging Social | AWS Messaging Blog
Create a next generation chat assistant with Amazon Bedrock, Amazon Connect, Amazon Lex, LangChain, and WhatsApp | AWS Machine Learning Blog
Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS | AWS Messaging & Targeting Blog

For any specific queries related to any service, we require details that are non-public information. Please open a support case with respective AWS service using the following link.

answered 10 months ago

AWS
SUPPORT ENGINEER

revised 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content