Serverless-Kontaktformulare mit AWS SAM: Warum sie bei Kosten, Sicherheit und Einfachheit gewinnen
Die meisten Kontaktformulare laufen immer noch auf einem Webserver, der 99,9 Prozent der Zeit idle ist. Ein WordPress-Plugin, eine Node.js-Express-Route oder ein Python-Flask-Endpunkt auf einem VPS, den niemand patcht und niemand überwacht. Das Formular bekommt eine Handvoll Einreichungen pro Tag, aber der Server läuft rund um die Uhr und sammelt Kosten, Risiko und operativen Ballast an.
Serverless-Architektur ändert sowohl die Ökonomie als auch die Sicherheitsposition gleichzeitig. Ein einziges AWS-SAM-Template kann das gesamte Backend für ein Produktions-Kontaktformular definieren: API Gateway für Routing und CORS, Lambda für Request-Handling, DynamoDB für Speicherung, SES für E-Mail-Benachrichtigungen und CloudWatch für Monitoring. Keine Server zu verwalten. Keine Patches anzuwenden. Keine Skalierung zu konfigurieren.
Dieser Beitrag behandelt, warum diese Architektur für die meisten Teams, die statische Sites und moderne Web-Properties ausliefern, die bessere Wahl ist, und wann sie es nicht ist.
Die echten Kosten „einfacher” Kontaktformulare
Ein traditionelles Kontaktformular-Backend scheint einfach: einen Server aufsetzen, einen POST-Handler schreiben, Einreichungen in einer Datenbank speichern, vielleicht eine Benachrichtigungs-E-Mail senden. Aber die echten Kosten umfassen alles drum herum.
Die offensichtlichen Kosten sind leicht zu übersehen, weil sie nicht im Anwendungscode stecken:
- Ein VPS oder Container, der 24/7 läuft, auch wenn null Anfragen ankommen
- SSL-Zertifikatserneuerung und -verwaltung
- Betriebssystem-Patching und Runtime-Updates
- Datenbank-Backups, Connection-Pools und Speicherwachstum
- SMTP-Relay-Verwaltung und Zustellbarkeitsmonitoring
- Uptime-Monitoring, Log-Management und Alerting
Für ein Formular, das fünf bis fünfzig Einreichungen pro Tag verarbeitet, summieren sich diese Kosten schnell relativ zur tatsächlichen Arbeitslast.
Ein Serverless-Stack ändert die Rechnung. API Gateway berechnet ungefähr einen Dollar pro Million Anfragen. Lambda bleibt im Free Tier für die meisten Kontaktformular-Workloads. DynamoDB On-Demand-Abrechnung kostet etwa 1,25 Dollar pro Million Write Request Units. SES berechnet etwa zehn Cent pro tausend E-Mails.
Eine Site, die tausend Formulareinreichungen pro Monat verarbeitet, zahlt unter fünfzig Cent pro Monat für das gesamte Backend. Vergleichen Sie das mit fünf bis zwanzig Dollar pro Monat für selbst den günstigsten VPS, vor den Zeitkosten für Patches, Backups und Uptime-Checks.
Der Kostenvorteil liegt nicht nur bei der Hosting-Rechnung. Er liegt in der operativen Zeit, die verschwindet. Kein Server-Patching. Keine Datenbank-Backups. Keine Kapazitätsplanung. Keine Middleware zu pflegen.
Sicherheit durch Design, nicht durch Aufwand
Der Sicherheitsvorteil serverloser Kontaktformular-Backends ist nicht theoretisch. Er kommt davon, Angriffsfläche zu entfernen statt Verteidigungen hinzuzufügen.
Es gibt keinen Server zum Patchen, kein Betriebssystem zum Härten, keine offenen Ports zu verwalten und keinen langlebigen Prozess zum Kompromittieren. Die Runtime existiert nur, wenn eine Anfrage eintrifft, und verschwindet nach Abschluss.
IAM-Policies setzen Least Privilege auf Infrastrukturebene durch. Der Submit-Handler bekommt DynamoDB-Schreibzugriff und SES-Sendeerlaubnis. Der List-Handler bekommt DynamoDB-Lesezugriff. Der Health-Check bekommt Nur-Lese-Zugriff. Keine Funktion hat breitere Berechtigungen als ihr spezifischer Job erfordert.
Eingabevalidierung passiert am Edge. Ein Schema-Registry ordnet jeden Einreichungstyp seinen erforderlichen Datenfeldern zu. Payloads, die nicht passen, werden abgelehnt, bevor sie den Speicher berühren. Feldzahl-Limits, Schlüssellängen-Limits und Wertgrößen-Limits verhindern Missbrauch selbst für gültige Einreichungstypen.
Rate Limiting nutzt DynamoDB selbst. Der Handler zählt kürzliche Einreichungen von derselben E-Mail-Adresse pro Site und lehnt Anfragen ab, die den Schwellenwert überschreiten. Der Rate Limiter ist fail-closed: Wenn die DynamoDB-Zählerabfrage aus irgendeinem Grund fehlschlägt, wird die Einreichung abgelehnt. Das verhindert Missbrauch während partieller Ausfälle.
CORS-Origin-Validierung passiert auf API-Gateway-Ebene. Nur whitelistete Origins erhalten CORS-Header. Cross-Origin-Anfragen von unbekannten Domains scheitern, bevor sie irgendeinen Handler erreichen.
E-Mail-Unterdrückung handhabt Bounces und Beschwerden automatisch. Wenn SES einen permanenten Bounce oder eine Beschwerde meldet, fügt ein SNS-getriggerter Lambda die Adresse einer Unterdrückungstabelle hinzu. Zukünftige E-Mails an diese Adresse werden übersprungen.
Admin-Endpunkte nutzen API-Key-Authentifizierung mit konstantzeitigem Vergleich über SHA-256-Hashing zur Verhinderung von Timing-Angriffen.
Das sind keine optionalen Sicherheits-Add-ons. Sie sind von Anfang an in die Architektur eingebaut. Für mehr zu API-Level-Sicherheitskontrollen siehe unseren Leitfaden für API-Sicherheits-Best-Practices. Für die breitere Vertrauensarchitektur, die diese Kontrollen unterstützen, siehe unseren Zero-Trust-Leitfaden.
Multi-Site von Anfang an
Einer der am meisten unterschätzten Vorteile eines gut gestalteten serverlosen Formular-Backends ist Multi-Site-Unterstützung ohne zusätzliche Infrastruktur.
Die Architektur nutzt zwei Registries: eine Site-Registry und eine Schema-Registry. Die Site-Registry ordnet Site-Identifikatoren der Konfiguration zu: Benachrichtigungs-E-Mail, erlaubte Einreichungstypen, Absender-E-Mail, Reply-To-Adresse und Branding. Die Schema-Registry ordnet Einreichungstypen ihren erforderlichen Datenfeldern zu.
Eine neue Site hinzuzufügen bedeutet, einen Eintrag zur Site-Registry und ihren Origin zur CORS-Allowlist hinzuzufügen. Keine neuen Lambda-Funktionen, keine neuen API-Gateway-Routen, keine neuen DynamoDB-Tabellen.
DynamoDB isoliert Daten zwischen Sites natürlich über das Partition-Key-Muster SITE#<site-identifier>. Die Einreichungen jeder Site leben in ihrer eigenen Partition. Abfragen sind standardmäßig auf eine einzelne Site beschränkt. Es gibt kein Risiko von Cross-Site-Datenleckage durch eine fehlende WHERE-Klausel.
Operative Einfachheit, die skaliert
Das gesamte serverlose Formular-Backend wird in einem einzigen SAM-Template definiert. API Gateway, Lambda-Funktionen, DynamoDB-Tabellen, SNS-Topics, CloudWatch-Log-Gruppen, Metric-Filter und Alarme. Eine Datei, ein Deployment.
Deployment sind zwei Befehle: sam build und sam deploy. Keine Docker-Images. Keine Kubernetes-Manifeste. Keine Load Balancer. Keine Auto-Scaling-Gruppen. Das erste Deploy erstellt alles von Grund auf. Nachfolgende Deploys aktualisieren nur, was sich geändert hat.
Monitoring ist im Template eingebaut. CloudWatch-Log-Gruppen bekommen 30 Tage Retention. Metric-Filter verfolgen Fehler, Rate-Limit-Treffer, erfolgreiche Einreichungen, Bounces, Beschwerden und Authentifizierungsfehler. Alarme feuern, wenn Schwellenwerte überschritten werden.
Datenretention handhabt sich selbst. Einreichungen bekommen eine 90-Tage-TTL. DynamoDB löscht abgelaufene Einträge automatisch. Keine Cron-Jobs, keine Cleanup-Skripte und keine Speicherkosten, die unbegrenzt wachsen.
Skalierung erfordert keine Konfiguration. API Gateway und Lambda handhaben, welchen Traffic auch immer ankommt. Wenn ein Formular viral geht und zehntausend Einreichungen in einer Stunde erhält, handhabt dieselbe Architektur das. Wenn es eine Woche lang null Einreichungen erhält, sind die Kosten null.
Frontend-Integrationsmuster
Ein serverloses Kontaktformular-Backend funktioniert mit jedem Frontend, das einen HTTP-POST-Request machen kann. Das umfasst Astro, Next.js, Hugo, Gatsby, reines HTML und Single-Page-Apps mit React, Vue oder Svelte.
Das Frontend sendet einen JSON-Payload mit dem Site-Identifikator, Einreichungstyp, E-Mail-Adresse und Datenfeldern. Das Backend validiert den Payload, prüft Rate Limits, speichert die Einreichung, sendet Benachrichtigungen und gibt eine Antwort zurück. Das ist die gesamte Integration.
Spam-Prävention auf dem Frontend nutzt ein Honeypot-Muster: ein verstecktes Formularfeld, das echte Benutzer nie ausfüllen. Wenn das Feld einen Wert hat, verwirft das Frontend die Einreichung still, ohne die API zu treffen. Kein CAPTCHA, keine Reibung, keine Drittanbieter-Abhängigkeit.
All das funktioniert mit Vanilla JavaScript. Kein framework-spezifisches SDK, keine Client-Library, keine Build-Time-Abhängigkeit. Der Formular-Handler ist ein fetch-Aufruf mit einem JSON-Body.
Wann Serverless nicht die richtige Wahl ist
Serverlose Kontaktformular-Backends funktionieren für die überwiegende Mehrheit der Sites gut, sind aber nicht universell.
Hochvolumige transaktionale Formulare, die Tausende von Einreichungen pro Minute verarbeiten, können von dedizierter Infrastruktur profitieren. Komplexe Formular-Workflows mit mehrstufigen Einreichungen, Dateiuploads, Genehmigungsketten oder bedingter Logik können einfache Lambda-Handler überfordern. Vendor-Lock-in ist real — diese Architektur ist zutiefst AWS-spezifisch. Regulatorische Anforderungen, die spezifische Datenresidenz, Hosting-Modelle oder Audit-Fähigkeiten vorschreiben, sind möglicherweise nicht vollständig ohne zusätzliche Kontrollen erfüllbar.
Starten Sie mit der Architektur-Checkliste
Serverlose Kontaktformular-Backends eliminieren den operativen Aufwand, Server für Workloads zu betreiben, die sie nicht rechtfertigen. Sie reduzieren Kosten auf nahezu null für typischen Traffic, verbessern die Sicherheitsposition durch Entfernung von Angriffsfläche und vereinfachen den Betrieb auf ein einziges Template und zwei Deployment-Befehle.
Der beste nächste Schritt ist, Ihre aktuelle Kontaktformular-Infrastruktur gegen das zu auditieren, was eine serverlose Architektur bietet, und zu entscheiden, ob der Wechsel für Ihre Sites sinnvoll ist.
Holen Sie sich die kostenlose Serverless-Form-Architektur-Checkliste →
Für die schrittweise technische Anleitung zum Bauen und Deployen dieser Architektur siehe unser Begleittutorial.
Für verwandte Sicherheits- und Architekturleitfäden siehe unseren Leitfaden für API-Sicherheits-Best-Practices, unseren Zero-Trust-Architekturleitfaden und unsere Roadmap für Software-Lieferkettensicherheit.