SQS "Message Must Be Shorter Than 262144 Bytes": The Fix

Amazon SQS "Message must be shorter than 262144 bytes" means the queue or an upstream publisher is enforcing the older 256 KiB limit. SQS itself now permits 1,048,576 bytes (1 MiB) per message: check the queue's MaximumMessageSize, then raise it in the console or with SetQueueAttributes. The counterintuitive catch is that increasing SQS alone may not help: an SNS topic upstream can still default to 262,144 bytes, and an SQS batch has a separate combined-size ceiling.

Jake runs a neighborhood phone shop and sends its repair orders into an SQS queue. His invoice generator has worked for months, until an unusually detailed order hits Message must be shorter than 262144 bytes. He wonders why the service is still talking about 256 KiB when a newer maximum exists.

Jake: "Why is SQS still talking about 256 KiB when the limit is 1 MiB now?"

Ethan: "First find which door is saying no. Your queue, your SNS topic, and your batch request can each have their own size rule."

Find out what the 262144-byte error really means

You see a rejected send, usually while your application tries to enqueue JSON, text, or serialized data. The message quotes 262144 because that is the 256 KiB boundary, not because your application is necessarily broken. An older queue configuration or another service in the publishing path may be enforcing that value.

SQS messages have an absolute current maximum of 1,048,576 bytes. That change became available on August 4, 2025 for standard and FIFO queues. The queue attribute can be set anywhere from 1,024 through 1,048,576 bytes. A configuration set lower than the service maximum still wins for that queue.

A rejected send does not put half a message on the queue. You should preserve the event on the producer side and retry only after fixing the actual constraint. Repeatedly sending the identical oversized body to the unchanged destination is not useful recovery.

Ethan: "A maximum supported by the service is a ceiling, not proof that every queue is already using it."

When Jake has dozens of old queues, that difference becomes the practical starting point.

The exact error text can vary by API, SDK, or intermediary. A failure mentioning 262,144 bytes might originate from an SNS publish, a validation library, or a queue configured to that number. Identify the failing request operation and resource ARN or URL before you change the queue.

If you send a payload through SNS into SQS, inspect the topic first. If you call SendMessage directly, start with the target queue. If the failure is in SendMessageBatch, also inspect the combined request size.

Use the current message-size limits, not the old 256 KiB table

When your error references a specific number, you need the current ceilings in one place. The figures below apply to the payload mechanisms shown; they are not interchangeable, and you should account for attributes, metadata, or envelope overhead where the integration adds them.

The SQS and SNS size expansions mean an old blog post saying SQS cannot exceed 256 KiB is obsolete. The right question now is which attribute and which intermediary you are using. SNS also has special subscription restrictions when a topic maximum exceeds 256 KiB.

The SQS batch maximum applies to the aggregate message bodies as well as each entry individually. The SQS request has a maximum of ten entries; it is not permission to send ten messages of 1 MiB each in one call.

If your system fans out to several destinations, design against the most restrictive route. A message accepted by SQS does not prove an EventBridge event, SNS topic, or external API will accept the same representation.

Read the exact queue setting before changing anything

If you inherited a queue or deployed it years ago, inspect its actual attributes.

Jake: "I have the queue name from the application config."

Ethan: "Give me the queue URL and the Region first. Names alone are ambiguous across AWS accounts."

aws sts get-caller-identity
aws sqs get-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/repair-orders \
  --attribute-names MaximumMessageSize QueueArn \
  --region us-east-1

The output includes MaximumMessageSize as a string. If it is 262144, your queue allows 256 KiB. If it is 1048576, that queue already allows the current SQS maximum and you should inspect the producer, upstream publisher, or actual message-body byte length.

In the console, open Amazon SQS, select Queues, and choose the queue. Its configuration and queue details show the relevant attribute. Confirm you are viewing the queue used by the application, not a similarly named development queue.

For an encrypted queue or one owned by another account, permissions can affect whether you can retrieve attributes. That access failure is separate from the message-size error. An SDK exception alone does not tell you the configured value.

