⚡ AWS Lambda Can Run for 90 Minutes Now — But Should It?

⚡ AWS Lambda Can Run for 90 Minutes Now — But Should It?

For years, AWS learners eventually memorized one number:

⏱️ 15 minutes.

Need a function to run for 5 minutes?

Lambda could handle it.

Need 10 minutes?

Still possible.

Need 20, 30, or 60 minutes?

Now you were probably reconsidering the architecture.

Then AWS changed the equation.

On September 9, 2026, AWS announced that Lambda Managed Instances can support function executions of up to:

🔥 90 MINUTES

for asynchronous and supported Event Source Mapping invocations.

That is six times the familiar 15-minute limit.

But there is a much more important question than:

“Can Lambda run for 90 minutes?”

The real question is:

🤔 Should your workload run inside Lambda for 90 minutes?

That is where this update becomes an architecture discussion rather than just a product announcement.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🚨 First: This Is NOT “Every Lambda Function Now Runs for 90 Minutes”

This distinction matters.

The new 90-minute maximum applies specifically to:

✅ AWS Lambda Managed Instances

and to:

✅ Asynchronous invocations

✅ Supported Event Source Mapping invocations

It does not mean every Lambda function suddenly received a 90-minute timeout.

Synchronous Lambda invocations still retain the familiar:

⏱️ 15-minute maximum.

The Lambda initialization phase on Managed Instances also remains limited to 15 minutes.

And some Event Source Mapping integrations, including Amazon MQ and Amazon DocumentDB, remain subject to the 15-minute limit.

So the accurate statement is not:

“Lambda now runs for 90 minutes.”

A better statement is:

“Lambda Managed Instances can now support up to 90-minute execution for specific asynchronous and Event Source Mapping workloads.”

That detail changes everything.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧠 What Are Lambda Managed Instances?

Before discussing the longer timeout, it helps to understand the environment where it applies.

Lambda Managed Instances extend the Lambda programming model while allowing functions to run using managed EC2-based capacity.

AWS continues handling infrastructure responsibilities such as:

⚙️ Instance lifecycle

🔄 Scaling

🩹 Operating system and runtime patching

🌐 Routing

⚖️ Load balancing

while developers continue working with familiar Lambda concepts such as:

⚡ Functions

📜 Handlers

🔐 Execution roles

🌐 VPC configuration

📊 CloudWatch monitoring

Lambda Managed Instances are especially interesting for workloads that benefit from:

🖥️ Specialized compute

📈 Predictable or steady-state usage

⚙️ Greater compute configuration flexibility

💰 EC2-based pricing characteristics

⏱️ And now, significantly longer continuous execution.

This is not simply “normal Lambda with a bigger timer.”

It represents another compute option inside the AWS ecosystem.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔥 Why the 15-Minute Limit Mattered

The old timeout forced an important architecture decision.

Imagine you have a job that normally requires:

25 minutes.

Traditional Lambda execution could not simply continue until completion.

You had to rethink the workload.

Maybe you:

🔄 Split the task into smaller Lambda functions.

📬 Used queues between processing stages.

🧩 Introduced Step Functions.

📦 Moved processing into containers.

⚙️ Used AWS Batch.

🖥️ Ran the workload on EC2.

Sometimes that restructuring improved the architecture.

Sometimes it added complexity mainly because the workload could not complete inside the Lambda execution window.

The new 90-minute option changes that trade-off for some workloads.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧪 What Kinds of Workloads Could Benefit?

AWS specifically highlights examples such as:

📊 Data processing

🎥 Media transcoding

💰 Financial calculations

🤖 AI inference

⚙️ Batch processing

🌐 Web crawling

📁 Large file transfers

Imagine a data-processing task that consistently takes:

22 minutes.

Previously:

❌ Too long for a standard 15-minute Lambda execution.

Now:

✅ Potentially feasible on Lambda Managed Instances when invoked through a supported asynchronous pattern.

