Lambda Managed Instances: Logs, die man braucht
LMI-Capacity-Provider schreiben Lifecycle-Logs nach CloudWatch. Structured JSON, default an – der blinde Fleck zwischen Function und Fleet wird kleiner.
Lambda Managed Instances bekommen Capacity-Provider-Logs in CloudWatch – structured JSON, default an. Wer Serverless auf EC2 fährt, sieht endlich Launches, Terminations und Health Checks, ohne erst ein eigenes Observability-Projekt zu bauen.
Das Wichtigste in Kürze
- Logs default-on. Capacity Provider schreiben Lifecycle-Events als strukturierte JSON-Logs nach CloudWatch.
- Sicht auf die EC2-Schicht. Launches, Terminations und Health Checks werden filterbar – Provisioning-Fehler lassen sich schneller eingrenzen.
- Für planbare Last. LMI zielt auf hohe, vorhersagbare Workloads mit speziellen Compute-Profilen und EC2-Preishebeln wie Savings Plans.
Verwandt:CloudFront 5xx: Was VPC Origins Teams prüfen müssen
Lambda Managed Instances (LMI) versprechen das Beste aus zwei Welten: Lambda-Operationsmodell und EC2-Kontrolle. In der Praxis fehlte oft genau die Schicht dazwischen – was der Capacity Provider gerade tut, wenn die Funktion „komisch“ skaliert.
Warum LMI ohne Logs riskant war
LMI lässt Lambda-Funktionen auf EC2-Instanzen laufen, die Capacity Provider im Auftrag provisionieren. Das ist attraktiv für hohe, planbare Last und Spezial-Compute. Der blinde Fleck: Wenn Provisioning hakt, sieht man Function-Errors, aber nicht den Host-Lifecycle.
Genau dort setzen die neuen Capacity-Provider-Logs an. AWS schreibt sie automatisch nach CloudWatch Logs. Strukturiertes JSON macht Filter und Alarme möglich, ohne erst Log-Parser zu erfinden.
Was die Logs konkret abdecken
Im Fokus stehen Scaling-Aktivität und Instanz-Lifecycle: Starts, Beendigungen, Health Checks. Darüber finden Teams fehlgeschlagene Operationen und Provisioning-Fehler schneller. Die Logs sind in allen kommerziellen AWS-Regionen verfügbar, in denen LMI läuft. Für alle Capacity Provider sind sie standardmäßig aktiv.
Konfiguration bleibt möglich über Lambda Console, API, CLI, SAM oder CloudFormation. Es gelten die üblichen CloudWatch-Logs-Kosten. Das ist ein Standard-Telemetrie-Pfad, den man budgetieren muss – wie Function-Logs auch.
Fünf Checks, bevor LMI in Produktion wächst
- Capacity Provider inventarisieren. Welche Provider, welche Instance-Familien, welche Limits?
- Log-Groups und Retention setzen. Default-on heißt nicht „für immer speichern“. Retention und Kostenbudget festlegen.
- Alarme auf Lifecycle-Fehler. Failed launches und wiederholte terminations als Pager-Ereignis, nicht erst als User-Ticket.
- Mit Function-Metriken koppeln. Throttles, Duration und Errors nur zusammen mit Provider-Logs lesen.
- Preishebel prüfen. Savings Plans und Reserved Instances lohnen erst, wenn die Instanzschicht stabil und beobachtbar ist.
Für wen sich der Schritt lohnt
LMI ist kein Ersatz für klassisches Lambda bei spikiger, seltener Last. Es ist ein Werkzeug für vorhersehbare, hohe Workloads mit speziellem Compute. Die neuen Logs machen den Betriebsfall ehrlicher: Serverless-Erlebnis ja, aber mit Host-Realität im Log.
Wer LMI schon fährt und Incidents „irgendwo zwischen Function und Fleet“ sucht, sollte die Capacity-Provider-Seite in der Lambda Console und die zugehörigen CloudWatch-Filter noch heute als Standard-Runbook verankern.
Quelle: AWS What’s New – Lambda Managed Instances capacity provider logs (24. Juli 2026).
Häufige Fragen
Was sind Lambda Managed Instances?
LMI lässt Lambda-Funktionen auf EC2-Instanzen laufen, die Capacity Provider verwalten. Ziel sind hohe, planbare Workloads mit speziellen Compute-Profilen und EC2-Preisoptionen – bei Lambda-ähnlicher Betriebsführung.
Was ist neu an den Capacity-Provider-Logs?
AWS schreibt structured JSON-Logs zu Scaling und Instanz-Lifecycle (Launches, Terminations, Health Checks) nach CloudWatch. Sie sind default aktiv und in den kommerziellen Regionen verfügbar, in denen LMI angeboten wird.
Fallen Extra-Gebühren an?
Für die Telemetrie gelten die üblichen Amazon CloudWatch Logs Charges. Die Logs selbst sind ein Standard-Feature der Capacity Provider und kein separates Add-on-Produkt.
Wie starte ich mit dem Monitoring?
In der Lambda Console die Capacity-Provider-Seite öffnen, Log-Groups prüfen, Retention setzen und Alarme auf fehlgeschlagene Lifecycle-Events legen. Danach Function-Metriken und Provider-Logs im selben Incident-Board koppeln.
Lesetipps der Redaktion
cloudmagazinCloudFront 5xx: Was VPC Origins Teams prüfen müssencloudmagazinNGINX-Lücke: Ingress und Gateway im Patch-ZwangcloudmagazinAcht Minuten bis AWS-Admin: offener S3-Bucket als LeckMehr aus dem MBF Media Netzwerk
MyBusinessFutureWenn der Kreditworkflow am Posteingang hängtDigital ChiefsVerwaiste Zugänge: die stille Cyber-LückeSecurityTodayServiceNow-RCE: sechs Checks vor dem TicketBildquelle: KI-generiert (Juli 2026)