A queue URL contains the account and Region context. That makes it a better diagnostic anchor than guessing from a Lambda environment variable named QUEUE_NAME. Verify the application points to this URL in the environment that failed.

Raise Maximum message size in the SQS console

If the queue currently says 256 KiB and the producer needs more, the direct console fix is a queue-configuration edit. You do not need to delete and recreate the queue just to increase this attribute.

1. Open the Amazon SQS console in the Region containing the failing queue.
2. Select Queues, then select the exact queue URL used by your application.
3. Choose Edit and find Maximum message size in the Configuration section.
4. Set the value to 1 MiB (1,048,576 bytes) and choose Save.
5. Reopen the queue details and confirm the saved value; allow normal attribute-propagation time.
6. Resend one representative payload and check that the consumer can process it correctly.

Most SQS attribute changes can take up to 60 seconds to propagate. That matters if your first immediate retry still sees the former limit. Check the setting again before assuming the console save failed.

Changing the maximum affects what producers may send going forward. It does not increase message retention, repair a malformed JSON body, remove permissions barriers, or alter an SNS topic upstream. Those are independent concerns.

Ethan: "Raise it once, then prove the receiver handles the bigger envelope. The send succeeding is only half the job."

This is especially relevant if downstream code loads the entire JSON into memory or assumes a much smaller schema.

Update an existing queue with one SetQueueAttributes call

If you manage infrastructure in scripts, use set-queue-attributes with the exact attribute name and byte count. The setting lives on the queue, not on the IAM role, consumer function, or SDK client.

aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/repair-orders \
  --attributes MaximumMessageSize=1048576 \
  --region us-east-1

aws sqs get-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/repair-orders \
  --attribute-names MaximumMessageSize \
  --region us-east-1

The expected attribute value in the second response is 1048576. Replace the example URL with the queue in your account. The caller needs permission to modify that queue; a permission error is not a reason to change the payload.

You can choose a smaller value if it fits an intentional application contract. For example, an internal system might keep a 256 KiB ceiling so producers are forced to store large files elsewhere. But if your goal is to allow the present SQS maximum, use 1,048,576.

Infrastructure as code should define the intended size too. If a Terraform or CloudFormation deployment continues to declare 262,144, a later update might restore the older configuration. Review ownership of the resource before making a one-off console change.

There is no supported attribute value above 1,048,576. A request to configure 2 MiB fails validation. That is the point where you should use the S3 reference pattern instead of retrying an impossible attribute change.

Understand why old queues can retain a 256 KiB setting

You might create a new queue today and see 1 MiB while an older production queue still rejects 300 KiB. This happens because a queue may retain the MaximumMessageSize setting assigned when it was created or later updated.

The current documented default for SQS is 1 MiB. That does not mean AWS must rewrite every resource where the attribute was previously set to 262,144. A historical default or explicit infrastructure configuration can leave an existing queue on the smaller value.

Jake: "Should I migrate all my queues to fresh names?"

Ethan: "Keep the working queue and change the one attribute. Recreating queues means new URLs, permissions, subscriptions, and consumer configuration to manage."

An old SDK may also validate against an older client-side assumption, even when the service permits larger messages. Inspect your dependency version if the queue returns 1,048,576 yet the failure occurs locally before an AWS request is sent.

The difference between service support and queue configuration is visible with get-queue-attributes. That command provides a much stronger clue than looking at the age of the AWS account.

Count UTF-8 bytes instead of characters

If you built a JSON string and counted characters, your estimate may be wrong. SQS limits are in bytes. A multibyte character can consume more than one byte in UTF-8, and JSON serialization choices affect the actual transmitted body.

# Python: measure the exact serialized body
import json

message = {"order": "1234", "note": "Customer note"}
body = json.dumps(message, ensure_ascii=False)
size = len(body.encode("utf-8"))
print(f"Body size: {size} bytes")

// Node.js: measure the serialized body
const message = { order: "1234", note: "Customer note" };
const body = JSON.stringify(message);
console.log(Buffer.byteLength(body, "utf8"), "bytes");

Count the body you actually pass to the API, not the original object before JSON conversion. Escaping, added wrappers, and base64 encoding can enlarge the payload. Base64 is particularly unhelpful if you are trying to squeeze an already large binary file into a message.

