Longer than 15 minutes: Fargate, durable functions or Managed Instances?

The short version

Running for a week isn't staying alive for a week

Two different things hide behind "long-running". A durable job is logically running for days but only uses compute in short bursts: it saves its progress after each step, stops, and resumes later, so a pause of a week costs nothing. A long process stays alive the whole time: a migration copying millions of rows, a video render, a batch of model calls holding state in memory.

Durable functions are built for the first. Fargate is built for the second. Most confusion comes from forcing one into the other: chopping a three-hour import into 15-minute Lambda pieces with their own checkpoints, or keeping a container up for a day to wait on someone's approval.

The lean Fargate setup, when the end time isn't known

Nothing has to stop Fargate when the job ends. EventBridge Scheduler starts one standalone ECS task on a schedule, the container runs the job, the process exits, and the task stops: Fargate bills per second from the image pull to the stop, with a one-minute minimum. No Lambda, no state machine, no "stopper".

Seven rules make that safe:

1. A standalone task, never an ECS service. A service keeps a set number of copies running: when your job finishes, it starts another.
2. One essential container, nothing else that runs forever. Send logs straight to CloudWatch with the awslogs driver, without a sidecar. An essential sidecar that never exits keeps the task, and the bill, alive.
3. The process must exit. Node.js stays alive while anything is open: a database pool, a timer, a socket. End the job with a clean shutdown and process.exit(code), 0 on success and anything else on failure.
4. A kill switch, because ECS has no maximum run time. Start the job through timeout: after 10 hours it sends SIGTERM, two minutes later a kill. Under the 12-hour gap between runs, two runs can never overlap. A run killed this way exits with code 124.
5. No NAT gateway. A public subnet, a public IP and a security group with no inbound rules. The address bills only while the task runs, about $0.005 an hour; a NAT gateway bills every hour of the month.
6. An alert when it goes wrong. The schedule only knows that RunTask was accepted. An EventBridge rule on ECS task state changes (STOPPED with a non-zero exit code) catches a crash, the timeout kill and a task that never started.
7. Regular Fargate, not Spot, for a job whose end you don't know. Spot can stop it with two minutes' notice, so it's only for jobs that save their progress and resume.

In Pulumi, everything is in @pulumi/aws:

const cluster = new aws.ecs.Cluster("jobs");
const logs = new aws.cloudwatch.LogGroup("job", { retentionInDays: 30 });

const task = new aws.ecs.TaskDefinition("job", {
  family: "long-job",
  requiresCompatibilities: ["FARGATE"],
  networkMode: "awsvpc",
  cpu: "2048",
  memory: "4096",
  runtimePlatform: { cpuArchitecture: "ARM64", operatingSystemFamily: "LINUX" },
  executionRoleArn: executionRole.arn, // pulls the image, writes the logs
  taskRoleArn: jobRole.arn,            // what the job itself may touch
  containerDefinitions: pulumi.jsonStringify([{
    name: "job",
    image: imageUri,
    essential: true,
    // Kill switch: SIGTERM after 10 h, SIGKILL 2 min later. Under the 12 h gap, so runs never overlap.
    command: ["timeout", "-k", "120", "36000", "node", "dist/job.js"],
    stopTimeout: 120,
    logConfiguration: {
      logDriver: "awslogs",
      options: { "awslogs-group": logs.name, "awslogs-region": region, "awslogs-stream-prefix": "job" },
    },
  }]),
});

new aws.scheduler.Schedule("job-twice-daily", {
  scheduleExpression: "cron(0 6,18 * * ? *)",
  scheduleExpressionTimezone: "Australia/Sydney",
  flexibleTimeWindow: { mode: "OFF" },
  target: {
    arn: cluster.arn,
    roleArn: schedulerRole.arn, // ecs:RunTask on the task definition, iam:PassRole on both roles
    retryPolicy: { maximumRetryAttempts: 3 },
    ecsParameters: {
      taskDefinitionArn: task.arn,
      launchType: "FARGATE",
      networkConfiguration: { subnets: publicSubnetIds, securityGroups: [noInboundSg.id], assignPublicIp: true },
    },
  },
});