That can reduce the need to break a naturally continuous computation into artificial pieces solely because of the previous timeout.

But convenience introduces another question.

What happens when that 22-minute job fails at minute 21?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 The Longer Your Function Runs, the More Expensive Failure Becomes

Suppose your function performs a 45-minute AI inference job.

Everything works for:

10 minutes.

20 minutes.

30 minutes.

Then at minute 39:

💥 Something fails.

Maybe:

🌐 An external dependency disconnects.

🔑 A temporary credential expires.

📡 A network connection dies.

🧠 The process throws an exception.

🗄️ A downstream service becomes unavailable.

Now what?

If your workload simply starts again from the beginning, you may repeat almost 40 minutes of expensive computation.

That is why a longer timeout changes more than the maximum runtime.

It increases the importance of:

🔁 Retry behavior

🧠 Idempotency

💾 Checkpointing

📊 Observability

🔐 Credential lifetime

🌐 Connection lifetime

💰 Failure cost

Longer-running serverless workloads require more deliberate failure design.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔁 Idempotency Becomes Even More Important

Imagine an SQS message triggers your Lambda function.

The function:

1️⃣ Reads the message.

2️⃣ Processes a large dataset.

3️⃣ Writes results into a database.

4️⃣ Sends a notification.

Now imagine the function fails after writing the database result but before completing the invocation.

The event may eventually be retried.

What happens when the same job runs again?

Does it:

✅ Detect that the operation already completed?

or:

❌ Write duplicate records?

❌ Charge the customer twice?

❌ Send duplicate notifications?

❌ Process the same file again?

That is the idea behind idempotency.

An idempotent operation can safely be repeated without creating unintended duplicate effects.

With longer execution windows, the consequences of poorly designed retries can become more expensive.

The takeaway:

⏱️ Longer timeout

does not reduce the importance of good distributed-system design.

It increases it.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💾 This Is Where Durable Functions Become Interesting

AWS also supports Lambda durable functions.

Durable functions introduce checkpointing concepts that allow execution progress to be preserved.

Imagine a long-running workload:

Step 1

↓

15 minutes of processing

↓

💾 Checkpoint

↓

Step 2

↓

20 minutes of processing

↓

💾 Checkpoint

↓

Step 3

Now suppose the underlying execution experiences a failure during Step 3.

Without useful checkpointing:

🔄 Start everything again.

With durable execution:

💾 Previously completed work can be recognized during recovery.

AWS describes durable functions as using checkpoints to track execution progress and replay execution while skipping completed work.

That becomes particularly valuable when re-running earlier computation would be expensive.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🤖 Example: Long AI Inference

Imagine an inference workload takes approximately:

40 minutes.

At minute 35:

💥 Infrastructure failure.

Starting again from minute zero means repeating 35 minutes of computation.

For expensive workloads, that can hurt:

💰 Cost

⏱️ Latency

📈 Throughput

😵 Operational reliability

A durable approach can make checkpointing part of the design.

The important architecture question becomes:

“Can the workload safely restart?”

If yes:

A normal retry model may be enough.

If no:

Consider checkpointing or another execution model.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📨 What Happens With Asynchronous Lambda Invocations?

For asynchronous invocations, Lambda can apply retry behavior when a function fails or times out.

That means architects need to think carefully about what happens when long-running work is retried.

Questions worth asking:

❓ Can the same event safely execute twice?

❓ Does processing create external side effects?

❓ Should failed events go to a dead-letter queue?

❓ Should an on-failure destination be configured?

❓ What should happen after repeated failure?

❓ Can processing resume instead of restart?

Long execution makes these questions more consequential.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📬 SQS + 90-Minute Lambda Requires Careful Configuration

SQS is a natural companion for asynchronous processing.

Architecture:

📨 Amazon SQS

↓

⚡ Lambda Managed Instance

↓

🧠 Long-running processing

↓

🗄️ Store result

But there is an important timing relationship.

