Lambda Provisioned Mode for SQS Reaches 10,000 Event Pollers: What That Actually Buys You

Executive summary

On 3 August 2026, AWS raised the maximum number of event pollers on a Provisioned Mode SQS event source mapping from 2,000 to 10,000. Because each event poller supports up to 10 concurrent invocations, the ceiling on a single event source mapping moves from 20,000 concurrent Lambda invocations to 100,000.

Measured against the standard-mode ceiling of 1,250 concurrent invocations, that is 80 times the capacity from one mapping. The change is generally available in all commercial Regions and requires no migration: if you already run Provisioned Mode, you can raise MaximumPollers today.

Three things deserve more attention than the headline number. Provisioned Mode cannot be combined with the Maximum concurrency setting — enabling one removes the other as a control. The minimum poller count is a floor you pay for continuously, whether messages arrive or not. And each poller issues up to 10 SQS polling calls per second, which are billed as ordinary SQS API requests on top of the poller charge.

What changed

One number: the upper bound of MaximumPollers on an SQS event source mapping configured for Provisioned Mode. It was 2,000. It is now 10,000.

What an event poller actually is

An event poller is a unit of compute that Lambda runs on your behalf, outside your function. It long-polls the queue, assembles batches, applies your filter criteria, and then invokes the function. It is the machinery between the queue and your code, and until Provisioned Mode existed you had no way to size it.

Each event poller provides, whichever limit it reaches first:

• up to 1 MB/second of throughput,
• up to 10 concurrent invocations, or
• up to 10 SQS polling API calls per second.

That "whichever comes first" matters when you size a mapping. A workload of many small messages will exhaust the polling-call limit long before the megabyte; a workload of large payloads will hit 1 MB/s while nowhere near 10 invocations. Sizing on concurrency alone will mislead you in both directions.

The resulting ceilings

MinimumPollers is unchanged: 2 to 200, defaulting to 2.

Why AWS raised the cap

Because customers were sharding queues to get around it, and sharding a queue is a bad thing to do for a reason that has nothing to do with your domain.

If your workload needed 60,000 concurrent invocations and one mapping stopped at 20,000, your options were all unpleasant:

• Split the queue. Three queues, three event source mappings, three sets of metrics, and a producer that now has to make a routing decision it should not care about. Message ordering guarantees, dead-letter handling, and redrive all fragment along the same seams.
• Fan out through an intermediary. Insert SNS or EventBridge purely to spread load across mappings. A component added for a scaling limit rather than a design reason, with its own failure modes and bill.
• Move off Lambda. Run consumers on ECS or EKS, where concurrency is yours to manage. This is a real answer, and for sustained high-throughput streaming it is often the right one — but it is a large migration to buy a number.
• Accept the latency. Let the backlog drain more slowly and hope the business does not notice. The most common answer, and the one that quietly becomes an incident during a peak event.

All four trade architectural clarity for throughput. Raising the cap to 10,000 removes the reason the first two ever existed.

Architecture

The mental model worth holding: standard mode is Lambda guessing how much polling capacity you need; provisioned mode is you telling it. Neither changes what your function does. Both change how quickly work reaches it.

The scale-up rate matters more than the ceiling

Most discussion of this feature fixates on the ceiling. For the majority of workloads, the rate is what you actually feel.

Standard mode begins at five concurrent invocations and adds up to 300 per minute. Reaching its own 1,250 ceiling from cold therefore takes roughly four minutes. Provisioned mode adds up to 1,000 concurrency per minute from a floor you have already paid to keep warm.

If your queue depth arrives as a spike — a batch job releasing at the top of the hour, a retail event opening, an upstream system flushing a backlog — the difference between those two ramps is the entire user-visible latency story. The ceiling only matters if you were going to reach it.

Where the concurrency actually lands

An event source mapping that can drive 100,000 concurrent invocations does not create 100,000 units of function concurrency out of nothing. It still draws on your account concurrency quota, and your function still has to be able to run at that width. A mapping sized far beyond your account quota will throttle, and throttled batches return to the queue and are retried — which increases queue traffic rather than reducing it.