Log the byte count and a correlation ID, not the complete customer record. That preserves enough diagnostic detail while reducing the risk of exposing order notes, addresses, or secrets in your logs.

Keep some margin under the selected maximum. Large bodies close to the ceiling leave little room for changes to your envelope or producer contract. If messages routinely approach 1 MiB, the S3 reference architecture may be easier to evolve.

Decode SendMessageBatch failures and the combined 1 MiB ceiling

Your producer might send ten small-looking messages at once. Each is valid individually, yet the batch is rejected because the sum of their bodies exceeds the batch maximum.

SQS SendMessageBatch accepts at most ten entries and a combined message-body size of at most 1,048,576 bytes. The maximum individual message body is also 1,048,576 bytes, so the two checks are different even though their numeric ceiling is the same.

For a worked example, suppose you send four messages of 300,000 bytes each. Every message is below 1 MiB, but the total is 1,200,000 bytes. That batch exceeds 1,048,576 bytes. Splitting it into two batches of two 300,000-byte entries respects the aggregate limit.

Use a size-aware batching loop, not simply messages.slice(0, 10). The loop should start a new batch whenever the next message would make the total too large, or when the entry count reaches ten.

The API reports individual entry successes and failures. An HTTP 200 response for a batch does not imply every entry succeeded. Inspect the Failed collection and retry failed entries according to their error details.

For FIFO queues, retry behavior also requires attention to message group IDs and deduplication. A blind resend of all entries can introduce duplicate logical work when the first batch partially succeeded.

Check SNS MaximumMessageSize before blaming SQS

If the pipeline is SNS -> SQS, the first rejection may happen at SNS. By default, SNS topics still allow 262,144 bytes, even though larger values can now be configured under specific conditions.

The SNS topic attribute is also named MaximumMessageSize. You can raise it up to 1,048,576 bytes, but topics above 256 KiB must have at most 100 subscriptions and may use only Amazon SQS, Amazon Data Firehose, and AWS Lambda subscription types.

aws sns get-topic-attributes \
  --topic-arn arn:aws:sns:us-east-1:123456789012:repair-events \
  --region us-east-1 \
  --query 'Attributes.MaximumMessageSize'

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

Review topic subscribers before running the update. If a topic includes email, SMS, HTTP/S, or other subscription types outside the supported set for large messages, this adjustment is not an appropriate one-line fix. You may need a separate topic or an S3 reference message.

SNS validates the combined body and message-attribute size against the configured topic maximum. That makes its accounting different from blindly measuring only the text body in an SQS batch. Build in headroom for message attributes and filtering metadata.

Jake: "The queue is already at 1 MiB, but the topic is still at 256 KiB."

Ethan: "Then the message never even got to your queue. Upgrade the first gate that rejected it."

Keep EventBridge payloads under their own request limit

If your architecture publishes an event through EventBridge before it reaches SQS, check PutEvents limits independently. EventBridge limits the total size of entries in one request to less than 1 MiB. It is not a ten-times-1-MiB arrangement.

An EventBridge entry contains more than its Detail JSON: source, detail type, resources, and an optional timestamp contribute to its calculated size. An SQS message that fits just under 1 MiB can become too large once wrapped as an EventBridge entry.

If your business workflow needs large attachments or very long document bodies, use an EventBridge detail object that carries an ID, type, version, bucket, and key. Consumers can retrieve the authoritative payload after validating permissions.

This also makes your event schema more stable. A small event such as "invoice 1234 is ready" can remain compact even if the invoice PDF later grows by many megabytes.

If the queue is a rule target, inspect whether input transformation changes the event size or format. A producer getting a PutEvents error needs an EventBridge fix, not an SQS attribute change.

Fit SQS messages into Lambda invocation payloads

When Lambda polls an SQS queue, it bundles records into a single invocation. The SQS-to-Lambda mapping supports the larger SQS payloads, but the total invocation event still has a synchronous invocation payload ceiling of 6 MB, including per-record metadata.