The queue's visibility timeout needs to accommodate the Lambda processing window and retry behavior.

AWS currently recommends configuring the SQS visibility timeout to at least:

6 × the Lambda function timeout.

So imagine configuring:

Lambda timeout:

90 minutes

Then the queue visibility timeout needs careful planning around that execution duration.

Why?

Because you do not want the same SQS message becoming visible again while the original invocation is still processing it.

Longer Lambda execution means surrounding services must also be configured with longer-running processing in mind.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📦 Batch Failure Handling Matters Too

Imagine an Event Source Mapping sends several records to your function.

The batch contains:

Record 1 ✅

Record 2 ✅

Record 3 ❌

Record 4 ✅

Record 5 ✅

Without careful failure handling, one bad record can cause successful records to be processed again.

For supported event sources, AWS provides partial batch failure capabilities.

That allows your application to communicate:

“These records succeeded.”

“These records failed.”

Then only failed records need to be retried.

With workloads that may run for tens of minutes, avoiding unnecessary reprocessing becomes even more valuable.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🌐 Long-Lived Network Connections Become a Real Architecture Concern

A five-second Lambda function usually does not make you think much about connection longevity.

A 70-minute function should.

Imagine your function connects to:

🗄️ Amazon RDS

⚡ Amazon ElastiCache

🌐 External APIs

🔌 Third-party databases

🚪 Services through a NAT Gateway

Now ask:

Will this connection remain valid for the full execution?

AWS recommends reviewing idle connection behavior when designing long-running Managed Instance functions.

For example, downstream services may terminate idle connections.

Network infrastructure may have its own idle timeout.

A connection that works during a short Lambda invocation may behave differently across an hour-long job.

This means long-running functions should be built assuming:

Connections can disappear.

Clients may need reconnection logic.

Retries need to be safe.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔑 Temporary Credentials Have Lifetimes Too

Long-running Lambda functions may interact with:

🔐 Temporary AWS credentials

🎟️ Authentication tokens

🌐 Third-party API tokens

🗄️ Temporary database credentials

Ask:

Will these credentials remain valid throughout the entire execution?

If not:

How will they be refreshed?

This is another subtle consequence of increasing execution duration.

Something that easily survives a 3-minute function may expire during a 75-minute process.

AWS specifically recommends reviewing temporary credentials and tokens for long-running Managed Instance functions.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🌍 DNS Can Change During Long Executions

Another subtle concern:

DNS.

An application may resolve:

api.example.com

at the beginning of execution.

But what happens if the destination changes later?

DNS records have TTL values.

Long-running applications should respect those TTL values rather than assuming one DNS result remains valid indefinitely.

AWS SDKs generally handle this appropriately, but custom clients deserve attention.

Again:

Long-running Lambda begins to resemble some operational concerns traditionally associated with persistent applications.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚡ So Should Everything Move to 90-Minute Lambda?

No.

And that is probably the most important part of this update.

The increased timeout expands your architectural options.

It does not eliminate the other options.

The right question is:

“What execution model matches this workload?”

Let us compare.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚡ Option #1 — Lambda Managed Instances

Consider this approach when:

✅ Your application already fits the Lambda programming model.

✅ Processing is event-driven.

✅ Execution is asynchronous.

✅ The job naturally completes within the supported window.

✅ You want Lambda's managed operational model.

✅ Longer continuous execution removes unnecessary architectural fragmentation.

✅ Specialized compute or Managed Instance economics fit the workload.

Questions to ask:

❓ Is the workload idempotent?

❓ What happens if execution fails near completion?

❓ How are retries handled?

❓ Are connections and credentials safe for the entire duration?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔄 Option #2 — AWS Step Functions

Step Functions becomes interesting when the real problem is not:

“How long can one piece of code run?”

but instead:

“How should multiple pieces of work coordinate?”

Step Functions supports workflows involving:

🔀 Branching

🔁 Retries

