AWS Communication Developer Services Consulting

What AWS Communication Developer Services covers

AWS Communication Developer Services (CDS) is AWS’s name for the channels a business uses to reach customers:

Push is an End User Messaging channel too, but it sits outside the CDS list. FactualMinds builds on these services. We do not hold a CDS designation, and this page does not claim one.

The deep dives are in our six-part series: the channel decision hub, RCS, SMS and 10DLC, WhatsApp, the SES agent skill, and the production agent architecture. The dedicated engagement pages are WhatsApp Business API on AWS and RCS Business Messaging on AWS.

Architecture we build

1. Send path per job. Each job gets its own origination identity and registration. OTP uses Notify or a dedicated OTP registration. Order status uses an RCS agent and a same-use-case SMS number in one phone pool. Promotions get their own registration. Email goes through SES configuration sets.
2. Event path. Every channel writes delivery and inbound events to Amazon SNS, EventBridge, or Firehose. Configuration sets are attached before the first send, because event destinations do not backfill.
3. Filter before the model. A Lambda function drops delivery, read, and status events. Only customer messages reach the model.
4. Agent. Amazon Bedrock answers with tools scoped to reads: order lookup, delivery window, policy text. For production runtime, identity, and memory we use Amazon Bedrock AgentCore.
5. Approval gate. Refunds, address changes, and price changes become a proposal a named person approves. The same rule is in human-in-the-loop approvals.
6. Consent. STOP and HELP keywords, opt-out lists, WhatsApp template categories, and the SES suppression list are configured and tested before go-live.

Between the channels and the agent sits an application layer we build and you own: one internal event contract for every channel, dedup on the provider message ID, one ordered queue per conversation, and a channel adapter per send path that keeps each channel’s registration, template, and opt-out rules. The agent never calls a send API or a write API directly. The engineering detail, including evaluation and failure handling, is in production agentic AI on AWS CDS and AgentCore.

Engagement phases

What the bill looks like before anyone replies

US list prices from the End User Messaging pricing page, read 29 September 2026. These are AWS list prices, not a client bill:

• US Rich RCS text: $0.01194 per delivered 160-byte segment. A rich card: $0.02949 per delivered message.
• WhatsApp: AWS charges a per-message fee and Meta charges its own on top, by country and message type. See the WhatsApp Business API page for current rates.
• US SMS: registration fees plus a per-carrier rate published as a CSV on the same page.

What could go wrong

• One registration for everything. Carriers review use cases. A password reset and a discount on the same RCS agent invites a denial.
• A testing agent treated as a launch. An RCS test agent delivers only to enrolled phones. Customers get nothing.
• Paying the model for receipts. WhatsApp delivery and read events share the topic with user messages. Filter first.
• WhatsApp budget from the AWS fee only. The invoice includes Meta’s fee.
• The agent decides refunds. Keep money movement out of the tool list.

Who this is for

Good fit if:

• You send customer messages from your own product or store and want sending, events, and billing in your AWS account.
• You have more than one message job (for example OTP, order status, and receipts) and today each one goes through a different vendor.
• Your team can own an application and an AWS account, and needs help with registrations, event wiring, and a cost model.
• You operate in countries where RCS or WhatsApp is a realistic option, or you need SES and SMS sorted out first.

Not a fit if:

• You want a campaign tool with a drag-and-drop editor and a marketing team that never touches AWS. A marketing platform is a better tool for that.
• You need to send to a country AWS does not cover for the channel you want. Check current country support for each channel before you plan.
• You need a launch date that ignores carrier and Meta review times. Registrations set the schedule.
• You want us to hold your consent records or act as the sender of record. Those stay with you.

Choosing a channel per job

How the pieces fit together

• Origination identities. SMS uses phone numbers, sender IDs, or pools of them. RCS uses an RCS agent. WhatsApp uses a phone number linked to a WhatsApp Business Account. SES uses a verified domain or address. We keep one identity per use case so a carrier or Meta review of one job does not hold up another.
• Phone pools. A pool containing an RCS agent and a dedicated SMS number tries RCS first and falls back to SMS. AWS documents that shared SMS routes are not used for RCS fallback, so the pool needs a dedicated number or sender ID.
• Configuration sets and event destinations. A configuration set is attached when you send. It points to event destinations such as Amazon SNS, Amazon CloudWatch Logs, or Amazon Data Firehose (up to five per configuration set for SMS). Events from before a destination was attached are not replayed, so we set these up before the first production send.
• Amazon Connect. Used when people, not code, answer. WhatsApp can be linked to a Connect instance so agents take WhatsApp contacts next to voice and chat.
• Your application. Owns consent, templates’ variable data, and the rules for which job uses which channel.

Deliverables and engagement boundaries

We deliver:

• A channel plan with one row per message job, the identity it uses, and the registration blocker
• Registration support for SES identities, SMS registrations, RCS agents and launches, and the WhatsApp account link, including preparing the forms for your sign-off
• Event destinations, a filtering function, alarms for failed deliveries, and a runbook for opt-out and complaint handling
• A list-price cost worksheet per channel, with AWS fees and Meta fees on separate lines
• Handover documentation and a walkthrough with your engineers

You or third parties own:

• Your company details, brand assets, opt-in language, privacy policy, and the right to message each recipient
• Carrier decisions on SMS and RCS, and Meta decisions on WhatsApp accounts and templates. We prepare submissions, we do not control outcomes or timing.
• Message content, legal review of it, and the production application that calls the APIs
• The AWS bill, including Meta charges that appear on it for WhatsApp

Prerequisites and limits

• An AWS account with permission to create the messaging resources. Regional availability differs between SES, End User Messaging SMS and RCS, and End User Messaging Social, so we confirm the Region for each before design.
• RCS country launches are supported in a defined list of countries (22 at the time we checked the AWS docs on 27 October 2026), and each carrier in a country reviews your agent independently. A country can be partially active while some carriers are still pending.
• Not every device receives RCS. AWS lists older Android devices and iPhones earlier than iOS 18 as unable to receive it, which is one reason SMS fallback is part of the design.
• WhatsApp messaging through End User Messaging Social is not available to customers located in China.
• SMS delivery receipts can take up to 72 hours.
• Prices and country lists change. We re-check them against the AWS pages at the start of every engagement.

Related guides and services

• Channel decision hub
• SMS and 10DLC guide
• WhatsApp guide
• RCS guide
• Production agent architecture: events, permissions, evaluation
• WhatsApp Business API on AWS
• RCS Business Messaging on AWS
• Amazon SES consulting
• Amazon Connect

Next step

Bring your OTP, order-status, promotion, and receipt flows. We will return the channel plan, the registration schedule, and the list-price cost model. Contact us.