Architektúra · Pillér
WordPress + AWS referencia-architektúra
Részletes műszaki térkép ahhoz, hogy a WordPress maradjon a szerkesztési réteg, miközben az identitást, a statikus kiszolgálást, a védett futtatókörnyezetet, az AI-t és a munkafolyamatokat az AWS kezeli.
Architekturális tézis: A WordPress maradjon a CMS és az adminisztrációs felület, ne minden funkció egyetlen futtatási határa. A WP Suite komponálható alkalmazás-frontendet épít belőle azzal, hogy az identitást, a védett kiszolgálást, az AI-t, az API-kat és a munkafolyamatokat az ügyfél saját AWS-szolgáltatásaiba helyezi.
Miért van szükség erre az architektúrára
A legtöbb WordPress-architektúra továbbra is abból indul ki, hogy a nyilvános futtatókörnyezet a WordPressé. A PHP rendereli az oldalt, a kérést a MySQL szolgálja ki, a pluginok ugyanabban a folyamatban futnak, a skálázás pedig ugyanennek a stacknek a bővítését jelenti.
A WP Suite más utat követ. A WordPress marad a szerkesztési és adminisztratív vezérlési sík, a futtatási felelősségek viszont az adott feladatra alkalmasabb AWS-szolgáltatások között oszlanak meg: statikus kiszolgálás a peremhálózaton, identitás a Cognitóban, API-k az API Gatewayben és Lambdában, AI Bedrock-alapú szolgáltatásokban, munkafolyamatok pedig eseményvezérelt infrastruktúrán.
Nem a WordPress headless újraépítése a cél. Hanem az, hogy amikor a webhely már több egyszerű tartalomközlő oldalnál, ne kelljen minden alkalmazási feladatot a WordPress futtatókörnyezetén átvezetni.
Rendszerhatár
Szerkesztők / adminisztrátorok
│
▼
WordPress + Gutenberg
tartalom, elrendezés, beállítások, admin UX
│
WP Suite integrációs réteg
│
┌─────────────────────────┼─────────────────────────┐
│ │ │
▼ ▼ ▼
Statikus kiszolgálás Identitási sík Futtatási API-k
Static Publisher Gatey + Cognito API Gateway + Lambda
S3 + CloudFront User/Identity Poolok üzleti logika
│ │ │
└──────────────┬──────────┴──────────────┬──────────┘
▼ ▼
Böngészős futtatókörnyezet AI- / munkafolyamat-sík
Gutenberg-renderelt oldalak Bedrock, S3, DynamoDB,
kliensoldali komponensek EventBridge, SES, WAF
A határ szándékosan egyszerű: a WordPress felel a tartalomkészítésért, az URL-struktúráért, a Gutenberg-jelölésért, a szerkesztési munkafolyamatokért és a modulok konfigurációjáért. Az AWS kezeli azokat a végrehajtási útvonalakat, amelyek önálló skálázást, erősebb izolációt, identitásalapú hozzáférést, eseményfeldolgozást vagy modellhozzáférést igényelnek.
A Static Publisher része a kiszolgálási folyamatnak, de önmagában nem CloudFormation-stack. A renderelt webhelyet exportálja és egy AWS-kiszolgálási célra publikálja; a stackalapú képességek az identitás, a védett kiszolgálás, az AI-backend és a munkafolyamat-futtatás köré épülnek.
Képességtérkép
Tartalmi sík
WordPress és Gutenberg
A megszokott szerkesztési réteg marad az oldalak, bejegyzések, blokkok, CPT-tartalmak, elrendezések, metaadatok és termékkonfiguráció hiteles forrása.
Kiszolgálási sík
Static Publisher, S3 és CloudFront
A renderelt oldalak és assetek S3-ról és CloudFrontból szolgálhatók ki, így a nyilvános forgalom nem függ az élő PHP-/MySQL-kapacitástól.
Identitási sík
Gatey és Amazon Cognito
A hitelesítést, regisztrációt, MFA-t, SSO-t, csoportokat, JWT-ket és opcionális IAM-hitelesítő adatokat a Cognito kezeli, a böngésző pedig közvetlenül használja őket.
Védett statikus sík
Static Site Guardian
A kijelölt statikus útvonalak a CloudFrontnál aláírt sütikkel, egy aláíró szolgáltatással és Cognito-alapú bejelentkezési folyamatokkal védhetők.
Alkalmazás-futtatókörnyezet
API Gateway és Lambda
A fiókműveletek, védett adatok, munkafolyamat-lépések és integrációs logika célzott API-kon érhetők el WordPress AJAX-végpontok helyett.
AI-futtatókörnyezet
AI-Kit, Bedrock és S3 Vectors
Az eszközön futó AI elvégezheti a helyi feladatokat, a backend tartalékútvonal és a RAG-munkafolyamatok pedig szükség esetén az ügyfél saját AWS-backendjében futnak.
Munkafolyamat-sík
Flow és eseményvezérelt szolgáltatások
Az űrlapok és többlépéses beküldések e-mailes, webhookos, EventBridge-, AI-agent- és backendfeldolgozási folyamatokat indíthatnak.
Provisionálási sík
Deployment Wizard és CloudFormation
Az ismételhető AWS-képességek vezetett sablonokkal települnek, így az ügynökségek és csapatok minden stack kézi felépítése nélkül szabványosíthatják a megvalósítást.
Kanonikus kérésfolyamatok
1. folyamat
Nyilvános statikus oldalkérés
A látogató nyilvános oldalt kér le. A CloudFront az exportált HTML-t és asseteket S3-ról szolgálja ki. A WordPress nincs a kérés útvonalában, így a forgalmi csúcs a CDN-t, nem a PHP-workereket és adatbázis-kapcsolatokat terheli.
2. folyamat
Bejelentkezett felhasználói állapot
A Gatey az oldalon rendereli a Cognito bejelentkezési felületét. A böngésző a Cognitónál hitelesít, tokeneket kap, majd úgy adja át az identitás állapotát a WP Suite blokkjainak, hogy a WordPress-szerver nem tárol titkokat vagy tokeneket.
3. folyamat
Védett API-hívás
A frontendkomponens JWT- vagy IAM-alapú jogosultsággal hívja az API Gatewayt. A Lambda végrehajtja az üzleti logikát, és csak azokat az adatokat adja vissza, amelyeket a hitelesített felhasználó láthat.
4. folyamat
Védett statikus útvonal
A látogató védett útvonalra érkezik. A CloudFront ellenőrzi az aláírt sütiket. Ha hiányoznak vagy lejártak, a felhasználót bejelentkezésre irányítja; sikeres ellenőrzés után az aláíró hozzáférést ad a védett útvonalakhoz.
5. folyamat
AI-/RAG-kérés
Az AI-Kit ott próbál helyi böngészős AI-t használni, ahol ez megfelelő. Ha backend szükséges, a böngésző a konfigurált API-végpontot hívja, amely Lambdán keresztül éri el a Bedrockot, az S3-dokumentumokat, a tudásbázis metaadatait és a védőkorlátokat.
6. folyamat
Űrlapból munkafolyamatba kerülő kérés
A Flow-űrlap rögzíti a frontend-interakciót, majd a tartós feldolgozást backendműveleteknek, e-mailnek, webhooknak, EventBridge-nek vagy AI-lépéseknek adja át ahelyett, hogy egyetlen szinkron PHP-kéréstől függne.
CloudFormation-alapú architektúracsaládok
A Deployment Wizard kevés termékdöntést alakít CloudFormation-paraméterekké, megnyitja az AWS Create stack ellenőrzési folyamatát, majd az olyan stackkimeneteket, mint az API-alap URL-ek, szerepkör-ARN-ek, User Pool-azonosítók vagy disztribúciós beállítások, szerződésként vezeti vissza a WordPressbe. Minden sabloncsaládnak valós architekturális felelősséghez kell kapcsolódnia.
| Sabloncsalád | Elsődleges felelősség | Tipikus AWS-erőforrások | Cikk fókusza |
|---|---|---|---|
| Cognito-identitás a második naptól | A Cognito újrahasznosítható WordPress-identitási gerinccé alakítása | User Pool, App Client, Identity Pool, IAM-szerepkörök, Lambda-triggerek, S3 e-mail-sablonok, opcionális Route53 | Az identitás több a bejelentkezésnél: tokenkialakítás, csoportleképezés, e-mail-kézbesítés és API-jogosultság is. |
| Static Site Guardian | Kijelölt statikus útvonalak védelme a PHP-futtatókörnyezet visszaállítása nélkül | S3, CloudFront, Key Groups/Public Keys, aláíró Lambda vagy peremlogika, API Gateway, KMS/SSM, opcionális Route53 | A statikus export megoldja a kiszolgálást, a privát tartalomhoz azonban peremhálózati jogosultságkezelés és fegyelmezett sütikezelés kell. |
| AI-Kit backend | Backend tartalékútvonal, RAG- és chatbot-API-k biztosítása az ügyfél fiókjában | API Gateway, Lambda, Bedrock, S3, S3 Vectors/Knowledge Base, DynamoDB, EventBridge, WAF, SSM/KMS | A privát AI infrastruktúraminta, nem csupán LLM-funkció. |
| Flow backend | Űrlapalapú munkafolyamatok futtatása a WordPress kérés-életciklusán kívül | API Gateway, Lambda, DynamoDB-táblák az űrlapokhoz, beküldésekhez, eseményekhez, sablonokhoz, munkafolyamatokhoz és webhookokhoz, S3 payload-/sablonbucketek, EventBridge, SES, WAF és reCAPTCHA | Az űrlapok alkalmazás-frontendeivé válnak, amikor a validációt, vázlatokat, feltöltéseket, e-maileket, webhookokat és munkafolyamat-eseményeket külön backend kezeli. |
| Static Publisher cél | A renderelt WordPress-kimenet publikálása AWS-kiszolgálási célra | S3-/CloudFront-telepítési célokat használ, de nem igényel saját dedikált stacket | A publikálási folyamat és a futtatási architektúra összefügg, de nem ugyanaz. |
Biztonsági és bizalmi határok
A legfontosabb tervezési döntés, hogy ne a WordPress birtokoljon minden titkot, tokent és futtatási döntést. Ebben a modellben a WordPress konfigurációt tárol és blokkokat renderel; a biztonsági határokat a böngésző, a Cognito, a CloudFront és az API Gateway kényszeríti ki.
Nincsenek WordPressben tárolt kliensoldali titkok
Nyilvános klienses Cognito-kialakítás
A Gatey böngészőoldali Cognito-folyamatokra épül. A WordPress-szervernek nem kell jelszavakat továbbítania, felhasználói tokeneket tárolnia vagy Cognito-kliens titkot őriznie.
Peremhálózati jogosultságkezelés
Védett útvonalak a CloudFrontnál
A statikus tartalom akkor is lehet privát, ha a CloudFront az S3-objektumok kiszolgálása előtt kikényszeríti az aláírt sütik használatát.
API-jogosultságkezelés
JWT vagy IAM az API Gatewaynél
A védett műveleteket az API-rétegben kell engedélyezni, nem frontend-CSS-sel vagy kizárólag WordPressre épülő láthatósági szabályokkal elrejteni.
Elkülönített felületek
Admin-, frontend- és nyilvános útvonalak
Az admin-/szerkesztői API-felületet, a látogatói frontend-API-t és a nyilvános statikus felületet egymástól függetlenül kell korlátozni, hitelesíteni és naplózni.
Ügyfél tulajdonában lévő backend
Infrastruktúra az ügyfél AWS-fiókjában
Az architektúra akkor a legerősebb, ha az érzékeny futtatási, identitási és AI-útvonalak az ügyfél fiókjában, nem egy közös SaaS-fekete dobozban működnek.
Legkisebb jogosultság stackenként
Kis IAM-hatókör
Minden sablon csak az adott képességhez szükséges jogosultságokat hozza létre, és biztosítson kimeneteket a más stackekkel való összeállításhoz.
Teljesítmény-, költség- és skálázási modell
A hagyományos dinamikus WordPress-stackeket gyakran csúcsterhelésre méretezik: PHP- és adatbázis-kapacitás, gyorsítótárrétegek, esetenként ritka eseményekre méretezett adatbázis-klaszterek. Ez bizonyos terheléseknél indokolt, de költséges, ha a legtöbb oldal gyorsítótárazható, és csak néhány interakció igényel futtatási logikát.
A WP Suite modellje különválasztja a folyamatosan elérhető és az igény szerint futó felületet. A nyilvános HTML és assetek a peremhálózatról érkeznek. A futásidejű funkciók önállóan skálázódnak, és csak akkor futnak, amikor a látogató bejelentkezik, űrlapot küld be, AI-kérdést tesz fel vagy védett API-t hív.
| Dimenzió | Hagyományos dinamikus WordPress | WP Suite AWS-szétválasztás | Miért fontos |
|---|---|---|---|
| Nyilvános oldalak kiszolgálása | A PHP és az adatbázis gyorsítótárazás mellett is a forrásoldali folyamat része | Az exportált HTML-t és asseteket az S3 és a CloudFront szolgálja ki | A forgalmi csúcsok nem teszik automatikusan szükségessé a PHP és az adatbázis skálázását. |
| Identitás | A pluginlogika gyakran a WordPressen belül fut, és ott tárolja a munkamenet állapotát | A Cognito kezeli a hitelesítést, az MFA-t, az SSO-t és a tokeneket | A hitelesítés statikus export után is működik, és független marad a WordPress-tárhelytől. |
| Dinamikus működés | AJAX/admin-ajax vagy egyedi PHP-végpontok | API Gateway és Lambda futásidejű képességenként | Minden funkció önállóan skálázható, hibázhat meg és védhető. |
| AI | Külső API-hívások PHP-ból vagy harmadik fél SaaS-pluginjából | Elsődlegesen eszközön fut, tartalék backend az ügyfél AWS-fiókjában | A tartalom, promptok, dokumentumok és szabályzatok közelebb maradnak a tulajdonoshoz. |
| Üzemeltetési kompromisszum | Egyszerűbb gondolkodási modell, erősebb futásidejű összekapcsolás | Több architektúra, kisebb összekapcsolás | A szétválasztás akkor térül meg, ha számít a biztonság, a skálázás, az adatvédelem vagy az ismételhetőség. |
Üzemeltetési modell
Az architektúra minden stacket körülhatárolt alrendszerként kezel saját kimenetekkel, naplókkal, jogosultságokkal és visszaállítási elvárásokkal.
Környezeti stratégia
Fejlesztői, staging- és éles stackek
Ahol lehetséges, használjon külön stackeket és domaineket. A Static Publisher ugyanazt a feltérképezési eredményt több telepítési célra is publikálhatja, ha csak a domain és a bucket tér el.
Megfigyelhetőség
Naplók a megfelelő határon
A CloudFront, az API Gateway, a Lambda, a Cognito-triggerek, a WAF és a Bedrock-hívások mind rendelkezzenek egyértelmű naplótulajdonossal és hibakeresési útvonallal.
Visszaállítás
A tartalom és a futtatókörnyezet külön állítható vissza
A tartalom visszaállítása ne igényelje az identitás újratelepítését. Egy Lambda-javítás miatt ne kelljen újraexportálni az egész webhelyet.
Eltéréskezelés
Sablonok a konzolos régészkedés helyett
A CloudFormation-alapú telepítés láthatóvá és megismételhetővé teszi a kívánt architektúrát a kézzel újraépített konzollépések helyett.
Hibák izolálása
Elsődleges a statikus keret
Ha egy AI-végpont átmenetileg nem érhető el, a nyilvános tartalomnak továbbra is be kell töltődnie. Ha a WordPress adminfelület leáll, a statikus frontend elérhető maradhat.
Biztonsági felülvizsgálat
Ne csak a pluginokat, a bizalmi határokat is vizsgálja
Az érdemi felülvizsgálat azt ellenőrzi, hol kényszerítik ki a tokenek, sütik, kulcsok, szerepkörök és védett útvonalak használatát.
Megvalósítási útvonal
- Térképezze fel, mely webhelyrészek csak tartalmiak, hitelesítettek, védett statikusak, AI-alapúak, űrlap- vagy API-vezéreltek.
- Válassza ki az első AWS-képességet: identitás, biztonságos statikus védelem, AI-backend vagy munkafolyamat-futtatókörnyezet.
- Telepítse a megfelelő sablont a Deployment Wizard vagy a CloudFormation útvonalán, és rögzítse a stackkimeneteket.
- Vezesse vissza a kimeneteket a megfelelő WP Suite-plugin konfigurációjába.
- Készítsen üzemeltetési kézikönyvet a paraméterekről, kimenetekről, DNS-ről, tanúsítványokról, naplókról, visszaállításról és az AWS-fiók tulajdonosáról.
- Csak akkor illessze be a következő képességet, amikor annak határa egyértelmű; az első projektből ne legyen egyszerre végrehajtott teljes platformmigráció.
Mikor jó választás
- A WordPress-webhelynek hitelesítésre, védett tartalomra, AI-funkciókra, űrlapokra vagy API-kra van szüksége, miközben a nyilvános oldalaknak gyorsnak és könnyen üzemeltethetőnek kell maradniuk.
- Egy ügynökség ismételhető, ügyfél tulajdonában lévő AWS-architektúrát szeretne egyedi pluginstackek helyett.
- Egy CTO a szerkesztési hatékonyság miatt WordPresst szeretne, de nem akarja, hogy minden futtatási feladatot a PHP/MySQL kezeljen.
- Egy dokumentációs, tudásbázis- vagy portálwebhelynek ugyanabban az élményben kell nyilvános tartalmat, privát részeket és AI-keresést biztosítania.
- A csapat csökkentené a forrásrendszer kitettségét anélkül, hogy a webhelyet teljesen headless alkalmazásként építené újra.
Mikor nem ajánlott
- Egy egyszerű bemutatkozó webhelyen nincs bejelentkezés, védett útvonal, AI, munkafolyamat vagy érdemi futtatási követelmény.
- A csapat nem tudja vállalni vagy delegálni az AWS-fiók, a DNS, a tanúsítványok és az üzemeltetési megfigyelés tulajdonlását.
- Szervezeti vagy szerződéses okokból minden dinamikus működésnek a meglévő WordPress-pluginokon belül kell maradnia.
- A projektnek fontosabb az egyszeri gyors megvalósítás, mint az újrahasznosítható architektúra.
Kapcsolódó források
Részletes bemutató
Cognito Day‑2 identitásarchitektúra
a Cognito CloudFormation-identitási gerinc részletes bemutatása
Részletes bemutató
Biztonságos statikus WordPress aláírt sütikkel
a védett statikus kiszolgálás, a CloudFront-sütik és a Cognito-bejelentkezés részletes bemutatása
Ügynökségek
WP Suite ügynökségeknek
ügyfél tulajdonában lévő AWS-kiszolgálás és szabványosított bevezetési útvonal
GYIK
Ez headless WordPress-architektúra?
Nem a szokásos értelemben. A WordPress marad a szerkesztési és tartalmi rendszer, a frontend pedig továbbra is lehet Gutenberg-renderelt WordPress-kimenet. A futtatókörnyezet úgy válik szét, hogy csak a kijelölt képességek kerülnek AWS-szolgáltatásokba.
Szüksége van a Static Publishernek CloudFormation-stackre?
Nem. A Static Publisher a publikálási folyamat. AWS-kiszolgálási célokra publikálhat, de a WP Suite modelljében nincs szüksége saját CloudFormation-stackre.
Mely részek épülnek ténylegesen sablonokra?
A legerősebb stackalapú családok az identitás, a védett statikus kiszolgálás, az AI-backend és a munkafolyamat-futtatókörnyezet. Egymástól függetlenül vezethetők be, és kimeneteken, valamint pluginkonfiguráción keresztül állíthatók össze.
Miért ne használjunk egyszerűen menedzselt WordPress-tárhelyet?
A menedzselt tárhely sok webhelynek továbbra is jó választás. A szétválasztott architektúra akkor válik értékessé, amikor számít az identitás, a privát útvonalak, az AI, a munkafolyamatok, az ügyfél tulajdonában lévő infrastruktúra vagy a szigorú futásidejű izoláció.
Bevezethető ez fokozatosan?
Igen. Kezdje egy egyértelmű határú képességgel, például Cognito-bejelentkezéssel vagy védett statikus résszel, majd csak indokolt esetben adjon hozzá AI- vagy munkafolyamat-futtatókörnyezetet.
Használja a WordPresst CMS-ként, az AWS-t futtatókörnyezetként
Használja ezt a pilléroldalt kiindulópontként: először értse meg a teljes rendszert, majd mélyedjen el az identitásban, a védett statikus kiszolgálásban, az AI-ban és a munkafolyamatokban.