Reliable State Flush on Spot Cloud VMs

Confidence-Certified Safe Operating Areas for Deadline-Bounded State Evacuation

Jiasheng Zhuang · Xinghan Chen · Velimir Dedic
Signum Magnum College · University of Washington

IEEE FiCloud 2026 | Jul 21 2026

Motivation

Spot VMs are cheap — until they vanish

💰

up to 90%

cost savings

Spot / preemptible pricing vs. on-demand

⏱

30 – 120 s

warning before shutdown

AWS 120 s · GCP 30 s preemptible

Stateful workloads — notebooks, databases, dev environments — can tolerate restarts. They cannot tolerate losing hours of computation.
Can the machine durably evacuate all relevant state to object storage before shutdown?

0:45–2:00 (75 s)

[POINT to the "up to 90%" card on the left] "Spot and preemptible machines offer dramatic cost savings — up to 90 percent off on-demand pricing. That makes them attractive for any workload that can tolerate interruption.

[POINT to the "30–120 s" card on the right] The trade-off is that the provider may reclaim them with very little warning. AWS normally provides a 120-second interruption notice. GCP's preemptible model gives only 30 seconds in the setting we study.

[PAUSE] That is fine for stateless web workers — they restart elsewhere. But a Jupyter notebook mid-training, a dev environment with uncommitted changes, a database with a write-ahead log — these hold valuable state in memory or on local disk.

[POINT to the takeaway bar at the bottom] For these workloads, downtime is tolerable — you restart the VM. Losing hours of computation or producing a corrupt checkpoint is not.

So the question is concrete: once the warning arrives, can the machine get all that state into object storage before shutdown?"

Key Insight

Averages hide deadline failures

✗ Throughput benchmark

"Average upload speed: 500 MB/s"

Does not tell you whether every part completed, whether one part became a straggler, or whether finalization succeeded before shutdown.

✓ Deadline-bounded completion

"Did the entire end-to-end upload finish before time W?"

Binary outcome. An upload that completes one second after the deadline is a failure, even if the object eventually becomes available.

What matters: tail latency, contention, retries, the slowest outstanding part. For multipart storage, the finalization request must also complete — acknowledging all parts alone does nothing.

2:00–3:10 (70 s)

[POINT to the left panel with the red ✗] "A common way to evaluate storage performance is to report average throughput. 'Average upload speed: 500 megabytes per second' — that sounds good. But average throughput is not enough for this problem.

It does not tell us whether every part completed, whether one part became a straggler that held up the whole upload, or whether the final multipart completion request finished before the machine was terminated.

[POINT to the right panel with the green ✓] For this problem, the relevant metric is binary: did the entire end-to-end operation finish by time W — yes or no? An upload that completes one second after the deadline is a failure, even if the object eventually becomes available in S3.

[POINT to the takeaway bar] Once you adopt this binary metric, what drives outcomes is tail latency, contention, retries, and the slowest outstanding part in a multipart upload. Averages wash all of that out.

One subtlety worth flagging: with S3 or GCS multipart, acknowledging all payload parts is not enough. The final CompleteMultipartUpload call must also return before shutdown, or the object does not exist as a readable object. Our results use end-to-end completion, not payload throughput."

Contribution

The Safe Operating Area frontier

S_max(W, k, P) = largest tested state size certified safe for deadline W, chunk size k, parallelism P

What it gives operators

A concrete configuration-to-safety boundary. If S_max = 12 GiB, then 12 GiB is the largest tested size that passes the certification rule. It does not mean 13 GiB is necessarily unsafe — it may not have been tested.

Research questions

RQ 1 — What frontier do we observe for each provider and deadline?

RQ 2 — Which tuning knob moves the frontier more: chunk size or parallelism?

↓operational workflow

3:10–4:00 (50 s)

[POINT to the equation] "We formalize this using the Safe Operating Area frontier. For a fixed warning window W, chunk size k, and parallelism P, the frontier S-max is the largest tested state size that remains certified safe.

