OpenReception auf AWS bereitstellen: Eine Referenzarchitektur für souveräne Terminbuchung

Was ist OpenReception? 

OpenReception ist eine Ende-zu-Ende-verschlüsselte Open-Source-Lösung für Terminbuchung und Patientenkommunikation – entwickelt als datenschutzkonforme Alternative zu proprietären Plattformen wie Doctolib. Das Projekt wird vom Bundesministerium für Bildung und Forschung (BMBF) gefördert und steht unter der AGPL-3.0-Lizenz. Am 3. Mai 2026 wurde Version 1.0.0 veröffentlicht. 

Die Kernfeatures: – E2E-Verschlüsselung aller Patientendaten und Termine – Multi-Tenant-Architektur mit isolierten Datenbanken pro Praxis – Self-Hosting-fähig – volle Datenhoheit bleibt beim Betreiber – Modularer Aufbau mit separaten Services (API, Frontend, Worker, Datenbank) 

Dieser Artikel beschreibt eine Referenzarchitektur für das Deployment auf AWS – ohne Codeänderungen an der Anwendung selbst. Ein getestetes AWS Cloud Development Kit (AWS CDK)-Template steht zur Verfügung. 

Warum AWS? 

Für den Betrieb von OpenReception in Produktionsumgebungen bietet AWS entscheidende Vorteile: 

• Managed Services: Kein Betrieb eigener Datenbank-Server oder Load Balancer erforderlich 

• Sicherheit: Private Subnets, Encryption at Rest und in Transit, IAM-basierte Zugriffskontrolle 

• Skalierbarkeit: AWS Fargate skaliert Container automatisch nach Last 

• Compliance: Die AWS-Region eu-central-1 (Frankfurt) erfüllt deutsche Datenschutzanforderungen – alle Daten bleiben in Deutschland. AWS verfügt über eine C5-Attestierung (Cloud Computing Compliance Criteria Catalogue) des BSI, die für den Einsatz im öffentlichen Sektor und im Gesundheitswesen in Deutschland maßgeblich ist. 

• Souveränität: Für Organisationen mit höchsten Anforderungen an digitale Souveränität steht zusätzlich die AWS European Sovereign Cloud zur Verfügung – eine eigenständige, physisch und logisch getrennte Cloud-Infrastruktur, die ausschließlich in der EU betrieben und von in der EU ansässigen Mitarbeitern kontrolliert wird. 

• Betriebskosten: Pay-per-Use statt dedizierter Hardware 

Architekturübersicht 

Das offizielle Docker-Image von OpenReception (openreception/open-reception:latest) wird direkt von Docker Hub bezogen – kein eigener Build-Schritt oder Container-Registry erforderlich. Die Architektur bildet sich wie folgt auf AWS ab: 

Warum Amazon CloudFront? Die Anwendung setzt in ihrer Content Security Policy upgrade-insecure-requests als hardcoded Header. Das bedeutet: Der Browser erzwingt HTTPS für alle Requests. Ohne HTTPS-Frontend wird die Anwendung nicht korrekt geladen. Amazon CloudFront stellt HTTPS mit einem kostenlosen AWS Certificate Manager (ACM)-Zertifikat bereit und leitet den Traffic an den internen ALB weiter. 

Architekturdiagramm 

Schritt-für-Schritt Deployment 

Das gesamte Deployment erfolgt über ein getestetes AWS CDK-Template (TypeScript). Drei Befehle, circa 8 Minuten: 

# 1. Abhängigkeiten installieren

git clone https://github.com/aws-samples/sample-openreception-on-aws

cd sample-openreception-on-aws
npm install

# 2. CDK deployen
npx cdk deploy --all

# 3. Fertig – CloudFront-URL aus dem CDK-Output nutzen 

Das AWS CDK-Template erstellt automatisch: – Amazon Virtual Private Cloud (Amazon VPC) mit Public und Private Subnets – Amazon RDS für PostgreSQL 16 mit angepasster Parameter Group – Amazon ECS Fargate Service mit dem Docker-Hub-Image – Application Load Balancer mit Health Checks – Amazon CloudFront-Distribution für HTTPS – AWS Secrets Manager für Datenbank-Credentials – Alle Security Groups und IAM-Rollen 

