Serverless Applications mit AWS Lambda verstehen und anwenden: Architektur, Kosten, Muster und Learnings aus „Serverless Applications with AWS Lambda“ von Thomas Jäger (Objectbay)

Warum Serverless – und warum jetzt?

Im Talk „Serverless Applications with AWS Lambda“ führt Thomas Jäger (Objectbay) praxisnah durch das, was viele von uns an Cloud-Modernisierung reizt: weniger Infrastruktur-Last, mehr Fokus auf Business-Funktionalität und belastbare Skalierung, ohne dafür eigene Server zu betreiben. Jäger kommt aus einer Welt, in der Webentwicklung „applikations-serverlastig“ war—träge, starr, monolithisch. Er erinnert daran, wie schnell Frameworks kommen und gehen und wie oft wir Hypes begleiten—bis sie an Relevanz verlieren. Gerade deshalb ist Serverless für Engineering-Teams spannend: Es verspricht, die Dauerbrenner „Skalierung“, „Verfügbarkeit“ und „Kostenkontrolle“ anders zu denken.

Aus der DevJobs.at-Perspektive war dieser Talk eine nüchterne, technische Einordnung: Was heißt „serverlos“ im AWS-Kosmos wirklich? Wofür ist es geeignet? Welche Architektur-Bausteine und Betriebsmodelle funktionieren in der Praxis? Und welche Versprechen halten stand, wenn man Zahlen danebenlegt?

Was „serverlos“ im AWS-Kontext bedeutet

„Serverless“ klingt nach „keine Server“. Faktisch laufen natürlich Server—aber wir verwalten sie nicht mehr selbst. Genau das ist der Punkt, den Jäger im AWS-Kontext hervorhebt: Wir zahlen nur, wenn Code wirklich läuft, und wir bekommen Skalierung inklusive. Statt Server zu provisionieren, patchen, überwachen und nachts leer laufen zu lassen, wird Rechenzeit on demand bereitgestellt.

Das ist besonders attraktiv, wenn:

• das Nutzeraufkommen stark variiert,
• Spitzen unvorhersehbar sind,
• und Time-to-Value zählt, ohne Infrastrukturprojekte vorweg zu finanzieren.

Gleichzeitig betont Jäger: Manche Marketing-Versprechen sind schwer messbar („Faster Time to Market“), andere sind sehr greifbar („Scales with Usage“). Diese Differenzierung zieht sich durch den gesamten Vortrag und ist ein hilfreicher Kompass für Teams, die die ersten Serverless-Workloads anpeilen.

AWS Lambda im Überblick

Jäger verortet AWS Lambda als eine Funktion, die „in Response to Events“ losläuft: Ein Ereignis tritt auf, und der Code wird ausgeführt. Zu den Eckpunkten, die er nennt:

• Basis: Amazon Linux AMI (das zugrundeliegende Amazon Machine Image wird von AWS betreut).
• Ressourcen: konfigurierbares Memory von 128 MB bis 10 GB; bis zu 6 vCPU-Cores—Lambda hat heute „richtig Power“.
• Betriebsmodell: Event-getrieben, keine direkte OS-Verwaltung durch das Team erforderlich.
• Plattform-Mehrwerte:
• Autoscaling und Load-Balancing übernimmt AWS.
• Fehlerbehandlung und Security-Mechanismen sind integriert; Berechtigungen lassen sich präzise zuschneiden.
• Logging und Metriken stehen ohne Zusatzaufwand bereit.

Der operative Effekt: Wir konzentrieren uns aufs Entwickeln, nicht aufs Betreiben des darunterliegenden Systems.

Drei Ausführungsmodelle für Lambda

Jäger ordnet die gängigen Startmechanismen von Lambda in drei Kategorien ein:

1. Push-basiert:

• Klassisch via REST-Aufruf—z. B. ein POST auf einen Endpoint.
• Das Ereignis kommt „von außen“, Lambda startet und verarbeitet die Anfrage.