[POINT to the left column — 'What it gives operators'] Say S-max comes out to 12 GiB. That means 12 GiB is the largest state size on our grid that passes certification. It does not mean 13 or 14 GiB would fail — we may not have tested them. The boundary is conservative by design.

[POINT to the right column — research questions] Two questions drive the paper. [CLICK to reveal RQ1] What frontier do we observe for each provider and deadline? [CLICK to reveal RQ2] And which control moves it more — chunk size or parallelism?

[POINT to the down arrow] The next slide shows how operators would actually use the frontier."

Contribution

How operators use the frontier

The SOA produces a measure → cache → admit workflow that can be reused across deployments.

Measure

Periodically benchmark provider,
region, and instance family

→

Cache

Store the resulting frontier
as an admission-control table

→

Admit

On warning: compare state size
vs. cached frontier

When a revocation warning arrives, the system checks the amount of state that must be evacuated and selects a chunk size and parallelism that remain inside the conservative boundary — or rejects transient execution if the state lies outside the frontier.

4:00–4:40 (40 s)

[POINT to step 1] "Operationally, the SOA produces a three-step workflow. First, you periodically benchmark your provider, region, and instance family — just as you would benchmark disk I/O on a new machine.

[POINT to step 2] Second, you cache the resulting frontier as an admission-control table. This is a static lookup — it does not need to be recomputed on every warning.

[POINT to step 3] Third, when the revocation warning actually arrives, the system compares the amount of state that must be evacuated against that cached frontier. If the state fits, proceed with the upload using the certified configuration. If it does not fit, the system knows in advance that evacuation is unlikely to succeed.

[POINT to the takeaway] The key point is that this is reusable — you build the table once, update it periodically, and consult it on every warning."

Methodology

Experimental setup & certification rule

Setup

Real AWS and GCP VMs, writing to same-region provider object storage
State sizes: 4, 8, 12, 16 GiB
Chunk sizes: 8, 16, 64 MiB
Parallelism: 10, 16, 64 threads
Deadlines: 30, 60, 120 seconds

25.7 M part upload attempts · 37.6 K runs · 6 regions · 5 instance families

Success = entire end-to-end completion (incl. multipart finalization) before deadline W.

Certification

Each run is a Bernoulli trial — a coin flip: did the upload finish in time, yes or no?

From those flips, compute a Wilson lower confidence bound — a pessimistic estimate of the true success rate, accounting for limited sample size.

Certified safe only when that pessimistic estimate ≥ 95%

Frontiers are computed separately per deployment segment (a region + instance family combination). We report the median frontier (the middle segment — typical capacity) and the worst-segment frontier (the unluckiest segment — how much you can safely count on everywhere).

↓what "certified-safe" means

4:40–5:30 (50 s)

[POINT to the left column — Setup] "We ran experiments on real AWS and GCP virtual machines, writing directly to same-region provider object storage. Keeping storage in the same region is important — it avoids turning this into a cross-region WAN study.

[GESTURE across the bullet list] We varied three major controls: state sizes from 4 to 16 GiB, multipart chunk sizes of 8, 16, and 64 MiB, and upload parallelism of 10, 16, and 64 threads.

[POINT to the dataset scale box] In total: 25.7 million part upload attempts, 37.6 thousand runs, across 6 regions and 5 instance families. Each run counts as successful only if end-to-end completion — including multipart finalization — occurred before the deadline.

[POINT to the right column — Certification] For certification, we treat each run as a coin flip — did the upload finish before the deadline, yes or no? That is a Bernoulli trial. Then we ask: given these coin flips, what is the worst-case success rate we can confidently claim? That is the Wilson lower confidence bound. If that pessimistic estimate reaches 95 percent, we call the configuration certified safe."

Methodology

What "certified-safe" means

Deliberately conservative

We do not use the raw observed success rate. If 19 out of 20 runs succeed, the observed rate is 95% — but with only 20 samples, the true rate could be lower. The Wilson lower bound accounts for that sample uncertainty, giving us a pessimistic estimate that must still exceed 95%.

A small number of deadline misses — or insufficient evidence — can prevent certification.

