Architektur · Grundlagen
WordPress-Referenzarchitektur auf AWS
Eine detaillierte technische Übersicht darüber, wie WordPress als redaktionelle Ebene dient, während AWS Identität, statische Bereitstellung, geschützte Laufzeit, KI und Workflows übernimmt.
Architekturthese: WordPress sollte das CMS und die Administrationsoberfläche bleiben, nicht jedoch die einzige Laufzeitgrenze für jede Funktion. WP Suite macht WordPress zu einem modularen Anwendungs-Frontend, indem Identität, geschützte Bereitstellung, KI, APIs und Workflows in AWS-Dienste im Eigentum des Kunden verlagert werden.
Warum diese Architektur existiert
Die meisten WordPress-Architekturdiagramme gehen noch immer von derselben Annahme aus: WordPress stellt die öffentliche Laufzeit bereit. PHP rendert die Seite, MySQL bedient die Anfrage, Plugins werden im selben Prozess ausgeführt, und Skalierung bedeutet, demselben Stack mehr Kapazität hinzuzufügen.
WP Suite verfolgt einen anderen Ansatz. WordPress bleibt die redaktionelle und administrative Steuerungsebene, die Laufzeitverantwortung wird jedoch auf AWS-Dienste verteilt, die für die jeweilige Aufgabe besser geeignet sind: statische Bereitstellung am Edge, Identität in Cognito, APIs in API Gateway und Lambda, KI in Bedrock-gestützten Diensten und Workflows in einer ereignisgesteuerten Infrastruktur.
Es geht nicht darum, WordPress durch einen Headless-Neuaufbau zu ersetzen. Stattdessen soll vermieden werden, jede Anwendungsfunktion durch die WordPress-Laufzeit zu führen, wenn die Website längst mehr als eine reine Publishing-Website ist.
Systemgrenze
Redakteure / Administratoren
│
▼
WordPress + Gutenberg
Inhalte, Layout, Einstellungen, Admin-UX
│
WP Suite-Integrationsschicht
│
┌─────────────────────────┼─────────────────────────┐
│ │ │
▼ ▼ ▼
Statische Bereitstellung Identitätsebene Laufzeit-APIs
Static Publisher Gatey + Cognito API Gateway + Lambda
S3 + CloudFront User/Identity Pools Geschäftslogik
│ │ │
└──────────────┬──────────┴──────────────┬──────────┘
▼ ▼
Browser-Laufzeit KI- / Workflow-Ebene
Gutenberg-gerenderte Seiten Bedrock, S3, DynamoDB,
clientseitige Komponenten EventBridge, SES, WAF
Die Grenze ist bewusst unspektakulär: WordPress ist für die Inhaltserstellung, URL-Struktur, Gutenberg-Markup, redaktionelle Workflows und Modulkonfiguration verantwortlich. AWS übernimmt Ausführungspfade, die unabhängige Skalierung, stärkere Isolierung, identitätsbasierten Zugriff, Ereignisverarbeitung oder Modellzugriff erfordern.
Static Publisher ist Teil der Bereitstellung, aber für sich genommen kein CloudFormation-Stack. Er exportiert und veröffentlicht die gerenderte Website in einem AWS-Bereitstellungsziel; die Stack-basierten Funktionen liegen in den Bereichen Identität, geschützte Bereitstellung, KI-Backend und Workflow-Laufzeit.
Funktionsübersicht
Inhaltsebene
WordPress und Gutenberg
Die vertraute Bearbeitungsebene bleibt die maßgebliche Quelle für Seiten, Beiträge, Blöcke, CPT-Inhalte, Layout, Metadaten und Produktkonfiguration.
Bereitstellungsebene
Static Publisher, S3 und CloudFront
Gerenderte Seiten und Assets können über S3 und CloudFront bereitgestellt werden, sodass der öffentliche Datenverkehr nicht mehr von aktiver PHP-/MySQL-Kapazität abhängt.
Identitätsebene
Gatey und Amazon Cognito
Authentifizierung, Registrierung, MFA, SSO, Gruppen, JWTs und optionale IAM-Anmeldedaten werden an Cognito delegiert und direkt im Browser verwendet.
Geschützte statische Ebene
Static Site Guardian
Ausgewählte statische Pfade lassen sich bei CloudFront mit signierten Cookies, einem Signierdienst und Cognito-basierten Anmeldeabläufen schützen.
Anwendungslaufzeit
API Gateway und Lambda
Laufzeitfunktionen wie Kontoaktionen, geschützte Daten, Workflow-Schritte und Integrationslogik werden als gezielte APIs statt als WordPress-AJAX-Endpunkte bereitgestellt.
KI-Laufzeit
AI-Kit, Bedrock und S3 Vectors
KI auf dem Endgerät kann lokale Aufgaben übernehmen; Backend-Fallback und RAG-Workflows laufen bei Bedarf in einem AWS-Backend im Eigentum des Kunden.
Workflow-Ebene
Flow und ereignisgesteuerte Dienste
Formulare und mehrstufige Übermittlungen können E-Mail-, Webhook-, EventBridge-, KI-Agenten- und Backend-Verarbeitungsabläufe auslösen.
Bereitstellungsebene
Deployment Wizard und CloudFormation
Wiederholbare AWS-Funktionen werden über geführte Vorlagen bereitgestellt, damit Agenturen und Teams die Implementierung standardisieren können, ohne jeden Stack manuell aufzubauen.
Kanonische Anfrageabläufe
Ablauf 1
Öffentliche statische Seitenanfrage
Ein Besucher ruft eine öffentliche Seite auf. CloudFront liefert das exportierte HTML und die Assets aus S3 aus. WordPress liegt nicht im Anfragepfad; Lastspitzen treffen daher das CDN und nicht PHP-Worker und Datenbankverbindungen.
Ablauf 2
Status eines angemeldeten Benutzers
Gatey rendert die Cognito-Anmeldeoberfläche auf der Seite. Der Browser authentifiziert sich bei Cognito, erhält Token und stellt den WP Suite-Blöcken den Identitätsstatus bereit, ohne Geheimnisse oder Token auf dem WordPress-Server zu speichern.
Ablauf 3
Geschützter API-Aufruf
Eine Frontend-Komponente ruft API Gateway mit JWT- oder IAM-basierter Autorisierung auf. Lambda führt die Geschäftslogik aus und gibt nur die Daten zurück, die der authentifizierte Benutzer sehen darf.
Ablauf 4
Geschützter statischer Pfad
Ein Besucher ruft eine geschützte Route auf. CloudFront prüft die signierten Cookies. Fehlen diese oder sind sie abgelaufen, wird der Benutzer zur Anmeldung weitergeleitet; nach erfolgreicher Prüfung gewährt der Signierdienst Zugriff auf die festgelegten geschützten Pfade.
Ablauf 5
KI-/RAG-Anfrage
AI-Kit versucht, wo sinnvoll, lokale Browser-KI zu verwenden. Ist ein Backend erforderlich, ruft der Browser den konfigurierten API-Endpunkt auf, der die Anfrage über Lambda an Bedrock, S3-Dokumente, Wissensdatenbank-Metadaten und Guardrails weiterleitet.
Ablauf 6
Vom Formular zum Workflow
Ein Flow-Formular erfasst die Frontend-Interaktion und übergibt dauerhafte Verarbeitungsschritte anschließend an Backend-Aktionen, E-Mail, Webhook, EventBridge oder KI-Schritte, statt von einer einzigen synchronen PHP-Anfrage abhängig zu sein.
CloudFormation-gestützte Architekturfamilien
Der Deployment Wizard überführt eine kleine Zahl von Produktentscheidungen in CloudFormation-Parameter, öffnet den AWS-Dialog „Create stack“ zur Prüfung und verwendet anschließend Stack-Ausgaben wie API-Basis-URLs, Rollen-ARNs, User-Pool-IDs oder Distributionseinstellungen als Vertrag zurück zu WordPress. Jede Vorlagenfamilie sollte einer tatsächlichen Architekturverantwortung entsprechen.
| Vorlagenfamilie | Primäre Verantwortung | Typische AWS-Ressourcen | Schwerpunkt des Artikels |
|---|---|---|---|
| Cognito-Identität ab Tag 2 | Cognito zu einem wiederverwendbaren Identitäts-Backbone für WordPress machen | User Pool, App Client, Identity Pool, IAM-Rollen, Lambda-Trigger, S3-E-Mail-Vorlagen, optional Route53 | Identität ist mehr als Anmeldung; sie umfasst Token-Design, Gruppenzuordnung, E-Mail-Zustellung und API-Autorisierung. |
| Static Site Guardian | Ausgewählte statische Pfade schützen, ohne erneut eine PHP-Laufzeit einzuführen | S3, CloudFront, Key Groups/Public Keys, Signier-Lambda oder Edge-Logik, API Gateway, KMS/SSM, optional Route53 | Der statische Export löst die Bereitstellung, private Inhalte erfordern jedoch Edge-Autorisierung und einen disziplinierten Umgang mit Cookies. |
| AI-Kit-Backend | Backend-Fallback, RAG und Chatbot-APIs im Kundenkonto bereitstellen | API Gateway, Lambda, Bedrock, S3, S3 Vectors/Knowledge Base, DynamoDB, EventBridge, WAF, SSM/KMS | Private KI ist ein Infrastrukturmuster, nicht nur eine LLM-Funktion. |
| Flow-Backend | Formularbasierte Workflows außerhalb des Lebenszyklus einer WordPress-Anfrage ausführen | API Gateway, Lambda, DynamoDB-Tabellen für Formulare/Übermittlungen/Ereignisse/Vorlagen/Workflows/Webhooks, S3-Buckets für Payloads und Vorlagen, EventBridge, SES, WAF und reCAPTCHA | Formulare werden zu Anwendungs-Frontends, wenn Validierung, Entwürfe, Uploads, E-Mails, Webhooks und Workflow-Ereignisse von einem dedizierten Backend verwaltet werden. |
| Static Publisher-Ziel | Gerenderte WordPress-Ausgabe in einem AWS-Bereitstellungsziel veröffentlichen | Verwendet S3-/CloudFront-Bereitstellungsziele, benötigt jedoch keinen eigenen dedizierten Stack | Bereitstellungspipeline und Laufzeitarchitektur hängen zusammen, sind aber nicht dasselbe. |
Sicherheits- und Vertrauensgrenzen
Die wichtigste Designentscheidung besteht darin, WordPress nicht zum Speicherort aller Geheimnisse, Token und Laufzeitentscheidungen zu machen. In diesem Modell speichert WordPress die Konfiguration und rendert Blöcke; Browser, Cognito, CloudFront und API Gateway setzen die Sicherheitsgrenzen durch.
Keine WordPress-Client-Geheimnisse
Cognito-Design für öffentliche Clients
Gatey ist auf browserseitige Cognito-Abläufe ausgelegt. Der WordPress-Server muss weder Passwörter weiterleiten noch Benutzer-Token speichern oder ein Cognito-Client-Geheimnis vorhalten.
Edge-Autorisierung
Geschützte Pfade bei CloudFront
Statische Inhalte können privat bleiben, wenn CloudFront signierte Cookies prüft, bevor S3-Objekte ausgeliefert werden.
API-Autorisierung
JWT oder IAM bei API Gateway
Geschützte Aktionen sollten auf der API-Ebene autorisiert werden, nicht durch Frontend-CSS oder reine WordPress-Sichtbarkeitsregeln verborgen sein.
Getrennte Oberflächen
Admin-, Frontend- und öffentliche Routen
Die API-Oberflächen für Administration und Redaktion, für Frontend-Besucher sowie die öffentliche statische Oberfläche sollten unabhängig voneinander gedrosselt, authentifiziert und protokolliert werden.
Backend im Eigentum des Kunden
Infrastruktur im AWS-Konto des Kunden
Die Architektur ist am stärksten, wenn sensible Laufzeit-, Identitäts- und KI-Pfade im Kundenkonto statt in einer gemeinsam genutzten SaaS-Blackbox liegen.
Minimalberechtigungen pro Stack
Kleiner IAM-Auswirkungsradius
Jede Vorlage sollte nur die für die jeweilige Funktion erforderlichen Berechtigungen bereitstellen und Ausgaben für die Kombination mit anderen Stacks verfügbar machen.
Leistungs-, Kosten- und Skalierungsmodell
Herkömmliche dynamische WordPress-Stacks werden häufig für Spitzenlast ausgelegt: PHP-Kapazität, Datenbankkapazität, Cache-Ebenen und bisweilen Datenbankcluster, die für seltene Ereignisse dimensioniert sind. Für manche Workloads ist das sinnvoll, aber teuer, wenn die meisten Seiten cachefähig sind und nur ausgewählte Interaktionen Laufzeitfunktionen benötigen.
Das WP Suite-Modell trennt die permanent verfügbare Oberfläche von der bedarfsgesteuerten Oberfläche. Öffentliches HTML und Assets werden am Edge ausgeliefert. Laufzeitfunktionen skalieren unabhängig und werden nur ausgeführt, wenn sich ein Besucher anmeldet, ein Formular absendet, eine KI-Frage stellt oder eine geschützte API aufruft.
| Dimension | Traditionelles dynamisches WordPress | WP Suite-Aufteilung auf AWS | Warum das wichtig ist |
|---|---|---|---|
| Bereitstellung öffentlicher Seiten | PHP und Datenbank bleiben trotz Caching Teil der Origin-Architektur | S3 und CloudFront liefern exportiertes HTML und Assets aus | Lastspitzen erfordern nicht automatisch eine Skalierung von PHP oder Datenbank. |
| Identität | Plugin-Logik läuft häufig innerhalb von WordPress und speichert dort den Sitzungsstatus | Cognito übernimmt Authentifizierung, MFA, SSO und Token | Die Authentifizierung bleibt auch nach einem statischen Export funktionsfähig und unabhängig vom WordPress-Hosting. |
| Dynamisches Verhalten | AJAX/admin-ajax oder eigene PHP-Endpunkte | API Gateway und Lambda je Laufzeitfunktion | Jede Funktion kann unabhängig skalieren, ausfallen und abgesichert werden. |
| KI | Externe API-Aufrufe aus PHP oder einem SaaS-Plugin eines Drittanbieters | Zuerst auf dem Endgerät, Backend-Fallback im AWS-Konto des Kunden | Inhalte, Prompts, Dokumente und Richtlinien bleiben näher beim Eigentümer. |
| Betrieblicher Zielkonflikt | Einfacheres mentales Modell, stärkere Laufzeitkopplung | Mehr Architektur, weniger Kopplung | Die Aufteilung zahlt sich aus, wenn Sicherheit, Skalierung, Datenschutz oder Wiederholbarkeit wichtig sind. |
Betriebsmodell
Die Architektur behandelt jeden Stack als abgegrenztes Subsystem mit Ausgaben, Protokollen, Berechtigungen und klaren Erwartungen an die Wiederherstellung.
Umgebungsstrategie
Stacks für Entwicklung, Staging und Produktion
Verwenden Sie nach Möglichkeit getrennte Stacks und Domains. Static Publisher kann dasselbe Crawling-Ergebnis in mehrere Bereitstellungsziele veröffentlichen, wenn sich nur Domain und Bucket unterscheiden.
Beobachtbarkeit
Protokolle an der richtigen Grenze
Für CloudFront, API Gateway, Lambda, Cognito-Trigger, WAF und Bedrock-Aufrufe sollten jeweils klare Verantwortliche für Protokolle und ein eindeutiger Debugging-Pfad festgelegt sein.
Rollback
Inhalte und Laufzeit getrennt zurücksetzen
Ein Inhalts-Rollback sollte keine erneute Bereitstellung der Identitätsinfrastruktur erfordern. Eine Lambda-Korrektur sollte keinen erneuten Export der gesamten Website voraussetzen.
Drift-Kontrolle
Vorlagen statt Konsolenarchäologie
CloudFormation-basierte Bereitstellung macht die beabsichtigte Architektur sichtbar und wiederholbar, statt sich auf manuell rekonstruierte Schritte in der Konsole zu verlassen.
Fehlerisolierung
Statische Grundoberfläche zuerst
Ist ein KI-Endpunkt vorübergehend nicht verfügbar, sollten öffentliche Inhalte weiterhin geladen werden. Ist die WordPress-Administration ausgefallen, kann das statische Frontend verfügbar bleiben.
Sicherheitsprüfung
Vertrauensgrenzen prüfen, nicht nur Plugins
Entscheidend ist die Prüfung der Stellen, an denen Token, Cookies, Schlüssel, Rollen und geschützte Routen durchgesetzt werden.
Implementierungspfad
- Ordnen Sie zu, welche Bereiche der Website ausschließlich Inhalte bereitstellen, authentifiziert, statisch geschützt, KI-gestützt, formularbasiert oder API-gesteuert sind.
- Wählen Sie die erste AWS-Funktion: Identität, sicherer statischer Schutz, KI-Backend oder Workflow-Laufzeit.
- Stellen Sie die passende Vorlage über den Deployment Wizard oder den CloudFormation-Pfad bereit und erfassen Sie die Stack-Ausgaben.
- Übertragen Sie die Ausgaben zurück in die Konfiguration des jeweiligen WP Suite-Plugins.
- Ergänzen Sie ein Runbook mit Parametern, Ausgaben, DNS, Zertifikaten, Protokollen, Rollback und der Zuständigkeit für das AWS-Konto.
- Fügen Sie die nächste Funktion erst hinzu, wenn deren Grenze klar ist; vermeiden Sie, das erste Projekt in eine gleichzeitige Migration der gesamten Plattform zu verwandeln.
Wann diese Architektur gut passt
- Eine WordPress-Website benötigt Authentifizierung, geschützte Inhalte, KI-Funktionen, Formulare oder APIs, während die öffentlichen Seiten schnell und wartungsarm bleiben sollen.
- Eine Agentur benötigt eine wiederholbare, kundeneigene AWS-Architektur statt individueller Plugin-Stacks.
- Ein CTO möchte WordPress für produktive Redaktionsarbeit nutzen, aber nicht jede Laufzeitfunktion PHP und MySQL überlassen.
- Eine Dokumentations-, Wissensdatenbank- oder Portal-Website benötigt öffentliche Inhalte, private Bereiche und KI-Suche in einer gemeinsamen Benutzererfahrung.
- Ein Team möchte die Exposition des Origins reduzieren, ohne die Website als vollständig Headless-Anwendung neu aufzubauen.
Wann diese Architektur nicht verwendet werden sollte
- Eine einfache Unternehmenswebsite benötigt weder Anmeldung noch geschützte Routen, KI, Workflows oder nennenswerte Laufzeitfunktionen.
- Das Team kann die Verantwortung für AWS-Konto, DNS, Zertifikate und Betriebsüberwachung weder selbst übernehmen noch delegieren.
- Aus organisatorischen oder vertraglichen Gründen muss das gesamte dynamische Verhalten in bestehenden WordPress-Plugins verbleiben.
- Für das Projekt ist eine schnelle einmalige Implementierung wichtiger als eine wiederverwendbare Architektur.
Verwandte Ressourcen
Technischer Deep Dive
Cognito-Identitätsarchitektur ab Tag 2
Detaillierte Betrachtung des Cognito-CloudFormation-Backbones für Identität
Technischer Deep Dive
Sicheres statisches WordPress mit signierten Cookies
Detaillierte Betrachtung geschützter statischer Bereitstellung, CloudFront-Cookies und Cognito-Anmeldung
Produkt
Flow
Formular- und Workflow-Automatisierungsebene für anwendungsähnliche WordPress-Erlebnisse
Agenturen
WP Suite für Agenturen
Bereitstellung in AWS im Eigentum des Kunden und standardisierter Rollout-Pfad
FAQ
Ist dies eine Headless-WordPress-Architektur?
Nicht im üblichen Sinn. WordPress bleibt das Bearbeitungs- und Inhaltssystem, und das Frontend kann weiterhin von WordPress gerenderte Gutenberg-Ausgabe sein. Die Laufzeit wird aufgeteilt, sodass ausgewählte Funktionen in AWS-Dienste verlagert werden.
Benötigt Static Publisher einen CloudFormation-Stack?
Nein. Static Publisher ist die Publishing-Pipeline. Er kann in AWS-Bereitstellungsziele veröffentlichen, benötigt im WP Suite-Modell jedoch keinen eigenen dedizierten CloudFormation-Stack.
Welche Bestandteile sind tatsächlich vorlagenbasiert?
Die wichtigsten Stack-basierten Familien sind Identität, geschützte statische Bereitstellung, KI-Backend und Workflow-Laufzeit. Sie lassen sich unabhängig einführen und über Ausgaben und Plugin-Konfiguration kombinieren.
Warum nicht einfach Managed WordPress Hosting verwenden?
Managed Hosting ist für viele Websites weiterhin eine gute Wahl. Die aufgeteilte Architektur wird wertvoll, wenn Identität, private Routen, KI, Workflows, kundeneigene Infrastruktur oder eine strikte Laufzeitisolierung wichtig sind.
Kann diese Architektur schrittweise eingeführt werden?
Ja. Beginnen Sie mit einer Funktion, deren Grenze klar ist, etwa der Cognito-Anmeldung oder einem geschützten statischen Bereich. Fügen Sie KI- oder Workflow-Laufzeit erst hinzu, wenn der Anwendungsfall dies rechtfertigt.
Nutzen Sie WordPress als CMS und AWS als Laufzeit
Verwenden Sie diese Übersichtsseite als Ausgangspunkt: Verschaffen Sie sich zunächst einen Überblick über das Gesamtsystem und vertiefen Sie anschließend Identität, geschützte statische Bereitstellung, KI und Workflows.