Linden Consulting.
AI/ML

MLOps auf AWS: Einführung und Best Practices für Engineering-Teams

2026-05-04 · 8 Min. Lesezeit

Machine Learning ist längst kein Forschungsthema mehr. In vielen Unternehmen laufen ML-Modelle in Produktion — für Empfehlungen, Betrugserkennung, Nachfrageprognosen oder Textanalyse. Was häufig fehlt, ist eine robuste Betriebsumgebung für diese Modelle. Genau hier setzt MLOps an.

In meiner Beratungspraxis sehe ich immer wieder dasselbe Muster: Ein Data-Science-Team hat ein hervorragendes Modell in einem Jupyter Notebook entwickelt. Aber der Weg von dort in die Produktion — mit reproduzierbaren Pipelines, automatischem Retraining, Monitoring und Versionierung — ist mühsam und fehleranfällig. Dieser Artikel zeigt, wie Sie mit AWS-Diensten eine solide MLOps-Grundlage aufbauen.

Was ist MLOps?

MLOps ist die Anwendung von DevOps-Prinzipien auf Machine-Learning-Workflows. So wie DevOps die Kluft zwischen Entwicklung und Betrieb überbrückt hat, überbrückt MLOps die Kluft zwischen Data Science und Production Engineering.

Die drei Säulen von MLOps:

  • Reproduzierbarkeit: Jedes Experiment, jedes Training und jedes Deployment muss nachvollziehbar und wiederholbar sein.
  • Automatisierung: Von der Datenaufbereitung über das Training bis zum Deployment — manuelle Schritte sind Fehlerquellen.
  • Monitoring: Ein Modell, das vor sechs Monaten gut funktioniert hat, kann heute schlechte Vorhersagen liefern, weil sich die Eingabedaten verändert haben (Data Drift).

Auf AWS bilden SageMaker und seine Komponenten das Rückgrat einer MLOps-Plattform. Aber auch Teams, die SageMaker nicht vollständig nutzen, können von einzelnen Bausteinen profitieren.

SageMaker Pipelines: CI/CD für ML

SageMaker Pipelines ist das Äquivalent zu einer CI/CD-Pipeline für Machine Learning. Sie definieren die einzelnen Schritte Ihres ML-Workflows — Datenaufbereitung, Training, Evaluation, Registrierung — als gerichteten azyklischen Graphen (DAG).

Warum nicht einfach Step Functions oder Airflow?

Sie können Step Functions oder MWAA (Managed Airflow) für ML-Orchestrierung nutzen — und für einfache Workflows ist das auch völlig in Ordnung. SageMaker Pipelines bietet jedoch ML-spezifische Vorteile: native Integration mit dem Model Registry, automatisches Experiment Tracking, Caching von Pipeline-Schritten und die Möglichkeit, Modelle direkt aus der Pipeline heraus für Approval zu registrieren.

Ein typischer Pipeline-Aufbau:

  1. Processing Step: Datenaufbereitung und Feature Engineering mit SageMaker Processing
  2. Training Step: Modelltraining mit einem SageMaker Training Job
  3. Evaluation Step: Modellbewertung gegen definierte Metriken
  4. Condition Step: Automatische Entscheidung, ob das Modell die Qualitätsschwelle erreicht
  5. Register Step: Registrierung im Model Registry bei bestandener Evaluation
  6. Deploy Step: Automatisches oder manuell genehmigtes Deployment auf einen Endpoint
# Pipeline-Ausführung starten
aws sagemaker start-pipeline-execution \
  --pipeline-name "my-training-pipeline" \
  --pipeline-parameters '[
    {"Name": "TrainingDataS3Uri", "Value": "s3://my-bucket/training-data/2026-03/"},
    {"Name": "ModelApprovalStatus", "Value": "PendingManualApproval"}
  ]'

# Status einer Pipeline-Ausführung prüfen
aws sagemaker describe-pipeline-execution \
  --pipeline-execution-arn "arn:aws:sagemaker:eu-central-1:123456789012:pipeline/my-training-pipeline/execution/abc123"

