Amazon SNS raises the message payload limit to 1 MiB, four times the old 256 KiB

AWS raised the maximum Amazon SNS message payload to 1 MiB, a four-fold increase on the previous 256 KiB limit, announced on 18 September. The stated reason is that application integration, IoT and generative-AI workloads increasingly exchange larger volumes of data in a single message.

What it means

Every team that hit 256 KiB built the same workaround: write the body to S3, publish a pointer, and deal with the lifecycle of the object afterwards. That pattern is now optional below a megabyte — and optional is the operative word, because the workaround also bought you things the raw limit does not: deduplication by object key, retention independent of the queue, and a body you can inspect after the fact.

Three things to check before celebrating:

• Downstream limits do not move together. A larger SNS payload still has to fit whatever consumes it, and the fan-out targets each have their own ceilings.
• Cost follows bytes. Quadrupling the payload ceiling is an invitation to quadruple the payload, and messaging is billed on what you send.
• A big message is usually a design smell. If the body is approaching a megabyte, the question is often whether the event should be carrying a document at all, or an identifier and a version.

The number that did not change

A larger message is still a message, and the parts of the system that were sized for 256 KiB were sized for a reason. A fan-out that delivers to a thousand subscribers moves a thousand copies of whatever you publish; quadrupling the body quadruples the bytes leaving the service, the bytes arriving at every consumer, and the memory each consumer holds while it parses.

There is also a limit that people forget until it bites: the larger the message, the more of your retry budget a single failed delivery consumes. A queue that redrives a 1 MiB message ten times has moved ten megabytes for one event.

A rule that has aged well: put the smallest thing in the message that lets the consumer do its job — usually an identifier, a type and a version — and let the consumer fetch the rest if it needs it. Then the event is a fact about what happened, not a transport for a document, and the size limit stops being a design constraint you have to route around.