AWS-basiertes Resume: So baust du dein Serverless-Profil

Die klassische Bewerbungsmappe als PDF ist out. Moderne Tech-Talente präsentieren ihre Skills heute mit einem interaktiven, serverlosen Resume – live im Netz. Genau das hat ein Entwickler mit dem Cloud Resume Challenge umgesetzt: Ein statisches Portfolio, das nicht nur ansprechend gestaltet ist, sondern auch eine echte Serverless-Infrastruktur nutzt. Besucherstatistiken, automatisierte Bereitstellung und eine vollständige Code-basierte Architektur machen das Projekt zu einem praktischen Einstieg in AWS-Services und DevOps-Praktiken.

Eine statische Website mit dynamischem Twist

Das Herzstück des Projekts ist eine vollständig statische Website – geschrieben in HTML und CSS. Diese wird in einem Amazon S3-Bucket abgelegt, der als kostengünstiger und hochverfügbarer Host dient. Doch der Clou liegt nicht im Frontend, sondern in der dahinterliegenden Infrastruktur:

• CloudFront agiert als globaler CDN-Cache, der die Ladezeiten weltweit optimiert und gleichzeitig die S3-Bucket-URL vor direktem Zugriff schützt.
• Route 53 leitet die benutzerdefinierte Domain (z. B. mein-resume.de) an die CloudFront-Verteilung weiter.
• Terraform provisioniert alle Ressourcen vollständig automatisiert – von der DNS-Konfiguration bis zu den Berechtigungen. Keine manuellen Klicks im AWS-Console nötig.

Sobald die Seite geladen ist, beginnt die Magie: Ein JavaScript-Code sendet eine Anfrage an API Gateway, das wiederum eine AWS Lambda-Funktion auslöst. Diese Lambda-Funktion ist der Schlüssel zum Besucher-Tracking.

Der Besucher-Tracker: DynamoDB, Lambda und API Gateway im Zusammenspiel

Der Besucher-Zähler ist ein separates, aber eng verzahntes System. Sobald ein Nutzer die Seite aufruft, passiert Folgendes:

1. Das Frontend lädt und rendert die Seite.
2. Ein JavaScript-Code im Browser sendet eine GET-Anfrage an API Gateway.
3. API Gateway leitet die Anfrage an eine Lambda-Funktion weiter – gesteuert durch eine Ressourcenrichtlinie, die festlegt, wer die Lambda überhaupt aufrufen darf.
4. Die Lambda-Funktion:

• Nutzt ihr Ausführungsrolle (Execution Role), um auf eine DynamoDB-Tabelle zuzugreifen.
• Liest den aktuellen Zählerstand aus der Tabelle.
• Erhöht den Wert um eins.
• Schreibt den neuen Stand zurück in die Tabelle.

1. Die Antwort wird über Lambda, API Gateway und schließlich das Frontend an den Nutzer zurückgegeben – der Zähler wird auf der Seite aktualisiert.

Jede Komponente hat ihre eigene IAM-Richtlinie, die genau definiert, welche Aktionen erlaubt sind. Dieser Dreiklang aus Serverless-Diensten zeigt, wie moderne Cloud-Architekturen mit minimalem Overhead skalieren können.

Was das Projekt wirklich lehrt: Terraform, Sicherheit und DevOps

Hinter den technischen Highlights stecken wertvolle Lektionen, die über das reine Programmieren hinausgehen. Hier die wichtigsten Erkenntnisse:

Infrastruktur als Code: Terraform dominiert

Terraform hat die Art und Weise verändert, wie der Entwickler AWS-Ressourcen aufbaut. Statt manuell im AWS-Console zu klicken, wurde jeder Teil der Infrastruktur in Code definiert:

• Versionierung: Alle Änderungen sind in Git nachvollziehbar.
• Wiederholbarkeit: Ein terraform apply baut das gesamte System von Grund auf neu auf.
• Fehlerbehebung: Probleme wie Abhängigkeitskonflikte (depends_on) wurden zur echten Herausforderung – Terraform weiß nicht automatisch, welche Ressource zuerst bereitgestellt werden muss.

resource "aws_lambda_function" "visitor_counter" {
  depends_on = [aws_dynamodb_table.resume_counter]
  # ... weitere Konfiguration
}

Datenbankwahl: DynamoDB statt Relational

Die Entscheidung für DynamoDB statt einer relationalen Datenbank wie Aurora Serverless fiel aus guten Gründen:

• Einfaches Datenmodell: Ein einziger Zählerstand, keine komplexen Abfragen.
• Skalierbarkeit: On-Demand-Pricing passt perfekt zu unvorhersehbaren Lastspitzen.
• Schemafreiheit: Kein starres Tabellendesign nötig – ideal für prototypische Projekte.

IAM und Sicherheit: Die unsichtbare Gefahr

Die größte Überraschung kam bei den Berechtigungen. Zwei zentrale Erkenntnisse:

1. Ausführungsrolle vs. Aufrufberechtigung:

• Die Ausführungsrolle einer Lambda-Funktion definiert, was die Funktion tun darf (z. B. DynamoDB lesen/schreiben).
• Die Ressourcenrichtlinie in API Gateway legt fest, wer die Lambda überhaupt aufrufen darf.
• Beide sind strikt voneinander getrennt – ein häufiger Fehlerpunkt.

1. Automatisierte Systeme brauchen eigene Identitäten:

• Der Entwickler lernte auf die harte Weise, dass GitHub Actions nicht mit persönlichen AWS-Zugangsdaten arbeiten sollte.
• Stattdessen wurden dedizierte IAM-Benutzer für die Pipeline erstellt – mit minimalen Berechtigungen.

Fallstricke und Lessons Learned

Jedes Projekt hat seine Stolpersteine. Drei wiederkehrende Muster prägten diese Erfahrung:

• Implizite Standardwerte: Lokale AWS-CLI-Einstellungen (z. B. Region) führten zu Fehlern, als der Code in einer frischen GitHub-Actions-Umgebung lief.
• Veraltete IAM-Richtlinien: Eine Pipeline scheiterte, weil sie keine Berechtigung hatte, sich selbst zu verwalten – ein klassisches Ownership-Problem.
• Monorepo vs. Multi-Repo: Anfangs in einem Repository gehalten, wurde das Projekt später in Frontend- und Backend-Repositories aufgeteilt, um unabhängige CI/CD-Pipelines zu ermöglichen.

Diese Herausforderungen zeigen: Infrastruktur wächst mit den Anforderungen – und wer sie von Anfang an sauber strukturiert, spart später Zeit.

Fazit: Ein Resume, das mehr ist als nur eine Seite

Das Cloud Resume Challenge-Projekt beweist, dass ein modernes Portfolio weit mehr sein kann als eine statische PDF-Datei. Es ist eine voll funktionsfähige Cloud-Anwendung, die Serverless-Technologien, Infrastruktur-as-Code und automatisierte Bereitstellung kombiniert.

Für Entwickler, die den Einstieg in AWS, DevOps oder moderne Webarchitekturen suchen, ist dieses Projekt ein praktischer Leitfaden – mit echten Fehlern, Lösungen und Best Practices. Und das Beste: Am Ende steht nicht nur ein beeindruckendes Resume, sondern auch ein tiefes Verständnis dafür, wie Cloud-Infrastrukturen heute funktionieren.