The full answer
Batch processing handles data collected over a period in one run, such as last night's orders; stream processing handles each event within seconds of it arriving, such as a card payment checked for fraud.
| Batch | Stream | |
|---|---|---|
| Input | A bounded set of data | An unbounded flow of events |
| Runs | On a schedule or trigger | Continuously |
| Latency | Minutes to hours | Milliseconds to seconds |
| Typical work | Daily reports, large joins, backfills | Alerts, live dashboards, fraud checks |
| Cost profile | Pay only while the job runs | Always-on capacity |
AWS services for batch
- AWS Glue: serverless Spark jobs for ETL, with the Data Catalog.
- Amazon EMR (on EC2, on EKS or Serverless): Spark, Hive and Trino when you need more control.
- Amazon Athena and Amazon Redshift: SQL transformations over S3 or warehouse tables.
- AWS Batch: containerised batch jobs that are not Spark.
- AWS Step Functions or Amazon MWAA (managed Airflow) to orchestrate them.
AWS services for streaming
- Amazon Kinesis Data Streams and Amazon MSK (managed Kafka) to carry the events and keep them for replay.
- Amazon Managed Service for Apache Flink for stateful processing such as windows and joins over streams.
- AWS Lambda, reading from Kinesis, MSK or SQS through an event source mapping, for simple per-event logic.
- Amazon Data Firehose to deliver streams into S3, Redshift, OpenSearch or Iceberg tables.
- AWS Glue streaming ETL and Spark Structured Streaming on EMR for micro-batch streaming.
The line between them is blurring. Spark Structured Streaming runs the same code as a stream or as a scheduled batch over new data, and many teams land a stream in S3 and process it in small, frequent batches because that is cheaper and simpler than true streaming. The deciding question is how fresh the result must be: if minutes are fine, frequent batches usually win; if a decision must be made within seconds of an event, stream it.
Last updated 16 October 2026
Sources