Demo-Pass — eigene Instanz je Besucher#

Stand: 2026-09-30 · Stufe 1 umgesetzt (Phase 4, Release v0.4.0) · Kennzeichnung: [B] belegt (offizielle Quelle), [A] Annahme/Schätzung, [E] Einschätzung.

Entscheidung (29.09.2026): Stufe 1 — Inhaber-Zugang und Einladungslinks. Ein bezahlter Zugang ist optional für später denkbar, aber nicht geplant.

Umgesetzt (30.09.2026): Stufe 1 ist gebaut und live geprüft — Einladungslinks aus dem Cockpit, Einlösen mit ALTCHA, eigener Mandant im Bridge-Modell in ≈ 10 s, Kontingente, Ablauf und Rückbau nach 7 Tagen, höchstens 3 gleichzeitige Pass-Mandanten. Wie es gebaut ist, beschreibt Architektur: Mandanten und Demo-Pass. Diese Seite bleibt die Entscheidungsgrundlage; wo die Umsetzung vom ursprünglichen Vorschlag abweicht, ist das vermerkt.

Fachbegriffe sind in jedem Abschnitt beim ersten Vorkommen mit dem Glossar verlinkt (Erklärung und Entsprechung außerhalb von AWS).

1. Anforderungen (29.09.2026)#

1. Der Inhaber kann die Demo für sich selbst jederzeit starten.
2. Die öffentliche Demoseite ist für alle zugänglich.
3. Ein Demo-Pass ist 7 Tage nutzbar, auch mehrfach, solange das Kontingent reicht; danach werden Instanz und Daten gelöscht.
4. Jeder Besucher bekommt eine eigene Instanz — Besucher stören sich gegenseitig nicht.
5. Spam- und Missbrauchsabwehr ist Pflicht.

2. Ergebnis#

Machbar [E]. Alle Teile — Freischaltung, eigene Instanz, Kontingent, Ablauf nach 7 Tagen — lassen sich mit den ohnehin geplanten, kostenlosen AWS-Bausteinen (Lambda, DynamoDB, EventBridge Scheduler, SNS) bauen. Der Demo-Pass wird dabei selbst zu einem vorzeigbaren Stück SaaS-Architektur: Mandantenfähigkeit, Bereitstellung auf Knopfdruck, automatischer Rückbau.

Eine Instanz kostet bei Demo-Nutzung Bruchteile eines Cents [A]. Den Zugang steuern deshalb Einladungslinks statt einer offenen Selbstbedienung: Sie halten Bots fern, ohne Besucher warten zu lassen.

3. Zwei Wege zum Demo-Pass#

Beide erzeugen dasselbe: einen Demo-Pass (7 Tage, Kontingent, eigene Instanz). Sie unterscheiden sich nur darin, wer ihn ausstellt.

Optional später: bezahlter Zugang für die Öffentlichkeit (nicht geplant) — technisch nur ein weiterer Aussteller desselben Demo-Passes.

Einladungslinks sind personenbezogen; ihre Nutzung gehört in die Datenschutzerklärung.

4. Ablauf für Besucher#

Technisch: Die Ausstellung legt den Pass in DynamoDB an und veröffentlicht das Domänen-Event DemoPassIssued; daraufhin wird der Mandant eingerichtet, und EventBridge Scheduler plant den Ablauf in 7 Tagen.

Umsetzung: So gebaut, mit zwei Abweichungen: Das System verschickt außer dem Einmal-Passwort von Cognito keine E-Mails (auch keine Bestätigung nach dem Löschen), und die Instanz „schläft" nicht eigens — geteilte Lambdas kosten ohne Aufrufe ohnehin nichts. Details: Architektur: Mandanten und Demo-Pass §4 und §7.

5. Eigene Instanz je Besucher#

„Eigene Instanz" lässt sich unterschiedlich tief umsetzen — in der SaaS-Architektur heißen die Modelle Silo, Bridge und Pool [E]:

Empfehlung: Bridge [E] — entschieden am 29.09.2026. Jeder Besucher bekommt einen eigenen Mandanten mit eigener DynamoDB-Tabelle (provisioned 5 RCU/5 WCU, Entscheidung 29.09.2026 — nur provisionierte Kapazität fällt unter Always Free; die 25 kostenlosen Einheiten je Konto und Region teilen sich alle Tabellen einschließlich Plattform-Tabelle, ein GSI belegt eigene Kapazität [E]; darüber hinaus trägt bis 29.09.2027 das Startguthaben), eigenem Datenstand beider Altsysteme auf dem eigenen Server (je Mandant ein eigenes Datenbankschema aus einer Vorlage) und eigenen Ereignis-Regeln auf dem gemeinsamen Bus. Die Lambdas werden geteilt, aber je Mandant gedrosselt; IAM-Bedingungen verhindern, dass eine Lambda auf die Tabelle eines anderen Mandanten zugreift. Start in Sekunden statt Minuten — wichtig, weil Besucher sonst wieder warten.

Umsetzung: Eigene Ereignis-Regeln je Mandant sind nicht nötig geworden — jedes Ereignis trägt tenantId, Konsumenten schreiben nur in die Tabelle dieses Mandanten, und eine einzige Regel zählt die Ereignisse aller Pass-Mandanten. Die Drosselung je Mandant ist das API-Kontingent; den Zugriff auf fremde Tabellen verhindert eine Token Vending Machine mit Sitzungs-Tag (Architektur: Mandanten und Demo-Pass §3).

Silo bleibt als Option für den Inhaber-Zugang (eigener vollständiger Stack auf Knopfdruck zeigt „Infrastruktur als Code" am deutlichsten).

Kontingent je Pass [A], als Vorschlag (umgesetzt wie unten, außer den E-Mails: nur das Einmal-Passwort — Architektur: Mandanten und Demo-Pass §5):

6. Spam- und Missbrauchsschutz#

7. Stufenplan [E]#

1. Stufe 1 – Inhaber-Zugang und Einladungslinks. Die Kosten (Cent-Bruchteile je Mandant) trägt der Inhaber. Umgesetzt (30.09.2026, v0.4.0). Der Inhaber-Mandant (owner) bleibt in der Tabelle der Base und läuft dauerhaft; Einladungslinks erzeugt er im Cockpit unter /cockpit/paesse.
2. Die öffentliche Seite zeigt von Anfang an Video, Architektur und Code — kostenlos, ohne Instanz.

8. Auswirkungen auf bisherige Entscheidungen#

• Die Betriebsarten Z1–Z3 (Kostenfreier Betrieb) werden durch den Demo-Pass ersetzt: Die gemeinsame Grundlage (Seite, Login, SSR-Lambda, geteilte Lambdas, Cognito) läuft dauerhaft und kostenlos; Mandanten entstehen nur mit einem Pass und verschwinden nach 7 Tagen. Das ist die Z3-Idee („kostet nur, wenn jemand es nutzt"), sauber an einen Einladenden gebunden.
• Kosten der gemeinsamen Cent-Dienste (API Gateway, EventBridge, S3) entstehen nur durch Mandanten, also durch Pass-Inhaber.
• Neu im Umfang: Pass-Verwaltung, Einladungslinks, Verwaltungsbereich für den Inhaber — gebaut in Phase 4 (Service tenancy, Seiten /pass und /pass/einloesen in der Shell, /cockpit/paesse).

Quellen#

• EventBridge-Quoten: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html · DynamoDB-Quoten: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html