A standard-queue mapping may be configured for many records, yet Lambda delivers fewer when the total event payload approaches its allowed size. This is expected behavior, not evidence that messages disappeared.

For an illustrative example, five records with 900,000-byte bodies account for 4,500,000 bytes before metadata. Six such bodies account for 5,400,000 bytes before metadata. A small amount of envelope data is added for each record, so leave room rather than calculating capacity using only message bodies.

Lambda also has a 1 MB asynchronous invocation payload limit. That limit does not mean SQS polling into Lambda is capped at one 1 MB total batch: the event source mapping is governed by the synchronous 6 MB request quota.

If your handler creates a second asynchronous Lambda invocation using the same large message, that outgoing invocation faces its own 1 MB limit. Every handoff deserves an independent size check.

For a consumer that performs heavy decompression, image processing, or parsing, test memory and timeout behavior with realistic large messages. Increasing what SQS accepts does not automatically increase what the application can process economically.

Store large payloads in S3 and send an SQS pointer

If a message truly exceeds the 1 MiB SQS ceiling, send a reference rather than the complete object. S3 stores the large payload; SQS carries only the metadata needed to locate it safely.

The Amazon SQS Extended Client Libraries for Java and Python support this pattern and can handle payloads up to 2 GiB through S3-backed storage. They place data in S3 and send a smaller SQS message referring to the stored object. Their send and receive integration depends on using a compatible library at both ends.

1. Upload the complete payload to a private S3 bucket, using a unique object key and appropriate encryption.
2. Publish a small SQS message containing the bucket, object key, schema version, correlation ID, and any integrity information you need.
3. Have the consumer retrieve the object after confirming authorization and validating the expected schema.
4. Only delete the SQS message after the consumer has completed its intended work.
5. Manage S3 object lifecycle and deletion separately so a retry can still obtain the payload.

If the SQS message is retried, the S3 object must still exist. Deleting the object as soon as the first consumer starts work creates a nasty failure: the second attempt sees a perfectly valid SQS pointer to missing data.

Use IAM policies that allow the producer to put objects and the consumer to get the objects it owns. Scope paths and buckets tightly. Encrypt sensitive payloads and avoid placing public or long-lived signed URLs into message bodies.

The AWS-provided extended libraries are not a transparent feature of the plain SQS console or CLI. Applications using ordinary SDK send/receive operations will see pointer messages unless they implement the agreed retrieval logic or use a compatible extended client.

Use the Python extended client with a compatible consumer

If your application uses boto3 and regularly sends bodies bigger than SQS permits, the Python extended client offers a supported integration. Install the extended-client package, configure the S3 bucket, and confirm the consumer uses the same convention for fetching stored payloads.

# Install the supported extension and boto3 in your environment
pip install boto3 amazon-sqs-extended-client

Package names and library settings deserve version-specific review when you deploy. The extended client exposes configuration for the supporting bucket and can store all messages through S3 or only those exceeding its configured threshold. The official example uses large_payload_support to identify the bucket.

If you choose a threshold around 256 KiB for compatibility with older consumers, remember that the standard SQS maximum is now 1 MiB. The threshold in a client library is a behavior switch, not necessarily the maximum the queue supports.

Your consumer must know whether a message is a literal business payload or a reference envelope. Introducing the extended library on the producer while leaving a plain consumer in place can break the schema contract, even though SQS happily accepts the pointer.

Ethan: "The queue does not fetch the document for you. Your application still owns that retrieval and cleanup."

This is why integration tests must cover both a small ordinary message and a larger S3-backed message.

Use the Java extended client for large SQS documents

For a Java publisher and consumer, the Amazon SQS Extended Client Library works with the AWS SDK and S3 to offload large message bodies. It can store messages in S3, send references through SQS, and retrieve them through the extended client.

The Java guidance includes examples for SDK for Java 2.x. Select a compatible published version and verify its dependency tree, particularly if your application already uses a dependency-management framework such as Maven or Gradle.

Provision an S3 bucket separately for predictable lifecycle management in production. A demo that creates and destroys a bucket in the same run is useful for learning but is not a durable production design when multiple consumers and retries share data.