Outside the SOA ≠ proven impossible

A point outside the Safe Operating Area is not necessarily proven to fail. It means we do not have sufficiently strong evidence to recommend it as safe.

The rule is deliberately harsh: limited evidence or a small number of misses can prevent a cell from being called safe.

Finalization matters. For multipart storage, acknowledging all payload parts is not sufficient — the final completion request must also finish before the deadline so the object exists as a normal readable object. Our primary results use end-to-end completion, not payload throughput alone.

5:30–6:20 (50 s)

[POINT to the green panel] "We do not use the raw observed success rate. If you see 19 out of 20 successes, that is 95 percent observed — but with only 20 trials, the true rate might be 85 percent and you got lucky. The Wilson lower bound asks: given this sample size, what is the worst the true rate plausibly is? That pessimistic number must exceed 95 percent.

So a few deadline misses — or just too few runs — can prevent certification. The rule is harsh on purpose.

[POINT to the red panel] So a point outside the SOA is not proven impossible. We just lack strong enough evidence to call it safe. We would rather under-certify than over-certify.

[POINT to the takeaway] Also note: with S3 and GCS multipart, acknowledging all payload parts is not enough — the CompleteMultipartUpload call must also return before the deadline. Our results use end-to-end completion, not payload acknowledgment."

RQ 1 — Results

The certified frontier: GCP dominates AWS

GCP at 30 s reaches 14 GiB — larger than AWS at 120 s (12 GiB). Not a universal claim; result for these instance types, regions, and campaigns.

6:20–7:40 (80 s)

"These four heatmaps are the core result. Each cell shows the certified frontier for one (chunk-size, parallelism) combination.

[POINT to top-left heatmap — AWS 60s] Top left: AWS, 60-second budget. Every cell is 4 GiB. All nine configurations collapse. Tuning cannot recover capacity here — 60 seconds is too short for AWS.

[POINT to top-right heatmap — AWS 120s] At 120 seconds, AWS opens up. [TRACE the gradient across cells] Values range from 4 to 12 GiB. Configuration starts to matter, but the spread is wide — choosing wrong costs you 8 GiB of headroom.

[POINT to bottom-left heatmap — GCP 30s] GCP with only 30 seconds. [TRACE the bright cells] Frontiers range from 0 to 14 GiB. The bright cells cluster in the upper right — large chunks, lower parallelism.

[POINT to bottom-right heatmap — GCP 60s] At 60 seconds, GCP saturates nearly the entire grid.

[CLICK to reveal takeaway] The comparison to notice: GCP's best at 30 seconds certifies more state than AWS's best at four times the deadline. [PAUSE] This is for the instance types, regions, and campaigns we tested — not a general provider ranking."

Evidence — Part-Upload Tail Latency

Why the frontier diverges: tail structure

CCDF = "what fraction of uploads took longer than x seconds?" — higher means more slow uploads.

AWS tail extends to ~100 s

GCP tail cuts sharply at ~20 s

AWS p99 ≈ 43–49 s vs. GCP p99 ≈ 4–5 s — an order-of-magnitude gap in tail risk. DKW bands (shaded) = sampling uncertainty around each curve; ~25.7 M observations.

7:40–8:50 (70 s)

"Why does GCP dominate those heatmaps? These plots answer that. Each curve shows: for any latency threshold on the x-axis, what fraction of part uploads took longer than that? So a curve that stays high far to the right means lots of slow uploads.

[POINT to the AWS plot on the left] On AWS, the curve stays elevated past 100 seconds. The p99 — the latency that only 1 percent of uploads exceed — sits around 43 to 49 seconds. A single part can eat almost the entire 120-second deadline.

[POINT to the GCP plot on the right] On GCP, the curve drops off sharply around 20 seconds. The p99 is 4 to 5 seconds — an order of magnitude lower.

[GESTURE across both plots] The shaded bands are DKW confidence intervals — they show how much the curve could shift given sampling uncertainty. With 25.7 million observations, they are very tight. [PAUSE] This gap is not noise.