1. Event-basiert:

• Trigger aus anderen AWS-Diensten (z. B. Notification-Services, S3-Events) oder aus Kafka.
• Lambda reagiert auf Nachrichten im Event-Bus und agiert als Konsument funktionaler Schritte.

1. Poll-basiert:

• Datenstrom- oder Datenbank-Änderungen, etwa in Amazon DynamoDB oder Amazon Kinesis.
• Lambda liest kontinuierlich, transformiert in Echtzeit oder reagiert auf Entitätsänderungen.

Diese Modellvielfalt ist die Grundlage für Muster, die über einfache Web-Backends hinausgehen—zum Beispiel Processing-Pipelines oder Replikations- und Integrationsjobs zwischen Systemen.

API Gateway: Das „Fenster zur Außenwelt“

Die meisten Backends brauchen eine saubere, sichere Verbindung zur Außenwelt. Genau dafür positioniert Jäger Amazon API Gateway: Es erstellt, veröffentlicht und schützt APIs (REST, WebSockets) und dient als Doorway, über den Anfragen in Lambdas und andere Services fließen.

Ohne API Gateway bleibt Serverless-Webentwicklung Stückwerk. Mit Gateway bekommt man Versionierung, Auth- und Schutzmechanismen und ein linientreues Entry-Point-Modell, in das sich Lambda nahtlos einklinkt.

Referenz: Web-Architektur mit S3, CloudFront, API Gateway und Lambda

Jäger beschreibt das Setup, das Objectbay am häufigsten nutzt, wenn Serverless im Web zum Einsatz kommt:

• Statischer Inhalt (HTML, JavaScript, CSS, Bilder) liegt in Amazon S3.
• Auslieferung erfolgt über ein CDN, konkret Amazon CloudFront, damit Nutzer schnell an ihren Content kommen—egal, ob am Smartphone oder Laptop.
• Für Backend-Funktionalität und Datenzugriff wird Amazon API Gateway eingesetzt, das Requests an AWS Lambda weiterreicht.
• Lambda interagiert dahinter mit Datenbanken und weiteren Services—und skaliert „bis theoretisch in die Unendlichkeit“.

Bemerkenswert ist, wie konsequent diese Architektur Skalierung von State trennt. Statischer Content ist hochgradig cachebar, und dynamische Funktionen sind horizontal elastisch. Aus DevJobs.at-Sicht ist genau das der Charme: Es gibt kaum einen Traffic-Peak, den man damit nicht abfangen kann—ohne einen Flottenpark an Servern zu pflegen.

Event-getriebene Muster: Messaging, Storage, Zeit und Monitoring

Jäger liefert mehrere praxistaugliche Trigger-Muster, die über das Web-Frontend hinausreichen:

• Messaging-getrieben:
• Beispiel: Ein CRM-System legt einen neuen Kunden an und emittiert ein Event. Mehrere Services „horchen“ darauf—darunter ein Lambda, das Umgebungen provisioniert oder kundenspezifische Initialisierungen vornimmt.
• Storage-getrieben:
• Beispiel: Ein Fotograf lädt hunderte Bilder und Videos in S3 hoch. Der erfolgreiche Upload ist das Event. Ein Lambda startet und führt Transformationen durch—kopieren, skalieren, Bildformate bereiten.
• Zeitgesteuert:
• Über Amazon CloudWatch lassen sich wiederkehrende Jobs definieren (z. B. täglich um 2 Uhr). Typische Tasks: Logfiles aufräumen, Tagesreports generieren.
• Monitoring- und Anomalie-getrieben:
• CloudWatch überwacht Services. Erkennt es, dass es einem Service „schlecht geht“, kann genau dieses Event genutzt werden, um mit einem Lambda korrigierend einzugreifen.

Das gemeinsame Muster: „Event –> Funktion –> Aktion“. Teams behalten damit eine einheitliche Denkweise, egal ob der Impuls vom Nutzer, von Daten, von der Uhrzeit oder vom Monitoring kommt.