Tipp: Aktivieren Sie Pipeline-Caching. Wenn sich nur der Training-Code ändert, aber nicht die Datenaufbereitung, muss der Processing Step nicht erneut ausgeführt werden. Das spart Zeit und Compute-Kosten.

Feature Store: das Fundament konsistenter Features

Eines der größten Probleme in ML-Projekten ist die Inkonsistenz zwischen Training- und Inference-Features. Das Data-Science-Team berechnet Features in einem Notebook anders als der Inference-Service in Produktion — und wundert sich dann über schlechtere Modellperformance.

SageMaker Feature Store löst dieses Problem mit zwei Komponenten:

  • Online Store: Niedriger Latenzugriff für Echtzeit-Inference (Single-Digit-Millisecond Reads)
  • Offline Store: S3-basierter Store für historische Features im Parquet-Format, ideal für Training
# Feature Group erstellen
aws sagemaker create-feature-group \
  --feature-group-name "customer-features" \
  --record-identifier-feature-name "customer_id" \
  --event-time-feature-name "event_time" \
  --feature-definitions '[
    {"FeatureName": "customer_id", "FeatureType": "String"},
    {"FeatureName": "event_time", "FeatureType": "String"},
    {"FeatureName": "total_orders_30d", "FeatureType": "Integral"},
    {"FeatureName": "avg_order_value_30d", "FeatureType": "Fractional"},
    {"FeatureName": "days_since_last_order", "FeatureType": "Integral"}
  ]' \
  --online-store-config '{"EnableOnlineStore": true}' \
  --offline-store-config '{"S3StorageConfig": {"S3Uri": "s3://my-bucket/feature-store/"}}'

Der entscheidende Vorteil: Sowohl das Training als auch die Inference nutzen exakt dieselbe Feature-Berechnung. Das eliminiert eine der häufigsten Fehlerquellen in ML-Systemen.

Model Registry: Versionierung und Governance

Das SageMaker Model Registry ist die zentrale Stelle, an der alle trainierten Modelle mit ihren Metriken, Artefakten und Metadaten gespeichert werden. Es funktioniert im Prinzip wie ein Container Registry, aber für ML-Modelle.

Kernfunktionen:

  • Versionierung: Jede Modellversion wird mit den zugehörigen Trainings-Metriken, dem Trainings-Dataset und den Hyperparametern gespeichert.
  • Approval Workflow: Modelle durchlaufen Status wie PendingManualApproval, Approved und Rejected. Nur genehmigte Modelle können in Produktion deployed werden.
  • Lineage Tracking: Nachvollziehbarkeit, welches Dataset und welcher Code zu welchem Modell geführt hat.
# Modellpaket im Registry auflisten
aws sagemaker list-model-packages \
  --model-package-group-name "my-model-group" \
  --sort-by CreationTime \
  --sort-order Descending \
  --max-results 5

# Modell genehmigen
aws sagemaker update-model-package \
  --model-package-arn "arn:aws:sagemaker:eu-central-1:123456789012:model-package/my-model-group/3" \
  --model-approval-status "Approved"

Best Practice: Implementieren Sie eine Policy, die automatisches Deployment nur für Modelle erlaubt, deren Evaluation-Metriken definierte Schwellenwerte überschreiten. Alles andere geht in den manuellen Approval-Prozess.

Monitoring von Model Drift

Ein in Produktion laufendes Modell ist kein statisches Artefakt. Die Welt verändert sich, und damit verändern sich auch die Daten, die Ihr Modell als Input bekommt. Model Drift bezeichnet den Effekt, dass die Vorhersagequalität über die Zeit abnimmt.

Es gibt zwei Arten von Drift:

  • Data Drift: Die Verteilung der Eingabedaten ändert sich. Beispiel: Ein Modell zur Kreditrisikoeinschätzung wurde vor der Pandemie trainiert — plötzlich sieht es Einkommensmuster, die es nie gelernt hat.
  • Concept Drift: Die Beziehung zwischen Eingabe und Ausgabe verändert sich. Beispiel: Kundenverhalten ändert sich nach einem Marktumbruch grundlegend.