[CLICK to reveal takeaway] That tail gap is what lets GCP certify larger states under shorter deadlines."

Evidence — Goodput Regimes

Upload speed regimes: fast, slow, degraded

A Hidden Markov Model automatically classifies each moment of an upload into one of three speed states.

GCP sustains ~600 MB/s goodput vs. AWS ~80 MB/s. Green = fast, yellow = slow, red = degraded. Classified automatically by a 3-state HMM.

8:50–9:45 (55 s)

"Same mechanism, now at the individual-run level. We used a Hidden Markov Model — essentially an algorithm that watches the upload speed over time and labels each moment as 'fast,' 'slow,' or 'degraded' based on the observed throughput pattern.

[POINT to green regions in the figure] Green is fast — peak throughput.

[POINT to yellow and red regions] Yellow is slow, red is degraded. [TRACE the AWS line] On AWS, frequent transitions into yellow and red — these are the same stragglers showing up in the CCDF tail.

[POINT to GCP portion of the figure] GCP stays predominantly green: around 600 megabytes per second sustained, versus roughly 80 on AWS. A 7x gap.

[CLICK to reveal takeaway] These regime switches explain why AWS needs four times the deadline to certify smaller state sizes."

RQ 1 — Typical vs. Robust

Median and worst-segment frontiers

Provider	W (s)	Best-median config	Median S_max	Worst-seg S_max	Role
AWS	120	P=10, k=16	12 GiB	0 GiB	Best typical
AWS	120	P=16, k=64	10 GiB	4 GiB	Only robust config
GCP	30	P=10, k=64	14 GiB	8 GiB	Best typical & robust
GCP	60	P=10, k=64	16 GiB	16 GiB	Saturates grid

↓interpretation

RQ 1 — Typical vs. Robust

Two very different operating postures

AWS gives two answers

Best typical capacity = 12 GiB, but zero worst-segment guarantee. The only robust config (positive worst-segment) drops to 4 GiB.

The operator must choose: maximize typical capacity, or plan around adverse observed conditions and accept lower capacity.

GCP aligns typical and robust

Even at 30 s, its best config offers 8 GiB in the weakest segment. At 60 s, the frontier saturates the test grid at 16 GiB.

Best-median and worst-segment configs are the same.

The gap between median and worst-segment is itself a finding: it measures how much an operator must sacrifice for guaranteed coverage.

RQ 1 — Reliability near the boundary

State size is a threshold, not a dial

Fraction of segments certified safe as state size increases — best config per provider

AWS W = 120 s (P=10, k=16)

GCP W = 30 s (P=10, k=64)

The cliff: AWS drops from 64% → 0% between 12 and 16 GiB. GCP retains 50% at 16 GiB. A 4 GiB increase near the boundary flips the outcome.

11:10–12:20 (70 s)

"A single frontier number can hide how fast reliability drops near the boundary. These bars show what happens as state size grows.

[POINT to the AWS bars on the left] Best AWS config — parallelism 10, 16 MiB chunks, 120 seconds. [TRACE downward along the bars] 91 percent of segments safe at 4 GiB, 73 at 8, 64 at 12. [POINT to where 16 GiB bar would be] At 16 GiB — zero.

[GESTURE — 'cliff' motion] That is a cliff, not a gradual rolloff.

[POINT to the GCP bars on the right] GCP at 30 seconds — [TRACE the bars] all segments certified through 8 GiB, 63 percent at 12, half at 16. The degradation is smoother.

[CLICK to reveal takeaway] [POINT to the takeaway] State size behaves as a threshold. Going from 12 to 16 GiB on AWS flips the result from 'most segments pass' to 'no segments pass.' That 4 GiB increment is where the operating regime changes character."

RQ 2 — Results

The dominant tuning knob is regime-dependent

AWS W = 120 s

Parallelism effect on median frontier

8 GiB

Chunk-size effect on median frontier

4 GiB

Parallelism is the stronger lever

GCP W = 30 s

Chunk-size effect on median frontier

12 GiB

Parallelism effect on median frontier