Raising MaximumPollers without checking the account concurrency quota and the function's reserved concurrency is the most likely way to make performance worse while paying more.

Business value

One queue, one mapping, one set of metrics. The clearest architectural win. Queue sharding introduced complexity that had to be understood by everyone who touched the system, forever, to work around a number. That reason is gone.

Latency becomes a configuration value. With a provisioned floor, drain time for a known spike is something you can size and commit to rather than something you observe afterwards. That is what makes an internal SLA on queue-processing latency defensible.

A credible answer to "can Lambda handle our peak?" For event-driven architectures that previously hit a wall and migrated to containers, 100,000 concurrent invocations from a single mapping changes the analysis — with the cost caveats below.

Headroom without redesign. Teams already on Provisioned Mode raise one number. No new resources, no migration, no code change.

Security considerations

The blast radius of a misconfiguration scales with the cap. A mapping able to drive 100,000 concurrent invocations against a poison-message loop, or a function with a runaway downstream call, will consume account concurrency and hammer the dependency far faster than one capped at 1,250. Downstream databases and third-party APIs are the usual casualties. Size the mapping to what the downstream can absorb, not to what Lambda now permits.

Dead-letter configuration stops being optional. At this width, a failing batch pattern amplifies quickly. Set maxReceiveCount on the source queue's redrive policy to at least 5, per AWS guidance, and make sure a dead-letter queue exists before you raise the cap.

Encrypted queues need the extra permission. The AWSLambdaSQSQueueExecutionRole managed policy covers reading the queue. If the queue is encrypted, the execution role also needs kms:Decrypt — easy to miss when a mapping is created by automation rather than the console.

Who can change the poller count. Whoever can call UpdateEventSourceMapping can now provision ten times more capacity than before, with a directly proportional cost consequence. This is a permission worth scoping deliberately rather than granting with general Lambda write access.

Cross-account queues remain supported. The function and queue must be in the same Region but may be in different accounts — worth confirming the trust relationship still reflects intent when you rescale a mapping you did not originally build.

Cost considerations

This is the section to read twice. Provisioned Mode is not a free performance switch, and the change makes the upper bound of the bill ten times larger.

Three charges, not one

Enabling Provisioned Mode adds a standing charge on top of normal Lambda costs:

1. Event Poller Units. Billed in EPU-hours, at $0.00925 per EPU-hour for SQS event source mappings in US East (N. Virginia). For comparison, the Kafka and MSK rate is $0.185 per EPU-hour. Rates vary by Region.
2. SQS API requests. Each event poller long-polls at up to 10 calls per second, and those are billed as ordinary SQS requests. At scale this is a material line item, and it is easy to overlook because it lands on the SQS bill rather than the Lambda one.
3. Normal Lambda charges. Requests and duration, unchanged.

What the floor costs

The minimum poller count is held continuously, so it bills whether or not messages arrive. At the published US East (N. Virginia) rate:

Arithmetic is pollers multiplied by $0.00925 multiplied by 730 hours, excluding SQS request charges and all normal Lambda charges. The last row is not a recommendation — it is there to show what setting minimum equal to maximum would mean, which is a mistake worth naming explicitly.

How to think about it

The minimum is the spend commitment; the maximum is the risk. The minimum bills constantly, so it should reflect your steady-state floor, not your peak. The maximum bills only when Lambda scales into it, so it can be generous — but it is also the ceiling on a runaway, and the new cap makes that ceiling five times higher than yesterday.

Verify current rates before modelling. The figures above are US East (N. Virginia) as published on the Lambda pricing page. Confirm your Region and confirm the EPU-to-poller relationship for your configuration rather than carrying these numbers into a business case unchecked.

Operational considerations

Raising the maximum is not a rollout. It takes effect on the mapping immediately. There is no gradual ramp and no canary. If the new ceiling is wrong, you discover it at the next traffic spike, in production, at ten times the previous width. Raise it in stages and observe.

