---
title: SNS messages can be 1 MiB now. The default is still 256 KiB.
description: On 18 Sep 2026 SNS raised the payload ceiling to 1 MiB, four times 256 KiB, but only after you set MaximumMessageSize. A full 1 MiB Standard publish is 16 requests. At 50 cents per million requests, one million of those publishes cost 8 dollars before the free tier.
url: https://www.factualminds.com/blog/amazon-sns-1-mib-payloads-2026/
datePublished: 2026-09-23T00:00:00.000Z
dateModified: 2026-09-23T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: aws-sns, aws-sqs, aws-lambda, messaging
---

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

> On 18 Sep 2026 SNS raised the payload ceiling to 1 MiB, four times 256 KiB, but only after you set MaximumMessageSize. A full 1 MiB Standard publish is 16 requests. At 50 cents per million requests, one million of those publishes cost 8 dollars before the free tier.

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](https://docs.aws.amazon.com/general/latest/gr/sns.html) 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](https://docs.aws.amazon.com/sns/latest/dg/large-message-payloads.html) and the [pricing page](https://aws.amazon.com/sns/pricing/) 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](/blog/amazon-sns-pricing-publishes-fanout-protocols/). This post is only the payload-size decision.

> **Reproduce this** — Open [`payload-cost-worksheet.csv`](/examples/architecture-blog-2026/sns-1mib/payload-cost-worksheet.csv) and [`set-maximum-message-size.md`](/examples/architecture-blog-2026/sns-1mib/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.

```bash
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](/blog/amazon-sqs-pricing-64kb-rule-fifo-vs-standard/) 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.

| Payload | Standard billable requests | USD per 1M publishes at 50 cents per million requests |
| --- | --- | --- |
| 64 KiB | 1 | 50 cents |
| 256 KiB | 4 | 2 dollars |
| 1 MiB | 16 | 8 dollars |

---

## Where delivery still fails

| Subscriber | What AWS says |
| --- | --- |
| Lambda | Async invocations already accept 1 MiB. No extra Lambda setting. |
| SQS | Topic limit wins. The queue's own `MaximumMessageSize` does not apply to SNS deliveries. |
| Data Firehose | Record limit is **1,000 KiB** (1,024,000 bytes), **including** SNS metadata such as message id and timestamp. A topic set to 1,048,576 bytes can accept a publish Firehose then 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](/blog/amazon-eventbridge-pricing-events-pipes-schema-archive/) 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.

## FAQ

### Does every SNS topic accept 1 MiB messages now?
No. Existing and new topics stay at 262144 bytes until you set MaximumMessageSize. The allowed range is 1024 to 1048576 bytes. If GetTopicAttributes omits the attribute, the topic is still at the 256 KiB default.

### When should I not raise MaximumMessageSize?
Do not raise it above 256 KiB if the topic has an HTTP, HTTPS, email, email-json, SMS, or mobile push subscription. Those endpoint types are rejected once the attribute is above 256 KiB. Do not raise it if the topic has more than 100 subscriptions. Do not set 1048576 on a topic with a Data Firehose subscription. Firehose records max out at 1000 KiB including SNS metadata, so a maxed SNS body can fail delivery.

### Why did my 1 MiB publish cost more than one request?
Standard topics bill each 64 KB chunk as one request. The SNS pricing page, fetched 23 Sep 2026, uses a 1 MiB payload as the example and counts it as 16 requests. At the FAQ rate of 50 cents per million requests, one million full-size publishes are 8 dollars in request charges before the one million request free tier. The same chunk rule applies to notification deliveries except SMS, so one 1 MiB HTTP delivery counts as 16 deliveries.

### How is this different from the SNS Extended Client and from EventBridge?
The Extended Client still stores the body in S3 and publishes a pointer. It is how you send above 1 MiB, up to 2 GB, and it still works when you need email or HTTP subscribers. EventBridge remains the bus when you need more endpoint types than SQS, Lambda, and Firehose. A 1 MiB SNS topic is for those three subscribers only, with at most 100 of them.

### Does the SQS queue MaximumMessageSize block a large SNS delivery?
AWS says no. For messages SNS delivers, the topic MaximumMessageSize is the effective cap. The queue attribute does not apply to those messages. SQS request billing is separate. Our SQS pricing post meters Standard requests in 64 KB chunks at 40 cents per million. Apply that rule to the delivered body, and re-check the SQS pricing page if the queue is FIFO.

### Which AWS page is wrong, the quotas page or the announcement?
On 23 Sep 2026 the service quotas page still said the maximum message size is 262144 bytes and pointed at the Extended Client for anything larger. The 18 Sep 2026 what's-new post, the large-message developer guide, and the pricing page's 16-request example all describe 1 MiB after you set the attribute. Trust the developer guide for behavior. Treat the quotas page as stale until it mentions 1048576.

---

*Source: https://www.factualminds.com/blog/amazon-sns-1-mib-payloads-2026/*