Use lifecycle rules only after considering queue retention, redrive policies, dead-letter queues, and manual replay windows. A payload expired from S3 before a dead-letter recovery attempt makes the pointer message impossible to process.

If your consumers span Java and Python, define a shared reference schema and serialization contract deliberately. The presence of two extended libraries does not by itself guarantee compatibility across every library option and version.

Decide when splitting or compressing is better than S3

You may be tempted to compress each message or split one logical operation across many SQS messages. Both can be valid designs, but neither is a universal one-line fix for the byte ceiling.

Compression reduces wire size only when your data is compressible, and it requires consumer-side decompression plus an agreed encoding field. Already compressed images or PDFs often gain little. Sending base64-encoded binary data commonly increases the body size instead.

Splitting into chunks makes sense when each chunk is useful independently or your application already has a durable reassembly protocol. Otherwise you must account for missing chunks, retries, duplicates, ordering, and partial failures.

An S3 pointer is usually easier for an indivisible 20 MB PDF or a large export. A chunked messaging design may suit streaming analytics, but you should choose it for workflow reasons rather than because a single message rejected your upload.

Jake: "Could I send 50 separate pieces of one receipt?"

Ethan: "You can, but now you own a fifty-piece assembly problem. Put the receipt in S3 and send its key."

Protect consumers when increasing accepted message size

A bigger queue limit can expose latent assumptions in your consumers. A worker may read the whole message into a fixed buffer, parse a document into memory, or copy the body into a service with a lower API limit.

Before turning on larger payloads for every producer, send a representative message slightly larger than the previous 256 KiB boundary through a test queue and consumer. Record the application behavior at each downstream hop.

Confirm your dead-letter queue and replay tools can handle the same bodies. SQS dead-letter queues do not solve large payload processing errors; they preserve messages for a separate investigation or later attempt.

Consider application-level schema limits. A 700 KiB JSON message may fit SQS but still contain an unexpectedly huge text field or deeply nested object. Treat its size and structure as business input requiring validation.

Version the message contract if your producer begins sending new large fields or pointer envelopes. Consumers deployed later should still understand how to handle messages placed on the queue earlier.

Check permissions when the attribute update is rejected

If the CLI cannot change the queue size, determine whether the problem is the value or the caller identity. AccessDenied during SetQueueAttributes points to authorization, not a mysterious 256 KiB service quota.

The permission boundary may include the identity policy, the queue policy, and organization guardrails. A cross-account queue requires care because an administrator in the producer account may not own the queue configuration.

Run aws sts get-caller-identity and compare the target URL and resource owner with your intended AWS account. Read the full error rather than trying to fix IAM by changing unrelated SQS values.

If your queue is managed by an infrastructure repository, coordinate the change there. An authorized console change can be reverted by a scheduled infrastructure deployment that still declares 262,144 bytes.

A safe change request records the current value, proposed value, owning team, and consumer compatibility check. It is a small configuration change, but its downstream effects merit the same care as other production input-contract changes.

Tell apart a queue ceiling, publisher ceiling, and batch error

If your 300 KiB message still fails after changing SQS, the exact failing AWS operation becomes your best clue. Use error metadata, AWS SDK operation names, and the affected resource to narrow the failure.

Start from the first failing operation, not the last resource in the diagram. If SNS rejected a message, no SQS queue attribute update will make that original SNS request succeed.

If direct sends work but a production workflow fails, compare the payload the workflow actually serializes. Middleware often adds trace metadata, customer context, and envelope fields after your initial size calculation.

Run one representative send to the exact destination in a nonproduction environment. Keep a copy of the body in your test fixtures, removing sensitive values. That gives you a repeatable regression check for future deployments.

Work through Jake’s 300 KiB repair-order failure

Jake prepares a 307,200-byte serialized order. It is bigger than the old 262,144-byte limit but smaller than the current 1,048,576-byte SQS maximum. His producer publishes through SNS to SQS, so there are at least two size checks.

The queue attributes show 1,048,576 bytes, but the SNS topic says 262,144. Changing the SQS queue again does nothing. The next action is to review the topic subscribers and whether the SNS large-message configuration is allowed for them.