Set the visibility timeout correctly first. AWS recommends the source queue's visibility timeout be at least six times the function timeout, plus the value of MaximumBatchingWindowInSeconds if you use a batch window. The function timeout must be less than or equal to the queue's visibility timeout, and Lambda validates this when the mapping is created or updated. Getting this wrong at 1,250 concurrency produces duplicate processing; getting it wrong at 100,000 produces a great deal of it.

Watch the downstream, not the queue. The metric that tells you the cap is too high is not queue depth — that will look excellent. It is downstream connection saturation, database CPU, and throttled dependency calls.

Batch size interacts with the payload limit. A standard queue allows a batch size up to 10,000 records, and any batch size over 10 requires MaximumBatchingWindowInSeconds of at least 1 second. Lambda passes the whole batch in one call, subject to the 6 MB synchronous invocation payload quota, and both Lambda and SQS metadata count toward that total — so the delivered batch is often smaller than the configured size.

Manage it in IaC. The CloudFormation property is ProvisionedPollerConfig on AWS::Lambda::EventSourceMapping. A poller floor changed by hand in the console is an unexplained recurring charge three months later.

Tradeoffs

Against standard mode. Standard mode costs nothing to poll, scales itself, and idles down to as few as 2 concurrent invokes. It is the right default and remains so for most queues. Provisioned Mode buys ramp speed and ceiling in exchange for a standing charge and a configuration you now own. If nobody can state the latency requirement in numbers, you do not need it yet.

Against maximum concurrency. These are mutually exclusive, and the choice is really about what you are protecting. Maximum concurrency exists to stop one queue consuming the function's reserved concurrency or the account quota — a protective ceiling, free to configure. Provisioned Mode exists to guarantee throughput. You cannot have both mechanisms at once; under Provisioned Mode, MaximumPollers becomes your only concurrency control.

Against containers. A sustained, predictable, very high-throughput consumer may still be cheaper and more controllable on ECS or EKS, where you pay for compute rather than for polling capacity plus invocations. Provisioned Mode narrows the gap considerably for spiky workloads; it does not close it for flat ones.

Against FIFO queues. Raising the poller cap does little for FIFO, where concurrency is bounded by the number of message group IDs or the concurrency setting, whichever is lower. Six message groups means six concurrent invocations regardless of how many pollers you provision. If ordering is the constraint, this launch is not for you.

Implementation guidance

Prerequisites

• An existing SQS queue and Lambda function in the same Region. Different accounts are permitted.
• AWSLambdaSQSQueueExecutionRole attached to the function's execution role, plus kms:Decrypt if the queue is encrypted.
• A dead-letter queue with maxReceiveCount of at least 5 on the source queue's redrive policy.
• Visibility timeout at least six times the function timeout, plus the batch window if used.
• Confirmed headroom in the account concurrency quota for the concurrency the mapping can now generate.
• Maximum concurrency not configured on the mapping — it cannot coexist with Provisioned Mode.

Sizing the mapping

Work from the binding limit rather than from concurrency alone. For a target of 40,000 messages per second at an average 4 KB payload, throughput is roughly 160 MB/s, which needs about 160 pollers on the throughput limit. Check the same target against the other two limits — 10 concurrent invocations and 10 polling calls per second per poller — and size to whichever demands the most. Then confirm the resulting concurrency fits inside the account quota.

Enabling and raising it

Set a conservative floor and a deliberate ceiling:

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-11111EXAMPLE \
    --provisioned-poller-config '{"MinimumPollers": 10, "MaximumPollers": 2000}'

Raise the ceiling once you have observed real traffic against it:

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-11111EXAMPLE \
    --provisioned-poller-config '{"MinimumPollers": 10, "MaximumPollers": 10000}'

Confirm what is actually configured, rather than what you believe you set:

aws lambda get-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-11111EXAMPLE

Best practices

1. Size on the binding limit — throughput, concurrency, or polling calls — not on concurrency by habit.
2. Set the minimum to steady state, the maximum to peak. The minimum is a continuous charge; the maximum is only a ceiling.
3. Check the account concurrency quota before raising the ceiling. A mapping that outruns the quota throttles, and throttled batches return to the queue.
4. Get the visibility timeout right first — at least six times the function timeout, plus the batch window.
5. Configure the dead-letter queue before scaling, not after.
6. Alarm on downstream saturation, not just queue depth. Queue depth looks healthy right up to the moment the database does not.
7. Raise the ceiling in stages and observe a real spike at each step.
8. Keep ProvisionedPollerConfig in IaC so the floor is reviewable and attributable.