Amazon RDS Parameter Group: SSL deaktivieren 

Ein wichtiges Detail beim Deployment: Der interne Migrations-Service von OpenReception baut Datenbank-Verbindungen programmatisch auf – ohne SSL-Parameter. Bei aktiviertem rds.force_ssl schlagen diese internen Admin-Verbindungen fehl. 

Die Lösung ist eine Custom Parameter Group mit rds.force_ssl=0: 

const parameterGroup = new rds.ParameterGroup(this, 'PG', {
  engine: rds.DatabaseInstanceEngine.postgres({
    version: rds.PostgresEngineVersion.VER_16
  }),
  parameters: { 'rds.force_ssl': '0' },
}); 

Die Anwendungsverbindungen selbst (über DATABASE_URL) können weiterhin SSL nutzen – nur die internen Admin-Verbindungen des Migrations-Services benötigen den Fallback ohne SSL. 

Multi-Tenant auf Amazon RDS: Dynamische Datenbank-Erstellung 

OpenReception nutzt ein Multi-Tenant-Modell mit einer separaten PostgreSQL-Datenbank pro Praxis beziehungsweise Mandant. Bei der Registrierung einer neuen Praxis erstellt die Anwendung automatisch: 

1. Eine neue Datenbank auf der Amazon RDS-Instanz 

1. Einen dedizierten Datenbank-User mit eingeschränkten Rechten 

1. Das vollständige Schema via Migrations 

Auf AWS bedeutet das: – Der Management-User der Amazon RDS-Instanz muss CREATE DATABASE-Rechte haben – Die Amazon ECS-Tasks verbinden sich mit dem Management-User für Tenant-Provisioning – Laufende Anfragen nutzen den tenant-spezifischen User – Skalierungsgrenze: Eine db.t4g.micro-Instanz unterstützt problemlos 50 und mehr separate Datenbanken 

Herausforderungen beim Deployment 

Beim Deployment von OpenReception auf AWS sind drei Besonderheiten aufgefallen, die in der Projektdokumentation nicht beschrieben sind: 

SSL-Verbindungen zur Datenbank 

Der interne Migrations-Service von OpenReception baut Admin-Verbindungen zur Datenbank programmatisch auf – ohne SSL-Parameter. Das ist im lokalen Docker-Compose-Setup kein Problem, aber auf Amazon RDS mit erzwungenem SSL schlagen diese Verbindungen fehl. Lösung: rds.force_ssl=0 in der Amazon RDS Parameter Group (siehe oben). 

Content Security Policy erzwingt HTTPS 

Die Anwendung setzt den CSP-Header upgrade-insecure-requests hardcoded im Security-Header-Handler. Das bedeutet: Jeder Browser-Request wird automatisch auf HTTPS hochgestuft. Ohne HTTPS-fähiges Frontend bleibt die Seite in einer Redirect-Schleife. Lösung: Amazon CloudFront als HTTPS-Frontend vor dem ALB. 

Schema-Migration beim ersten Start 

Beim allerersten Deployment muss die zentrale Datenbank initialisiert werden. Der Migrations-Service erwartet eine leere Datenbank und führt das Schema-Setup automatisch durch. Falls die erste Amazon ECS-Task fehlschlägt (beispielsweise wegen Timing mit Amazon RDS), genügt ein Neustart des Services – die Migration ist idempotent. 

Sicherheitsaspekte 

Netzwerk-Isolation 

• Amazon CloudFront als einziger Internet-Zugang (HTTPS) 

• ALB in privaten Subnets, akzeptiert nur Traffic von Amazon CloudFront 

• Amazon ECS Tasks und Amazon RDS in privaten Subnets ohne direkten Internet-Zugang 

• Security Groups: Minimale Regeln – ALB→ECS:3000, ECS→RDS:5432 