Suppose all subscriptions are SQS, Lambda, or Firehose and the topic meets the subscription-count constraint. Jake can raise the topic attribute, then publish an event with the same byte count and inspect delivery to the consumer.

If that topic also fans out to unsupported subscription types, splitting notification channels or using an S3 reference is safer than trying to force a forbidden topic attribute value.

After a successful publish, Jake validates that the order worker receives the complete payload and records completion. If it generates a second EventBridge event, the workflow should send only the compact completion metadata, not blindly forward the whole order.

This example shows why every successful change deserves an end-to-end check. The right goal is not simply making the error vanish; it is reliably getting the repair instruction to the worker.

Plan for S3 cost and duplicate-work risks

The S3 extended-client pattern uses more than SQS. It adds object storage, S3 requests, and potentially data-transfer costs according to the workload and Region. It may also add latency for upload and retrieval.

A failed consumer retry can read the same S3 object again. Your storage design should retain the object long enough for retries without leaving sensitive objects forever. Decide who owns deletion, lifecycle policy, and dead-letter recovery.

Delete the object only after the queue message has been processed successfully. A partial processing failure followed by a retry requires the pointer to remain usable. Your application may also need idempotency based on a stable message ID.

If your messages rarely exceed 256 KiB and always stay under 1 MiB, raising the existing queue attribute can be simpler than introducing S3. If your payloads include photos, PDFs, or exports measured in megabytes, an offload design is usually easier to maintain.

The size limit is not itself a price quote. AWS request billing and payload-based request units depend on service pricing. Check current pricing for your Region rather than assuming every larger message costs the same as a tiny one.

Collect enough evidence before contacting AWS Support

If every relevant attribute is set correctly and the AWS API still reports an unexpected size constraint, gather a minimal reproduction. Include the exact operation, Region, account, queue URL or topic ARN, configured attribute, sanitized payload byte count, and the error returned.

Separate an SDK-side validation exception from an AWS response. The difference tells support whether the request even reached the service. Include your language, SDK version, relevant middleware, and whether the direct AWS CLI reproduces the failure.

If the sender uses batching, record both the individual sizes and the combined total. A screenshot of one small message is not evidence that the entire batch was under the maximum.

For integrations, map the full route: API or application, SNS topic if any, EventBridge if any, queue URL, Lambda mapping, and downstream output. This lets you identify the service that rejected the message rather than opening a case against whichever dashboard you happened to inspect first.

Ethan: "A useful support ticket has one rejected request and a precise boundary. It does not start with SQS is broken."

Prevent the old size limit from returning in CI and IaC

After your incident is resolved, write the intended queue size in infrastructure as code and make it visible in automated checks. That reduces the chance that a redeployment quietly restores 262,144 bytes.

Add a producer-side check for the serialized UTF-8 body, plus an explicit path for payloads that exceed 1 MiB. This can make the error actionable before a message hits SQS.

Include a regression test using a message larger than 262,144 bytes but below 1 MiB. If the queue, SNS topic, or SDK regresses to an older setting, the test catches the change before a customer's unusually long order does.

For batch sending, test a case where every entry is valid individually but the combined total exceeds 1 MiB. Your batching code should split the request without losing entries and should inspect per-entry failures.

For the S3 path, test missing objects, permission errors, duplicate delivery, expired lifecycle objects, and dead-letter replay. These are the cases most likely to turn a seemingly successful offload design into an operational headache.

Test the exact byte boundary without risking production orders

If your team is nervous about raising the queue maximum, use a dedicated test queue and a deterministic sample body. You can choose a string whose UTF-8 length is known, rather than copying a customer record from production. A minimal body lets you separate size handling from your JSON schema, IAM policy, and application validation. Your test should use the same queue configuration as the intended production destination, but should not send synthetic messages into a live order-processing workflow.

Build three inputs: one a few bytes below 262,144, one modestly above that older boundary, and one below 1,048,576. The middle case is particularly informative. If the first succeeds and the second fails on a queue whose attribute reads 262144, you have a consistent queue configuration explanation. If the middle case fails despite an attribute of 1048576, capture the SDK exception and the exact operation before making further changes.