Orchestrierung: Step Functions bringen Struktur

Viele kleine Lambdas zu haben, ist mächtig—aber kann unübersichtlich werden. Jäger benennt das explizit: „Zu viele von diesen Dingen, das macht es ein bisschen unübersichtlich.“ Die Antwort: AWS Step Functions, um Workflows zu koordinieren.

Das Beispiel im Talk: Bildverarbeitung als State Machine.

• Start: Ein Bild wird hochgeladen—ein Lambda startet den Workflow.
• Schritt 1: Metadaten extrahieren.
• Schritt 2: Basierend auf den Metadaten werden Pfade verzweigt—z. B. JPEG/PNG weiterverarbeiten; Sternbilder oder andere Typen gesondert behandeln.
• Parallelität: Mehrere Lambdas lassen sich parallel anstoßen.
• Fehlerpfade: Nicht unterstützte Formate führen zu einem Fehler („Not supporting image type“), auf den der Workflow gezielt reagieren kann.

Wichtig ist hier die Klarheit: Step Functions ermöglichen eine visuelle und nachvollziehbare Orchestrierung von Teilschritten, inklusive Retry- und Fehlerbehandlung. Für Teams, die viele granulare Funktionen betreiben, ist das ein entscheidender Hebel gegen implizite Komplexität.

Kostenmodell: Requests und Dauer bestimmen die Rechnung

Jäger bricht die Kosten auf zwei Faktoren herunter:

• Anzahl der Requests: Wie oft wird ein Lambda getriggert?
• Dauer: Wie lange läuft es (gemessen in Millisekunden), multipliziert mit dem konfigurierten Memory (als GB-Sekunden)?

Zentrale Eckpunkte, die er nennt:

• Eine Million Requests kosten 20 Cent.
• Abrechnung der Compute-Dauer erfolgt pro GB-Sekunde. Beispiel: Ein Lambda mit 512 MB Memory verbraucht pro Sekunde 0,5 GB-Sekunden.
• Free Tier:
• 1.000.000 Requests frei.
• 400.000 GB-Sekunden frei.

Jägers generelles Fazit zur Preisstruktur: „Mal grundsätzlich günstig.“ Besonders im Vergleich zu einer herkömmlichen Server-Infrastruktur ist es schwer, die gleiche Elastizität und Leistung für das Geld nachzubauen.

Beispielrechnung aus den Folien

• Konfiguration: 512 MB Memory
• Ausführungen: 3.000.000 pro Monat
• Dauer: 1 Sekunde pro Ausführung
• Kosten: 19 Dollar

Die Kernaussage dazu: Für eine verlässliche, hochskalierende Verarbeitung von Millionen Tasks ist dieses Kosten-Niveau schwer mit einer fix provisionierten Serverlandschaft zu schlagen—insbesondere, wenn Last variabel und spitzenbelastet ist.

Real-World-Beispiel: Eine Million Uploads, parallele Lambdas, klare Kosten

Das greifbarste Stück des Talks ist ein Projektbeispiel:

• Workload: 1.000.000 Image-/Video-Uploads pro Monat in S3.
• Ausführung: Für jeden Upload startet ein 512-MB-Lambda; durchschnittliche Laufzeit 5 Sekunden.
• Fronting: Amazon API Gateway mit ca. 1.000.000 Requests, Kosten laut Jäger 38 Dollar im Monat (konfigurationsabhängig und mit Optimierungspotenzial).

Das Gegenbild ist eine Spring-Boot-Anwendung auf Servern:

• Um ausfallsicher zu sein, braucht es mehrere Instanzen.
• Server kosten Tag und Nacht, auch wenn keine Uploads stattfinden.
• Selbst mit zeitgesteuertem Herunterfahren (z. B. nachts) riskiert man Funktionsausfälle bei frühmorgendlichen Uploads.
• Die Kosten im Beispiel lägen „so bei 117, 120 Dollar“—und bei wachsender Last skaliert dieser Ansatz kostenseitig „massiv“ nach oben.

