An AWS Step Functions Standard execution failed near the end of a long workflow after a downstream outage. What does redriving that execution do, and when is an execution not eligible for it?

## The problem redrive solves Before redrive existed, a Standard execution that failed at step twelve of fifteen left you with two bad options. Start a new execution from the beginning and re-run the eleven expensive, already-successful steps — duplicating their side effects, paying for their state transitions again, and possibly re-charging a customer. Or hand-craft a second state machine that begins at the failure point and feed it a reconstructed payload, which is exactly the kind of one-off operational script that rots. Redrive replaces both. Introduced in November 2023, it restarts a failed execution **from its first unsuccessful state**, with the input that state originally received. ## What it actually does - **Skips successful work.** Every state that already succeeded stays succeeded. Only the failed state and everything after it runs. - **Keeps identity.** The redriven run reuses the same state machine ARN, execution ARN and execution name. This matters more than it first appears: any idempotency key derived from the execution — the context object exposes `$$.Execution.Name` — is stable across a redrive, so downstream deduplication keeps working. - **Appends to the same history.** The new events land in the existing execution history rather than a separate one, so the whole story of the attempt stays in one place. `DescribeExecution` reports how many times the execution has been redriven and when it last was. - **Works on partial failures too.** A `Map` run whose child executions partially failed can be redriven so only the failed items re-run, rather than the whole batch. You trigger it with the `RedriveExecution` API, from the CLI, or with the Redrive button in the console on a failed execution. ## When it is not available This is the half interviewers actually probe, because it constrains architecture: 1. **Standard workflows only.** Express workflows are not redrivable. Express executions do not retain the durable, per-state execution history that redrive resumes from — one of the concrete reasons the Standard-versus-Express choice is not purely about cost and duration. 2. **The execution must have ended unsuccessfully** — failed, aborted, or timed out. A successful execution is not redrivable; there is nothing to resume. 3. **There is a time window.** Redrive is available for a bounded period after the execution ended — 14 days as of 2025. Beyond that the execution is no longer eligible, and `DescribeExecution` reports its redrive status accordingly. Check that status programmatically rather than assuming, because it also tells you when an execution can only be redriven through its parent Map run. ## What redrive is not Redrive re-runs the *same work* on the assumption that the reason it failed has been removed — a dependency that was down is back, a permission that was missing has been granted, a quota has been raised. It is an operational recovery tool, not a deployment mechanism: if the workflow's own logic was wrong, the honest move is to fix the definition and start a fresh execution, because the failed one was doing the wrong thing, not the right thing at the wrong time. Nor is it a substitute for designing failure paths. Retriers still handle transient errors inside a single execution, catchers still route to compensating branches, and both operate automatically at machine speed. Redrive is the manual, human-in-the-loop layer above them, for the case where automated handling correctly gave up because the problem was outside the workflow's power to solve. ## Operating with it The practical pattern is: catchers route irrecoverable failures to a state that records enough context to diagnose them and then fails the execution deliberately; an alarm on failed executions brings a human in; the human fixes the external cause and redrives the affected executions, possibly in bulk from a list of failed execution ARNs. Because redrive preserves identity and skips completed work, that bulk recovery is safe to run even against executions that got most of the way through — which is precisely what makes it worth designing for rather than discovering during an incident.