Legacy Batch Job Modernization on AWS

Legacy Batch: Replace the Cron Server with Scheduler, Step Functions, and Batch

Quick summary: Classic Lambda stops at 900 seconds. Lambda Managed Instances can run async work for 5,400 seconds. Anything longer than that band belongs on AWS Batch, not on the VM that only exists for the schedule.

Key Takeaways

Classic Lambda stops at 900 seconds
Lambda Managed Instances can run async work for 5,400 seconds
Anything longer than that band belongs on AWS Batch, not on the VM that only exists for the schedule
The lab diagram on 4 October 2026 still had a VM whose only purpose was a nightly script
On Lambda Managed Instances, asynchronous invocations and event-source mappings can run for 5,400 seconds, except Amazon MQ and Amazon DocumentDB

The lab diagram on 4 October 2026 still had a VM whose only purpose was a nightly script. Classic Lambda stops at 900 seconds. On Lambda Managed Instances, asynchronous invocations and event-source mappings can run for 5,400 seconds, except Amazon MQ and Amazon DocumentDB. Those ceilings are in the Lambda timeout documentation. The VM was not in either band. It was a computer that existed so Task Scheduler had somewhere to run.

This is not the EventBridge patterns post, which owns domain events. It is not the serverless strangler playbook, which owns the request path. The 90-minute LMI post owns that timeout as an operations topic. A Lambda whose handler is one SDK call belongs on the Scheduler spoke, not here.

Reproduce this — Copy the duration-band worksheet. One job per row. Write the band before you draw a new server.

Three bands

Normal run	Compute	Stop
Up to 900 seconds	Classic Lambda, started by EventBridge Scheduler	The job branches across hours of dependencies. Use Step Functions for the chain, not a longer function.
Up to 5,400 seconds, async or event-source	Lambda Managed Instances	You needed a service that stays up. That is not a job. Amazon MQ and DocumentDB sources are outside this window.
Multi-hour, or an array of work items	AWS Batch	You are about to raise a function timeout in a loop. Batch is the band.

Step Functions holds the dependencies between jobs. Scheduler is the clock. File arrival is a trigger, an S3 event or a similar signal, not a second cron that hopes the file is there.

We recommend deleting the VM when the job fits a band. The trade-off is an AWS schedule and a compute service you did not operate before. Take that trade when the VM’s only job is the schedule. Keep a server when the workload is a long-running process with its own uptime, and then it is not a batch job.

Where this fails

What broke — Lab, 4 October 2026. Not a customer account. The nightly job was moved to classic Lambda and timed out at 900 seconds because the run was two hours. Detection: the duration cell was empty and the target was Lambda anyway. Recovery: put the run on Batch and let Scheduler start the state machine. Lesson: rehosting the cron VM, or picking Lambda because it is familiar, preserves the box or the timeout.

What to Do This Week

Export the cron entries and Task Scheduler tasks. One line per job: name, duration, dependency.
Mark the band. Leave one-call API wrappers for the Scheduler spoke.
Replace file-polling crons with an arrival event.
Put dependencies in Step Functions. Do not encode them as “start this cron 20 minutes later.”
If the estate is the modernization program, continue with application modernization.

What This Post Doesn’t Cover

It does not price Step Functions transitions, design a fan-out of a million items, or explain EventBridge versus SNS versus SQS. The fan-out comparison is a different article. The one-call Scheduler spoke is a different article. Operations for LMI stay on the LMI guides.

Frequently asked questions

How do we retire a Windows or EC2 box that only runs nightly jobs?

Sort each job by duration. Under 900 seconds can be classic Lambda. From there to 5,400 seconds of asynchronous work can be Lambda Managed Instances. Multi-hour work and array jobs belong on AWS Batch. EventBridge Scheduler starts the run. Step Functions holds dependencies. Rehosting the VM keeps the box.

When should we not put the job on classic Lambda?

When a normal run is longer than 900 seconds, or when the work is a long-running service rather than a job. The 900-second ceiling is the classic Lambda timeout. Crossing it with a retry loop is how the cron server survives.

What could go wrong if file arrival is modeled as a second cron?

The job runs on the clock, finds no file, and exits, or it runs late and processes yesterday. File arrival is an event, not a second schedule. Polling the bucket from the old VM is the pattern this page is trying to delete.

Is this the article about a Lambda that only calls one API?

No. A handler whose only job is one SDK call is the Scheduler spoke. This page is the batch estate: hours, dependencies, and file drops. Do not merge them.

Where do Step Functions patterns stop and this page start?

The patterns post owns workflow shapes. This page owns the choice of compute for a job that used to be a cron entry, and it links that post instead of redrawing it.