Verschlüsselung 

• At Rest: Amazon RDS Storage Encryption (AES-256) 

• In Transit: TLS 1.3 via Amazon CloudFront, HTTPS zwischen Browser und CloudFront 

• Anwendungsebene: E2E-Verschlüsselung der Patientendaten durch OpenReception selbst 

Secrets Management 

• Keine Credentials in Task Definitions oder Umgebungsvariablen 

• Datenbank-Credentials via AWS Secrets Manager 

• IAM-Rollen statt statischer Access Keys 

Kostenübersicht 

Mit den Default-Werten des CDK-Templates (1 Fargate Task, db.t4g.micro, Single-AZ) ist eine nutzbare Umgebung ab unter 100 € pro Monat in eu-central-1 (Frankfurt) möglich. Die tatsächlichen Kosten hängen stark davon ab, wie die Lösung im Einzelfall konfiguriert, skaliert und betrieben wird – beispielsweise durch Multi-AZ-Deployments, größere Instanztypen oder höheres Datenvolumen. Preise unterliegen Änderungen; aktuelle Preise finden Sie auf den jeweiligen AWS-Service-Preisseiten. 

Fazit 

OpenReception lässt sich ohne Codeänderungen auf AWS betreiben – das offizielle Docker-Image von Docker Hub wird direkt in Amazon ECS mit AWS Fargate deployed. Ein getestetes AWS CDK-Template macht das Deployment in unter 10 Minuten möglich. Die Referenzarchitektur bietet: 

• Datensouveränität: Betrieb in deutschen AWS-Regionen, volle Kontrolle über Patientendaten 

• Einfaches Deployment: npm install && cdk deploy – fertig 

• Kosteneffizienz: Circa 86 Euro pro Monat für eine produktionsreife Umgebung 

• Skalierbarkeit: Von einer einzelnen Praxis bis zu hunderten Mandanten auf derselben Infrastruktur 

Für öffentliche Einrichtungen und Gesundheitsdienstleister, die eine DSGVO-konforme, selbst gehostete Terminbuchung suchen, bietet diese Architektur einen produktionsreifen Einstieg – mit der Flexibilität, bei wachsenden Anforderungen nahtlos zu skalieren. 

Weiterführende Ressourcen 

• AWS CDK-Template für OpenReception — Referenzarchitektur und Infrastructure-as-Code 

• AWS CDK Developer Guide — Einstieg in Infrastructure as Code mit AWS CDK 

• Amazon ECS Best Practices — Best Practices für Container-Workloads 

• Amazon RDS für PostgreSQL — Dokumentation zu Amazon RDS für PostgreSQL 

• OpenReception auf GitHub [Extern] — Quellcode und Dokumentation des Projekts 

 Über die Autoren

Michael Wahlers, Principal Solutions Architect und Public Sector Specialist, ist in Deutschland, Österreich und der Schweiz tätig. Mit leidenschaftlichem Enthusiasmus unterstützt er öffentliche Einrichtungen mit innovativen digitalen Lösungen. Seine Expertise gewährleistet eine nahtlose Servicebereitstellung und macht ihn zu einem wertvollen Aktivposten für die Gestaltung der digitalen Zukunft des öffentlichen Sektors in der Region. Neben seinen beruflichen Verpflichtungen erforscht er gerne komplexe verteilte Systeme und bezieht lokale Kontexte in seine Arbeit mit ein.

David Surey ist Senior Technical Account Manager bei AWS Enterprise Support mit Fokus auf den deutschen, öffentlichen Sektor. Mit 25 Jahren Erfahrung in verschiedenen IT-Rollen und Branchen unterstützt er Behörden und öffentliche Einrichtungen bei der sicheren Cloud- Transformation. Er führt Architektur-Reviews durch, begleitet kritische Migrationen und treibt Innovationen in hochregulierten Umgebungen voran. Seine Expertise umfasst Sovereign Cloud-Lösungen, Compliance-Anforderungen und die Modernisierung komplexer Legacy-Infrastrukturen.