0 GiB — no median effect

Chunk size is the stronger lever

Advice such as "always increase concurrency" is unsafe. The useful control depends on the provider, the deadline, and the operating regime.

12:20–13:30 (70 s)

"Which tuning knob moves the frontier more — chunk size or parallelism? It depends on where you are operating.

[POINT to the AWS panel on the left] AWS at 120 seconds: [POINT to the parallelism bar] parallelism shifts the median frontier by 8 GiB, [POINT to the chunk-size bar] chunk size by 4. [CLICK to reveal verdict] Parallelism wins here.

[POINT to the GCP panel on the right] GCP at 30 seconds — reversed. [POINT to the chunk-size bar] Chunk size shifts the frontier by 12 GiB. [POINT to the parallelism bar] Parallelism has zero median effect. [CLICK to reveal verdict] Chunk size wins.

[CLICK to reveal takeaway] [POINT to the takeaway] If you follow the usual advice — 'maximize concurrency for faster uploads' — you may be making things worse on AWS under deadline pressure, and wasting your tuning budget on GCP. The right knob depends on the regime."

RQ 2 — Mechanism

Why the tuning advice changes

AWS — Straggler exposure

Multipart completion cannot finish until every required part has completed. Higher concurrency increases exposure to slow outstanding parts.

p95 slowest-part time (95% of uploads had a slowest part faster than this):

P=10 → ~13 s P=64 → ~65 s

Fail rate climbs steadily: 37% → 58% as parallelism increases — more threads, more exposure to a slow part.

GCP — Chunk-throughput leverage

Larger chunks translate more strongly into useful end-to-end throughput on GCP in the tested regime.

p95 throughput at 16 GiB (95th percentile):

~696 MiB/s (best config)

The short-window frontier responds strongly to chunk efficiency rather than thread count.

Concurrency controls reliability, not just throughput. We observe the association; we do not claim a specific provider-internal cause.

13:30–14:50 (80 s)

"Why does the dominant knob differ? Two different failure modes.

[POINT to the AWS panel on the left] On AWS: straggler exposure. Multipart completion waits for every part. [POINT to the p95 numbers] The p95 of the slowest part goes from ~13 seconds at parallelism 10 to ~65 seconds at parallelism 64.

[CLICK to reveal the failrate chart] [POINT to the failrate chart] And the deadline failure rate tracks that: 37 percent at P=10, monotonically up to 58 percent at P=64. More threads, more exposure to a slow request that blocks finalization.

[POINT to the GCP panel on the right] On GCP the story is different. [POINT to the throughput number] Larger chunks convert more efficiently into end-to-end throughput — 696 MiB per second at 16 GiB in the best config. The bottleneck is per-chunk overhead, not stragglers.

[CLICK to reveal takeaway] [POINT to the takeaway] A caveat: we observe the association, we do not claim a specific internal throttling mechanism. But concurrency clearly acts as a reliability control, not just a throughput dial."

Validity

Do the conclusions hold up?

Swapping Wilson for Clopper–Pearson (a stricter way to compute the same confidence bound) changed 0 / 163 segment frontiers.
Enforcing monotonicity — requiring that giving more time never shrinks the frontier — changed 0 / 18 configurations.
Raising the threshold above 95% shifts individual frontiers, but qualitative conclusions hold.

AWS remains more constrained and configuration-sensitive. GCP remains more forgiving. The dominant tuning control remains regime-dependent.

14:50–15:50 (60 s)

"Are these conclusions artifacts of our statistical choices? Three checks.

[POINT to the first bullet] Swapping Wilson for Clopper–Pearson — a stricter interval. [POINT to '0/163'] Zero of 163 segment frontiers changed.

[CLICK to reveal second bullet] [POINT to second bullet] Enforcing monotonicity — a larger budget should never shrink the frontier. [POINT to '0/18'] Zero of 18 configurations changed. The data already satisfies this.

[CLICK to reveal third bullet] [POINT to third bullet] Raising the threshold above 95 percent shifts individual numbers, as expected, but does not change which provider or which knob dominates.

