SQS Long Polling for MCP Servers — WaitTimeSeconds, Cost Reduction, Lambda ESM

Short polling vs long polling: mechanics

SQS distributes messages across multiple servers. A short-poll ReceiveMessage request samples only a subset of those servers and returns any messages found immediately. If the sampled servers hold no messages, an empty response is returned — even if messages exist on other servers. This means short polling can return empty even on a non-empty queue, requiring more calls to drain the queue.

A long-poll ReceiveMessage request queries all SQS servers. If no messages are available, the connection stays open until:

• A message arrives (returned immediately),
• WaitTimeSeconds elapses (empty response returned), or
• The HTTP connection times out at an intermediate proxy or load balancer (you should set HTTP client timeouts to at least 25 seconds to accommodate 20-second long-poll waits).

Configuring long polling: queue vs per-call

There are two places to configure WaitTimeSeconds:

• Queue attribute ReceiveMessageWaitTimeSeconds: sets the default for all ReceiveMessage calls on the queue that do not supply an explicit WaitTimeSeconds. Range: 0–20 seconds.
• Per-call WaitTimeSeconds parameter: overrides the queue default for that specific call. Range: 0–20 seconds.

If both are set, the per-call value takes precedence.

import { Queue, Duration } from 'aws-cdk-lib/aws-sqs';
import { SQSClient, ReceiveMessageCommand } from '@aws-sdk/client-sqs';

// Set long polling as the queue default
const probeQueue = new Queue(this, 'ProbeQueue', {
  receiveMessageWaitTime: Duration.seconds(20),  // CDK maps to ReceiveMessageWaitTimeSeconds
  visibilityTimeout: Duration.seconds(90),
  deadLetterQueue: { queue: dlq, maxReceiveCount: 3 },
});

// Manual polling loop (ECS consumer) — respects the queue default
const sqs = new SQSClient({});

async function pollLoop(queueUrl: string): Promise {
  while (true) {
    const resp = await sqs.send(new ReceiveMessageCommand({
      QueueUrl: queueUrl,
      MaxNumberOfMessages: 10,
      // WaitTimeSeconds omitted — uses queue's ReceiveMessageWaitTimeSeconds default (20s)
      AttributeNames: ['All'],
      MessageAttributeNames: ['All'],
    }));

    if (!resp.Messages || resp.Messages.length === 0) continue;  // empty long-poll response

    await Promise.all(resp.Messages.map(processMessage));
  }
}

Lambda ESM and long polling

Lambda's Event Source Mapping polls your SQS queue using long polling with WaitTimeSeconds=20 by default. This is built in and cannot be changed through CDK or CloudFormation — it is a Lambda ESM implementation detail, not a configurable property.

Consequences:

• Lambda-triggered SQS queues generate at most ~3 empty ReceiveMessage calls per minute per polling process (one per 20 seconds). At production scale with thousands of Lambda concurrent executions, this is still negligible.
• Lambda ESM runs multiple polling processes concurrently. The number scales automatically with the number of messages in the queue, up to the maximumConcurrency limit or Lambda's service quota.
• If your queue uses SSE with a customer-managed KMS key, Lambda's polling IAM role needs kms:Decrypt permission on the key — long polling does not change this requirement.

For most AliveMCP probe pipelines using Lambda consumers, no long-polling configuration is required — the default ESM behavior already optimises empty-response cost.

When short polling is appropriate

Short polling (WaitTimeSeconds=0) is appropriate in two specific situations:

• Non-blocking queue depth check: a diagnostic handler that reports the approximate number of messages in the queue without waiting. Use GetQueueAttributes with ApproximateNumberOfMessages instead — this is more accurate and does not consume a ReceiveMessage call.
• High-throughput saturation polling: when the queue is always expected to have messages and you want maximum throughput from a multi-threaded consumer. In this mode, empty responses are rare (queue is never idle), so the cost of short polling is low. Long polling's 20-second wait would add latency during the brief idle gaps between bursts.

For MCP probe pipelines, the queue is typically idle between 60-second probe cycles. Long polling is almost always the right choice for probe-result queues.

HTTP client timeout configuration for long polling

Long-polling requests keep the HTTP connection open for up to 20 seconds. AWS SDK v3 sets the HTTP socket timeout to 0 (infinite) by default for Node.js when using the SQS client — but if you are running behind a load balancer or proxy with a short idle connection timeout, long-poll requests may be aborted prematurely, producing a socket hang up or ECONNRESET error.

import { SQSClient } from '@aws-sdk/client-sqs';
import { NodeHttpHandler } from '@smithy/node-http-handler';

const sqs = new SQSClient({
  requestHandler: new NodeHttpHandler({
    socketTimeout: 25_000,    // 25 seconds — 5s margin above max 20s long-poll wait
    connectionTimeout: 5_000, // 5 seconds for initial TCP connect
  }),
});

On ECS tasks behind an ALB: set the ALB idle timeout to at least 25 seconds (ALB default is 60 seconds — this is fine by default, but worth verifying if your DevOps team has tuned it down).

Common failure modes