AWS-Einführung für Quereinsteiger: Mein erstes Produktionsprojekt als Cloud-Engineer

Maurice Murphy stand vor einer scheinbar einfachen Aufgabe: ein Produktionsprojekt auf Amazon Web Services (AWS) zu realisieren – und das als Quereinsteiger mit Fokus auf Cloud-Engineering. Innerhalb von nur wenigen Monaten entwickelte er ein serverloses URL-Kürzungssystem, das nicht nur als Portfolio-Projekt diente, sondern auch sein Verständnis für AWS-Infrastruktur vertiefte. Das Ergebnis ist ein schlankes, kosteneffizientes System, das von den Grundlagen bis zu fortgeschrittenen Sicherheitskonzepten alle Aspekte abdeckt.

Nach fast einem Jahrzehnt Erfahrung in Full-Stack-Entwicklung mit React, React Native und Node.js wagte Murphy den Sprung in die Cloud-Welt. Sein Ziel: eine AWS-zertifizierte Rolle im dritten Quartal 2026 zu erreichen. „Ich wollte ein End-to-End-System ausschließlich mit AWS-Diensten aufbauen – und das mit Fokus auf reine Effizienz“, erklärt er. „Jeder Dienst musste einen klaren Zweck erfüllen und durfte nicht unnötig Ressourcen verbrauchen.“

Ein serverloses System mit klaren Komponenten

Das Projekt, eine URL-Kürzungsplattform, folgt einem einfachen Prinzip: Nutzer geben eine lange URL ein und erhalten einen kurzen Code zurück. Klickt ein Nutzer später auf diesen Code, wird er zur ursprünglichen Zieladresse weitergeleitet. Hinter den Kulissen kommen fünf AWS-Dienste zum Einsatz, die nahtlos zusammenarbeiten:

• AWS Lambda für die serverlose Ausführung der Logik
• API Gateway als Schnittstelle zwischen Internet und Lambda
• DynamoDB als NoSQL-Datenbank für die Speicherung der URL-Mappings
• Amazon S3 für die statische React-Webanwendung
• CloudFront für sichere Inhaltsbereitstellung und HTTPS-Verschlüsselung

„Der größte Vorteil dieses Ansatzes ist die Skalierbarkeit“, betont Murphy. „Lambda startet nur, wenn tatsächlich eine Anfrage eingeht – und kostet nahezu nichts bei geringer Auslastung.“ Sein Ziel war es nicht, das Rad neu zu erfinden, sondern zu verstehen, wie komplexe Systeme strukturiert und verwaltet werden. „Früher habe ich oft unbewusst komplexe Architekturen gebaut. Jetzt wollte ich es bewusst tun – und dabei die AWS-Dienste optimal nutzen.“

Warum DynamoDB die richtige Wahl war

Für die Datenbank fiel Murphys Entscheidung schnell auf DynamoDB. „Die Zugriffsmuster sind extrem einfach: Ein kurzer Code wird abgefragt, und eine URL wird zurückgegeben“, erklärt er. „Das ist eine einzelne Schlüsselabfrage – perfekt für NoSQL.“ Seine Erfahrung mit MongoDB und Mongoose half ihm, sich schnell in DynamoDB einzuarbeiten. „Die Syntax mag anders sein, aber die Konzepte sind ähnlich.“

Im Gegensatz zu einer relationalen Datenbank wie Amazon RDS benötigt DynamoDB keine ständige Serverbereitstellung. Die Kosten bleiben niedrig, selbst bei wachsendem Traffic. „Ich musste mich nicht um Indizes, Joins oder Schemadefinitionen kümmern – genau das, was ich für dieses Projekt brauchte“, so Murphy.

Die Herausforderungen: Von IAM bis CloudFront

Trotz der scheinbaren Einfachheit des Projekts stolperte Murphy über mehrere Stolpersteine – und lernte dabei wertvolle Lektionen für zukünftige AWS-Projekte.

IAM-Berechtigungen und Regionenkonflikte

Seine erste Hürde war ein scheinbar trivialer Fehler: Sein IAM-Benutzer hatte nicht die Berechtigung, Rollen zu erstellen. „Lambda erstellt automatisch eine Ausführungsrolle, wenn man eine Funktion anlegt“, erklärt Murphy. „Doch mein IAM-Benutzer konnte diese Rolle nicht erstellen – weil die entsprechende Berechtigung fehlte.“ Die Lösung war simpel: Er fügte die fehlende Berechtigung iam:CreateRole über sein Admin-Konto hinzu. „Das war ein guter Reminder, immer die Berechtigungen meiner IAM-Benutzer zu prüfen, bevor ich Ressourcen provisioniere.“