🛑 Error handling

⏳ Waiting

📨 Service integrations

🔄 Multiple processing steps

📞 Callback patterns

For example:

Receive file

↓

Validate

↓

Process

↓

Wait for external result

↓

Transform

↓

Store output

↓

Notify user

That may be easier to understand as a workflow than as one enormous 80-minute function.

Step Functions also supports Retry and Catch behavior for handling task failures.

The decision is architectural:

One long computation?

or

Several coordinated steps?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📦 Option #3 — Amazon ECS + AWS Fargate

Maybe your workload is already containerized.

Maybe you require:

🐳 Custom container behavior

🖥️ Greater runtime control

📦 Larger application dependencies

⚙️ Long-running worker processes

🔧 More control over CPU and memory configuration

AWS Fargate allows ECS workloads to run containers without requiring you to manage EC2 server clusters directly.

That can be attractive when:

The application naturally behaves like a containerized worker rather than an event-driven function.

Instead of asking:

“Can I force this workload into Lambda?”

ask:

“Which compute abstraction naturally matches the application?”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚙️ Option #4 — AWS Batch

For true batch workloads, AWS Batch deserves consideration.

AWS Batch is designed to plan, schedule, and run batch-computing workloads while managing underlying compute capacity.

That can be useful for:

🧮 Scientific workloads

🤖 Machine learning processing

📊 Analytics

🧪 Simulation

🎞️ Large-scale media processing

📦 Queued compute jobs

If your problem fundamentally looks like:

“Here are thousands of compute jobs. Schedule and execute them efficiently.”

then the workload may align naturally with AWS Batch.

Again:

Longer Lambda does not mean every batch workload should become a Lambda workload.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧠 Architecture Decision: Ask About the Workload, Not the Trend

Instead of asking:

“Which AWS service is best?”

ask questions like:

⏱️ How long does processing take?

📈 Is traffic steady or bursty?

📦 Is the application containerized?

🔄 Is the workload one computation or many coordinated steps?

💥 What happens when execution fails?

📬 How does work enter the system?

💾 Does the workload need checkpoints?

🔐 What credentials are involved?

🌐 Does the workload maintain long-lived connections?

💰 What does the cost profile look like?

📊 How will I monitor it?

🧪 Can processing safely run more than once?

Architecture decisions become much clearer when they begin with requirements instead of service popularity.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 A Quick Decision Framework

⚡ Lambda Managed Instances

Think:

Event-driven + continuous asynchronous execution + Lambda programming model.

🔄 Step Functions

Think:

Workflow orchestration + multiple steps + retries + branching + waiting.

📦 ECS / Fargate

Think:

Containerized workload + runtime control + long-running process.

⚙️ AWS Batch

Think:

Queued batch jobs + compute-intensive processing + scheduling at scale.

These services can also work together.

Architecture is not always:

A versus B.

Sometimes it is:

A + B + C.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🏗️ Example Architecture #1 — Long Data Processing Job

Imagine:

An S3 upload triggers processing of a very large file.

Architecture:

🪣 Amazon S3

↓

📨 Amazon SQS

↓

⚡ Lambda Managed Instance

↓

📊 Process dataset

↓

🪣 Store output in S3

↓

📈 CloudWatch

Typical processing time:

35–50 minutes.

Now ask:

✅ Is processing idempotent?

✅ Is the SQS visibility timeout configured correctly?

✅ Can the job safely restart?

✅ Are downstream connections resilient?

✅ Are metrics and logs sufficient?

✅ Is Lambda Managed Instances the right cost model?

This is where the new capability becomes genuinely useful.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #1 — Minute 47 Failure

Imagine the job normally takes 50 minutes.

At minute:

47

the function fails.

The event is retried.

What happens?

Option A:

🔄 Repeat the entire 47 minutes.

Option B:

💾 Resume from a checkpoint.

Option C:

📦 Use another architecture where job state is managed differently.

There is no universal answer.

