In this article
Interruption notices supplement a restartable application; they should not be the first opportunity to save all progress. Measure recovery before comparing complete costs.
A GPU workload on AWS Spot should continue after losing its instance. Save progress regularly outside temporary compute state and test a new launch. An interruption notice is useful, but it should not be the only occasion on which important work is preserved.
Define what can be repeated
Spot uses spare EC2 capacity that may be reclaimed. The application must tolerate pauses and restoration. One uninterrupted run does not establish that property.
Choose a unit of repeatable work: an independent input file, a completed block or a defined calculation checkpoint. Describe exactly which files and parameters continuation needs. The word checkpoint is insufficient if the new process still depends on variables available only in the old session.
Use notices as an additional signal
The documentation provides interruption information through EventBridge and instance metadata on a best-effort basis. Stop and termination have a short warning mechanism, while hibernation has different timing behaviour.
Keep the handler simple: stop accepting new work, finish an allowed small step and preserve state. Do not expect the final warning window to accommodate the first full dataset export or an unknown amount of process memory. Regular saves remain the main resilience mechanism.
Test an independent-job workflow
For a document collection, save results by input identifier and processing version, with a separate completion record. After a restart, select missing or explicitly failed items.
| Test | Required behaviour |
|---|---|
| Repeated item | No unnoticed duplicate output |
| Partial file | Not counted as completed |
| Lost process | Progress remains outside its memory |
| New instance | Reads progress and continues |
| Missing warning | Latest regular save is still usable |
This tests application architecture rather than a particular language model. Save the checkpoint ID and accepted-result count so the report shows whether continuation really occurred or the task silently restarted from the beginning.
Verify storage and recovery cost
Determine what survives the selected interruption action. For EBS, check deletion settings and placement; for external storage, confirm role access and completed writes. A local filename alone does not prove independence.
Keep code version, configuration and inputs with the saved state to avoid mixing incompatible runs. In a bounded pilot, deliberately stop and restore the task, measuring loading, repeated work and integrity. Only then compare complete Spot expense with an alternative under the same useful-result definition.
Turn the check into a practical next step
Interruption notices supplement a restartable application; they should not be the first opportunity to save all progress. Measure recovery before comparing complete costs.
For the documented details, consult the primary documentation; configuration reference. Continue with aws gpu vcpu quota workflow and aws gpu ebs after termination.