Architektur · Deep Dive · Bereitstellungsmodell
Architektur des AWS Deployment Wizard für WordPress-Teams
Eine praxisnahe Architektur, die WP Suite-Produktentscheidungen in wiederholbare CloudFormation-Bereitstellungen im AWS-Konto des Kunden überführt.
Architekturthese: Der Deployment Wizard ist keine kosmetische Einrichtungsoberfläche. Er bildet die Brücke zwischen der Produktabsicht in WordPress und dem Eigentum an der AWS-Infrastruktur: Er erfasst einige wesentliche Entscheidungen, öffnet den CloudFormation-Prüfablauf „Create stack“, stellt im richtigen Konto bereit und verbindet anschließend die resultierenden Ausgaben wieder mit WordPress.
Warum die Bereitstellungs-UX Teil der Architektur ist
Die meisten WordPress-Benutzer möchten API Gateway, Lambda, Cognito, DynamoDB, WAF oder Bedrock nicht von Hand entwerfen. Die meisten AWS-Architekten möchten nicht, dass kritische Infrastruktur von einem Plugin erstellt wird, das seine Aktionen verbirgt. WP Suite muss beiden Seiten Sicherheit geben.
Der Deployment Wizard löst diesen Zielkonflikt, indem er bewusst schlank bleibt. Er erfasst Entscheidungen auf Produktebene, erzeugt einen vorausgefüllten CloudFormation-Ablauf und lässt AWS den Ort bleiben, an dem der Stack geprüft, erstellt und verwaltet wird.
Deshalb verdient dieses Thema einen eigenen Architekturartikel: Das Bereitstellungsmodell ist Teil des Vertrauenskonzepts. Es erklärt, wie WP Suite fortgeschrittene AWS-Muster anbieten kann, ohne zu einer undurchsichtigen, gehosteten SaaS-Abhängigkeit zu werden.
Systemgrenze
WP Suite- / Plugin-Einstellungen
Benutzer wählt die gewünschte Funktion und einige wichtige Optionen
│
▼
Deployment Wizard
prüft die Auswahl und erstellt CloudFormation-Parameter
│
▼
AWS Console → CloudFormation → Create stack (Prüfung)
Kunde prüft Ressourcen, Parameter, IAM und Ausgaben
│
▼
AWS-Stack im Eigentum des Kunden
Cognito / KI-Backend / Flow-Backend / Stack für geschützte Bereitstellung
│
▼
CloudFormation-Ausgaben
ApiBaseUrl, UserPoolId, Rollen-ARNs, Distribution-/Domaindetails, Bucket-Namen
│
▼
WordPress-Plugin-Konfiguration
Gatey, AI-Kit, Flow oder Komponenten für statischen Schutz rufen das bereitgestellte Backend auf
Die entscheidende Grenze ist das Eigentum. WP Suite kann den Bereitstellungspfad erzeugen, die Laufzeit gehört jedoch zu dem AWS-Konto, in dem der Stack erstellt wird.
Der Vertrag des Wizards
| Vertragselement | Wofür der Wizard verantwortlich ist | Wofür AWS/CloudFormation verantwortlich ist |
|---|---|---|
| Erfassung von Entscheidungen | Erfragen Sie nur die wenigen Produktentscheidungen, die den Aufbau des Stacks verändern: Funktionen, Authentifizierungsmodus, optionale Schutzmaßnahmen, Domains und Integrationswerte. | Parameter validieren, Ressourcen erstellen, Drift und Aktualisierungen verfolgen und Ausgaben bereitstellen. |
| Vorlagenquelle | CloudFormation auf die richtige Version des in S3 gehosteten Vorlagenartefakts verweisen. | Die Vorlage lesen und die deklarierten Ressourcen im Zielkonto und in der Zielregion erstellen. |
| Prüfschritt | Den Benutzer mit vorausgefüllten Parametern zur Prüfung von „Create stack“ führen. | Vor der Bereitstellung den endgültigen Ressourcen-, IAM- und Change-Set-Kontext anzeigen. |
| Verknüpfung nach der Bereitstellung | Dem Benutzer mitteilen, welche Ausgaben in die WordPress-Einstellungen kopiert werden müssen. | Ausgaben wie API-Basis-URLs, Cognito-IDs, Rollen-ARNs, Bucket-Namen oder Distributionseinstellungen erzeugen. |
| Versionskontrolle | Sichere Produktentscheidungen zugänglich machen und entwicklergesteuerte Release-Werte aus den üblichen Benutzeroptionen heraushalten. | Vorlagenversionen verwenden, um bereitgestellte Infrastruktur vorhersehbar zu aktualisieren. |
Warum nicht alles direkt aus WordPress bereitstellen?
Ein WordPress-Plugin kann eine benutzerfreundliche Oberfläche bereitstellen, sollte aber nicht unbemerkt zur Infrastruktur-Steuerungsebene für produktive AWS-Konten werden. Für CTOs und Agenturen ist der AWS-Prüfschritt keine Reibung, sondern der Governance-Punkt, an dem IAM, Regionen, Abrechnung, DNS und betriebliche Verantwortung sichtbar sind.
| Verborgene Bereitstellung durch das Plugin | Deployment Wizard + CloudFormation | Warum sich WP Suite für die zweite Variante entscheidet |
|---|---|---|
| Einfacher erster Klick, schwacher Audit-Pfad | Der Benutzer sieht einen CloudFormation-Stack im AWS-Konto | Die Infrastruktur bleibt für den Kunden oder die Agentur auffindbar. |
| Das Plugin benötigt weitreichende AWS-Anmeldedaten | AWS Console verwaltet die Berechtigungen zur Stack-Erstellung | WP Suite muss keine langlebigen Cloud-Anmeldedaten des Kunden speichern. |
| Schwer über mehrere Kunden hinweg zu reproduzieren | Parameter und Ausgaben bilden einen wiederholbaren Vertrag | Agenturen können Runbooks verfassen und Umgebungen vergleichen. |
| Das Anbieterkonto kann Eigentümer der Laufzeit sein | Das Kundenkonto ist Eigentümer der Laufzeitressourcen | Daten, Protokolle, Kosten und Sicherheitskontrollen bleiben näher beim Kunden. |
Parameterdesign: weniger fragen, nicht mehr verbergen
Ein guter Bereitstellungsassistent legt nicht jeden CloudFormation-Parameter offen. Er zeigt die Entscheidungen, welche die Architektur verändern, und verbirgt jene, die zum Publishing- oder Release-Prozess gehören. Ein Assistent für ein KI-Backend kann beispielsweise fragen, welche Frontend-Funktionen und Schutzmaßnahmen benötigt werden, während DeploymentVersion unter Kontrolle der Entwickler bleibt.
Funktionsschalter
Nur aktivieren, was die Website benötigt
Eine Website, die nur DocSearch benötigt, sollte nicht versehentlich jede mögliche öffentliche KI-Route bereitstellen.
Authentifizierungsmodi
Frontend- und Admin-Oberflächen trennen
Admin-APIs können standardmäßig Cognito- und Scope-Prüfungen verwenden, während öffentliche Routen je nach Anwendungsfall reCAPTCHA, WAF oder Cognito nutzen können.
Domainoptionen
DNS ist optional, aber ausdrücklich konfiguriert
Eigene Domains, Zertifikate und Route53-Einträge sollten als sichtbare Optionen behandelt werden, da sie Eigentum und Fehlerbehebung beeinflussen.
Sicherheitskontrollen
Schutzmaßnahmen sind Architekturentscheidungen
WAF, IP-Zulassungslisten, reCAPTCHA, KMS und GuardDuty-ähnliche Optionen verändern, wie das Backend sicher zugänglich gemacht werden kann.
Artefaktquelle
Vorlagen müssen für CloudFormation lesbar sein
Bei direkten Vorlagenlinks benötigt CloudFormation eine S3-Vorlagen-URL; die Richtlinie des Artefakt-Buckets muss dem CloudFormation-Serviceprinzip das Lesen erlauben.
Integrationsübergabe
Stack-Ausgaben verbinden die Komponenten
Werte wie ApiBaseUrl sollten aus CloudFormation kopiert und nicht aus Namenskonventionen erraten werden.
Stack-Familien im WP Suite-Modell
| Stack-Familie | Ziel des Wizards | Typischer Ausgabevertrag | Warum das wichtig ist |
|---|---|---|---|
| Cognito- / Gatey-Identität | Ein wiederverwendbares Cognito-Identitäts-Backbone mit App Client, Gruppen, Triggern und optionaler eigener Domain erstellen oder anbinden. | User Pool ID, App Client ID, Identity Pool ID, Rollen-ARNs, Domainwerte. | Die Anmeldung wird zu einer wiederverwendbaren Laufzeit-Identitätsebene und bleibt nicht nur eine Plugin-Einstellung auf Seitenebene. |
| AI-Kit-Backend | Backend-Fallback, Chatbot, DocSearch/RAG sowie geschützte KI- und Admin-Routen im Kundenkonto aktivieren. | ApiBaseUrl, Routen- und Authentifizierungseinstellungen sowie gegebenenfalls IDs für Wissensdatenbank und Speicher. | Private KI wird zu einer bereitstellbaren Backend-Funktion statt zu einer reinen SaaS-Plugin-Funktion. |
| Flow-Backend | Laufzeit für Formulare, Übermittlungen, Entwürfe, Uploads, Vorlagen, Workflows, E-Mail und Webhooks bereitstellen. | API-Basis-URL oder eigene Domain, Bucket-, Tabellen- und Funktionsausgaben sowie Routen- und Authentifizierungsoptionen. | Formulare werden zu dauerhaften Workflows, die statische Bereitstellung und externe Integrationen überstehen. |
| Geschützte statische Bereitstellung | Das Edge-Autorisierungsmuster für private statische Pfade erstellen. | CloudFront-Distribution oder -Domain, Signier- und API-Endpunkte, Schlüssel- und Cookie-Einstellungen. | Privates statisches WordPress kann auf der CDN- oder Objektebene durchgesetzt werden. |
| Static Publisher-Ziel | Gerenderte WordPress-Ausgabe in AWS-Bereitstellungsziele veröffentlichen; für den Publisher selbst ist kein eigener Stack erforderlich. | Konfiguration des Bereitstellungsziels statt eines separaten Laufzeit-Stacks. | Publishing und Laufzeitarchitektur bleiben miteinander verbunden, ohne verwechselt zu werden. |
Am Ausgabevertrag wird WordPress wieder angebunden
Die Bereitstellung ist nur nützlich, wenn WordPress sie verwenden kann. Die Verbindung sollte einfach und eindeutig sein: Stack bereitstellen, Ausgaben kopieren, in die Plugin-Einstellungen einfügen und die Route testen. AI-Kit ist das klarste Beispiel: Nach der Bereitstellung kopiert der Benutzer ApiBaseUrl aus den CloudFormation-Ausgaben in AI-Kit Settings → API Settings.
| Ausgabetyp | Beispielwert | Verwendung in WordPress |
|---|---|---|
| API-Basis-URL | https://abc123.execute-api.region.amazonaws.com/prod oder eigene Domain | AI-Kit- und Flow-Blöcke sowie Admin-Oberflächen wissen, wohin Backend-Anfragen gesendet werden müssen. |
| Cognito-IDs | User Pool ID, App Client ID, Identity Pool ID | Gatey kann den Authenticator anzeigen und Token für geschützte APIs beziehen. |
| Rollen-ARNs / Scopes | IAM-Rollen-ARNs, aus Gruppen abgeleitete Scopes, Admin-Scopes | APIs können Autorisierung durchsetzen, statt einem verborgenen Frontend-Status zu vertrauen. |
| Distributions- und Domainwerte | CloudFront-Distributionsdomain, Endpunkt zur Ausgabe signierter Cookies | Statischer Schutz und Publishing-Ziele lassen sich dokumentieren und prüfen. |
| Bucket- und Tabellennamen | Payload-Bucket, Vorlagen-Bucket, Datentabellen | Runbooks und Diagnosen können Betreiber zu den richtigen AWS-Ressourcen führen. |
Governance-Modell für Agenturen und CTOs
Eigentum des Kunden
Die Laufzeit wird im richtigen AWS-Konto bereitgestellt
Agenturen können abhängig von Vertrag, Compliance und Supportmodell im eigenen Konto oder im Kundenkonto bereitstellen.
Prüfbares IAM
Die Stack-Prüfung legt Berechtigungen offen
Architekten können IAM und Ressourcenerstellung vor dem Start prüfen, statt einem undurchsichtigen Plugin-Ablauf zu vertrauen.
Wiederholbarer Support
Gleiche Vorlage, andere Parameter
Runbooks können Parameter, Ausgaben, DNS, Zertifikate, Protokolle und Rollback einmal beschreiben und das Muster anschließend kundenübergreifend wiederverwenden.
Kostentransparenz
Die AWS-Abrechnung folgt dem bereitgestellten Konto
Kunde oder Agentur können Kosten für API, Lambda, Modelle, Speicher, WAF und Protokollierung direkt einsehen.
Änderungskontrolle
Aktualisierungen sind Stack-Änderungen
Eine neue Laufzeitfunktion kann durch Aktualisieren eines Stacks oder einer Version eingeführt werden, statt Konsolenressourcen manuell zu bearbeiten.
Ausstiegspfad
Ressourcen bleiben sichtbar
Selbst wenn sich das WordPress-Plugin später ändert, sind die bereitgestellten AWS-Ressourcen nicht in einem unerreichbaren Anbieterkonto verborgen.
Fehlerszenarien, die der Artikel ausdrücklich benennen sollte
| Fehlerszenario | Was geschieht | Wie es dokumentiert wird |
|---|---|---|
| Falsche Region | Der Stack wird bereitgestellt, zugehörige Ressourcen wie Zertifikate oder die Cognito-Konfiguration befinden sich jedoch in einer anderen Region. | Erforderliche Regionen je Stack-Familie aufführen und Einschränkungen für Zertifikate und Domains hervorheben. |
| Ausgabe nicht kopiert | Das WordPress-Plugin verweist weiterhin auf einen alten oder leeren Endpunkt. | Das Kopieren der Ausgaben als Punkt in die Bereitstellungs-Checkliste aufnehmen, statt es informellem Teamwissen zu überlassen. |
| Abweichende Admin-Authentifizierung | Das Backend erwartet Cognito-, IAM- oder Scope-Daten, für deren Übertragung das Plugin nicht konfiguriert ist. | Authentifizierungsmodus, Scopes und Testaufrufe unmittelbar nach der Bereitstellung dokumentieren. |
| DNS oder Zertifikat unvollständig konfiguriert | Die eigene Domain existiert, aber Zertifikat, Route53 oder API-Zuordnung sind unvollständig. | Im Runbook zwischen „Stack bereitgestellt“ und „eigene Domain aktiv“ unterscheiden. |
| Versionsdrift | Eine Website verwendet alte Stack-Ressourcen mit den Erwartungen einer neueren Plugin-Oberfläche. | Vorlagen- und Plugin-Versionen gemeinsam im Kundendatensatz erfassen. |
Implementierungspfad
- Von der Produktfunktion ausgehen: Identität, KI-Backend, Flow-Backend, geschützte statische Inhalte oder Bereitstellungsziel.
- Den kleinsten Satz sichtbarer Benutzerentscheidungen bestimmen, der zum Aufbau dieses Stacks erforderlich ist.
- Eine CloudFormation-Prüf-URL für „Create stack“ mit vorausgefüllten Parametern erzeugen.
- Nach der Bereitstellung die relevanten Ausgaben in die passenden WP Suite-Plugin-Einstellungen kopieren.
- Öffentliche, geschützte und Admin-Routen getrennt testen.
- Parameter, Ausgaben, DNS, Zertifikate, Authentifizierungsmodi, Protokolle und Rollback-Anweisungen im Runbook der Website erfassen.
Verwandte Ressourcen
Deep Dive
WordPress-Referenzarchitektur auf AWS
Der Grundlagenartikel, der Bereitstellung, Identität, statische Auslieferung, KI und Workflow-Laufzeit in einem Modell zusammenführt.
Deep Dive
Privates KI- und RAG-Backend
Der Artikel zum AI-Kit-Backend, in dem die ApiBaseUrl Ausgabe zum Integrationsvertrag mit WordPress wird.
Deep Dive
Ereignisgesteuertes Backend für Formulare und Workflows
Der Flow-Backend-Stack als konkretes Beispiel einer geführten Bereitstellung für Formulare und Workflows.
Lösung
WordPress für Agenturen auf AWS
Die geschäftliche und betriebliche Begründung für wiederholbare Infrastruktur im Eigentum des Kunden.
FAQ
Ist der Deployment Wizard ein eigener Laufzeit-Stack?
Nein. Er ist eine geführte Bereitstellungsebene. Der Laufzeit-Stack ist das System, dessen Bereitstellung er unterstützt, etwa Cognito, das AI-Kit-Backend, das Flow-Backend oder die geschützte statische Auslieferung.
Warum CloudFormation statt einer eigenen API verwenden, die AWS-Ressourcen erstellt?
CloudFormation bietet dem Kunden einen prüfbaren Stack im eigenen Konto mit Parametern, Ausgaben und Lebenszyklusverwaltung. Außerdem muss WP Suite dadurch keine weitreichenden, langlebigen Cloud-Anmeldedaten speichern.
Was sollte nach der Bereitstellung dokumentiert werden?
Mindestens die ausgewählten Parameter, Stack-Ausgaben, in das Plugin kopierten Einstellungen, DNS- und Zertifikatsoptionen, Authentifizierungsmodi und Scopes, Protokollgruppen, kostensensitive Ressourcen und Rollback-Schritte.
WP Suite-Laufzeit-Stacks bereitstellen, ohne die AWS-Architektur zu verbergen
Erstellen Sie mit geführter CloudFormation-Bereitstellung AWS-Backends im Eigentum des Kunden und verbinden Sie anschließend die Stack-Ausgaben wieder mit WordPress.