When you use the CLI, be aware of shell quoting and the distinction between message text and file contents. A body read from a UTF-8 file is less error-prone for large test fixtures than trying to paste hundreds of thousands of characters into a shell command. Check whether the client treats the argument as a literal body, a file reference, or a special AWS CLI blob form for that command. Your test must send the bytes you think it sends.

It is worth testing the receiver as well as the sender. A successful SendMessage result proves acceptance by the queue, but it does not establish that your Lambda, ECS task, or custom worker can parse the bigger body. For each test, record whether the queue accepted the message, whether the worker received it, and whether the worker completed the expected action. Those three results reveal different failures.

Jake: "Should I run the biggest possible test against the shop's real order queue?"

Ethan: "Use a separate queue and a fake repair order. Your customers did not sign up to become a load test."

Once your staging route behaves correctly, you can deploy the attribute change to production during an ordinary change window and observe the initial larger messages carefully.

Find the hidden 256 KiB limit in multi-account pipelines

You may own the application but not the destination queue. Some organizations place SNS topics in a shared integration account and queues in workload accounts. In that design, the producer, publisher, and consumer can have different owners. An engineer may inspect a development queue in one account while the production SDK sends to a topic in another. The error still quotes 262144 bytes, but the resource requiring the change is not obvious from the screen currently open.

Start with the producer's effective credentials and the exact resource ARN or URL supplied at runtime. If you use environment variables, confirm which deployment version loaded them. If your workload uses an assumed role, use the caller identity in the appropriate execution environment rather than assuming your laptop's profile represents production. Then inspect the first managed service that receives the message and follow each hop until you reach the queue.

When the SNS topic belongs to another account, your application team may be allowed to publish but not to inspect or change MaximumMessageSize. In that case, give the topic owner the failing request ID or timestamp, message byte count, and the subscriptions that need to support larger messages. Your request should explain why an increase is safe for every destination. Asking only for "more SQS capacity" can send the ticket to the wrong team.

If you cannot modify an upstream service because other subscribers rely on its smaller contract, using a compact S3 pointer can preserve interoperability. A small pointer message passes through narrow integrations while the larger payload remains available to authorized consumers. The tradeoff is that each consumer requiring the full payload needs S3 retrieval permission and robust missing-object handling. Make that access part of the contract, not an undocumented assumption.

For incident review, save a small topology description with the account, Region, resource and owner at each stage. You will use it again when the next developer reports that a message fits in the queue console but fails from the actual application. The most useful diagram is often just producer, topic, event bus, queue and worker with the first failing arrow highlighted.

Separate the SQS maximum number of messages from maximum message size

If you search for sqs max number of messages, you may find an answer about ten messages and mistake it for a 10-message queue capacity. The ten-message number belongs to a single SendMessageBatch or ReceiveMessage request, not the total messages that a standard queue can hold. Queue depth, in-flight-message behavior, per-request count and message byte size are separate questions.

You can send one message through SendMessage or up to ten through SendMessageBatch. For batch sends, the combined message body lengths must fit within 1,048,576 bytes; ten messages each near that ceiling will fail, even though each is individually legal. For receiving, MaxNumberOfMessages controls how many messages may be returned by one ReceiveMessage call. It cannot be used to raise your message-size limit.

When readers search sqs send_message size, the most useful first check is the UTF-8 byte length of the exact serialized MessageBody, not the length of the input object or the count of characters. JSON serialization adds punctuation and sometimes escaping. If your producer builds a Unicode string, two visually similar payloads can have different byte lengths. Measure after serialization, immediately before sending.

import json

payload = {"orderId": "A123", "description": "Repair ready"}
body = json.dumps(payload, ensure_ascii=False)
size_bytes = len(body.encode("utf-8"))
print(f"SQS MessageBody: {size_bytes} bytes")
if size_bytes > 1_048_576:
    raise ValueError("Offload the payload to S3 before sending")

This check is useful for a sqs message too long exception, but it cannot tell you which service actually rejected a multi-service workflow. If the producer publishes to SNS or EventBridge first, inspect that publisher's limit independently. If SQS itself reports 262,144 bytes, retrieve the target queue's MaximumMessageSize before changing application logic.

