AWS sms-voice documentation change
Summary
Updated AI agent prompt with more detailed instructions for RCS message sending patterns, including CLI commands, Python/boto3 examples, compliance warnings, and delivery verification methods.
Security assessment
The changes are documentation improvements for using the RCS messaging service, focusing on operational patterns and compliance guidance. There is no evidence of addressing a specific security vulnerability, weakness, or incident. The compliance warning about account-level sending is about identity selection control, not a security fix.
Diff
diff --git a/sms-voice/latest/userguide/rcs-send-message.md b/sms-voice/latest/userguide/rcs-send-message.md index 7173fb063..ffd71a347 100644 --- a//sms-voice/latest/userguide/rcs-send-message.md +++ b//sms-voice/latest/userguide/rcs-send-message.md @@ -154,28 +154,82 @@ Copy the following prompt and paste it into your AI agent or coding assistant: - `pinpoint-sms-voice-v2` service. - - I need help with: - - 1. **Pool-based sending (recommended)** — Send a message through a phone pool - that contains my AWS RCS Agent and SMS phone numbers. Use the - `send-text-message` command with `--origination-identity` set to my pool ID. - The service handles RCS-first delivery with automatic SMS fallback. - - 2. **Account-level sending** — Send a message without specifying an origination - identity. The service selects the best identity from my account. Warn me - about compliance risks if I have multiple use cases. - - 3. **Direct RCS sending** — Send a message directly through my AWS RCS Agent - ARN for RCS-only delivery with no SMS fallback. Use this when I want - RCS-or-nothing delivery. - - For each pattern, show me: - - The AWS CLI command - - A Python/boto3 code example - - How to check the delivery status using CloudWatch metrics or event - destinations - - Important notes: - - The API is `send-text-message` (same as SMS), not a separate RCS API - - Pool-based sending is always recommended for automatic SMS fallback - - Sticky sending remembers the last successful identity for 25 hours - - Asynchronous SMS fallback occurs if no RCS signal within 25 seconds + `pinpoint-sms-voice-v2` service. Show me exact CLI commands and Python/boto3 + examples. Ask me for my details before generating any commands. + + **Important rules for generating commands:** + - The API is `send-text-message` — the same command used for SMS. There is + NO separate RCS send API. + - There is NO `describe-messages` API. Do not generate it. + - The boto3 method is `send_text_message` on the + `pinpoint-sms-voice-v2` client. + - Use the term "testing" — NOT "sandbox". + + **Prerequisites:** I have an existing RCS agent (created via the setup process) + and a verified test device. + + ### Pattern 1: Direct RCS sending (simplest, good for testing) + + Send directly through my RCS Agent ARN. RCS-only delivery, no SMS fallback. + If the recipient's device doesn't support RCS, the message is not delivered. + + CLI: `send-text-message --destination-phone-number <E.164> + --origination-identity <agent-arn> --message-body "<text>" + --message-type <TRANSACTIONAL|PROMOTIONAL>` + + Returns `MessageId`. + + ### Pattern 2: Pool-based sending (recommended for production) + + Send through a phone pool containing my RCS agent (and optionally SMS phone + numbers for fallback). The service tries RCS first, then falls back to SMS + asynchronously if no RCS signal within 25 seconds. This is NOT synchronous + fallback — the SMS is sent as a separate attempt after the timeout. + + To set up a pool: + - `create-pool --origination-identity <rcs-agent-id> --message-type TRANSACTIONAL` → returns `PoolId` + - Optionally add SMS numbers: `associate-origination-identity --pool-id <id> + --origination-identity <phone-number-id>` + + CLI: `send-text-message --destination-phone-number <E.164> + --origination-identity <pool-id> --message-body "<text>" + --message-type <TRANSACTIONAL|PROMOTIONAL>` + + ### Pattern 3: Account-level sending + + Send without specifying `--origination-identity`. The service auto-selects + the best identity from the account. + + CLI: `send-text-message --destination-phone-number <E.164> + --message-body "<text>" --message-type <TRANSACTIONAL|PROMOTIONAL>` + + **Compliance warning:** If the account has multiple RCS agents, SMS numbers, + or different use cases, the service picks an identity automatically — which + may not be the intended one. Use pool-based or direct sending for explicit + control over which identity is used. + + ### Delivery verification + + - For testing: check the test device directly — the message appears from + the branded RCS agent. + - For production: configure event destinations BEFORE sending using + `create-event-destination` (SNS, CloudWatch Logs, or Firehose). Event + destinations do not retroactively capture events for already-sent messages. + - CloudWatch metrics in `AWS/SMSVoice` namespace provide aggregate delivery + statistics. + + ### Behavioral notes + + - Sticky sending: the service remembers the last successful identity per + destination number for 25 hours. + - Pool-based sending is recommended for production because it provides + automatic SMS fallback. + - All three patterns use the same `send-text-message` API — the only + difference is what you pass (or don't pass) as `--origination-identity`. + + --- + + **Before generating commands, ask me for:** + - Which sending pattern I want to use (direct, pool-based, or account-level) + - My RCS Agent ARN + - My pool ID (if using pool-based sending) + - Destination phone number in E.164 format + - Message type (TRANSACTIONAL or PROMOTIONAL) + - Message text