An integration environment has an SQS queue that triggers a Lambda to transform messages and call a third-party API. Increased usage causes the third-party API to return many HTTP 429 Too Many Requests, blocking message processing. How should the developer fix this?

The correct solution is to set maximum concurrency on the SQS event source to match the third-party API's documented rate limits. This directly controls how many concurrent Lambda invocations process messages from the SQS queue, preventing the Lambda from overwhelming the third-party API and receiving 429 errors. Increasing the SQS event source's batch size would process more messages per Lambda invocation, but wouldn't limit the rate of invocations, potentially worsening the problem. Configuring provisioned concurrency for the Lambda ensures a certain number of Lambda instances are always warm, but doesn't regulate the rate at which they are invoked by SQS or prevent them from collectively exceeding the third-party API's limits. Increasing Lambda asynchronous retry attempts and maximum event age would only delay the inevitable 429 errors and keep retrying failed requests, not prevent the initial overload.