SageMaker Model Monitor erkennt beide Arten:

# Baseline für Data Quality erstellen
aws sagemaker create-monitoring-schedule \
  --monitoring-schedule-name "my-model-data-quality" \
  --monitoring-schedule-config '{
    "MonitoringJobDefinition": {
      "MonitoringInputs": [{
        "EndpointInput": {
          "EndpointName": "my-model-endpoint",
          "LocalPath": "/opt/ml/processing/input"
        }
      }],
      "MonitoringOutputConfig": {
        "MonitoringOutputs": [{
          "S3Output": {
            "S3Uri": "s3://my-bucket/monitoring/data-quality/",
            "LocalPath": "/opt/ml/processing/output"
          }
        }]
      },
      "MonitoringResources": {
        "ClusterConfig": {
          "InstanceCount": 1,
          "InstanceType": "ml.m5.large",
          "VolumeSizeInGB": 20
        }
      },
      "MonitoringAppSpecification": {
        "ImageUri": "156813124566.dkr.ecr.eu-central-1.amazonaws.com/sagemaker-model-monitor-analyzer"
      }
    },
    "ScheduleConfig": {"ScheduleExpression": "cron(0 */6 * * ? *)"}
  }'

Mein Rat: Richten Sie Monitoring von Tag eins an ein, nicht erst wenn Probleme auftreten. Definieren Sie klare Schwellenwerte und koppeln Sie Alarme an automatische Retraining-Pipelines. Wenn die Datenqualität unter den Schwellenwert fällt, wird automatisch ein neues Training mit aktuellen Daten angestoßen.

Amazon Bedrock für GenAI-Anwendungen

Nicht jedes ML-Projekt erfordert eigenes Modelltraining. Für viele Anwendungsfälle — Textgenerierung, Zusammenfassung, Klassifikation, Chatbots — bieten Foundation Models über Amazon Bedrock einen schnelleren und kostengünstigeren Weg.

Wann Bedrock statt eigenem Training?

  • Textverarbeitung: Zusammenfassungen, Sentiment-Analyse, Entity Extraction — Foundation Models sind out-of-the-box stark.
  • RAG-Anwendungen (Retrieval-Augmented Generation): Kombination aus eigener Wissensbasis und Foundation Model für domänenspezifische Antworten.
  • Prototyping: Schnell testen, ob ein ML-basierter Ansatz für Ihren Anwendungsfall funktioniert, bevor Sie in eigenes Training investieren.

Bedrock in bestehende Architekturen integrieren:

# Verfügbare Foundation Models auflisten
aws bedrock list-foundation-models \
  --query 'modelSummaries[*].{ID:modelId,Name:modelName,Provider:providerName}' \
  --output table

# Modell aufrufen (Beispiel: Claude)
aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-3-sonnet-20240229-v1:0 \
  --content-type application/json \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":1024,"messages":[{"role":"user","content":"Fasse diesen Text zusammen: ..."}]}' \
  response.json

Kostenoptimierung bei Bedrock: Nutzen Sie Provisioned Throughput für vorhersehbare Workloads und Batch Inference für nicht-zeitkritische Verarbeitung großer Datenmengen. Cachen Sie Antworten, wo möglich, um redundante API-Aufrufe zu vermeiden.

Kostenoptimierung für ML-Workloads

ML-Workloads sind notorisch teuer — besonders das Training. Hier sind die wichtigsten Hebel zur Kostensenkung.

Spot Instances für Training

SageMaker Training Jobs unterstützen Managed Spot Training, das bis zu 90 % der Trainingskosten einsparen kann. SageMaker übernimmt das Checkpoint-Management automatisch: Wenn eine Spot Instance unterbrochen wird, setzt das Training beim letzten Checkpoint fort.

