Meyi RunLeanBatch Compute · AWS EC2

Cut the cost of your longest jobs.
Never restart one again.

For platform, HPC and FinOps teams running long batch compute: RunLean checkpoints a running container and resumes it on a right-sized instance. Jobs survive interruptions instead of restarting, and instances match what the job actually uses — not its worst-case peak.

Schedule a Cloud AssessmentHow it works →

Run lean on AWS. Your jobs never restart.

runlean · checkpoint & resumeactive
Job stateCheckpointed
InstanceRight-sized
Restarts0 since enable
Spot eligibleYes — safe
No SDK · No code changes · No restarts▸ 20–35% cost reduction
The problem

You pay for the peak. You use a fraction of it.

Long-running batch compute breaks the usual cost playbook. The instance is sized for the worst minute of the job, and the job can't tolerate being interrupted.
Sized for peak

Jobs are provisioned for peak memory and spend most of their runtime far below it.

Spot is off the table

An interruption loses hours of work, so discounted capacity goes unused.

One OOM, one day gone

A job that fails at hour 20 of a 30-hour run costs a full day of throughput.

How it works

Checkpoint. Move. Resume.

RunLean captures the full state of a running container and restores it elsewhere. To the job, nothing happened.

STEP 01

Job runs

Your container runs unchanged on EC2 — same image, same command, same data paths.

STEP 02

Checkpoint

Memory, processes and open state are captured to durable storage on S3 and EBS.

STEP 03

Move

On interruption or a resize decision, the checkpoint is placed on different capacity.

STEP 04

Resumes right-sized

Work continues from the checkpoint on an instance matched to real usage.

The application is not modified and the job does not restart. No SDK, no code changes, no re-architecting your pipeline. The process resumes from the exact point it was checkpointed.

Inside RunLean

What actually changes on the instance.

Four mechanics, drawn out. Each diagram is illustrative — the Assessment measures these curves against your own workloads.
Mechanic 01

The gap you pay for

A 30-hour job is provisioned for its worst minute. The shaded band is memory you are billed for and never use. RunLean provisions against the actual curve instead of the ceiling.

512G256G00h10h20h30hjob runtimeREQUESTED — sized for peakpeakBILLED, NEVER USED
Requested (what you pay for)Actual memory usedRunLean provisioned
Mechanic 02

What a checkpoint captures

The full execution state is written to durable storage in your own account — then rebuilt on different capacity. The application never learns that it moved.

RUNNING CONTAINERMemory pagesProcess treeOpen files & socketsUnmodified applicationCAPTURECHECKPOINT STATEAmazon S3Amazon EBSYOUR AWS ACCOUNT · YOUR ENCRYPTIONRESTORENEW INSTANCERight-sized to actualResumes mid-executionNO RESTART · NO CODE CHANGE
Mechanic 03

An interruption at hour 20

Without checkpointing, a reclaimed instance costs you everything computed so far. With it, the job picks up where it left off — which is what makes discounted capacity usable at all.

0h10h20h30h40h50hWITHOUT RUNLEAN20h of workINTERRUPTED — WORK LOSTrestarts from zero — full 30h againDONE AT 50hWITH RUNLEAN20h of workCHECKPOINTED · RESUMED ON NEW CAPACITYremaining 10hDONE AT ~30h
Mechanic 04

Stepping down as the job shrinks

Memory demand is not flat across a run. Once a job can move, each phase can sit on the instance it actually needs instead of the one the heaviest phase required.

PHASE 1 · alignmentPHASE 2 · variant callingPHASE 3 · annotationLARGEpeak footprintMOVEMEDIUMlower demandMOVESMALLtail workINSTANCE PROVISIONEDORANGE = MEMORY ACTUALLY USED
Who it's for

Built for the jobs that run for hours.

Single-node, long-running, memory-spiky work — where restarting is expensive and peak-sizing is the only safe option today.

Genomics & NGS secondary analysis

GATKNextflowCromwell

Per-sample variant calling is sized for the largest sample in the cohort. Most samples never approach that ceiling.

CI/CD build farms

Long integration suitesBuild agents

Agents hold large instances for the whole suite while compilation and test phases have very different footprints. Idle headroom is billed all run.

Single-node analytics

pandasRSASMATLAB

Actuarial, clinical and econometric jobs that can't be distributed. One join or pivot sets the memory ceiling for the entire run.

EDA & semiconductor verification

SynthesisPlace-and-route

Multi-hour solves with sharp memory spikes late in the flow. A failure near the end restarts the whole stage.

Quantitative finance batch risk

Overnight VaRXVABacktesting

Overnight windows are fixed and unforgiving. Interruption risk rules out discounted capacity entirely.

CryoEM & structural biology

RELIONcryoSPARC

Refinement runs for many hours with stage-dependent memory. Peak-sized instances sit underused for most of the job.

CFD & FEA simulation

Single-node solvesParametric sweeps

Sweeps launch many long solves of uneven size. Every one is provisioned for the heaviest case.

Savings estimator

See the order of magnitude. Then get real numbers.

Move the inputs to see an indicative annual range for your batch compute. This is a directional model, not a quote.

$40k

Only the portion spent on long-running batch jobs.

12 hours

Longer jobs benefit more — there is more runtime spent below peak, and more work at risk from an interruption.

45%

Roughly what fraction of requested memory the job actually uses on average. Lower utilisation means more recoverable headroom.

Indicative annual range

$44k–$112k

Equivalent to roughly 9–23% of the batch compute spend you entered.

Assumptions used on screen
  • Recoverable headroom is derived from the utilisation you entered — the gap between requested and actual memory.
  • Longer jobs are modelled as capturing more of that headroom, because more runtime sits below peak.
  • The range assumes a portion of the workload becomes eligible for interruptible capacity once jobs no longer restart.
  • No allowance is made for checkpoint storage, data transfer, or engagement fees.
  • Figures are annualised from the monthly spend you entered, with no growth or seasonality.

Indicative only. This is a directional model based on the inputs above — not a measurement of your environment, a quote, or a guaranteed result. Your actual figure depends on your workload mix and instance families.

Schedule a Cloud Assessment

The Assessment replaces this estimate with measured requested-vs-actual figures from your own workloads.

RunLean Assessment

One week. Read-only. Real numbers.

The Assessment is the entry point. We measure requested versus actual memory and CPU across your existing workloads and show you where the headroom is — before any migration is discussed.

What you receive

  • Requested vs. actual memory and CPU, per workload
  • The headroom available on your current instance choices
  • Which workloads are candidates for interruptible capacity
  • A prioritised shortlist ranked by effort against impact

What it requires

  • Read-only access — we make no changes to your environment
  • One week of elapsed time, not a week of your team's time
  • No agent in your application and no code changes
  • A short kickoff call and a walkthrough at the end

What it costs to try

  • Scoped and fixed before we begin — no open-ended engagement
  • The findings are yours whether or not you proceed
  • No commitment to the Platform to run the Assessment
Schedule a Cloud Assessment
Honest fit

Where RunLean fits — and where it doesn't.

Good fit

  • Long-running batch jobs measured in hours, not seconds
  • Single-node workloads that can't easily be distributed
  • Memory-spiky runs where peak sizing wastes most of the runtime
  • Throughput work where completion time matters more than latency

Not a fit

  • Interactive services — anything a user waits on in real time
  • Databases and stateful services with continuous client connections
  • Hard latency SLAs where a resume window is unacceptable
  • Very short jobs — there is no runtime to recover
FAQ

Questions we get from platform teams.

Does my application need to change?+
No. RunLean checkpoints the running container from outside the application. There is no SDK to import, no code to modify, and no change to your image or entrypoint.
What happens on a Spot interruption?+
The job is checkpointed and resumed on other capacity. Work continues from the checkpoint rather than starting over, which is what makes interruptible capacity usable for long jobs in the first place.
Does the job restart?+
No. The process resumes from the exact point it was checkpointed — memory, processes and open state included.
Which workloads are not a good fit?+
Interactive services, databases and stateful services with live client connections, and anything with a hard latency SLA. Very short jobs also see little benefit — there isn't enough runtime to recover. We would rather tell you at the Assessment than after a migration.
Is my data safe?+
Checkpoints are written to storage in your own AWS account, using S3 and EBS with your encryption settings. Your data does not leave your account.
What access do you need for the Assessment?+
Read-only access to metrics and workload configuration. We make no changes to your environment during the Assessment and deploy nothing into your application.
How long does the Assessment take?+
One week of elapsed time. It needs a short kickoff call and a walkthrough of the findings at the end — not a week of your team's attention.
Do I have to commit to the Platform afterwards?+
No. The Assessment is scoped and priced on its own, and the findings are yours whether or not you proceed.
Ready to measure

Find out what your longest jobs are really costing you.

Bring one workload and its instance type. We'll tell you honestly whether checkpointing and right-sizing would change your bill — or whether it wouldn't.

Book a Discovery CallSee Managed Cloud Ops →