Serverless Data Processing: Wann es funktioniert, wann nicht

Serverless ist eines der überstrapaziertesten Konzepte im Data Engineering. Das Versprechen — unendliche Skalierung, null Ops, Pay-per-Invocation — zieht Teams dazu, es für Workloads zu nutzen, für die es nie gebaut wurde. Das Ergebnis sind Systeme, die teuer, schwer debuggbar und langsamer als das sind, was sie ersetzten.

Gleichzeitig ist Serverless für spezifische Data-Processing-Patterns genuin exzellent. Das Problem: die meisten Teams haben kein klares Entscheidungs-Framework, wann sie es nutzen sollten.

Dieser Guide gibt dir das Framework, mit ehrlichen Benchmarks.

TL;DR

• Serverless top: Event-Driven Micro-Ingestion, Serverless-SQL (Athena/BigQuery), Glue-Code, Quality-Checks
• Serverless schlecht: Long-Running Batch (>15 Min), High-Throughput Streaming mit State, ML-Inference at Scale, Latency-sensitive User-APIs
• Serverless Spark (EMR Serverless, Databricks Serverless) ist der Middle-Ground

Was "Serverless" für Data-Processing wirklich heißt

Der Begriff deckt mehrere distinkte Execution-Modelle ab, mit verschiedenen Trade-offs:

Fundamental verschiedene Produkte. "Soll ich Serverless nutzen?" ist die falsche Frage — "welches Serverless-Modell passt zu diesem Workload?" ist richtig.

Wo Serverless gut funktioniert

1. Event-Driven Micro-Ingestion

Kleine, häufige, unvorhersehbare Events sind der kanonische Serverless-Use-Case. Ein IoT-Sensor sendet Readings, wenn er was zu melden hat — nicht auf Schedule. Ein Webhook feuert bei Payment-Completion.

Das funktioniert, weil:

• Events klein sind (< 1 MB)
• Processing stateless ist
• Volumen unvorhersehbar (Lambda handhabt 0 → 10.000 Events/min ohne Pre-Provisioning)
• Cold Starts akzeptabel (Background-Processing)

Lambda für Webhook-Ingestion:

# lambda_function.py
import json
import boto3
import os
from datetime import datetime

s3 = boto3.client('s3')
BUCKET = os.environ['BRONZE_BUCKET']

def lambda_handler(event, context):
    # Webhook-Payload parsen
    payload = json.loads(event['body'])
    
    # Mit Metadata anreichern
    record = {
        **payload,
        "_ingested_at": datetime.utcnow().isoformat(),
        "_source": event['headers'].get('X-Webhook-Source', 'unknown'),
        "_partition_date": datetime.utcnow().strftime('%Y/%m/%d')
    }
    
    # Mit Partitioning nach S3
    key = f"webhooks/{record['_partition_date']}/{context.aws_request_id}.json"
    s3.put_object(
        Bucket=BUCKET,
        Key=key,
        Body=json.dumps(record),
        ContentType='application/json'
    )
    
    return {'statusCode': 200, 'body': 'OK'}

# Terraform — Lambda mit SQS-Trigger und DLQ
resource "aws_lambda_function" "webhook_ingestion" {
  filename      = "webhook_ingestion.zip"
  function_name = "webhook-ingestion"
  role          = aws_iam_role.lambda_ingestion.arn
  handler       = "lambda_function.lambda_handler"
  runtime       = "python3.12"
  timeout       = 30
  memory_size   = 256

  environment {
    variables = {
      BRONZE_BUCKET = aws_s3_bucket.bronze.id
    }
  }

  dead_letter_config {
    target_arn = aws_sqs_queue.ingestion_dlq.arn
  }
}

resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn = aws_sqs_queue.webhook_queue.arn
  function_name    = aws_lambda_function.webhook_ingestion.arn
  batch_size       = 100
  
  filter_criteria {
    filter {
      pattern = jsonencode({
        body = {
          event_type = ["payment.completed", "payment.failed"]
        }
      })
    }
  }
}

2. Serverless SQL für Ad-hoc Analytics

Athena und BigQuery sind die klarsten Serverless-Wins im Daten-Space. Null Infrastruktur, SQL-Interface, Pay pro TB scanned.

Wann es passt:

• Queries laufen 0–20× pro Tag (On-Demand ist günstiger als Reserved)
• Daten schon in S3/GCS (keine Bewegungskosten)
• Queries sind explorativ, kein Production-SLA

-- Athena-Query mit Partition-Pruning (schnell + günstig)
SELECT 
    event_type,
    COUNT(*) as event_count,
    SUM(revenue_usd) as total_revenue