But the failure should be designed before production.

Do not wait until minute 47 to discover your recovery strategy.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #2 — Duplicate Delivery

The same event executes twice.

Does your workload:

✅ recognize the duplicate?

or:

❌ create duplicate output?

For example:

A financial workload should not accidentally process the same transaction twice.

A file processor should not create multiple inconsistent copies.

A notification system should avoid sending the same message repeatedly.

Long-running execution does not change the fundamental rule:

Design distributed systems expecting retries and duplicates.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #3 — External API Dies Midway

Your Lambda function processes data for 30 minutes.

Then it calls an external API.

The API returns:

500 Internal Server Error.

What happens next?

Ask:

🔁 Should you retry?

⏱️ How long should you wait?

📈 Should exponential backoff be used?

🚫 When should you stop?

💾 Should progress be checkpointed before the call?

📨 Should the failed job move to another queue?

This is why “90 minutes” is not simply a timeout configuration.

It becomes a reliability-design problem.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #4 — Authentication Token Expires

Your job obtains a temporary token.

Token lifetime:

60 minutes.

Function execution:

75 minutes.

At minute 65:

🔐 Authentication begins failing.

The Lambda function itself is still running.

But its dependency is no longer accessible.

The lesson:

Longer compute duration requires reviewing assumptions made by every dependency around that compute.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧪 A Student-Friendly Hands-On Lab

You do not need to immediately create a 90-minute production workload.

Instead, build a simulation.

Create a long-running asynchronous processing flow.

For example:

📨 SQS

↓

⚡ Lambda

↓

🧠 Process several simulated steps

↓

📊 Write progress into logs

↓

🗄️ Save result

Example stages:

Step 1 — Validate input

Step 2 — Load data

Step 3 — Process chunk A

Step 4 — Process chunk B

Step 5 — Save results

Then deliberately introduce:

💥 An exception during Step 4.

Observe:

📊 CloudWatch logs.

📨 Retry behavior.

🔁 Duplicate processing.

⏱️ Execution duration.

Then modify your design.

Add:

🆔 Idempotency keys.

💾 Checkpointing.

📬 Failure destinations.

📊 Better structured logs.

Now the exercise teaches architecture, not just Lambda syntax.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📈 Monitoring Matters More When Jobs Take Longer

Imagine a 2-second Lambda function.

If it fails, you usually discover quickly.

Now imagine a function that runs for:

68 minutes.

You do not want to discover at minute 68 that nothing useful happened.

Observability becomes critical.

Monitor:

⏱️ Duration

❌ Errors

🚫 Throttles

📈 Resource utilization

🧠 Application progress

📜 Logs

🔄 Retry behavior

For Lambda Managed Instances, AWS also exposes capacity-provider-level metrics such as CPU and memory utilization.

Long-running execution should produce enough telemetry to answer:

“Is useful work actually progressing?”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💰 What About Cost?

Longer execution does not automatically mean cheaper or more expensive architecture.

The answer depends on:

⚙️ Compute configuration

📈 Utilization

⏱️ Duration

🔢 Concurrency

📦 Workload pattern

💳 Pricing model

📊 Steady-state versus bursty traffic

AWS specifically notes that Lambda Managed Instances are particularly suited to steady-state workloads with predictable high-volume traffic, while default Lambda capacity may still be more cost-effective for burstier workloads.

That means:

“90 minutes exists”

is not enough information to make a cost decision.

Measure your workload.

Model the alternatives.

Then decide.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️ Do Not Set Every Timeout to 90 Minutes

Another tempting response to the announcement is:

“Great! Set everything to 5,400 seconds.”

Please don't.

Timeouts are also safety mechanisms.

Imagine buggy code enters an unintended loop.

A short timeout limits how long the problem continues.

A very generous timeout allows the problem to consume resources much longer.

Set the timeout based on realistic workload behavior.

For example:

Expected duration:

12 minutes

Maybe the correct timeout is:

15 or 20 minutes.

Not automatically:

90 minutes.

Configuration should reflect expected execution, not the maximum number AWS allows.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎤 Turn This Update Into an Interview Discussion

Imagine an interviewer asks:

“A workload runs asynchronously for about 40 minutes. AWS Lambda Managed Instances now support up to 90-minute execution. Would you use Lambda?”

A weak answer:

“Yes, because Lambda supports 90 minutes now.”

A stronger answer:

“I would first evaluate the workload characteristics. If it is event-driven, naturally fits the Lambda programming model, runs asynchronously, and can safely handle retries and duplicate execution, Lambda Managed Instances could be a good option. I would also evaluate idempotency, connection and credential lifetimes, checkpointing requirements, observability, and cost. If the workload is really a multi-step orchestration, containerized worker, or large batch-processing job, I would also compare Step Functions, ECS/Fargate, or AWS Batch before deciding.”

That demonstrates:

🧠 Architecture thinking

⚡ Lambda knowledge

🔄 Workflow awareness

📦 Container knowledge

⚙️ Batch-compute awareness

💥 Failure analysis

💰 Cost awareness

🔐 Operational thinking

Much stronger than memorizing:

“Lambda maximum timeout = 90 minutes.”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔥 The Bigger Lesson

The biggest Lambda update is not simply:

15 minutes → 90 minutes.

The bigger change is:

AWS architects now have another compute decision to make.

Previously, exceeding 15 minutes could immediately eliminate Lambda from certain designs.

Now some of those workloads deserve another look.

But every expanded capability also expands the architecture questions.

Longer execution introduces more responsibility around:

🔁 Retries

💾 Recovery

🔐 Credentials

🌐 Connections

📊 Monitoring

💰 Cost

🧠 Idempotency

💥 Failure handling

A higher limit gives you flexibility.

It does not remove the need for engineering judgment.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎯 Final Thoughts

I think the most interesting part of AWS Lambda's new 90-minute capability is not the number itself.

It is the conversation it creates.

For years:

Long-running workload?

Lambda probably was not the first choice.

Now the answer becomes:

“Maybe.”

And “maybe” is where architecture becomes interesting.

Do not choose Lambda because the timeout increased.

Do not reject Lambda because you remember the old 15-minute limitation.

Instead:

📋 Understand the workload.

🧠 Understand the failure model.

⏱️ Understand the execution characteristics.

🔄 Understand retries.

💾 Understand recovery.

📊 Understand observability.

💰 Understand cost.

Then choose the compute model that actually fits.

That is the difference between:

Knowing AWS services

and

Designing with AWS services.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

☁️ Your Turn — Architecture Challenge

Imagine this workload:

📊 Data-processing job

⏱️ Typical duration: 35–50 minutes

📨 Triggered asynchronously

💥 Occasionally fails around minute 30

💰 Reprocessing is moderately expensive

📈 Workload arrives consistently throughout the day

What architecture would you investigate first?

⚡ Lambda Managed Instances

🔄 AWS Step Functions

📦 ECS + AWS Fargate

⚙️ AWS Batch

or

🧩 A combination of them?

And more importantly:

Why?

💬 Share the architecture you would choose and the trade-offs that would drive your decision.

There may not be one universally correct answer.

That is exactly what makes the discussion valuable. 🚀

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📚 AWS Resources Behind This Article

• AWS announcement: 90-minute function timeout on Lambda Managed Instances

• AWS Compute Blog: Announcing 90-minute function timeout on AWS Lambda Managed Instances

• AWS Lambda documentation: Configuring function timeout

• AWS Lambda documentation: Managed Instances best practices

• AWS Step Functions documentation: Service integrations and error handling

• Amazon ECS documentation: AWS Fargate architecture

• AWS Batch documentation: What is AWS Batch?

Always verify current service limits, supported invocation types, pricing, and regional availability in the latest AWS documentation before designing production workloads.