Step Functions vs Airflow — and Using Both
Airflow is a scheduler and dependency manager; Step Functions is a durable AWS-native state machine. Here is how to split responsibilities.
AWSIntermediate3 min readUpdated 11 Oct 2026
AWSWhat each is good at
| Apache Airflow | AWS Step Functions | |
|---|---|---|
| Model | DAGs of Python-defined tasks | JSON/YAML state machines (ASL) |
| Strength | Scheduling, backfills, cross-system dependencies, rich operator ecosystem | Durable, serverless coordination of AWS services with built-in retries and .sync integrations |
| Runs where | Your scheduler + workers (or MWAA / Astronomer) | Fully managed |
| State | Metadata database | Execution history (Standard workflows keep up to 90 days) |
| Cost model | Infrastructure | Per state transition (Standard) |
A clean split
Who does what
Airflowdecides when
Step Functionscoordinates AWS
Glueextract + transform
Lambdavalidate + lock
Snowflakepublish
Let Airflow decide when, and let Step Functions decide how inside AWS:
Sequence diagramSwipe to explore →Technical diagram
Rendering sequence diagram
start = StepFunctionStartExecutionOperator(
task_id="start", state_machine_arn=STATE_MACHINE_ARN,
state_machine_input={"batch_id": "{{ ds_nodash }}"})
wait = StepFunctionExecutionSensor(
task_id="wait", execution_arn=start.output, mode="reschedule", poke_interval=30)
start >> waitRules that keep it safe
- Pass IDs and configuration, never data rows, through orchestration state
- Make every task idempotent — retries will happen
max_active_runs=1only protects runs started by that DAG; use a real lock if anything else can start the workflow- Notification failures must never trigger a republish
Finished this note?