FROM events
WHERE 
    year = '2024'
    AND month = '03'
    AND day BETWEEN '01' AND '31'
    AND event_type IN ('purchase', 'subscription')
GROUP BY 1
ORDER BY 3 DESC;
-- Scannt ~2 GB (partitioniert) vs 800 GB (unpartitioniert) — 400x Kostenunterschied

3. Orchestration-Glue und Quality-Checks

Leichte, seltene Jobs, die Datenqualität prüfen, Downstream-Pipelines triggern oder Arbeit fan-outen, sind ideal für Serverless.

# AWS Step Functions — Serverless-Orchestration
StateMachine:
  Type: AWS::StepFunctions::StateMachine
  Properties:
    Definition:
      StartAt: ValidateSchema
      States:
        ValidateSchema:
          Type: Task
          Resource: !GetAtt SchemaValidationLambda.Arn
          Next: BranchByResult
        BranchByResult:
          Type: Choice
          Choices:
            - Variable: $.validation_passed
              BooleanEquals: true
              Next: TriggerTransformation
          Default: AlertAndFail
        TriggerTransformation:
          Type: Task
          Resource: arn:aws:states:::glue:startJobRun.sync
          Parameters:
            JobName: silver-transformation
          End: true
        AlertAndFail:
          Type: Task
          Resource: !GetAtt AlertLambda.Arn
          Next: Fail
        Fail:
          Type: Fail

Wo Serverless versagt

1. Long-Running, Memory-intensive Batch-Jobs

Lambda hat 15-Minuten-Timeout und 10 GB Memory-Limit. Cloud Run hat 60-Minuten-Timeout und 32 GB. Keines ist passend für einen 4-Stunden-Spark-Job auf 10 TB Daten.

Das Fail-Pattern:

Team versucht Spark-Cluster durch Lambda für nightly ETL zu ersetzen.
- Job läuft 2h → Lambda Timeout bei 15 min
- Team splittet Job in 1000 kleinere Lambdas
- Cold Starts bringen 30 min Overhead
- Koordinations-Logic wird komplexer als der ursprüngliche Job
- Kosten: $340/Nacht vs $12/Nacht mit Spot EMR

Die Ironie: die operative Simplizität von Serverless verschwindet, wenn du tausende Functions orchestrierst, um zu simulieren, was Spark nativ macht.

2. High-Throughput Streaming mit Stateful Processing

Lambda + Kinesis handhabt ~1 MB/s pro Shard. Bei einem 10 MB/s Stream mit Stateful Windowing (Session-Analyse, Fraud-Detection) bist du schnell am Limit.

Benchmarks — 100 Events/Sek nachhaltig für 8h:

Lambda verliert bei Latenz und Throughput-Ceiling. Flink gewinnt bei beidem, und die Cost-Delta ist bei Scale klein.

3. ML-Inference bei hohem Volumen

Ein Model-Inference-Lambda mit 1.000 Requests/Sek bei 100 ms p50 sieht günstig aus. Bis du rechnest:

1.000 req/s × 100 ms × 1 GB memory = 100 GB-Sekunden/s
100 GB-Sekunden/s × 86.400 s/Tag = 8.640.000 GB-Sekunden/Tag
Kosten: 8.640.000 × $0,0000166667 = $144/Tag = $4.320/Monat

Gleicher Workload auf 3× ml.c5.2xlarge (8 vCPU, 16 GB):
$0,464/h × 3 × 720h = $1.002/Monat

Serverless ist 4× teurer für diesen Workload, und du hast schlechtere Tail-Latency wegen Cold Starts.

4. Cold-Start-Steuer für User-Facing APIs

Wenn deine Daten-API < 200 ms p99 braucht, sind Serverless-Functions meist die falsche Wahl ohne aggressive Provisioned Concurrency (was den Kosten-Vorteil drastisch reduziert).

Lambda Cold-Start (Python 3.12, 512 MB):
- Container-Init: 80–200 ms
- Runtime-Init: 50–150 ms
- Handler-Init (Imports, Connections): 100–500 ms
Total: 230 ms – 850 ms zum ersten Request

Provisioned Concurrency eliminiert Cold Starts, kostet aber $0,0000646/Function-Sekunde — etwa wie laufende EC2-Instanzen.

Das Entscheidungs-Framework

Frage in dieser Reihenfolge:

• Duration: <5 min, 5–60 min, >60 min?
• Memory: <3 GB oder mehr?
• Frequenz: unvorhersehbare Bursts, scheduled, häufig?
• Kosten-Vergleich gegen Container/Spark