Ein weiterer Fehler war ein Regionenkonflikt. Murphy hatte seine Lambda-Funktion in us-east-2 erstellt, während DynamoDB in us-east-1 lief. „Alles andere war in us-east-1 konfiguriert, also passte ich die Lambda-Region an“, sagt er. Doch das war nicht das einzige Problem: Die Lambda-Funktion konnte zunächst nicht auf DynamoDB zugreifen.

Die Dynamik der Berechtigungen

Die Standard-Ausführungsrolle von Lambda enthielt nur CloudWatch-Logging-Berechtigungen. „Ich musste vorübergehend die volle DynamoDB-Zugriffsberechtigung hinzufügen, um zu testen, ob alles funktioniert“, erklärt Murphy. Sobald das System lief, ersetzte er diese durch eine maßgeschneiderte Richtlinie, die nur die beiden benötigten Aktionen zulässt: dynamodb:GetItem und dynamodb:PutItem.

„Das ist das Prinzip der geringsten Berechtigungen in Aktion“, sagt er. „Selbst wenn meine Lambda-Funktion kompromittiert würde, könnte sie nur auf diese eine Tabelle zugreifen – nichts anderes im AWS-Konto wäre gefährdet.“

CORS und CloudFront: Die größten Frustrationen

Die größte technische Hürde war jedoch CORS (Cross-Origin Resource Sharing). Sein React-Frontend auf localhost wurde blockiert, weil der Browser vor jedem POST-Request einen OPTIONS-Preflight sendet. „API Gateway antwortete mit 404, weil die OPTIONS-Route nicht existierte“, erinnert sich Murphy. Die Lösung erforderte vier Schritte:

• Hinzufügen einer OPTIONS-Route in API Gateway
• Hinzufügen von CORS-Headern in jeder Lambda-Antwort
• Ergänzen eines expliziten OPTIONS-Handlers in Lambda
• Neuerstellung der gesamten API Gateway, da Deployment-Änderungen nicht übernommen wurden

„CORS erfordert Header in API Gateway UND Lambda“, erklärt Murphy. „Die Preflight-Route muss existieren, und Lambda muss sie explizit behandeln.“

Das finale Hindernis war CloudFront. Trotz korrekter Bucket-Policies erhielt Murphy weiterhin 403-Fehler. „Das Problem war, dass ich den S3-Website-Endpunkt verwendet habe“, sagt er. „CloudFront funktioniert nur mit dem REST-API-Endpunkt von S3.“ Nach der Umstellung auf den korrekten Endpunkt lief alles reibungslos.

Die wichtigsten Erkenntnisse aus dem Projekt

Murphys Fazit ist klar: „Dieses Projekt hat mir gezeigt, wie wichtig es ist, AWS-Dienste nicht nur technisch zu verstehen, sondern auch ihre Interaktionen zu begreifen.“ Seine drei wichtigsten Lehren:

• Regionen immer explizit definieren: „Ich habe gelernt, dass man bei der AWS-SDK-Konfiguration immer die Region hartkodieren sollte – besonders bei boto3.“
• Berechtigungen von Anfang an richtig setzen: „Die geringste Berechtigungsstrategie ist kein Luxus, sondern eine Notwendigkeit.“
• Fehler sind Lernchancen: „Jeder Fehler hat mir mehr über AWS beigebracht als jede Dokumentation. Ohne diese Erfahrungen hätte ich die Fallstricke nicht verstanden.“

Sein serverloses URL-Kürzungssystem ist nun einsatzbereit – und dient als solides Fundament für zukünftige AWS-Projekte. „Ich fühle mich jetzt besser vorbereitet für die SAA-C03-Zertifizierung und vor allem für meine Rolle als Cloud-Engineer“, sagt Murphy. „Dieses Projekt war der perfekte Einstieg in die Welt der serverlosen Architekturen.“

Für alle, die ähnliche Projekte planen, hat Murphy einen Rat: „Fang klein an, aber denk groß. Baue ein System, das du wirklich verstehst – und das dir gleichzeitig neue Herausforderungen bietet. Nur so lernt man AWS wirklich.“