[CLICK to reveal takeaway] [POINT to the takeaway] AWS stays more constrained, GCP stays more forgiving, tuning stays regime-dependent. The conclusions survive all three perturbations."

Summary

Takeaways

Deadline-bounded state evacuation is a reliability problem. Throughput benchmarks miss the failure modes.

The SOA frontier gives operators a lookup table: given (provider, deadline, config), how large can the state be?

GCP certifies 14 GiB at 30 s; AWS certifies 12 GiB at 120 s with a cliff at the boundary.

Tuning guidance is regime-specific. Parallelism dominates AWS at 120 s; chunk size dominates GCP at 30 s.

Future work

Checkpoint creation overhead Serialization cost Restart-time measurement Additional providers Alternative storage paths

15:50–17:00 (70 s)

"Four things to take away.

[POINT to card 01] State evacuation under a deadline is a reliability problem. Average throughput does not tell you whether the upload finishes in time.

[CLICK to reveal card 02] [POINT to card 02] The SOA frontier turns that into a reusable lookup — given provider, deadline, and config, what state size is certified safe?

[CLICK to reveal card 03] [POINT to card 03] [GESTURE between the provider numbers] GCP certifies 14 GiB at 30 seconds; AWS certifies 12 GiB at 120 seconds, with a cliff at the boundary.

[CLICK to reveal card 04] [POINT to card 04] And which knob to turn depends on the regime. Parallelism on AWS, chunk size on GCP.

[CLICK to reveal future work] [POINT to the pills] What we have not covered yet: the cost of creating the checkpoint itself, serialization overhead, restart time, and additional providers."

A confidence-certified Safe Operating Area tells us how much state can be flushed before a spot VM disappears.

GCP · 30 s

14 GiB

median frontier / 8 GiB worst-segment

AWS · 120 s

12 GiB

median frontier / 0 GiB worst-segment (best median config)

Failure near the boundary behaves like a cliff. The correct tuning decision depends on the operating regime.

Thank you. Questions?

jiasheng.zhuang@smc.college

17:00–17:30 (30 s)

[PAUSE — let the audience absorb the final slide]

"One sentence: a confidence-certified SOA tells you how much state can be flushed before a spot VM disappears.

[POINT to the GCP number] 14 GiB on GCP under 30 seconds. [POINT to the AWS number] 12 GiB on AWS under 120 seconds.

And near the boundary, reliability drops as a cliff — the tuning decision that matters depends on the regime.

Thank you. I welcome your questions."

Q&A Backup Answers:

"Why use a 95% lower bound instead of observed success rate?"
"If you flip a coin 20 times and get 19 heads, the observed rate is 95% — but you would not bet your production system that this coin lands heads 95% of the time. The Wilson lower bound asks: given this sample size, how low could the true rate plausibly be? We require that pessimistic number to still exceed 95%."

"Does S-max mean every size below it is guaranteed safe?"
"Only on the tested grid and under the stated certification rule. We optionally enforce monotonicity, but this is an empirical certified boundary, not an absolute provider guarantee."

"Why is GCP faster despite the shorter warning?"
"We do not claim a single universal cause. In our measurements, larger chunks translated more effectively into end-to-end throughput on GCP, while AWS showed a heavier straggler tail. The CCDF plots quantify this — AWS p99 is 43-49 seconds, GCP p99 is 4-5 seconds."

"Why not continuously checkpoint instead of flushing after warning?"
"Continuous checkpointing is complementary. This work addresses workloads that retain opaque or local state — think closed-source applications or notebooks — and asks about the final survivability boundary after a warning arrives."

"Can these results be generalized to every region and instance type?"
"The methodology generalizes; the numerical frontiers must be measured for each deployment. Different regions, instance families, storage paths, and client implementations will yield different frontiers — that is exactly why we propose the measure-cache-admit workflow."

"How do you handle the cost of running these benchmarks?"
"The benchmarks use spot instances themselves, so the measurement cost is low. The total dataset — 25.7 million part uploads — was collected over multiple campaigns, not a single expensive run."