Zwei strukturelle Einsichten aus diesem Vergleich:

1. Mit Lambda skaliert Parallelität nativ: 100 gleichzeitige Uploads bedeuten 100 parallele Lambdas, ohne Vorplanung.
2. Jeder Lambda-Task hat sein konfiguriertes Memory-Budget (z. B. 512 MB). Auf einem geteilten Server konkurrieren parallel laufende Tasks um Ressourcen (z. B. 16 GB RAM über alle Prozesse hinweg). Das schlägt spürbar auf Durchsatz und Antwortzeiten, wenn viele Nutzer gleichzeitig arbeiten.

Oder, wie Jäger es pointiert: Links (Lambda) ändert sich der Preis mit wachsender Last „nicht viel“, rechts (Server) „massiv“—weil zusätzliche Serverleistung und Redundanz finanziert werden müssen.

Was die großen Versprechen taugen

Am Ende legt Jäger die Common Claims gegen die Praxis:

• „No Service to Manage“: Stimmt. Betriebssystem-Management und Infrastrukturlast fallen weg.
• „Pay what you need“: Stimmt. Abgerechnet wird, was tatsächlich gebraucht wird—Requests und Laufzeit.
• „Faster Time to Market“: Ambivalent. Der Aufbau von Lambda-Umgebung, Step Functions und Co. kostet Einarbeitungszeit. Auf lange Sicht kann sich das auszahlen, kurzfristig ist es schwer messbar.
• „Scales with Usage“: Stimmt. Das ist einer der größten Pain-Points, der mit Lambda praktisch verschwindet.
• „Availability“: Anders zu denken. Lambdas laufen nicht „24/7“ im klassischen Sinn—sondern sie sind „sofort da, wenn man sie braucht“. Für klassische, dauerhaft laufende Server ist das kein 1:1-Vergleich. Wichtig ist, das Betriebsmodell umlernen.
• „Better Focus“: Teilweise. Man kann sich stärker auf Business-Logik konzentrieren, aber man muss sich ebenso mit der Serverless-Architektur auseinandersetzen—inklusive Orchestrierung und Beobachtung.

Diese ehrliche Einordnung macht den Talk hilfreich: Sie hält die Balance zwischen Begeisterung und Bodenhaftung.

Praktische Leitplanken für Engineering-Teams

Aus der Beobachtung des Talks leiten wir folgende praxisnahe Punkte für den Einstieg ab:

• Startet mit einem klaren, event-getriebenen Use Case.
• S3-Uploads mit Bild-/Video-Transformation sind ein sauberer Anfang—genau dafür ist Lambda prädestiniert.
• Alternativ: CRM-Events, die Folgeaktionen auslösen (z. B. Provisionierungen), wie von Jäger skizziert.
• Behaltet die drei Trigger-Modelle im Blick und wählt bewusst:
• Direkt via REST (API Gateway)
• Event-Bus (z. B. Notification Services, Kafka)
• Datenstrom-/Datenbank-Änderungen (DynamoDB, Kinesis)
• Orchestriert früh mit Step Functions, wenn:
• mehrere Teilschritte involviert sind,
• Fehlerpfade existieren,
• parallele Verarbeitungen sinnvoll sind.
• Denkt die Außenanbindung sauber:
• Statische Inhalte auf S3
• Auslieferung via CloudFront
• Einstieg über API Gateway
• Lambdas dahinter schlank halten und klaren Zuständigkeitsbereich definieren
• Plant Monitoring und Reaktion ein:
• CloudWatch als Beobachtungsinstanz nutzen
• Auf Anomalien mit Lambdas reagieren (z. B. Selbstheilungsaktionen)
• Prüft das Kostenmodell mit realistischen Parametern:
• Requests pro Monat, durchschnittliche Dauer, Memory-Konfiguration
• Free Tier einkalkulieren (1 Mio. Requests, 400.000 GB-Sekunden)
• Beispielhafte Kalkulationen wie „3 Mio. Aufrufe, 512 MB, 1 Sekunde ≈ 19 Dollar“ geben ein Gefühl für Größenordnungen
• Achtet auf Architektursauberkeit:
• Zu viele, unkoordinierte Lambdas erzeugen Chaos—Step Functions und klare Namens-/Paketierungskonzepte helfen.
• Security konsequent modellieren—präzise Berechtigungen sind integraler Teil des Ansatzes.

