AWS sends SMS two ways: Amazon SNS for simple, one-line transactional texts, and AWS End User Messaging (the service formerly called Amazon Pinpoint SMS) for two-way messaging, campaigns, and dedicated sender IDs. Both are powerful and pay-as-you-go — but sending to Indian numbers adds DLT registration, a sender-ID approval step, and a sandbox you must escape first. This guide covers every part.
The two ways AWS sends SMS
There isn't a single “AWS SMS” product. Two services send text messages, and picking the right one matters:
| Amazon SNS | AWS End User Messaging (Pinpoint SMS) | |
|---|---|---|
| Best for | Transactional OTPs & alerts | Campaigns, two-way, marketing |
| Send model | Publish to a number or topic | Send + receive, with events |
| Two-way / replies | No | Yes |
| Dedicated sender ID / number | Basic | Full (sender IDs, long/short codes) |
| Opt-out management | Manual | Built-in keyword handling |
| Setup effort | Minutes | More — pools, config sets, phone numbers |
Amazon SNS — the fastest path to a text
Amazon Simple Notification Service (SNS) can send an SMS with a single Publish call — no phone-number resource to provision. You either publish directly to a phone number in E.164 format, or publish to an SNS topic that fans out to many subscribers.
A minimal send
- Create an IAM user or role with
sns:Publishpermission. - Set your account's default SMS type — Transactional (higher priority, for OTPs) or Promotional.
- Call
Publishwith aPhoneNumberlike+9199XXXXXXXXand aMessagebody. - Read the delivery status from CloudWatch / delivery-status logs.
It's the same request whether you call it from the CLI, an SDK, or a Lambda — which is why SNS is the go-to for wiring an OTP into an existing AWS backend. If you just need to push a code from code, this is the shortest route; our guide to the SMS API shows the equivalent on a dedicated Indian platform.

AWS End User Messaging — for campaigns and two-way
AWS renamed the SMS and voice side of Amazon Pinpoint to AWS End User Messaging in 2024. This is the richer service: you provision origination identities (sender IDs, long codes, short codes), group them into phone pools, attach configuration sets for event logging, and handle inbound replies and opt-out keywords automatically.
- Two-way SMS. Receive replies and route them to an SNS topic or Amazon Connect.
- Opt-out lists. STOP/UNSUBSCRIBE handling is managed for you.
- Event stream. Per-message delivery, bounce, and complaint events to Kinesis/CloudWatch.
- Sender IDs. Register a branded alphabetic sender ID where the country supports it — including India.

Sending SMS on AWS in India: the DLT catch
This is where teams get stuck. India's TRAI regulations require every business sender to be registered on a telecom-operator DLT platform, and AWS enforces it. To deliver to Indian numbers you must supply, per message, your DLT Entity ID and Template ID, and send from a registered Sender ID (Header) that matches an approved template.
- Complete DLT registration — Principal Entity, Header (sender ID), and content templates — on a DLT portal (Jio, Airtel, Vodafone Idea, or BSNL).
- Register your Sender ID and templates inside AWS End User Messaging, mapping them to the DLT Entity ID and Template ID.
- Pass the Entity ID and Template ID as message attributes on every send, or the operator rejects the message.
The SMS sandbox and spending limits
Two account-level gates trip up first-time senders:
- The SMS sandbox.Every new AWS account starts in a sandbox that can only send to phone numbers you've verified. You must open a support case to move to production before you can text real customers.
- Monthly spend quota.AWS sets a low default SMS spending limit (historically about $1/month). Until you request an increase, sends stop the moment you hit it — a classic “why did my OTPs stop” surprise in production.
AWS SMS pricing, briefly
Both services are pay-as-you-go with no minimum. You pay a per-message price that varies by destination country and, in India, by the carrier and message type. On top of the AWS price there can be operator/DLT fees. AWS also bills for inbound (two-way) messages and for dedicated numbers.
Because Indian carrier rates and DLT fees change, always price against AWS's current India rate card rather than a number you read in a blog. For a plain-English comparison of how Indian SMS is priced across platforms, see our guide to sending SMS online in India.

Quick setup checklist
- Create an IAM role scoped to only the SNS / End User Messaging actions you need.
- Choose the service: SNS for one-way OTPs, End User Messaging for two-way or campaigns.
- Request production access (leave the SMS sandbox) and raise your monthly spend limit.
- For India: finish DLT registration, then register the sender ID and templates in AWS.
- Set up a configuration set / delivery-status logging so you can actually see failures.
- Send a test to a verified number, confirm the delivery event, then go live.
When AWS SMS is the right call — and when it isn't
If your stack already lives on AWS and you have the DevOps capacity to manage DLT registration, sender-ID mapping, the sandbox, and delivery monitoring yourself, AWS SMS is a solid, scalable choice that keeps everything in one bill.
But if you're India-first, want DLT and sender-ID onboarding handled for you, need someone to call when the operator route misbehaves, or just don't want to run the template-mapping gauntlet, a dedicated Indian provider gets you to first-message faster — often the same day — with delivery support built in.
| If you need… | AWS SMS | Dedicated India provider |
|---|---|---|
| Everything inside your AWS bill | Yes | Separate |
| DLT & sender ID handled for you | You do it | Done for you |
| Time to first live SMS in India | Days–weeks | Often same day |
| Hands-on delivery support | Support plan | Included |
| Deep AWS-native automation | Best | Via API/webhooks |
Frequently asked questions
AWS itself was never the problem — DLT template mismatches were. We spent more time on sender-ID and template paperwork than on the actual integration.



