miruky

Posted on Sep 9

Compare Raw and Wrapped Amazon SNS Messages in Amazon SQS

#aws #sns #sqs #tutorial

Introduction

Hi, I'm miruky.

An Amazon SNS subscription to Amazon SQS can deliver either an SNS notification envelope or the published message body itself. The Raw message delivery setting controls that boundary, and the consumer sees a materially different payload even though both queues receive the same publish.

This Console run connects one Standard topic to two Standard queues. One subscription keeps raw delivery disabled, while the other enables it; a single synthetic JSON message then produces a wrapped body in one queue and the unchanged message in the other.

The exercise uses one SNS publish and a few SQS requests. Current SNS and SQS request pricing and free-tier terms are linked below.

1. Create one topic and two queues

Before resource creation, the working session used the English AWS Console in United States (N. Virginia). The topic, queues, subscriptions, publish, and receives remain in us-east-1.

The header confirms United States (N. Virginia) while the SNS Console is in English. This fixes the Region shared by the topic, subscriptions, queues, and messages.

Open Amazon SNS, choose Topics, and search for miruky-oxsoiimhavlbcyhm. Confirm that no exact match exists, then start creating a Standard topic with that name. Leave delivery-status logging unconfigured so the run does not create a logging role or publish delivery logs.

The creation-form crop shows miruky-oxsoiimhavlbcyhm and Standard before the topic is created. Topic ARN and account-scoped details do not yet exist in this view; delivery-status logging is verified privately after creation.

In Amazon SQS, search for the exact names miruky-wpmasjamumxmwsaj and miruky-uqlprtivfyrjaxtz, and stop if either already exists. Otherwise, create both as Standard queues. Keep their default delivery settings and SQS-managed server-side encryption.

The queue list shows miruky-wpmasjamumxmwsaj and miruky-uqlprtivfyrjaxtz as Standard queues. Their random names do not reveal which subscription will use raw delivery.

The queue assigned the wrapped role will retain the SNS envelope. The queue assigned the raw role will receive only the published message body; the random names avoid encoding those roles into AWS resource names.

2. Subscribe both queues, then change one attribute

Open miruky-wpmasjamumxmwsaj, choose Actions, then Subscribe to Amazon SNS topic. Select miruky-oxsoiimhavlbcyhm from the same-account topic list and save. Repeat for miruky-uqlprtivfyrjaxtz.

Creating the subscriptions from the SQS Console also manages the required queue policy statement. Do not publish that policy: its resource and condition contain the queue and topic ARNs with your account ID.

Return to the SNS topic and open its subscriptions. Leave raw delivery disabled for the subscription whose endpoint ARN ends with miruky-wpmasjamumxmwsaj. For the subscription whose endpoint ends with miruky-uqlprtivfyrjaxtz, store the raw-delivery attribute as true and save the change. Match only the generated suffixes; never copy an account-scoped ARN into the article.

The cropped editor shows Enable raw message delivery selected for the raw-target subscription. Its endpoint ARN and subscription ID are excluded. The wrapped-target subscription is left at its disabled default; the wrapped result below verifies that behavior rather than relying on an additional settings screenshot.

The setting applies to later deliveries. Configure both subscriptions before publishing so the two bodies come from the same SNS message.

3. Prove the comparison starts with an empty queue

Before publishing, open miruky-wpmasjamumxmwsaj, choose Send and receive messages, and complete one polling cycle. Expect zero messages at this point.

The receive area remains empty after the polling cycle. This negative control rules out an older queue message before the comparison begins.

4. Publish one controlled JSON message

Choose Publish message on the topic. Leave the subject empty, use identical payloads for all delivery protocols, and enter this message body:

{"orderId":"order-001","status":"ready"}

Enter that JSON on one line so whitespace cannot change the escaped wrapped value. Do not add message attributes. Raw delivery to SQS supports at most ten message attributes, and SNS discards a raw-delivery message with more than ten as a client-side error; attributes are outside this comparison.

The public crop shows Identical payload for all delivery protocols. and the exact {"orderId":"order-001","status":"ready"} body. I verified the empty subject and empty message-attribute inputs privately before the only publish. The single-line body fixes the escaped value expected in the wrapped message.

Choose Publish message and record the success confirmation without its service-generated message ID. One publish should fan out to both queue subscriptions.

The Console reports that the message was published successfully. The service-generated message identifier is outside the retained confirmation.

5. Compare the two SQS bodies

Open miruky-wpmasjamumxmwsaj, choose Send and receive messages, and poll. With raw delivery disabled, the SQS body is an SNS notification JSON document. Its outer Message member can be shown without retaining the account-scoped fields around it:

"Message": "{\"orderId\":\"order-001\",\"status\":\"ready\"}"

The Message value is a JSON string inside the larger SNS notification envelope. The complete body also carries an SNS notification type, a message ID, topic ARN, timestamp, signature, certificate URL, and unsubscribe URL. Those fields surround Message in the full document, so the published image is one tight rectangular crop around that line only.

The cropped excerpt shows Message with the escaped {"orderId":"order-001","status":"ready"} value. No type, topic, signature, timestamp, URL, or message identifier remains in the image.

Now poll miruky-uqlprtivfyrjaxtz. With raw delivery enabled, SNS strips its metadata and sends the published body as-is:

{"orderId":"order-001","status":"ready"}

The raw queue body is exactly {"orderId":"order-001","status":"ready"}. The displayed body text matches the original SNS publish.

The raw queue has no outer Type, TopicArn, Message, signature, or unsubscribe URL fields. Its consumer can parse the order object directly, while the wrapped consumer must parse the SNS envelope and then parse the escaped Message string.

Both destinations are Standard queues, so this comparison proves the body contract, not exactly-once delivery. Standard queues can deliver a duplicate or occasionally change message order; a production consumer still needs idempotent handling regardless of the raw-delivery setting.

Wrap-up

One SNS publish reached both SQS queues. The wrapped SQS body was an SNS notification envelope; the raw SQS body was the original two-field JSON.

Raw delivery reduces envelope parsing when a consumer needs only the published payload. Wrapped delivery retains SNS metadata that can matter to consumers, so the choice belongs in the subscription contract rather than being treated as a cosmetic Console setting.

Thanks for reading this far.

See you in the next one.

Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.

DEV Community