SNS messages can be 1 MiB now. The default is still 256 KiB.

On 18 Sep 2026, Amazon SNS added message payloads up to 1 MiB (1,048,576 bytes), four times the old 256 KiB ceiling. Nothing changes until you set the topic attribute MaximumMessageSize. Every existing topic, and every new topic, still defaults to 262,144 bytes. Publish a larger body and SNS returns InvalidParameter.

The useful part is not the new ceiling. It is the bill, the subscriber lockout, and a quotas page that has not caught up. On 23 Sep 2026 the SNS service quotas page still said the maximum message size is 262,144 bytes and told you to use the Extended Client above that. The large-message guide and the pricing page already describe 1 MiB. If those two disagree in your browser, believe the developer guide for what Publish accepts, and believe the pricing page for how the chunk is counted.

Protocol prices, SMS, and fan-out to email stay in the SNS pricing post. This post is only the payload-size decision.

Reproduce this — Open payload-cost-worksheet.csv and set-maximum-message-size.md. The worksheet prices three sizes at 50 cents per million Standard requests: 64 KiB = 50 cents per million publishes, 256 KiB = 2 dollars, 1 MiB = 8 dollars. That is the FAQ rate times the chunk count. It is not a bill from a production topic.

What you have to set

MaximumMessageSize accepts any integer from 1,024 to 1,048,576. SNS counts the message body and message attributes against it. Publish and PublishBatch both enforce it. There is no new API. CreateTopic takes the attribute. SetTopicAttributes changes it later. GetTopicAttributes returns it only after you set it. Omitted means 262,144.

Above 256 KiB the topic is a different product shape:

• At most 100 subscriptions. One more subscription returns InvalidParameter.
• Every subscription must be Amazon SQS, AWS Lambda, or Amazon Data Firehose.
• HTTP, HTTPS, email, email-json, SMS, and mobile push are legal only while the attribute stays at 256 KiB or below.

You can raise or lower the value later. To cross 256 KiB, the topic must already satisfy the 100-subscription rule and the endpoint rule. Clean the subscribers first, then set the attribute.

AWS CLI v2. Replace the topic ARN. Use a smaller value on Firehose topics. The commands are also in the artifact.

aws sns set-topic-attributes \
  --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic \
  --attribute-name MaximumMessageSize \
  --attribute-value 1048576

Opinion: Keep the default on any topic that still has a human subscriber (email, SMS, webhook). Raise the attribute only on an internal topic whose subscribers are SQS, Lambda, or Firehose, and whose body actually sits between 256 KiB and 1 MiB. A payload that is a document, an image, or a model response belongs in S3 with a small event. The Extended Client still does that, up to 2 GB.

The 64 KB chunk did not go away

Standard topics still bill one request per 64 KB chunk of published data. The pricing page’s own example, fetched 23 Sep 2026, says a single publish with a 1 MiB payload is billed as 16 requests. A 256 KiB publish remains 4 requests. The new ceiling costs four times the request count of the old ceiling, for one publish.

The SNS FAQ rate is 50 cents per million requests. One million publishes of a full 1 MiB body are 16 million billable requests, which is 8 dollars before the monthly free tier of the first 1 million requests. One worked example, not a second invented workload: that is the entire Standard publish line for this shape. Delivery is extra.

The same chunk rule applies to notification deliveries, except SMS. One 1 MiB notification is 16 deliveries. HTTP delivery in the pricing post is 60 cents per million. A 1 MiB HTTP subscriber therefore multiplies that line by 16 as well. You should not be on HTTP anyway once the topic is above 256 KiB. The chunk note matters for the day you still have that subscriber and the attribute change is rejected, and for any delivery path that stays on the 64 KB rule.

SNS does not charge a per-message delivery fee to SQS or Lambda. The pricing page does charge data transfer from SNS to SQS or Lambda at internet data-transfer rates, including when the transfer stays in one Region. Read the live data-transfer table before you model a 1 MiB fan-out. Do not assume “SQS delivery is free” covers the bytes. The SQS 64 KB post still prices Standard queue requests at 40 cents per million, one request per 64 KB. A 1 MiB body that lands on a Standard queue is 16 SQS requests on that rule (6 dollars and 40 cents per million such receives) unless the SQS pricing page says otherwise when you check it.

FIFO is the page that did get updated. Fetched the same day: each message from 1 KB up to the topic maximum (up to 1 MiB) counts as one FIFO message, plus the per-GB payload charge. Our June 2026 pricing breakdown has FIFO publish at 30 cents per million plus 17 cents for every 10 GB of payload. A 1 MiB FIFO message is one API message plus 1 MiB on the per-GB payload line. The Standard chunk multiplier does not apply. Confirm those two unit prices on the pricing page. The “up to 256 KB counts as one message” sentence is gone from the page we read.

Where delivery still fails

What broke (AWS-documented) — Firehose delivery fails when the SNS body plus delivery metadata exceeds 1,024,000 bytes, even though SNS accepted the publish. Detection: NumberOfNotificationsFailed on the topic, and the subscription DLQ if you attached one. Recovery: set MaximumMessageSize lower on any topic that has a Firehose subscription, and leave headroom under 1,000 KiB. A DLQ on every large-message subscription is the difference between a failed delivery you can replay and a body you only notice in a cost report.

Put a CloudWatch alarm on NumberOfNotificationsFailed the same day you raise the attribute.

How this differs from the old escape hatches

Claim check / Extended Client. Java and Python libraries write the payload to S3 and publish a reference. Still the path above 1 MiB, up to 2 GB, and the path that keeps email and HTTP subscribers on a small message. You pay S3 for the object. Subscribers must dereference the pointer. SQS subscribers use the SQS extended client. Lambda subscribers use the payload-offloading library. Do not adopt 1 MiB inline bodies and also wrap them in the extended client. Pick one.

EventBridge. Use it when the consumer set is not “SQS, Lambda, Firehose, at most 100.” The EventBridge pricing post is the cost comparison for custom buses. SNS-to-SQS remains the cheaper fan-out when the consumers are known queues and the body fits.

Leave the body in S3 from the start. If the message is a document the consumer will parse, the 1 MiB raise only delays the S3 design. It does not remove the 16-chunk Standard multiplier or the Firehose metadata trap.

What to Do This Week

1. Run get-topic-attributes on topics that have been failing publishes near 256 KiB. Missing MaximumMessageSize means the default still applies.
2. List subscriptions. If you see email, SMS, or HTTP, do not raise the attribute. Split those subscribers onto a topic that stays at 262144.
3. If every subscriber is SQS or Lambda and the count is 100 or under, set the attribute to the size you need, not automatically to 1048576.
4. If any subscriber is Firehose, stay under 1,024,000 bytes with room for SNS metadata.
5. Add a DLQ and an alarm on NumberOfNotificationsFailed.
6. Price the publish with the worksheet before you tell finance the change is free. One million 1 MiB Standard publishes are 8 dollars in request units at 50 cents per million, before delivery, data transfer, and the SQS side.

What This Post Doesn’t Cover

SMS country rates, FIFO throughput quotas, and filter-policy pricing. Those stay in the SNS pricing post. We did not publish a 1 MiB body in a customer account for this post. The service quotas page was still on 256 KiB when we read it on 23 Sep 2026. In-region SNS-to-SQS data-transfer dollars change by Region. Read the table. Do not copy the $8 figure onto FIFO. FIFO is one message plus payload gigabytes.