# Training Job mit Spot Instances
aws sagemaker create-training-job \
  --training-job-name "my-model-training-spot" \
  --enable-managed-spot-training \
  --stopping-condition '{"MaxRuntimeInSeconds": 86400, "MaxWaitTimeInSeconds": 172800}' \
  --resource-config '{
    "InstanceType": "ml.p3.2xlarge",
    "InstanceCount": 1,
    "VolumeSizeInGB": 50
  }' \
  --algorithm-specification '{
    "TrainingImage": "123456789012.dkr.ecr.eu-central-1.amazonaws.com/my-training:latest",
    "TrainingInputMode": "File"
  }' \
  --input-data-config '[{"ChannelName":"training","DataSource":{"S3DataSource":{"S3Uri":"s3://my-bucket/data/","S3DataType":"S3Prefix"}}}]' \
  --output-data-config '{"S3OutputPath": "s3://my-bucket/models/"}'

Serverless Inference

Für Modelle mit variablem oder geringem Traffic bietet SageMaker Serverless Inference eine kosteneffiziente Alternative zu dedizierten Endpoints. Sie zahlen nur für die tatsächliche Inference-Zeit — ohne Kosten für Leerlauf.

# Serverless Endpoint erstellen
aws sagemaker create-endpoint-config \
  --endpoint-config-name "my-model-serverless" \
  --production-variants '[{
    "VariantName": "default",
    "ModelName": "my-model-v3",
    "ServerlessConfig": {
      "MemorySizeInMB": 2048,
      "MaxConcurrency": 10
    }
  }]'

Weitere Spartipps:

  • Lifecycle Configurations für Notebook-Instanzen: Automatisch herunterfahren nach Inaktivität.
  • S3 Intelligent-Tiering für Trainingsdaten und Modell-Artefakte, die nicht ständig gebraucht werden.
  • Rightsizing der Inference-Instanzen: Nutzen Sie SageMaker Inference Recommender, um die kostenoptimale Instanz zu finden.

Organisationsstruktur: Wer macht was?

Technologie allein reicht nicht. Die organisatorische Aufstellung entscheidet maßgeblich über den Erfolg von MLOps.

Das bewährte Modell: Ein zentrales ML Platform Team stellt die Infrastruktur bereit — Pipelines, Feature Store, Model Registry, Monitoring. Die Data Science Teams in den Fachbereichen nutzen diese Plattform, um ihre Modelle zu entwickeln und zu deployen.

Verantwortlichkeiten klar definieren:

  • ML Platform Team: Infrastruktur, CI/CD-Pipelines, Monitoring-Plattform, Kostenoptimierung, Security und Compliance.
  • Data Science Teams: Modellentwicklung, Feature Engineering, Modell-Evaluation, fachliche Modellüberwachung.
  • Engineering Teams: Integration der Modell-Endpoints in Anwendungen, End-to-End-Latenz, Application-Level-Monitoring.

Diese Aufteilung spiegelt die Plattform-Engineering-Bewegung wider, die sich in der Softwareentwicklung bewährt hat: Ein zentrales Team baut die Plattform, die Fachteams nutzen sie als Self-Service.

Fazit

MLOps auf AWS ist ein breites Feld, aber Sie müssen nicht alles auf einmal umsetzen. Starten Sie mit den Grundlagen: einer reproduzierbaren Training Pipeline, einem Model Registry und grundlegendem Monitoring. Erweitern Sie dann schrittweise um Feature Store, automatisiertes Retraining und fortgeschrittenes Drift-Monitoring.

Die wichtigste Erkenntnis aus meiner Beratungspraxis: Behandeln Sie ML-Modelle wie Software. Versionieren Sie Code, Daten und Modelle. Automatisieren Sie das Deployment. Testen Sie vor dem Release. Und monitoren Sie in Produktion. Wenn Sie diese Prinzipien beherzigen, sind Sie auf einem guten Weg.

Wenn Sie Ihre MLOps-Strategie auf AWS aufbauen oder optimieren wollen, sprechen Sie mich gerne an. Gemeinsam erarbeiten wir einen pragmatischen Fahrplan, der zu Ihrem Team und Ihren Anforderungen passt.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen