How do I reduce my Flink cluster cost without breaking checkpointing?

A Flink cluster's bill doesn't move the way a batch job's does — you're paying for TaskManagers that are up whether or not there's backpressure, and for checkpoints that fire on a timer regardless of how much actually changed. That makes this less about one bad job and more about settings nobody's revisited since launch.

1. Checkpoint interval is the cost knob nobody revisits

Every checkpoint means a full pass through the state backend — for RocksDB, that's disk I/O plus, on a cloud deployment, a batch of PUT requests to whatever object store holds state.checkpoints.dir. An interval set conservatively short during initial rollout, when nobody wanted to risk losing progress on an unproven job, keeps paying that cost indefinitely once the job's been stable for months. Widening execution.checkpointing.interval cuts that recurring cost directly — the trade-off is more data to reprocess on the next failure, so it's worth sizing against actual recovery-time tolerance, not just how short the number can safely go.

2. Parallelism set for the worst day, paid for every day

TaskManager slot count is usually set once, against a peak-load estimate, and left there — so steady-state traffic pays for capacity it isn't using most of the time. Reactive Mode or a platform-level autoscaler can close that gap automatically; even without it, comparing per-subtask backpressure against provisioned slots catches the obvious case: parallelism sized for a spike that happens twice a year, running full-price every day in between.

3. Unbounded state growth inflates checkpoints quietly

Keyed state that's never had a TTL applied grows for as long as the job runs, and every checkpoint has to serialize all of it — so checkpoint duration and storage footprint creep upward over months without any single deploy causing it. Nothing breaks, which is exactly why it goes unnoticed. Applying a TTL that matches how long the business logic actually needs that state is usually a bigger win than it looks, precisely because it's fixing a slow drift, not one bad value.

4. Not every TaskManager is a safe spot-instance candidate

Whether a TaskManager can run on spot capacity comes down to what it's holding: a job that restarts cleanly from its last checkpoint, with recovery-time tolerance wide enough to absorb a preemption, is a safe fit — the same recovery-time budget from lever #1. A job holding large keyed state that takes minutes to rebuild from cold start is a worse candidate, since a preemption there costs more than the compute it saved.