Who should adopt, who should wait

Adopt

• Teams who sharded a queue across multiple event source mappings purely to clear the old ceiling. Consolidating removes real complexity.
• Workloads with sharp, scheduled spikes — hourly batch releases, retail events, upstream backlog flushes — where the ramp rate is the user-visible problem.
• Anyone with a stated latency objective on queue processing that standard mode's four-minute ramp cannot meet.
• Teams who left Lambda for containers over the concurrency ceiling and have not revisited the decision since.

Wait

• Anyone whose standard mode ceiling of 1,250 is not actually being reached. Provisioned Mode would add a standing charge for no gain.
• Workloads that depend on the Maximum concurrency setting to protect a shared function or account quota. You cannot keep it and enable Provisioned Mode.
• FIFO queues, where message group count bounds concurrency regardless of pollers.
• Teams without downstream capacity to match. Raising the cap in front of a database that cannot absorb it converts a queueing delay into an outage.
• Anyone unable to attribute the EPU charge. If the floor cannot be explained on next month's bill, do not set it yet.

The setting this silently takes away

This deserves its own section because it is a mutual exclusion rather than a warning, and the thing it removes is a protective control.

Maximum concurrency exists for a specific defensive reason: to stop one event source consuming a function's reserved concurrency or the account's quota, starving everything else. It is free to configure and costs nothing to leave in place. If several SQS mappings feed the same function, it is often the only thing keeping one noisy queue from crowding out the others.

Enabling Provisioned Mode on such a mapping removes that guard and replaces it with a poller ceiling — which is a throughput control, not a concurrency budget. The two are related but not equivalent, and the substitution is easy to make without noticing, because nothing fails at the moment you make it. It surfaces later, when the queue that used to be politely capped saturates the function.

Before enabling Provisioned Mode on a shared function, check whether Maximum concurrency is currently doing protective work. If it is, translate that intent into MaximumPollers deliberately — remembering that one poller permits up to 10 concurrent invocations, so a 500-concurrency guard is roughly 50 pollers, not 500.

Key takeaways

1. MaximumPollers moves from 2,000 to 10,000, raising a single SQS event source mapping from 20,000 to 100,000 concurrent invocations — 80 times the standard-mode ceiling of 1,250.
2. MinimumPollers is unchanged at 2 to 200, default 2.
3. One event poller provides up to 1 MB/s, up to 10 concurrent invocations, or up to 10 SQS polling calls per second — whichever it reaches first. Size on the binding limit.
4. For most workloads the +1,000 concurrency per minute ramp matters more than the ceiling, versus +300 per minute in standard mode.
5. Provisioned Mode and Maximum concurrency are mutually exclusive. Enabling one removes the other as a control.
6. EPUs bill at $0.00925 per EPU-hour for SQS in US East (N. Virginia), and the minimum is held continuously. SQS polling calls bill separately as SQS requests.
7. Never set minimum equal to maximum. The minimum is a warm floor, not a reservation.
8. The mapping still draws on your account concurrency quota. Raising the ceiling past it produces throttling and retries, not throughput.
9. GA in all commercial Regions, no migration required.

Official AWS references

• AWS Lambda Provisioned Mode for Amazon SQS event source mappings now supports up to 10,000 event pollers
• Configuring scaling behavior for SQS event source mappings
• Creating and configuring an Amazon SQS event source mapping
• Using Lambda with Amazon SQS
• How Lambda processes records from stream and queue-based event sources
• AWS::Lambda::EventSourceMapping ProvisionedPollerConfig
• UpdateEventSourceMapping API reference
• AWS Lambda pricing
• Amazon SQS pricing
• AWS Lambda announces Provisioned Mode for SQS event source mapping
• AWSLambdaSQSQueueExecutionRole managed policy