Für >60 min: containerised Batch (Spark/Ray/Dask auf Kubernetes). Für <5 min und Bursts: Lambda. Für scheduled <1/Tag: Serverless Spark. Für scheduled >1/Tag: persistenter Spark-Cluster.

Serverless Spark: der Middle-Ground

AWS EMR Serverless und Databricks Serverless lösen die Hauptpunkte klassischen Serverless für Daten: kein Cold-Start-Lock-in, keine Timeout-Limits, echtes Spark-Scale.

# EMR Serverless — Spark-Job submitten
aws emr-serverless start-job-run \
  --application-id app-1234567890abcdef \
  --execution-role-arn arn:aws:iam::123456789:role/emr-serverless-execution \
  --job-driver '{
    "sparkSubmit": {
      "entryPoint": "s3://my-bucket/scripts/transform.py",
      "sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=8g"
    }
  }' \
  --configuration-overrides '{
    "monitoringConfiguration": {
      "s3MonitoringConfiguration": {
        "logUri": "s3://my-bucket/logs/"
      }
    }
  }'

EMR Serverless vs EMR auf EC2 (1 TB Job, 2× monatlich):

EMR Serverless gewinnt klar für seltene Jobs. Für tägliche+ Jobs gewinnen Managed-Cluster mit Spot bei Kosten.

Observability für Serverless Pipelines

Das härteste am Serverless-Debugging: verteilte Execution, ephemere Logs, kein SSH.

# Strukturiertes Logging für Lambda — Pflicht in Production
import json
import logging
import time
from functools import wraps

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def log_invocation(func):
    @wraps(func)
    def wrapper(event, context):
        start = time.time()
        request_id = context.aws_request_id
        
        logger.info(json.dumps({
            "event": "lambda_start",
            "request_id": request_id,
            "function": context.function_name,
            "memory_mb": context.memory_limit_in_mb,
            "records_count": len(event.get('Records', [event]))
        }))
        
        try:
            result = func(event, context)
            duration_ms = (time.time() - start) * 1000
            
            logger.info(json.dumps({
                "event": "lambda_success",
                "request_id": request_id,
                "duration_ms": round(duration_ms, 2),
                "remaining_ms": context.get_remaining_time_in_millis()
            }))
            return result
            
        except Exception as e:
            logger.error(json.dumps({
                "event": "lambda_error",
                "request_id": request_id,
                "error": str(e),
                "error_type": type(e).__name__
            }))
            raise
    return wrapper

@log_invocation
def lambda_handler(event, context):
    # Deine Logic
    pass

FAQ

Wann reicht Lambda, wann muss es Spark sein? Lambda für Events <15 min, einzelne Records. Spark, wenn du Datasets >GB joinst, aggregierst oder ML-Features baust.

Cold Starts in Production wirklich problematisch? Bei B2C-APIs mit P99-SLAs: ja. Bei Background-Jobs: meist egal. Provisioned Concurrency hilft, kostet aber.

Cloud Run vs Lambda — was wählen? Cloud Run, wenn du Container willst, längere Timeouts (60 min) und mehr Memory (32 GB) brauchst. Lambda, wenn du in AWS bist und unter 15 min/10 GB bleibst.

DACH-Compliance bei Serverless? EU-Regionen verfügbar (eu-central-1 Frankfurt für AWS, europe-west3 für GCP, Germany West Central für Azure). AVV mit allen Hyperscalern verfügbar.

Was kostet Serverless realistisch im Vergleich? Bei seltenen Bursts: 10–100× günstiger als Always-on. Bei konstanter Last: 2–10× teurer als provisionierte VMs.

Zusammenfassung

Serverless Data Processing ist genuin exzellent für Event-Driven Ingestion, Ad-hoc SQL-Analytics und seltene Batch-Jobs. Es ist schlechter Fit für Long-Running Jobs, High-Throughput Streaming, ML-Inference at Scale und Latency-sensitive User-APIs.

Die Branche bewegt sich zu Serverless Spark (EMR Serverless, Databricks Serverless) als überzeugender Middle-Ground — Managed Infrastructure und Auto-Scaling ohne FaaS-Hardlimits.

Nutze das Framework: Duration, Memory, Frequenz und Cost-Vergleich. Die richtige Antwort ist workload-spezifisch, nicht ein pauschales "Serverless ist modern, also richtig".

Harbinger Explorer 7 Tage gratis — teste deine Serverless-Daten-API-Endpoints, validiere Response-Schemas unter Last und identifiziere Cold-Start-Issues, bevor deine User es tun. harbingerexplorer.com

Stand: 14. Mai 2026.