Executive summary
Amazon SNS now supports “message payloads up to 1 MiB, a 4x increase from the previous 256 KiB limit.” It applies to both Standard and FIFO topics, is available in every Region where SNS runs, and is opt-in through a new MaximumMessageSize topic attribute.
For anyone who has built the S3-pointer pattern — write the payload to a bucket, publish a reference, make every consumer fetch it and eventually expire it — this removes a class of plumbing outright.
There is a cost, and it is stated in one sentence that is easy to read past: “Topics with MaximumMessageSize set above 256 KiB support Amazon SQS, Amazon Data Firehose, and AWS Lambda subscriptions, with up to 100 total subscriptions per topic.”
What changed
The ceiling moved, for topics that ask. 256 KiB to 1 MiB, on an attribute you set per topic. Nothing changes for existing topics unless you change it, which is the right default for a limit that other things depend on.
Two constraints arrive with it. A topic above 256 KiB supports three subscription types — SQS, Data Firehose and Lambda — and no more than 100 subscriptions in total.
Both halves matter. The protocol list excludes HTTP/S, email, SMS and mobile push, which is most of what SNS is used for outside service-to-service messaging. And 100 is a very different number from the standard topic default, which is 12,500,000 subscriptions per topic.
So this is not simply a bigger version of the topic you already have. It is a different kind of topic, selected by a size attribute.
Architecture
The clearest way to see the change is to line the two topic shapes up against each other.
A default standard topic carries up to “262,144 bytes (256 KiB)” and can fan out to every protocol SNS supports, with a subscription quota of 12.5 million. Raise the attribute and you get four times the payload, three protocols, and a hundred subscriptions.
That is a coherent design. Large payloads to HTTP endpoints, email and SMS do not make sense, and a topic that delivers megabyte messages to millions of subscribers is a different cost and reliability proposition entirely. But it does mean the decision is architectural rather than operational: you are choosing what the topic is for.
One further limit worth carrying if Firehose is in the plan: its subscription quota is 5 per topic, per subscription owner, which binds well before the 100.
Business value
The value is deleting the S3-pointer pattern for the middle band of payload sizes — the messages between 256 KiB and 1 MiB that were just over the line.
That pattern is not expensive in dollars; it is expensive in obligations. Every consumer needs bucket permissions. Every payload needs a lifecycle rule. Every failure mode gains a variant where the message arrived and the object did not, or the object expired before a replay. Removing it removes all of that at once for workloads that fit.
The workloads that benefit are recognisable: a document or image processing event carrying metadata rather than a reference, a change event carrying the full new state instead of an ID, an audit or analytics record too detailed for 256 KiB. All of them are service-to-service, which is exactly the shape the protocol restriction permits.
Security considerations
No permission model change is stated, and nothing about who can publish or subscribe moves.
The genuine security angle is a quiet improvement: the S3-pointer pattern requires every consumer to hold read access to a bucket that holds message payloads. That is a broader grant than “may receive this message”, and it is durable — a consumer removed from a topic keeps its bucket permission until somebody remembers. Carrying the payload in the message removes that second grant entirely.
In the other direction, larger payloads mean more data in the message body, where SNS data protection policies and any downstream logging will see it. A 1 MiB message with personal data in it is a bigger surface than a pointer was. Worth checking that subscription filter policies and data protection policies still do what you expect at the new size — and noting that filter policies are themselves quota'd at 200 per topic and 10,000 per account.
Cost considerations
The announcement makes no pricing statement, which is itself worth flagging rather than assuming. SNS has historically billed in 64 KB chunks for request accounting, so a 1 MiB message is not obviously priced the same as a 256 KiB one. The announcement does not say, and I am not going to guess at a number — check the pricing page before modelling a migration at volume.
The offsetting saving is real and easy to miss: the S3-pointer pattern costs a PUT, a GET per consumer, and storage until expiry. Fan out one message to six consumers and that is one PUT and six GETs that disappear. For a high-volume topic that is a meaningful line item, and it comes with the operational simplification rather than instead of it.
Operational considerations
Setting the attribute is a one-way door for your subscribers. The moment a topic goes above 256 KiB it supports three protocols. If anything is subscribed over HTTP/S or email today, find it before changing the attribute, not after.
The 100-subscription cap is the one that surprises later. A topic well under the limit today can grow past it, and the failure will arrive as a subscribe call that does not work, in whatever pipeline creates subscriptions automatically. Worth an alarm on subscription count for any topic running in this mode.
The Extended Client Library still exists and still goes further. AWS's documented answer for oversized messages remains: “To publish messages larger than 256 KiB, you can check the Amazon SNS Extended Client Libraries… The maximum payload size is 2 GB.” Native 1 MiB is simpler; the library path is two thousand times larger and keeps full fan-out. They solve different problems and the new feature does not retire the old one.
Check the header budget separately. Message attributes are not free of limits — the maximum header size is 16,384 bytes (16 KiB), unchanged by this. A design that moves metadata into attributes to keep the body small is working against a different ceiling.
Tradeoffs
Payload size against fan-out breadth. Stated plainly by the announcement, and the right way to think about it: a topic is now either a broadcast hub or a large-message pipe. Most estates will want both, on different topics.
Native simplicity against the 2 GB ceiling. The Extended Client Library is more moving parts and vastly more headroom. Choosing native 1 MiB is choosing simplicity with a hard wall at 1 MiB — fine if your payloads are bounded, painful if they are user-supplied.
An attribute that reads as a tuning knob and behaves as an architecture choice. MaximumMessageSize sounds like something you adjust. It changes what can subscribe. That mismatch between name and consequence is the thing most likely to catch a team out.
Implementation guidance
Inventory subscriptions before touching the attribute. List subscriptions by protocol on any candidate topic. Anything that is not SQS, Firehose or Lambda has to move or stay behind.
Split the topic rather than converting it. If a topic serves both service consumers and HTTP or email subscribers, the clean answer is a second topic for the large-payload path. Converting in place forces every subscriber into the restricted set.
Decide by payload distribution, not by maximum. If the 99th percentile fits in 1 MiB but the maximum does not, native payloads will fail on the tail. Either keep the Extended Client Library path for overflow or cap at the producer, deliberately.
Alarm on subscription count. 100 is low enough that an automated subscriber-creation process can reach it. That failure is far easier to diagnose from an alarm than from a subscribe call failing in someone else's pipeline.
Best practices
Name the topic for its mode. A topic restricted to three protocols and 100 subscriptions is a different contract from a broadcast topic. Encode that in the name so the next person does not try to attach an email subscription to it.
Keep payloads small where you can. A higher ceiling is not an invitation. Large messages cost more to move, more to log, and more to inspect, and they make filter policies and data protection policies work harder.
Record why the attribute is set. It is one number in a topic configuration with consequences nobody can infer from it. One line of comment in the infrastructure code is what stops it being raised or lowered by someone tidying up.
Who should adopt this
Available now in all Regions where SNS runs, opt-in per topic, nothing changes unless you set the attribute.
Adopt it if you have service-to-service topics fanning out to SQS, Lambda or Firehose with payloads that outgrew 256 KiB, and you are currently paying the S3-pointer tax to work around it. Skip it if your topic serves HTTP, email, SMS or mobile push subscribers, if you need more than 100 subscriptions, or if your payloads can exceed 1 MiB — in which case the Extended Client Library remains the right answer.
Key takeaways
- SNS payloads can now reach 1 MiB, a 4x increase from 256 KiB, on Standard and FIFO topics, in every SNS Region.
- It is opt-in per topic via the new
MaximumMessageSizeattribute. - Above 256 KiB the topic supports only SQS, Data Firehose and Lambda subscriptions — no HTTP/S, email, SMS or mobile push.
- And no more than 100 total subscriptions, against a standard-topic default of 12,500,000.
- Firehose binds earlier still, at 5 subscriptions per topic per subscription owner.
- The Extended Client Libraries remain the path for larger messages, up to 2 GB, with fan-out intact.
- No pricing statement was made in the announcement. Check the pricing page before modelling at volume.
Comments