Arquitectura · Guía principal
Arquitectura de referencia de WordPress en AWS
Un mapa técnico detallado para utilizar WordPress como capa editorial mientras AWS se ocupa de la identidad, la entrega estática, el entorno de ejecución protegido, la IA y los flujos de trabajo.
Tesis de arquitectura: WordPress debe seguir siendo el CMS y la experiencia de administración, no el único límite de ejecución para todas las funciones. WP Suite convierte WordPress en un frontend de aplicaciones componible al trasladar la identidad, la entrega protegida, la IA, las API y los flujos de trabajo a servicios de AWS propiedad del cliente.
Por qué existe esta arquitectura
La mayoría de los diagramas de arquitectura de WordPress siguen partiendo de la misma premisa: WordPress controla el entorno de ejecución público. PHP renderiza la página, MySQL atiende la solicitud, los plugins se ejecutan dentro del mismo proceso y escalar significa añadir más capacidad al mismo stack.
WP Suite sigue un camino diferente. WordPress continúa siendo el plano de control editorial y administrativo, pero las responsabilidades de ejecución se distribuyen entre los servicios de AWS más adecuados para cada tarea: entrega estática en el edge, identidad en Cognito, API en API Gateway y Lambda, IA en servicios respaldados por Bedrock y flujos de trabajo en infraestructura orientada a eventos.
El objetivo no es sustituir WordPress por una reconstrucción headless. Se trata de dejar de forzar todas las funciones de la aplicación a pasar por el entorno de ejecución de WordPress cuando el sitio ya es más que un sitio de publicación.
Límite del sistema
Editores / administradores
│
▼
WordPress + Gutenberg
contenido, diseño, ajustes, UX de administración
│
capa de integración de WP Suite
│
┌─────────────────────────┼─────────────────────────┐
│ │ │
▼ ▼ ▼
Entrega estática Plano de identidad API de ejecución
Static Publisher Gatey + Cognito API Gateway + Lambda
S3 + CloudFront User/Identity Pools lógica de negocio
│ │ │
└──────────────┬──────────┴──────────────┬──────────┘
▼ ▼
Entorno de ejecución del navegador Plano de IA / flujos de trabajo
páginas renderizadas con Gutenberg Bedrock, S3, DynamoDB,
componentes del lado del cliente EventBridge, SES, WAF
El límite es deliberadamente sencillo: WordPress se ocupa de la autoría, la estructura de URL, el marcado de Gutenberg, los flujos editoriales y la configuración de módulos. AWS se ocupa de las rutas de ejecución que requieren escalado independiente, mayor aislamiento, acceso basado en identidad, procesamiento de eventos o acceso a modelos.
Static Publisher forma parte de la estrategia de entrega, pero no es por sí mismo un stack de CloudFormation. Exporta y publica el sitio renderizado en un destino de entrega de AWS; las funciones respaldadas por stacks se sitúan alrededor de la identidad, la entrega protegida, el backend de IA y el entorno de ejecución de flujos de trabajo.
Mapa de capacidades
Plano de contenido
WordPress y Gutenberg
La capa de edición habitual continúa siendo la fuente de referencia para páginas, entradas, bloques, contenido de CPT, diseño, metadatos y configuración de productos.
Plano de entrega
Static Publisher, S3 y CloudFront
Las páginas y los recursos renderizados pueden servirse desde S3 y CloudFront, de modo que el tráfico público deje de depender de capacidad PHP/MySQL activa.
Plano de identidad
Gatey y Amazon Cognito
La autenticación, el registro, la MFA, el SSO, los grupos, los JWT y las credenciales IAM opcionales se delegan en Cognito y se utilizan directamente en el navegador.
Plano estático protegido
Static Site Guardian
Las rutas estáticas seleccionadas pueden protegerse en CloudFront mediante cookies firmadas, un servicio de firma y flujos de inicio de sesión integrados con Cognito.
Entorno de ejecución de aplicaciones
API Gateway y Lambda
El comportamiento en tiempo de ejecución, como las acciones de cuenta, los datos protegidos, los pasos de flujos de trabajo y la lógica de integración, se expone mediante API específicas en lugar de endpoints AJAX de WordPress.
Entorno de ejecución de IA
AI-Kit, Bedrock y S3 Vectors
La IA en el dispositivo puede encargarse de las tareas locales, mientras que el backend alternativo y los flujos RAG se ejecutan, cuando es necesario, en un backend de AWS propiedad del cliente.
Plano de flujos de trabajo
Flow y servicios orientados a eventos
Los formularios y los envíos de varios pasos pueden convertirse en desencadenadores de correo electrónico, webhooks, EventBridge, agentes de IA y flujos de procesamiento backend.
Plano de aprovisionamiento
Deployment Wizard y CloudFormation
Las capacidades repetibles de AWS se despliegan mediante plantillas guiadas, de modo que las agencias y los equipos puedan estandarizar la implementación sin construir manualmente cada stack.
Flujos de solicitud canónicos
Flujo 1
Solicitud de página estática pública
Un visitante solicita una página pública. CloudFront sirve desde S3 el HTML exportado y los recursos. WordPress no forma parte de la ruta de la solicitud, por lo que los picos de tráfico afectan al CDN, no a los workers PHP ni a las conexiones de base de datos.
Flujo 2
Estado del usuario autenticado
Gatey renderiza en la página la interfaz de inicio de sesión de Cognito. El navegador se autentica con Cognito, recibe tokens y expone el estado de identidad a los bloques de WP Suite sin almacenar secretos ni tokens en el servidor de WordPress.
Flujo 3
Llamada a una API protegida
Un componente frontend llama a API Gateway con autorización basada en JWT o IAM. Lambda ejecuta la lógica de negocio y devuelve únicamente los datos que el usuario autenticado puede consultar.
Flujo 4
Ruta estática protegida
Un visitante accede a una ruta protegida. CloudFront comprueba las cookies firmadas. Si faltan o han caducado, se redirige al usuario para que inicie sesión; una vez validado, el servicio de firma concede acceso al conjunto de rutas protegidas.
Flujo 5
Solicitud de IA/RAG
AI-Kit intenta utilizar IA local en el navegador cuando resulta adecuado. Si se necesita un backend, el navegador llama al endpoint de API configurado, que dirige la solicitud mediante Lambda a Bedrock, documentos de S3, metadatos de la base de conocimiento y guardrails.
Flujo 6
Solicitud del formulario al flujo de trabajo
Un formulario de Flow captura la interacción del frontend y después transfiere el trabajo persistente a acciones backend, correo electrónico, webhooks, EventBridge o pasos de IA, en lugar de depender de una única solicitud PHP síncrona.
Familias de arquitectura respaldadas por CloudFormation
Deployment Wizard convierte un pequeño número de decisiones de producto en parámetros de CloudFormation, abre el flujo de revisión «Create stack» de AWS y utiliza después las salidas del stack —como URL base de API, ARN de roles, identificadores de User Pool o ajustes de distribución— como contrato de retorno a WordPress. Cada familia de plantillas debe corresponder a una responsabilidad arquitectónica real.
| Familia de plantillas | Responsabilidad principal | Recursos habituales de AWS | Enfoque del artículo |
|---|---|---|---|
| Identidad de Cognito a partir del segundo día | Convertir Cognito en una base de identidad reutilizable para WordPress | User Pool, App Client, Identity Pool, roles de IAM, desencadenadores Lambda, plantillas de correo en S3 y Route53 opcional | La identidad es más que el inicio de sesión: incluye el diseño de tokens, la asignación de grupos, la entrega de correo y la autorización de API. |
| Static Site Guardian | Proteger rutas estáticas seleccionadas sin reintroducir un entorno de ejecución PHP | S3, CloudFront, Key Groups/Public Keys, Lambda de firma o lógica de edge, API Gateway, KMS/SSM y Route53 opcional | La exportación estática resuelve la entrega, pero el contenido privado requiere autorización en el edge y una gestión rigurosa de las cookies. |
| Backend de AI-Kit | Proporcionar un backend alternativo y API de RAG y chatbot en la cuenta del cliente | API Gateway, Lambda, Bedrock, S3, S3 Vectors/Knowledge Base, DynamoDB, EventBridge, WAF y SSM/KMS | La IA privada es un patrón de infraestructura, no solo una función de un LLM. |
| Backend de Flow | Ejecutar flujos de trabajo iniciados por formularios fuera del ciclo de vida de las solicitudes de WordPress | API Gateway, Lambda, tablas de DynamoDB para formularios/envíos/eventos/plantillas/flujos de trabajo/webhooks, buckets de S3 para payloads y plantillas, EventBridge, SES, WAF y reCAPTCHA | Los formularios se convierten en frontends de aplicaciones cuando la validación, los borradores, las cargas, los correos, los webhooks y los eventos de flujo de trabajo son responsabilidad de un backend dedicado. |
| Destino de Static Publisher | Publicar la salida renderizada de WordPress en un destino de entrega de AWS | Utiliza destinos de despliegue de S3/CloudFront, pero no necesita un stack dedicado propio | La canalización de entrega y la arquitectura de ejecución están relacionadas, pero no son lo mismo. |
Límites de seguridad y confianza
La decisión de diseño más importante es evitar que WordPress se convierta en el custodio de todos los secretos, tokens y decisiones de ejecución. En este modelo, WordPress almacena la configuración y renderiza bloques; el navegador, Cognito, CloudFront y API Gateway hacen cumplir los límites de seguridad.
Sin secretos de cliente en WordPress
Diseño de Cognito para clientes públicos
Gatey está diseñado en torno a flujos de Cognito ejecutados en el navegador. El servidor de WordPress no necesita actuar como proxy de contraseñas, conservar tokens de usuario ni guardar un secreto de cliente de Cognito.
Autorización en el edge
Rutas protegidas en CloudFront
El contenido estático puede seguir siendo privado si CloudFront exige cookies firmadas antes de servir los objetos de S3.
Autorización de API
JWT o IAM en API Gateway
Las acciones protegidas deben autorizarse en la capa de API, no ocultarse mediante CSS del frontend o reglas de visibilidad exclusivas de WordPress.
Superficies separadas
Rutas de administración, frontend y públicas
La superficie de API de administración y edición, la superficie de API para visitantes del frontend y la superficie estática pública deben limitarse, autenticarse y registrarse de forma independiente.
Backend propiedad del cliente
Infraestructura en la cuenta de AWS del cliente
La arquitectura es más sólida cuando las rutas sensibles de ejecución, identidad e IA residen en la cuenta del cliente en lugar de una caja negra SaaS compartida.
Privilegio mínimo por stack
Radio de impacto de IAM reducido
Cada plantilla debe aprovisionar únicamente los permisos necesarios para esa capacidad y exponer salidas que permitan componerla con otros stacks.
Modelo de rendimiento, costes y escalado
Los stacks dinámicos tradicionales de WordPress suelen diseñarse para la carga máxima: capacidad PHP, capacidad de base de datos, capas de caché y, en ocasiones, clústeres de bases de datos dimensionados para eventos poco frecuentes. Esto tiene sentido para algunas cargas de trabajo, pero resulta caro cuando la mayoría de las páginas pueden almacenarse en caché y solo determinadas interacciones necesitan comportamiento en tiempo de ejecución.
El modelo de WP Suite separa la superficie siempre activa de la superficie bajo demanda. El HTML público y los recursos se entregan en el edge. Las funciones de ejecución escalan de forma independiente y solo se ejecutan cuando un visitante inicia sesión, envía un formulario, formula una pregunta a la IA o llama a una API protegida.
| Dimensión | WordPress dinámico tradicional | Separación de WP Suite en AWS | Por qué es importante |
|---|---|---|---|
| Entrega de páginas públicas | PHP y la base de datos siguen formando parte del origen incluso con caché | S3 y CloudFront sirven el HTML exportado y los recursos | Los picos de tráfico no implican automáticamente escalar PHP o la base de datos. |
| Identidad | La lógica del plugin suele ejecutarse dentro de WordPress y almacenar allí el estado de sesión | Cognito gestiona la autenticación, la MFA, el SSO y los tokens | La autenticación puede sobrevivir a la exportación estática y continúa siendo independiente del alojamiento de WordPress. |
| Comportamiento dinámico | AJAX/admin-ajax o endpoints PHP personalizados | API Gateway y Lambda para cada capacidad de ejecución | Cada función puede escalar, fallar y protegerse de forma independiente. |
| IA | Llamadas a API externas desde PHP o desde un plugin SaaS de terceros | Primero en el dispositivo, con backend alternativo en la cuenta de AWS del cliente | Mantiene el contenido, los prompts, los documentos y las políticas más cerca de su propietario. |
| Compromiso operativo | Modelo mental más sencillo, mayor acoplamiento en tiempo de ejecución | Más arquitectura, menos acoplamiento | La separación compensa cuando importan la seguridad, el escalado, la privacidad o la repetibilidad. |
Modelo operativo
La arquitectura trata cada stack como un subsistema delimitado, con salidas, registros, permisos y expectativas de reversión.
Estrategia de entornos
Stacks de desarrollo, staging y producción
Utilice stacks y dominios separados siempre que sea posible. Static Publisher puede publicar el mismo resultado de rastreo en varios destinos de despliegue cuando solo cambian el dominio y el bucket.
Observabilidad
Registros en el límite adecuado
CloudFront, API Gateway, Lambda, los desencadenadores de Cognito, WAF y las llamadas a Bedrock deben tener un responsable claro de los registros y una ruta definida para la depuración.
Reversión
Revertir el contenido y el entorno de ejecución por separado
Revertir el contenido no debe exigir volver a desplegar la identidad. Corregir una función Lambda no debe obligar a exportar de nuevo todo el sitio.
Control de desviaciones
Plantillas en lugar de arqueología en la consola
El despliegue basado en CloudFormation hace visible y repetible la arquitectura prevista, en lugar de depender de pasos de consola recreados manualmente.
Aislamiento de fallos
Primero, la estructura estática
Si un endpoint de IA deja de estar disponible temporalmente, el contenido público debe seguir cargándose. Si la administración de WordPress está inactiva, el frontend estático puede continuar disponible.
Revisión de seguridad
Revisar los límites de confianza, no solo los plugins
La revisión relevante se centra en dónde se aplican los tokens, las cookies, las claves, los roles y las rutas protegidas.
Ruta de implementación
- Identifique qué partes del sitio son solo de contenido, autenticadas, estáticas protegidas, basadas en IA, controladas por formularios o dirigidas por API.
- Seleccione la primera capacidad de AWS: identidad, protección estática segura, backend de IA o entorno de ejecución de flujos de trabajo.
- Despliegue la plantilla correspondiente mediante Deployment Wizard o la ruta de CloudFormation y capture las salidas del stack.
- Conecte las salidas con la configuración del plugin de WP Suite correspondiente.
- Añada un runbook que incluya parámetros, salidas, DNS, certificados, registros, reversión y la responsabilidad sobre la cuenta de AWS.
- Componga la siguiente capacidad solo cuando su límite esté claro; evite convertir el primer proyecto en una migración integral de la plataforma.
Cuándo resulta adecuado
- Un sitio de WordPress necesita autenticación, contenido protegido, funciones de IA, formularios o API, pero las páginas públicas deben seguir siendo rápidas y requerir poco mantenimiento.
- Una agencia busca una arquitectura de AWS repetible y propiedad del cliente en lugar de stacks de plugins creados caso por caso.
- Un CTO quiere WordPress por su productividad editorial, pero no desea que PHP/MySQL controle todas las funciones en tiempo de ejecución.
- Un sitio de documentación, una base de conocimiento o un portal necesita contenido público, secciones privadas y búsqueda con IA dentro de la misma experiencia.
- Un equipo quiere reducir la exposición del origen sin reconstruir el sitio como una aplicación completamente headless.
Cuándo no utilizarla
- Un sitio corporativo sencillo no tiene inicio de sesión, rutas protegidas, IA, flujos de trabajo ni requisitos relevantes de ejecución.
- El equipo no puede asumir ni delegar la responsabilidad de una cuenta de AWS, el DNS, los certificados y la supervisión operativa.
- Por razones organizativas o contractuales, todo el comportamiento dinámico debe permanecer dentro de los plugins existentes de WordPress.
- El proyecto prioriza la velocidad de una implementación única frente a una arquitectura reutilizable.
Recursos relacionados
Análisis detallado
Arquitectura de identidad de Cognito a partir del segundo día
Análisis detallado de la base de identidad de Cognito con CloudFormation
Análisis detallado
WordPress estático seguro con cookies firmadas
Análisis detallado de la entrega estática protegida, las cookies de CloudFront y el inicio de sesión de Cognito
Producto
Gatey
Inicio de sesión con Cognito, SSO, MFA y autenticación en el navegador para WordPress
Producto
Static Publisher
Exportación consciente del renderizado y canalización de publicación en AWS
Producto
Flow
Capa de automatización de formularios y flujos de trabajo para experiencias de WordPress similares a aplicaciones
Familia de productos
WP Suite Platform
El mapa general de la plataforma que sustenta el grupo de arquitecturas
Guía de implementación
Documentación de implementación
Documentación para desarrolladores y referencias de API
Agencias
WP Suite para agencias
Entrega en AWS propiedad del cliente y ruta de implantación estandarizada
Preguntas frecuentes
¿Es esta una arquitectura headless de WordPress?
No en el sentido habitual. WordPress sigue siendo el sistema de edición y contenido, y el frontend puede continuar siendo una salida de WordPress renderizada con Gutenberg. El entorno de ejecución se divide para trasladar capacidades seleccionadas a servicios de AWS.
¿Necesita Static Publisher un stack de CloudFormation?
No. Static Publisher es la canalización de publicación. Puede publicar en destinos de entrega de AWS, pero en el modelo de WP Suite no necesita un stack de CloudFormation dedicado.
¿Qué partes están realmente respaldadas por plantillas?
Las familias respaldadas por stacks más importantes son la identidad, la entrega estática protegida, el backend de IA y el entorno de ejecución de flujos de trabajo. Pueden adoptarse de forma independiente y componerse mediante salidas y la configuración de los plugins.
¿Por qué no utilizar simplemente alojamiento gestionado de WordPress?
El alojamiento gestionado sigue siendo una buena opción para muchos sitios. La arquitectura dividida aporta valor cuando importan la identidad, las rutas privadas, la IA, los flujos de trabajo, la infraestructura propiedad del cliente o el aislamiento estricto del entorno de ejecución.
¿Puede introducirse gradualmente?
Sí. Empiece por la capacidad que tenga un límite claro, como el inicio de sesión de Cognito o una sección estática protegida; añada el entorno de ejecución de IA o flujos de trabajo solo cuando el caso de uso lo justifique.
Utilice WordPress como CMS y AWS como entorno de ejecución
Utilice esta página principal como punto de partida: comprenda primero el sistema completo y profundice después en la identidad, la entrega estática protegida, la IA y los flujos de trabajo.