Arquitectura · Análisis detallado · Modelo de despliegue
Arquitectura de AWS Deployment Wizard para equipos de WordPress
Una arquitectura práctica que convierte las decisiones de producto de WP Suite en despliegues repetibles de CloudFormation dentro de la cuenta de AWS del cliente.
Tesis de arquitectura: Deployment Wizard no es una pantalla de configuración meramente estética. Es el puente entre la intención de producto en WordPress y la propiedad de la infraestructura de AWS: recopila unas pocas decisiones relevantes, abre el flujo de revisión «Create stack» de CloudFormation, despliega en la cuenta correcta y conecta después las salidas resultantes con WordPress.
Por qué la experiencia de despliegue forma parte de la arquitectura
La mayoría de los usuarios de WordPress no quieren diseñar manualmente API Gateway, Lambda, Cognito, DynamoDB, WAF o Bedrock. La mayoría de los arquitectos de AWS tampoco quieren que un plugin cree infraestructura crítica ocultando lo que ha hecho. WP Suite debe ofrecer confianza a ambas partes.
Deployment Wizard resuelve esta tensión manteniéndose deliberadamente ligero. Recopila decisiones de producto, genera un flujo de CloudFormation con parámetros predefinidos y permite que AWS siga siendo el lugar donde se revisa, crea y posee el stack.
Por eso este tema merece su propio artículo de arquitectura: el modelo de aprovisionamiento forma parte de la relación de confianza. Explica cómo WP Suite puede ofrecer patrones avanzados de AWS sin convertirse en una dependencia SaaS alojada y opaca.
Límite del sistema
WP Suite / ajustes del plugin
el usuario elige la función deseada y unas pocas opciones importantes
│
▼
Deployment Wizard
valida las elecciones y crea los parámetros de CloudFormation
│
▼
AWS Console → CloudFormation → Create stack (revisión)
el cliente revisa los recursos, parámetros, IAM y salidas
│
▼
Stack de AWS propiedad del cliente
Cognito / backend de IA / backend de Flow / stack de entrega protegida
│
▼
Salidas de CloudFormation
ApiBaseUrl, UserPoolId, ARN de roles, detalles de distribución/dominio, nombres de buckets
│
▼
Configuración del plugin de WordPress
Gatey, AI-Kit, Flow o los componentes de protección estática llaman al backend desplegado
El límite importante es la propiedad. WP Suite puede generar la ruta de despliegue, pero el entorno de ejecución pertenece a la cuenta de AWS donde se crea el stack.
El contrato del asistente
| Elemento del contrato | De qué se ocupa el asistente | De qué se ocupa AWS/CloudFormation |
|---|---|---|
| Recopilación de decisiones | Solicitar únicamente las pocas decisiones de producto que modifican la forma del stack: funciones, modo de autenticación, protecciones opcionales, dominios y valores de integración. | Validar parámetros, crear recursos, controlar desviaciones y actualizaciones, y exponer las salidas. |
| Origen de la plantilla | Dirigir CloudFormation a la versión correcta del artefacto de plantilla alojado en S3. | Leer la plantilla y crear los recursos declarados en la cuenta y región de destino. |
| Paso de revisión | Enviar al usuario a la revisión de «Create stack» con los parámetros predefinidos. | Mostrar el contexto final de recursos, IAM y change set antes del despliegue. |
| Conexión posterior al despliegue | Indicar al usuario qué salidas debe copiar en los ajustes de WordPress. | Producir salidas como URL base de API, identificadores de Cognito, ARN de roles, nombres de buckets o ajustes de distribución. |
| Control de versiones | Exponer decisiones de producto seguras y mantener los valores de versión controlados por los desarrolladores fuera de las elecciones habituales del usuario. | Utilizar versiones de plantillas para actualizar la infraestructura desplegada de forma predecible. |
¿Por qué no desplegarlo todo directamente desde WordPress?
Un plugin de WordPress puede ofrecer una interfaz sencilla, pero no debe convertirse silenciosamente en el plano de control de infraestructura para cuentas de producción de AWS. Para CTO y agencias, el paso de revisión en AWS no supone fricción: es el punto de gobernanza donde se hacen visibles IAM, las regiones, la facturación, el DNS y la responsabilidad operativa.
| Aprovisionamiento oculto mediante el plugin | Deployment Wizard + CloudFormation | Por qué WP Suite elige la segunda opción |
|---|---|---|
| Primer clic sencillo, trazabilidad de auditoría débil | El usuario ve un stack de CloudFormation en la cuenta de AWS | La infraestructura sigue siendo localizable por el cliente o la agencia. |
| El plugin necesita credenciales amplias de AWS | AWS Console gestiona los permisos para crear el stack | WP Suite no necesita almacenar credenciales cloud de larga duración del cliente. |
| Difícil de reproducir entre distintos clientes | Los parámetros y las salidas forman un contrato repetible | Las agencias pueden redactar runbooks y comparar entornos. |
| La cuenta del proveedor puede ser propietaria del entorno de ejecución | La cuenta del cliente es propietaria de los recursos de ejecución | Los datos, los registros, los costes y los controles de seguridad permanecen más cerca del cliente. |
Diseño de parámetros: preguntar menos, no ocultar más
Un buen asistente de despliegue no expone todos los parámetros de CloudFormation. Expone las decisiones que modifican la arquitectura y oculta las que pertenecen al proceso de publicación o versión. Por ejemplo, un asistente de backend de IA puede preguntar qué funciones y protecciones de frontend se necesitan, mientras mantiene DeploymentVersion bajo el control de los desarrolladores.
Selectores de funciones
Activar únicamente lo que necesita el sitio
Un sitio que solo necesita DocSearch no debe desplegar por accidente todas las rutas públicas de IA posibles.
Modos de autenticación
Separar las superficies de frontend y administración
Las API de administración pueden utilizar de forma predeterminada Cognito y comprobaciones de scopes, mientras que las rutas públicas pueden recurrir a reCAPTCHA, WAF o Cognito según el caso de uso.
Opciones de dominio
El DNS es opcional, pero explícito
Los dominios personalizados, los certificados y los registros de Route53 deben presentarse como opciones visibles porque afectan a la propiedad y a la resolución de problemas.
Controles de seguridad
Las protecciones son decisiones arquitectónicas
WAF, las listas de IP permitidas, reCAPTCHA, KMS y las opciones similares a GuardDuty modifican cómo puede exponerse el backend de forma segura.
Origen del artefacto
CloudFormation debe poder leer las plantillas
Al utilizar enlaces directos a plantillas, CloudFormation necesita una URL de plantilla de S3; la política del bucket de artefactos debe permitir su lectura al principal de servicio de CloudFormation.
Transferencia de la integración
Las salidas del stack conectan las piezas
Los valores como ApiBaseUrl deben copiarse desde CloudFormation, no deducirse a partir de convenciones de nombres.
Familias de stacks en el modelo de WP Suite
| Familia de stacks | Objetivo del asistente | Contrato de salida habitual | Por qué es importante |
|---|---|---|---|
| Identidad de Cognito / Gatey | Crear o conectar una base de identidad reutilizable en Cognito con App Client, grupos, desencadenadores y un dominio personalizado opcional. | User Pool ID, App Client ID, Identity Pool ID, ARN de roles y valores de dominio. | El inicio de sesión se convierte en una capa de identidad reutilizable en tiempo de ejecución, no en un ajuste de plugin limitado a una página. |
| Backend de AI-Kit | Activar en la cuenta del cliente el backend alternativo, el chatbot, DocSearch/RAG y las rutas protegidas de IA y administración. | ApiBaseUrl, ajustes de rutas y autenticación, e identificadores de base de conocimiento y almacenamiento cuando corresponda. | La IA privada se convierte en una capacidad backend desplegable, no en una función de plugin disponible solo como SaaS. |
| Backend de Flow | Desplegar el entorno de ejecución para formularios, envíos, borradores, cargas, plantillas, flujos de trabajo, correo electrónico y webhooks. | URL base de API o dominio personalizado, salidas de buckets, tablas y funciones, y opciones de rutas y autenticación. | Los formularios se convierten en flujos de trabajo duraderos capaces de funcionar con entrega estática e integraciones externas. |
| Entrega estática protegida | Crear el patrón de autorización en el edge para rutas estáticas privadas. | Distribución o dominio de CloudFront, endpoints de firma y API, y ajustes de claves y cookies. | La privacidad de WordPress estático puede aplicarse en la capa de CDN u objetos. |
| Destino de Static Publisher | Publicar la salida renderizada de WordPress en destinos de entrega de AWS; el propio publisher no requiere un stack dedicado. | Configuración del destino de despliegue en lugar de un stack de ejecución independiente. | La publicación y la arquitectura de ejecución permanecen relacionadas, pero no se confunden. |
El contrato de salida es donde WordPress vuelve a conectarse
El despliegue solo resulta útil cuando WordPress puede utilizarlo. La conexión debe ser sencilla y explícita: desplegar el stack, copiar las salidas, pegarlas en los ajustes del plugin y probar la ruta. AI-Kit es el ejemplo más claro: después del despliegue, el usuario copia ApiBaseUrl desde las salidas de CloudFormation a AI-Kit Settings → API Settings.
| Tipo de salida | Valor de ejemplo | Uso en WordPress |
|---|---|---|
| URL base de API | https://abc123.execute-api.region.amazonaws.com/prod o dominio personalizado | Los bloques de AI-Kit y Flow y las pantallas de administración saben dónde enviar las solicitudes al backend. |
| Identificadores de Cognito | User Pool ID, App Client ID, Identity Pool ID | Gatey puede renderizar el Authenticator y obtener tokens para API protegidas. |
| ARN de roles / scopes | ARN de roles IAM, scopes derivados de grupos y scopes de administración | Las API pueden exigir autorización en lugar de confiar en un estado oculto del frontend. |
| Valores de distribución y dominio | Dominio de distribución de CloudFront y endpoint emisor de cookies firmadas | La protección estática y los destinos de publicación pueden documentarse y verificarse. |
| Nombres de buckets y tablas | Bucket de payloads, bucket de plantillas y tablas de datos | Los runbooks y los diagnósticos pueden dirigir a los operadores hacia los recursos correctos de AWS. |
Modelo de gobernanza para agencias y CTO
Propiedad del cliente
El entorno de ejecución llega a la cuenta correcta de AWS
Las agencias pueden desplegar en su propia cuenta o en la cuenta del cliente según el contrato, los requisitos de cumplimiento y el modelo de soporte.
IAM revisable
La revisión del stack expone los permisos
Los arquitectos pueden inspeccionar IAM y la creación de recursos antes del lanzamiento, en lugar de confiar en un flujo de plugin opaco.
Soporte repetible
La misma plantilla, parámetros diferentes
Los runbooks pueden describir una vez los parámetros, las salidas, el DNS, los certificados, los registros y la reversión, y reutilizar después el patrón con distintos clientes.
Visibilidad de costes
La facturación de AWS corresponde a la cuenta donde se despliega
El cliente o la agencia pueden consultar directamente los costes de API, Lambda, modelos, almacenamiento, WAF y registro.
Control de cambios
Las actualizaciones son cambios del stack
Una nueva función de ejecución puede introducirse actualizando un stack o una versión, en lugar de editar manualmente recursos en la consola.
Ruta de salida
Los recursos permanecen visibles
Aunque el plugin de WordPress cambie más adelante, los recursos de AWS desplegados no quedan ocultos en una cuenta inaccesible del proveedor.
Modos de fallo que el artículo debe explicar de forma explícita
| Modo de fallo | Qué sucede | Cómo documentarlo |
|---|---|---|
| Región incorrecta | El stack se despliega, pero los recursos relacionados, como certificados o la configuración de Cognito, se encuentran en otra región. | Enumerar las regiones necesarias para cada familia de stacks y señalar las restricciones de certificados y dominios. |
| Salida no copiada | El plugin de WordPress sigue apuntando a un endpoint antiguo o vacío. | Incluir la copia de salidas como punto de la lista de comprobación del despliegue, no dejarla como conocimiento informal del equipo. |
| Discordancia en la autenticación de administración | El backend espera Cognito, IAM o scopes que el plugin no está configurado para enviar. | Documentar el modo de autenticación, los scopes y las llamadas de prueba inmediatamente después del despliegue. |
| DNS o certificado configurado a medias | El dominio personalizado existe, pero el certificado, Route53 o el mapeo de API están incompletos. | Distinguir en el runbook entre «stack desplegado» y «dominio personalizado activo». |
| Desviación de versiones | Un sitio utiliza recursos antiguos del stack con las expectativas de una interfaz de plugin más reciente. | Registrar conjuntamente las versiones de la plantilla y del plugin en la ficha del cliente. |
Ruta de implementación
- Parta de la función de producto: identidad, backend de IA, backend de Flow, contenido estático protegido o destino de entrega.
- Defina el conjunto mínimo de opciones visibles para el usuario necesario para dar forma al stack.
- Genere una URL de revisión «Create stack» de CloudFormation con parámetros predefinidos.
- Después del despliegue, copie las salidas relevantes en los ajustes correspondientes del plugin de WP Suite.
- Pruebe por separado las rutas públicas, protegidas y de administración.
- Registre en el runbook del sitio los parámetros, las salidas, el DNS, los certificados, los modos de autenticación, los registros y las instrucciones de reversión.
Recursos relacionados
Análisis detallado
Arquitectura de referencia de WordPress en AWS
El artículo principal que integra en un mismo modelo el despliegue, la identidad, la entrega estática, la IA y el entorno de ejecución de flujos de trabajo.
Análisis detallado
Backend privado de IA y RAG
El artículo sobre el backend de AI-Kit en el que la salida ApiBaseUrl se convierte en el contrato de integración con WordPress.
Análisis detallado
Backend orientado a eventos para formularios y flujos de trabajo
El stack del backend de Flow como ejemplo concreto de despliegue guiado para formularios y flujos de trabajo.
Solución
WordPress para agencias en AWS
El argumento empresarial y operativo para una infraestructura repetible propiedad del cliente.
Preguntas frecuentes
¿Es Deployment Wizard un stack de ejecución independiente?
No. Es una capa de aprovisionamiento guiado. El stack de ejecución es aquello que ayuda a desplegar, como Cognito, el backend de AI-Kit, el backend de Flow o la entrega estática protegida.
¿Por qué utilizar CloudFormation en lugar de una API personalizada que cree recursos de AWS?
CloudFormation proporciona al cliente un stack revisable y propiedad de su cuenta, con parámetros, salidas y gestión del ciclo de vida. También evita que WP Suite tenga que almacenar credenciales cloud amplias y de larga duración.
¿Qué debe documentarse después del despliegue?
Como mínimo: los parámetros seleccionados, las salidas del stack, los ajustes copiados en el plugin, las opciones de DNS y certificados, los modos y scopes de autenticación, los grupos de registros, los recursos sensibles al coste y los pasos de reversión.
Despliegue stacks de ejecución de WP Suite sin ocultar la arquitectura de AWS
Utilice un despliegue guiado de CloudFormation para crear backends de AWS propiedad del cliente y vuelva a conectar después las salidas del stack con WordPress.