I know this is a little bit late reply but just wanna share my insights. From my testing with batchSize and maxBatchingWindow, the 16 seconds difference you observed was due to enable maxBatchingWindow config. The process of consuming event from SQS can be separated into 2 steps. First, your lambda will have resources called event pollers (which is what you are able to config batchSize, batchWindow), these pollers will be responsible to pull message from SQS servers to invoke your lambda. The second part involves the SQS itself, it is the process of new message detection and delivery of the SQS servers. The second part is mainly the root causes for the latency difference you saw in your testing. With batching window enabled, SQS actually applying a scan on every server/storage, instead of a scan on only a subset of servers, to reduce empty message response and optimize long polling strategy from lambda event pollers. As you can see this is a very expensive query and in order to scaling down efficiently in low-traffic scenario, AWS would very likely to apply a backoff strategy here in case of multiple empty scans which would explain why the initial event consumption take very long around 20 seconds before lambda can be invoked (even if your batchSize is 1)