Jake: "Can I just split one 1.5 MiB object into ten messages?"

Ethan: "Only if your consumer knows how to put the pieces back together. For one large business object, an S3 pointer is usually easier to operate."

Chunking introduces ordering, retries, deduplication and cleanup work; the extended-client pattern gives you an alternative when one logical payload must remain one logical item.

Frequently asked questions about the SQS 262144-byte error

If you searched for an exact error string, these answers help match it to the right service and size check. They are short by design; the procedures above provide the details when the first fix does not stick.

Why does SQS say message must be shorter than 262144 bytes?

Your queue may still be configured for 256 KiB, or an upstream publisher may enforce that limit. Inspect the specific failing operation and the resource MaximumMessageSize before changing it.

What is the current Amazon SQS maximum message size?

Amazon SQS standard and FIFO queues support up to 1,048,576 bytes, or 1 MiB, for one message. Individual queue MaximumMessageSize settings may be lower.

How do I increase SQS MaximumMessageSize in the console?

Open Amazon SQS, choose Queues, select the queue, choose Edit, and set Maximum message size to 1 MiB in Configuration. Save and confirm the queue attribute.

How do I change the SQS message size using AWS CLI?

Use aws sqs set-queue-attributes with the queue URL and --attributes MaximumMessageSize=1048576, then read the attribute using get-queue-attributes.

Why does my old SQS queue still show 262144?

An existing queue can retain a previously configured 256 KiB attribute. Newer service defaults do not override an explicit or retained queue setting.

Can I increase the SQS message size above 1 MB?

You cannot configure a message body above the 1 MiB SQS ceiling. Store larger payloads in Amazon S3 and send a small SQS reference instead.

Does SQS SendMessageBatch allow ten 1 MiB messages?

No. SendMessageBatch allows at most ten entries and a combined message-body payload of at most 1 MiB across the entire batch.

Why does SNS reject a message that my SQS queue accepts?

SNS topics default to 256 KiB even though eligible topics can be configured up to 1 MiB. Inspect the topic MaximumMessageSize and subscriber restrictions.

How large can a Lambda event from SQS be?

An SQS event source mapping sends records in one synchronous Lambda invocation, with a 6 MB request payload limit that includes SQS and Lambda record metadata.

Does Lambda asynchronous invocation have the same size limit?

No. Asynchronous Lambda invocation requests have a 1 MB payload limit. SQS event source mappings use the synchronous payload quota.

Can EventBridge send a full 1 MiB SQS message?

EventBridge PutEvents limits the combined event entries in one request to less than 1 MiB and counts entry fields beyond the detail body, so the same full-sized payload may not fit.

How do I send an SQS message larger than 1 MiB?

Use an S3-backed pattern: upload the large content to S3, enqueue a pointer containing the bucket and object key, and retrieve the object in the consumer.

What is the Amazon SQS Extended Client Library?

The Java and Python extended clients store large message bodies in Amazon S3 and send SQS references. Compatible consumers retrieve the original object from S3.

Why do UTF-8 messages exceed the SQS byte limit?

UTF-8 characters may use multiple bytes, and serialization can add escapes or wrappers. Measure the final encoded message body, not the visible character count.

How do I fix an SQS message-size error after increasing the queue limit?

Confirm the application uses the updated queue, wait for normal attribute propagation, inspect SDK validation, and check SNS, EventBridge, batching, or consumer constraints upstream and downstream.

Should I use terraform or a console edit to change SQS message size?

For a queue managed through infrastructure as code, update the declared setting in that configuration so later deployments preserve the intended size. A console edit can be a controlled immediate fix.

If your queue is rejecting Jake's oversized order today, start with its actual configuration and the API call that failed. Correct that specific gate, then test the entire route to your consumer. I hope the next large order takes the normal path without any more 262144-byte surprises.

Revision note. Written October 9, 2026, with the 1 MiB SQS limit and the configurable SNS topic limit both in place. Little drops make a flood, says a Tamil proverb, and 262,144 bytes fill faster than anyone expects.