Ein realistischer Erwartungsrahmen

Jäger rät am Schluss: „Give it a try.“ Der AWS-Kalkulator hilft beim Durchspielen, und das Free Tier senkt die Einstiegshürden. Aus DevJobs.at-Sicht lauten die Erwartungen an Teams so:

• Serverless lohnt sich besonders dort, wo Workloads sprunghaft sind oder wo Parallelität zählt (z. B. Massen-Uploads, Event-Processing).
• Die größten Gewinne liegen in Betrieb und Skalierung—nicht zwingend in der ersten Entwicklungswoche. Rechnet Lernkurven und Orchestrierung mit ein.
• Availability ist anders: Es geht um „Verfügbarkeit bei Bedarf“, nicht um dauerhaft laufende Prozesse. Das wirkt sich auf Architektur- und Monitoring-Entscheidungen aus.
• Wirtschaftlich bleibt Lambda schwer schlagbar, wenn man Millionen kurzlebiger Tasks zuverlässig und parallel verarbeiten muss.

Fazit: Serverless als solide, skalierende Basis für moderne Workloads

„Serverless Applications with AWS Lambda“ von Thomas Jäger (Objectbay) liefert genau das, was Engineering-Teams brauchen: eine klare Landkarte durch Architekturbausteine, Trigger-Modelle, Orchestrierung und Kosten. Ohne Marketing-Überhöhung, mit echten Zahlen und mit ehrlicher Bewertung der Versprechen.

Für viele Use Cases—insbesondere im Web-Umfeld mit S3/CloudFront/API Gateway/Lambda—ist das Muster ausgereift. Messaging-, Storage- und Zeit-Trigger fügen sich nahtlos ein, und Step Functions geben komplexeren Abläufen Struktur. Wer Millionen Tasks parallelisieren will, bekommt Leistung, Kostenkontrolle und Betriebsruhe in einem Paket.

Der nächste Schritt ist niedrigschwellig: Ein kleiner, sauber geschnürter Event-Case und ein Blick in den AWS-Kalkulator. Der Rest ergibt sich aus den Daten—und genau das ist eine Stärke von Serverless.

• 

  

  Microservices for Front Ends

  Michael Eder von Objectbay spricht in seinem devjobs.at TechTalk über einen Ansatz, wie man die gängige Architektur der Microservices auch im Front End anwenden könnte.

  Jetzt ansehen
• 

  

  Die Wahl der richtigen Software Architektur

  Alexander Knapp von Objectbay beschäftigt sich in seinem devjobs.at TechTalk mit der Herangehensweise, wie man aus einer Vielzahl an verschiedenen Software Architekturen die passende auswählt.

  Jetzt ansehen
• 

  

  Mutation Testing

  Alexander Knapp von Objectbay widmet sich in seinem devjobs.at TechTalk dem Thema Mutation Testing – was es ist und wie jedes Software Projekt davon profitieren kann.

  Jetzt ansehen

• 

  

  Alexander Knapp, Full Stack Software Engineer bei Objectbay

  Alexander Knapp von Objectbay schildert im Interview seinen Werdegang bis hin zu seiner aktuellen Rolle im Full Stack Engineering und was seiner Meinung nach für Beginner wichtig ist.

  Jetzt ansehen