// A crash, the timeout kill (exit 124) or a task that failed to start: send it to an SNS topic you're subscribed to.
new aws.cloudwatch.EventRule("job-failed", {
  eventPattern: pulumi.jsonStringify({
    source: ["aws.ecs"],
    "detail-type": ["ECS Task State Change"],
    detail: { clusterArn: [cluster.arn], lastStatus: ["STOPPED"], containers: { exitCode: [{ "anything-but": 0 }] } },
  }),
});

The timeout form with seconds works with coreutils (Debian-based node:*-slim images) and recent BusyBox (Alpine). The schedule avoids 2 to 3 am, the hour Sydney skips the night daylight saving starts.

What it costs: 2 vCPU and 4 GB on Arm in Sydney is $0.09474 an hour. A job of about 2.5 hours twice a day is about 150 hours a month: about $15, plus about $0.75 for the public address and a few cents of logs and image storage. Nothing between runs.

If you'd rather have a timeout built in than the timeout wrapper, AWS Batch on Fargate has job timeouts and retries. It costs three more resources (a compute environment, a job queue, a job definition) for what one word in the command does, so I'd only reach for it once there are many such jobs.

Durable functions, when the job mostly waits

When the long part is waiting (an approval, a partner's callback, a rate limit to wait out), a container that stays up to wait is the wrong tool. A durable function saves each completed step, suspends during context.wait() or waitForCallback() without compute charges, and resumes on the next line days later. Each invocation still stops at 15 minutes, so any one step must fit inside that. The rules of replay, and the comparison with Step Functions, are in Durable functions or Step Functions?.

The two combine well. The durable function runs the workflow, starts a Fargate task for the step that needs an hour of CPU, and waits on a callback; the task's last act is to call that callback with its result.

Why not Managed Instances and their 90 minutes

Since 9 September 2026, Lambda Managed Instances allow a 90-minute timeout. Read the small print first: only asynchronous and event-source calls get it (synchronous calls and the init phase stay at 15 minutes), and the instances behind it don't scale to zero, three by default, around the clock. For a job twice a day, that's paying for machines all day to run them for three hours. Behind SQS it also means a visibility timeout of at least six times the function timeout: nine hours for a 90-minute function.

It only makes sense for a large, steady, event-driven Lambda that already runs that long and that a team won't rewrite as a container. For anything new, a Fargate task has no limit at all and bills nothing between runs.

Fargate or Trigger.dev?

Trigger.dev runs long TypeScript tasks on its own machines, with retries, free pauses and live progress built in. Here is the same work on both: Fargate at Sydney Arm rates plus the public address, Trigger.dev at its published prices.

On raw compute Fargate always wins. Trigger.dev only wins when Fargate is left up through a wait, and on AWS a durable function does that waiting for free.

What Trigger.dev does that Fargate doesn't, without building it:

• Pauses mid-job with the process saved, resuming on the next line with its variables. Only its own waits are free; an ordinary await on an API is still billed.
• Live progress in the app: status, metadata and even an LLM's output streamed from the task to the browser.
• Starts in a fraction of a second (100 to 300 ms warm, its own figure) against 30 to 90 seconds for a Fargate task: what matters behind a button.
• Retries, history and a dashboard per run, with reruns from the dashboard, queues with limits per customer, and preview environments per branch.

What Fargate does that Trigger.dev doesn't: the code and the data stay in the client's AWS account, in Sydney, with an IAM role and direct access to the private database. It goes up to 16 vCPU, 120 GB and 200 GB of disk, runs any language or binary as it is, is in Pulumi officially, and has no plan cap on concurrent runs.

That's why it's a skip for me. For a startup that isn't on AWS and starts its jobs from an app, Trigger.dev's plumbing is worth its price.

And Inngest?

Inngest isn't compute: it orchestrates steps in code that runs on your own hosting, with the same replay model as durable functions. On Lambda, each step still stops at 15 minutes, so it doesn't solve a long process either. Its strengths are flow control per tenant and its dashboard, and it fits apps that aren't on AWS.

Sources, checked on 30 October 2026: Fargate pricing, scheduling ECS tasks with EventBridge Scheduler, the 90-minute timeout on Lambda Managed Instances, AWS Compute Blog on the 90-minute timeout, Lambda durable functions, Trigger.dev pricing, Trigger.dev v4, Inngest pricing.