Amazon SNS 1 MiB Payloads Make 256 KiB a Compatibility Boundary
Cover image: Amazon SNS payload-size compatibility map showing the default 256 KiB boundary, the opt-in 1 MiB ceiling, and the restricted SQS, Lambda, and Data Firehose path above 256 KiB. Original illustration: Tech Trend Insight.
AWS expanded Amazon Simple Notification Service payloads on September 19, 2026, from 256 KiB to a configurable maximum of 1 MiB (1,048,576 bytes) for Standard and FIFO topics. The feature is opt-in through the MaximumMessageSize topic attribute; existing and newly created topics remain at 256 KiB (262,144 bytes) unless that attribute is set. (AWS announcement, AWS 2026 announcement archive)
The consequential boundary is not 1 MiB, however. It is 256 KiB. Configuring a topic above that threshold restricts which endpoints may subscribe, limits the topic to 100 subscriptions, creates a size mismatch with Amazon Data Firehose, and changes the cost profile of large messages. The setting should therefore be treated as part of the topic’s interface contract—not as a routine quota increase.
What changes when a topic crosses 256 KiB
According to the Amazon SNS Developer Guide, MaximumMessageSize accepts any integer from 1,024 to 1,048,576 bytes. SNS compares the configured value with the combined size of the message body and its message attributes. When that combined size exceeds the limit, Publish returns an InvalidParameter error.
The threshold also determines the topic’s subscription profile:
| Topic configuration | Eligible subscription types | Large-message-specific subscription limit |
|---|---|---|
MaximumMessageSize at or below 256 KiB |
SQS, Lambda, Data Firehose, HTTP/HTTPS, SMS, email, email-JSON, and mobile push | No 100-subscription restriction documented for this feature |
MaximumMessageSize above 256 KiB |
Amazon SQS, AWS Lambda, and Amazon Data Firehose only | 100 total subscriptions |
For an existing topic, AWS will reject an attempt to set MaximumMessageSize above 256 KiB if the topic has more than 100 subscriptions or contains an unsupported endpoint. Attempts to add a 101st subscription to an already eligible large-message topic also return InvalidParameter.
Architectural inference: a topic above 256 KiB becomes a narrower application-to-application channel. If one topic currently serves SQS consumers alongside webhooks, email, SMS, or mobile push, increasing its ceiling in place is not compatible with the existing topology. A separate large-message topic preserves the broader notification paths without forcing every subscriber to adopt the new contract.
Illustrative topology: the 256 KiB boundary separates broad-protocol SNS fan-out from a large-message path limited to SQS, Lambda, and Data Firehose. This is a configuration diagram, not a performance result.
The attribute is explicit, and absence still means 256 KiB
Large-message support uses existing SNS operations rather than a separate publishing API. AWS documents the following behavior:
CreateTopicacceptsMaximumMessageSizein its attributes map.SetTopicAttributeschanges the threshold on an existing topic.GetTopicAttributesreturnsMaximumMessageSizeonly when it has been explicitly set. If the attribute is absent, the effective value remains 262,144 bytes.- New
Publishrequests are evaluated against the current threshold after it changes.
That last point matters for rollout discipline. Raising the value allows publishers to begin emitting larger events immediately, but lowering it later causes newly published messages above the reduced threshold to fail. The configured maximum should therefore be versioned with the event contract and represented in infrastructure configuration rather than treated as an undocumented console setting.
Payload budgeting must include attributes. A producer that validates only the serialized body can still be rejected when routing, tracing, or business metadata pushes the combined size over the topic limit.
SNS admission does not guarantee Firehose delivery
The largest documented interoperability gap is between SNS and Amazon Data Firehose.
SNS can admit a message up to 1,024 KiB (1,048,576 bytes), while the Amazon Data Firehose quota limits a record to 1,000 KiB (1,024,000 bytes) before base64 encoding. For SNS delivery, AWS says the Firehose record calculation includes SNS metadata such as the message ID and timestamp. A message can therefore satisfy the SNS topic limit but fail on the Firehose subscription.
AWS explicitly recommends setting a lower MaximumMessageSize for topics with Firehose subscriptions. It does not publish one universally safe replacement value because the delivered record must include both the payload and applicable delivery metadata.
The other supported endpoint types have different documented behavior:
- Amazon SQS: SNS can deliver up to the SNS topic’s configured limit. AWS states that the queue’s own
MaximumMessageSizesetting does not apply to messages delivered from SNS; the topic setting is the effective limit for this path. - AWS Lambda: SNS invokes Lambda asynchronously, and AWS documents support for asynchronous invocation payloads up to 1 MiB without additional SNS subscription configuration.
- Amazon Data Firehose: delivery fails if the resulting record exceeds the Firehose limit, even when SNS accepted the publication.
Illustrative failure path: SNS validates the body-plus-attributes publish size first, but Firehose applies a separate record limit that includes delivery metadata. The diagram represents documented limits, not measured headroom.
Raw delivery changes the envelope, not the documented admission rule
Raw message delivery is configured per subscription:
- For an SQS subscription, raw delivery removes the SNS JSON metadata wrapper and sends the published message as-is. With raw delivery enabled, SQS subscriptions can receive at most 10 message attributes; SNS discards messages with more than 10 attributes for that subscription as client-side errors.
- For a Firehose subscription, AWS states that the message body is delivered and message attributes are not sent when raw delivery is enabled.
Raw delivery therefore changes the downstream representation. It does not change the documented SNS publish rule: admission is still based on the body plus message attributes. AWS also does not document a universal Firehose-safe SNS ceiling for every raw and non-raw envelope configuration.
Recovery controls belong on every subscription
The large-message guide recommends configuring a dead-letter queue on every subscription and monitoring failed deliveries with CloudWatch.
An SNS dead-letter queue is an SQS queue attached to an individual subscription, not to the topic. It retains messages that SNS cannot successfully deliver, allowing later analysis or reprocessing. Without a DLQ, SNS discards a message after the applicable delivery behavior is exhausted.
AWS also recommends an alarm on the NumberOfNotificationsFailed metric. Its interpretation varies by endpoint: for SQS, email, SMS, and mobile push, it increments when SNS stops attempting delivery; for HTTP/HTTPS, it includes failed retry attempts; for other endpoints, it increments when delivery fails regardless of attempt count.
For DLQ activity itself, AWS recommends monitoring the SQS ApproximateNumberOfMessagesVisible metric rather than NumberOfMessagesSent, because the latter does not capture every message moved into a DLQ through failed processing.
A 1 MiB Standard publish counts as 16 requests
The Amazon SNS pricing page uses different metering models for Standard and FIFO topics.
For Standard topics, AWS bills each 64 KB chunk of published data as one request. Its explicit example states that a single publish containing a 1 MiB payload is billed as 16 requests. Except for SMS, each 64 KB chunk of delivered data is similarly counted as one delivery, so a 1 MiB notification is 16 delivery units where delivery pricing applies.
Endpoint conditions still matter. AWS states that SNS does not charge a per-message notification-delivery fee for SQS and Lambda, although data-transfer charges may apply. Consequently, multiplying 16 units by a generic delivery rate would not produce a valid estimate for every subscriber mix.
For FIFO topics, each message from 1 KB through the configured maximum of up to 1 MiB is counted as one message, with messages below 1 KB rounded up. FIFO pricing also includes payload data, and subscribed-message calculations count both filtered and delivered messages.
Filtering adds another size-sensitive dimension:
- Attribute-based filtering is free.
- Payload-based filtering is charged on outbound payload data scanned for every subscription with an active filter policy.
- Both filtered-out and delivered messages contribute to scanned data.
- Each outbound message scanned has a minimum billable size of 1 KB.
Illustrative metering comparison: Standard topics divide a 1 MiB publication into 16 published-data request units, while FIFO topics count the message once and separately meter payload data. This is not a cost forecast.
| Capability / Tool | Operation Scope | Risk Tier | Authorization / Confirmation | Failure Fallback Policy |
|---|---|---|---|---|
| list_structures | Query home spaces & room hierarchies | Low Risk | Not required (Autonomous) | Return cached local topology |
| list_devices | Enumerate registered devices & traits | Low Risk | Not required (Autonomous) | Degrade to known device roster |
| get_device_state | Poll real-time sensor/switch telemetry | Moderate | Not required (Autonomous) | Report last-known state with timestamp |
| execute_device_action | Mutate physical device state (e.g. locks, power) | High / Critical | Mandatory for security traits | Rollback transaction & notify user |
| batch_device_actions | Multi-step composite room automations | Elevated Risk | Preview confirmation prompt | Atomic abort if any critical step fails |
Direct delivery and S3 offload solve different size ranges
For messages above 1 MiB, AWS continues to support its Extended Client Libraries for Java and Python. The libraries store the payload in Amazon S3 and publish an S3 reference through SNS. The current large-message guide documents support for payloads up to 2 GB with both Standard and FIFO topics.
The S3 path remains relevant below 1 MiB as well. Direct delivery removes the S3 object from the message path, but it does not establish a universal cost or reliability advantage. AWS documents that the offload path incurs S3 storage charges, while direct Standard-topic delivery remains subject to chunked publishing, applicable delivery units, filtering scans, and data transfer.
A workload-specific comparison should include:
- the observed body-plus-attribute size distribution;
- SNS publish, delivery, filtering, and transfer charges;
- S3 storage and request charges for offloaded payloads;
- consumer support for dereferencing S3 objects;
- access-control and encryption requirements;
- failure inspection, retention, and replay behavior.
Open evidence boundary: AWS has not published a universal direct-delivery break-even point, nor comparative latency, throughput, memory, or retry-amplification results for near-1 MiB SNS messages.
Independent boundary test corroborates the documentation
A DevelopersIO test published September 19, 2026 configured a Standard topic at 1,048,576 bytes, subscribed an SQS queue with raw message delivery, and used bodies without message attributes.
The author reported that a 1,048,576-byte body was accepted and received by SQS, while a 1,048,577-byte publish was rejected with InvalidParameter: Message too long. The same article reported acceptance at the unset default boundary of 262,144 bytes and rejection at 262,145 bytes.
This is secondary corroboration, not Tech Trend Insight testing. It validates the documented byte boundary under one configuration; it does not establish latency, throughput, reliability, memory use, or Firehose-safe headroom.
Decision rule: raise the ceiling only when the whole route qualifies
Setting every eligible topic to 1 MiB is not the conservative default. Use the lowest threshold that covers the measured payload distribution, including attributes, and raise it only when all of the following are true:
- Topology qualifies: every subscription is SQS, Lambda, or Data Firehose, and the topic has no more than 100 subscriptions.
- The complete event fits: body and attributes remain within the chosen ceiling under representative production data.
- Firehose has tested headroom: when Firehose is present, the chosen limit remains below the effective delivered-record boundary for the intended envelope configuration.
- Failures are recoverable: each subscription has an appropriate DLQ, alarms cover delivery failures, and replay behavior has been exercised.
- The economics are measured: direct delivery has been compared with the existing S3 claim-check path using the real payload distribution and subscriber fan-out.
If any condition fails, keep the topic at 256 KiB, split the fan-out into separate topics, reduce the event, or retain S3 offload.
Proposed validation plan — not performed by Tech Trend Insight
- Test combined size, not body size alone. Publish representative events with production-like attributes at the proposed threshold, one byte below it, and one byte above it.
- Exercise every subscription independently. Confirm delivery to SQS, Lambda, and Firehose rather than treating successful publication as end-to-end success.
- Probe Firehose incrementally. Record body size, attributes, raw-delivery state, delivered format, DLQ outcome, and
NumberOfNotificationsFailed. The goal is a configuration-specific ceiling, not a universal estimate. - Compare raw and wrapped delivery. Verify the consumer-visible message shape and attribute behavior for each supported endpoint.
- Measure both architectures. Run the same payload distribution through direct SNS delivery and the existing S3 offload path, recording latency percentiles, retries, throughput, billable units, S3 usage, and recovery outcomes.
- Test rollback before migration. Confirm how publishers behave when
MaximumMessageSizeis lowered after larger events have been introduced.
