Can Amazon Connect wait beyond 60 seconds for a long-running Lambda invocation ?

Amazon Connect has a maximum timeout limit of 60 seconds when invoking Lambda functions in asynchronous execution mode, and 8 seconds for synchronous mode. Unfortunately, there is no supported way to extend these timeout limits beyond these maximums within Amazon Connect's native capabilities.

For your use case where the external automation process takes 80-100 seconds, you'll need to adopt an asynchronous architecture rather than relying on a single synchronous Lambda invocation. Here's how you can approach this:

1. Use Asynchronous Lambda Invocation with Wait Block: Configure your Lambda function block to use asynchronous execution mode. This allows the contact flow to continue without waiting for the Lambda to complete. You can then use a Wait block configured for event-based waiting, which can monitor the Lambda invocation using its RequestId. However, even with this approach, the Wait block itself has limitations and cannot indefinitely hold for extremely long operations.

2. Keep Callers Engaged During Processing: While waiting, you can use flow blocks to play hold music, prompts, or periodic updates to keep the caller informed that their request is being processed. This improves the caller experience during the wait time.

3. Alternative Architecture Pattern: For operations exceeding 60 seconds, consider decoupling the long-running process:

   • Have the initial Lambda function immediately acknowledge the request and initiate the backend automation asynchronously
   • Store the request state in a database or queue
   • Use a callback mechanism or polling approach where the flow periodically checks the status
   • Once complete, either notify the caller through a callback or provide them with a reference number to check status later

The fundamental constraint is that Amazon Connect's Lambda integration is designed for relatively quick operations, not long-running processes that exceed 60 seconds. For your 80-100 second automation workflow, an asynchronous architecture with state management is the recommended approach rather than trying to extend the native timeout limits.
Sources
Flow block in Connect Customer: AWS Lambda function - Amazon Connect Customer
Flow block in Connect Customer: Wait - Amazon Connect Customer

There is a native way to do this in Amazon Connect, and it handles 80–100 second work without needing to hang up and call the customer back. The key is Asynchronous execution mode on the Lambda block paired with the Wait block.

First, on the timeouts you're seeing, so the numbers make sense:

• The Invoke AWS Lambda function block has two Execution modes. Synchronous waits for the Lambda and has a max Timeout of 8 seconds. Asynchronous does not wait — "the contact is routed to the next block without waiting for the Lambda to complete" — and its max Timeout is 60 seconds. The ~60 seconds you're hitting matches the asynchronous ceiling, and neither mode can be raised past its max. So you're right that a single synchronous call can't wait for an 80–100s job.

The native pattern that does work:

1. Invoke AWS Lambda function block in Asynchronous mode. Your Lambda kicks off (or performs) the long job and Connect immediately moves on without blocking the call. Note the invocation RequestId is available as $.LambdaInvocation.InvocationId.
2. Wait block with the Set event-based wait option, given that RequestId. Per the docs, this "specify a Lambda to wait for its completion and route the contact down the Lambda Return branch when the execution of specified Lambda is completed." The Wait block's max timeout is 7 days, so an 80–100 second job is well within range — duration isn't the limiting factor here.
3. When the Lambda finishes, the flow takes the Lambda Return branch. Use a Load Lambda Result action / Set contact attributes to read the returned data and then tell the caller the outcome.

That directly answers your three questions:

• Wait longer than the block timeout: not by raising the 8s/60s block timeout, but yes via the Wait block's event-based wait, which waits for the Lambda to actually complete (up to 7 days).
• Keep the caller engaged while it runs: yes. You can run other blocks while waiting — add a Play prompt block on the Wait block's Continue branch to play hold music or a "please hold while we finish this" message. So the caller isn't sitting in silence, and they get the final result on the same call.
• Native support for long-running work: this async-invoke + event-based-Wait combination is the supported native mechanism. You do not have to move to an external queue/middleware just to get past 60 seconds, though decoupling the heavy work is still good practice (see the note below).

Two things to watch, since you're on a voice call specifically:

• On Voice, the Wait block is only supported in an Inbound flow, and only when the Keep running while waiting or Set event-based wait option is selected. Since you'll be using event-based wait, that condition is met — just make sure it's an inbound flow.
• You can't nest Wait blocks, and if you pass the wrong Invocation ID the block just waits until its timeout. So double-check the RequestId wiring.

One design note: even though the Wait block can hold for a long time, it's still cleaner to have the async Lambda hand the actual 80–100s work off to something built for it (an async worker, Step Functions, SQS, or EventBridge) and simply signal completion. That keeps the Lambda itself lightweight and makes retries and failures easier to reason about. But the flow-side waiting is fully handled by the async + Wait pattern above.

References:

• Invoke AWS Lambda function block (Synchronous vs Asynchronous, 8s/60s timeouts, Load Lambda Result): https://docs.aws.amazon.com/connect/latest/adminguide/invoke-lambda-function-block.html
• Wait block (Set event-based wait, Lambda Return branch, 7-day max, voice support, Play prompt while waiting): https://docs.aws.amazon.com/connect/latest/adminguide/wait.html
• Grant Connect access to your Lambda functions: https://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html

No. Amazon Connect cannot wait beyond the maximum synchronous Lambda invocation timeout configured for contact flows. While AWS Lambda supports execution times of up to 15 minutes, the Invoke AWS Lambda function block in Amazon Connect has its own service-side timeout (approximately 60 seconds), which is not configurable.

This timeout is enforced by Amazon Connect, not Lambda. Therefore:

Increasing the Lambda timeout to 120, 300, or 900 seconds will not cause Amazon Connect to wait longer. Playing hold music, looping prompts, or using a Loop block does not extend the active Lambda invocation. Once the invocation exceeds the Connect timeout, the block returns an error and follows the configured error branch.

For workloads that take 80–100 seconds, the recommended AWS architecture is to decouple the long-running task:

Amazon Connect │ ▼ Short Lambda (< 5–10 sec) │ ▼ Step Functions / SQS / EventBridge │ ▼ External Automation │ ▼ DynamoDB / S3 / RDS (Persist Status) │ ▼ Callback / Polling / Event Notification

If the caller must receive the result during the same interaction, the only practical approach is to:

Start the long-running process asynchronously. Persist the execution state (for example, in DynamoDB). Periodically invoke short-lived Lambda functions from the contact flow to poll the status (each invocation must complete within the Connect timeout). Continue the flow once the status changes to COMPLETED.

Alternatively, use an outbound callback or a follow-up contact once the backend processing finishes.

There is currently no native Amazon Connect capability that allows a single synchronous Lambda invocation to remain active for 80–100 seconds and then resume the contact flow with its response. This is a service limitation rather than a Lambda limitation.