AWS, Cloudflare, Vercel, Supabase, headless CMS: ¿qué persiste?
Hola, soy Otsuka, CTO de Liberogic.
En la entrega anterior, clasificamos las diferencias entre registros de acceso, registros de aplicaciones y registros de auditoría.
Esta vez, examinaremos de manera más concreta qué tipos de registros se pueden obtener de los servicios que usamos habitualmente: AWS, Cloudflare, Vercel, Supabase y headless CMS.
Dicho esto, no se trata de comparar en detalle los precios y características de cada servicio.
Las características varían considerablemente de un servicio a otro en cuanto a "qué se conserva de forma estándar" y "hasta dónde se puede verificar posteriormente", así que organizaremos esto de manera general.
Servicios | Registros que se pueden confirmar principalmente | Enfoque para la retención a largo plazo | Puntos a tener en cuenta |
|---|---|---|---|
AWS | Ejecución, acceso y operaciones administrativas | Combinar CloudWatch y S3 | Se requiere configuración por servicio |
Cloudflare | Ejecución de Workers, excepciones, etc. | Transferencia a R2 o servicios externos | La entrega estática es independiente de los registros de ejecución |
Vercel | Functions, implementación, registros de ejecución | Transferencia externa mediante Log Drains, etc. | El rango de almacenamiento depende del plan |
Supabase | Base de datos, API, autenticación, operaciones administrativas | Transferencia externa mediante Log Drains, etc. | Las operaciones específicas de la aplicación se implementan por separado |
Headless CMS | Actualización de contenidos, operaciones administrativas | Utilizar las funciones de historial y auditoría del servicio | Las operaciones y planes objetivo difieren |
Datadog／Sentry | Registros consolidados, información de errores | Diseñado según el uso y el volumen de almacenamiento | La simple implementación no constituye un registro de auditoría |
Aunque sea la misma «función de registro», las operaciones objetivo y los períodos de retención varían.
Además, que algo se muestre en la pantalla administrativa es diferente de que se conserve a largo plazo para auditoría.
AWS tiene todo lo necesario, pero se requiere configuración
AWS cuenta con una amplia gama de servicios relacionados con registros.
Por ejemplo, la ejecución de servicios como Lambda o API Gateway se recopila en CloudWatch Logs. Las operaciones realizadas en la consola de administración de AWS o a través de API se pueden registrar en CloudTrail.
En pocas palabras,
- CloudWatch Logs: visualiza la actividad de aplicaciones y servicios de AWS
- CloudTrail: visualiza quién hizo qué en tu entorno de AWS
- S3: almacena registros a largo plazo
es la división de responsabilidades.
Como se puede buscar, monitorear, notificar y archivar a largo plazo todo dentro de AWS, es una arquitectura que se adapta fácilmente a sistemas con requisitos de auditoría estrictos.
Sin embargo, no es cierto que "si usas AWS, todo se registra automáticamente".
Necesitas configurar la salida de registros para cada servicio que utilices y decidir el período de retención y la ubicación de almacenamiento. Dado el alto grado de flexibilidad, es fundamental diseñar esto correctamente.
Cloudflare separa las investigaciones a corto plazo del almacenamiento externo
En Cloudflare Workers, puedes ver el contenido registrado con console.log() y los errores en Workers Logs.
Es muy conveniente para verificar durante el desarrollo e investigar problemas recientes, pero cuando se necesita mantener un rastro de auditoría a largo plazo, es recomendable no depender únicamente de la pantalla de registro estándar.
Para los registros que requieren almacenamiento a largo plazo, se recomienda considerar una configuración que envíe los datos a R2 o a un servicio externo de gestión de registros utilizando Logpush u herramientas similares.
Además, cuando se distribuyen sitios web estáticos a través de Cloudflare Pages o Workers, no todos los accesos quedan registrados en los registros de ejecución de Worker.
Aunque el sitio se muestra correctamente, es fácil asumir que "obviamente también habrá registros de acceso", pero la distribución de archivos estáticos y la ejecución de Workers son procesos distintos.
Cloudflare facilita crear configuraciones relativamente compactas, pero es necesario entender qué proceso pasa por dónde para diseñar los registros correctamente.
Vercel facilita la verificación de registros de Next.js
En Vercel, puede verificar los registros generados por Next.js Functions, Server Actions y otras funciones directamente desde el panel de administración.
Dado que el despliegue y los registros de ejecución están cerca uno del otro, el entorno es intuitivo para los desarrolladores y facilita la investigación diaria de errores.
Por otro lado, el período durante el cual se pueden consultar los registros y el alcance de la transferencia externa varían según el plan.
Si necesita mantener registros durante un período prolongado, será necesario implementar un mecanismo alternativo, como usar Drains para enviar los datos a un destino de almacenamiento externo.
No es solo Vercel; que los registros se muestren en la consola de administración y que se conserven a largo plazo con fines de auditoría son dos cosas diferentes.
Es necesario verificar estas dos cosas por separado.
Supabase tiene muchos registros además de la base de datos
Aunque Supabase es un servicio centrado en PostgreSQL, en realidad está compuesto por múltiples funciones más allá de la base de datos: autenticación, API, almacenamiento, Edge Functions y más.
Como cada registro se puede verificar desde la consola de administración, es fácil rastrear el comportamiento de toda la aplicación.
También hay registros relacionados con la autenticación y registros de auditoría para verificar las operaciones realizadas en la consola de administración de Supabase.
Sin embargo, aquí también es importante tener en cuenta que las operaciones de administración de Supabase y las operaciones dentro de la aplicación que haya creado son cosas diferentes.
Por ejemplo, aunque el servicio puede registrar "quién cambió la configuración del proyecto en Supabase", registrar "quién cambió la información del cliente en la consola de administración de su empresa" debe hacerse en el lado de la aplicación.
Verificar el historial de operaciones del headless CMS
Los headless CMS como microCMS, Kuroco y NILTO proporcionan el historial de actualización de contenido y registros de operaciones de la consola de administración.
Los registros sobre quién actualizó un artículo, cuándo se publicó, o si se cambiaron configuraciones y permisos son importantes como registros de auditoría en la operación de sitios web.
Sin embargo, las operaciones que se registran, el período que se puede revisar y los planes disponibles varían según el servicio.
Aunque es posible verificar el historial de actualizaciones de contenido, no todas las operaciones de administración se quedan necesariamente como registros de auditoría.
Además, el CMS normalmente solo mantiene registros de operaciones dentro del CMS. El acceso al sitio web publicado y los errores que ocurren en el lado del frontend deben verificarse en el entorno de hosting.
En proyectos de headless CMS, es más clara la visión si consideramos el CMS, frontend, hosting y API como un único sistema.
Cuando se añaden Datadog o Sentry
Si los registros se distribuyen entre varios servicios, tendrás que abrir cada panel de administración para investigar cada vez que ocurra un incidente.
La consolidación en un servicio de gestión de registros como Datadog permite buscar registros de múltiples entornos en conjunto y detectar anomalías para enviar notificaciones.
Sentry también se utiliza frecuentemente, pero este servicio es especialista en investigar dónde ocurrieron errores y su alcance de impacto.
Ambos son convenientes, pero su implementación no automáticamente completa el registro de auditoría.
La aplicación debe determinar qué registrar, y almacenar todos los registros durante períodos prolongados aumenta los costos conforme crece el volumen de datos.
Método de almacenamiento | Casos de uso recomendados | Características |
|---|---|---|
Panel de administración y servicio de gestión de registros | Investigación de incidencias rutinarias | Búsqueda rápida disponible, pero los costos aumentan según la capacidad de almacenamiento |
Almacenamiento en R2, S3 y similares | Auditoría y conservación a largo plazo de registros de trazabilidad | Opción económica para conservar datos, aunque requiere un proceso de extracción para su investigación |
Es práctico separar los registros que consultas habitualmente de aquellos que almacenas para situaciones de emergencia.
¿Cuál es el mejor servicio? No es una pregunta que se pueda responder así.
No puedes decidir que AWS o Cloudflare es el mejor simplemente comparando registros.
Lo importante es entender qué es lo que necesitas registrar en cada proyecto.
- Investigar errores del servicio
- Mantener registro de las acciones del administrador
- Revisar el historial de actualizaciones del CMS
- Rastrear cambios de autenticación y permisos
- Conservar registros a largo plazo para auditoría
Una vez que identifiques lo que necesitas, podrás ver qué funcionalidades estándar de cada servicio cubrirán tus requisitos y dónde necesitarás implementar soluciones adicionales.
Tampoco nosotros preparamos una base de registros grande desde el principio, sino que configuramos la estructura según los requisitos y presupuesto de cada proyecto.
La próxima vez abordaremos, cuando se combinan estos servicios, qué tipos de registros genera la aplicación y dónde se almacenan. Presentaremos algo más cercano a la práctica real.
Bueno, hasta luego.
Pilar de la división técnica de Liberogic. Cuando escucha "Me gustaría que existiera esto, sería muy útil", lo implementa en un instante, añadiendo valor gracias a su ingenio innato. Persona con gran capacidad de comunicación, querida por muchos clientes, es un tesoro de nuestra empresa y adora los gatos.
Shō Ōtsuka
Director Técnico / Ingeniero Jefe / Representante de Nekoana LLC / Aparentemente más joven de lo que es