¿Qué permanece en AWS, Cloudflare, Vercel, Supabase y headless CMS?
Hola, soy Otsuka, CTO de Liberogic.
En la entrega anterior, clarificamos las diferencias entre registros de acceso, registros de aplicación y registros de auditoría.
Esta vez examinaremos de forma más concreta qué tipo de registros se pueden obtener en AWS, Cloudflare, Vercel, Supabase y headless CMS, servicios que manejamos regularmente.
Esto no significa que haremos una comparación detallada de precios y características de cada servicio.
Las características varían considerablemente de un servicio a otro en términos de "qué se registra de forma estándar" y "hasta dónde se puede revisar posteriormente", así que lo organizaremos de manera general.
Servicios | Registros que principalmente se pueden confirmar | Enfoque de retención a largo plazo | Puntos a tener en cuenta |
|---|---|---|---|
AWS | Ejecución, acceso y operaciones de administración | 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 se separa 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 requieren implementación adicional |
Headless CMS | Actualizaciones de contenido, operaciones administrativas | Uso de funciones de historial y auditoría de servicios | Las operaciones objetivo y planes difieren |
Datadog／Sentry | Registros consolidados, información de errores | Diseñado según uso y volumen de almacenamiento | La implementación sola no genera un registro de auditoría |
Incluso con la misma "funcionalidad de registro", las operaciones objetivo y los períodos de retención varían.
Además, lo que se muestra en la pantalla de administración y lo que se conserva a largo plazo con fines de auditoría son dos cosas diferentes.
AWS tiene todo cubierto, pero requiere configuración
AWS cuenta con una gama muy completa de servicios relacionados con registros.
Por ejemplo, la actividad de servicios como Lambda o API Gateway se recopila en CloudWatch Logs. Las operaciones realizadas en la consola de administración de AWS o mediante API se pueden registrar en CloudTrail.
En pocas palabras,
- CloudWatch Logs: visualizar el comportamiento de aplicaciones y servicios de AWS
- CloudTrail: ver quién hizo qué en tu entorno de AWS
- S3: almacenar registros a largo plazo
es la división de roles.
Dado que búsqueda, monitoreo, notificaciones y almacenamiento a largo plazo se pueden montar dentro de AWS, es una arquitectura fácil de adaptar a sistemas con requisitos de auditoría estrictos.
Sin embargo, no es que "si usas AWS, todo se guarde automáticamente".
Necesitas configurar la salida de registros para cada servicio que uses, y también decidir el período de retención y el destino de almacenamiento. Cuanta mayor flexibilidad, más importante es un diseño adecuado.
Cloudflare separa las investigaciones a corto plazo del almacenamiento externo
En Cloudflare Workers, puedes ver el contenido que genera console.log() y los errores en Workers Logs.
Es muy útil para verificar durante el desarrollo e investigar problemas recientes, pero cuando necesita mantener un registro de auditoría a largo plazo, no es recomendable depender únicamente de la pantalla de registro estándar.
Para los registros que requieren almacenamiento prolongado, considere una configuración que utilice Logpush u otro servicio para enviarlos a R2 o a un servicio de gestión de registros externo.
Además, cuando distribuye sitios web estáticos mediante Cloudflare Pages o Workers, no todos los accesos quedan registrados en los registros de ejecución de Worker.
Aunque el sitio se muestre normalmente, es fácil asumir que «naturalmente habrá registros de acceso», pero la distribución de archivos estáticos y la ejecución de Worker son procesos diferentes.
Aunque Cloudflare facilita crear configuraciones relativamente compactas, debe entender qué proceso pasa por dónde para diseñar los registros adecuadamente.
Vercel facilita verificar los registros de Next.js
En Vercel, puede verificar los registros generados por funciones de Next.js, Server Actions y similares desde el panel de administración.
Como los registros de implementación y ejecución están cerca uno del otro, es fácil de entender para los desarrolladores y facilita la investigación de errores en el día a día.
Sin embargo, el período durante el cual puede verificar registros y el alcance de transferencia externa varía según el plan.
Si necesita conservarlos durante más tiempo, será necesario un mecanismo adicional, como usar Drains para enviarlos a un destino de almacenamiento externo.
No es lo mismo que los registros se muestren en la consola de administración de Vercel que el hecho de que se conserven a largo plazo con fines de auditoría.
Es necesario verificar estos dos aspectos por separado.
Supabase genera muchos registros más allá de la base de datos
Aunque Supabase es un servicio centrado en PostgreSQL, en realidad está compuesto por múltiples funciones además de la base de datos: autenticación, API, almacenamiento y Edge Functions.
Es posible verificar cada uno de estos registros desde la consola de administración, lo que facilita el seguimiento del funcionamiento de toda la aplicación.
También existen 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 desarrollaste son distintas.
Por ejemplo, aunque el servicio puede registrar "quién cambió la configuración del proyecto de Supabase", es necesario que la aplicación misma registre "quién cambió la información del cliente en la consola de administración propia".
Verifica el historial de operaciones del headless CMS
Los headless CMS como microCMS, Kuroco y NILTO ofrecen historiales de actualización de contenido y registros de operaciones en la consola de administración.
Los registros de quién actualiza un artículo, cuándo se publica, y cambios en configuración y permisos son fundamentales como registros de auditoría en la gestión de sitios web.
Sin embargo, las operaciones registradas, el período de visualización disponible y los planes accesibles varían según el servicio.
Aunque se puede confirmar el historial de actualizaciones de contenido, no todas las operaciones de administración se registran necesariamente como registros de auditoría.
Además, un CMS contiene fundamentalmente registros de operaciones internas del CMS. El acceso al sitio web publicado y los errores que ocurren en el lado del frontend deben verificarse en el entorno de alojamiento.
En proyectos de headless CMS, es útil considerar el CMS, frontend, alojamiento y API como un único sistema.
Cuando se añaden Datadog o Sentry
Cuando los registros se distribuyen en múltiples servicios, debe abrir cada panel de administración para investigar cada vez que ocurre 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 es un servicio especializado en investigar dónde ocurren errores y su alcance de impacto.
Aunque ambos son útiles, su implementación no garantiza automáticamente un registro de auditoría completo.
La aplicación debe decidir qué registrar, y almacenar todos los registros durante períodos prolongados aumentará los costos según el volumen de datos.
Método de almacenamiento | Casos de uso recomendados | Características |
|---|---|---|
Servicio de gestión de panel de administración y registros | Investigación de incidentes rutinarios | Búsqueda rápida disponible, pero los costos aumentan según la capacidad de almacenamiento |
Almacenamiento como R2 o S3 | Retención a largo plazo de registros de auditoría y trazabilidad | Bajo costo de almacenamiento, pero requiere extracción de datos para investigaciones |
En la práctica, es razonable separar los registros que consultas regularmente de aquellos que guardas por si acaso.
No se puede decidir cuál servicio es superior
No puedes determinar que AWS o Cloudflare es el mejor simplemente comparando registros.
Lo importante es saber qué necesitas registrar en tu proyecto específico.
- Investigar errores del servicio
- Mantener registro de las acciones del administrador
- Verificar 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 qué necesitas, podrás ver qué se puede cubrir con las funciones estándar de cada servicio y qué requiere soluciones adicionales.
Nosotros tampoco preparamos una base de registros grande desde el principio, sino que pensamos en la configuración de acuerdo con los requisitos y el presupuesto de cada proyecto.
La próxima vez, cuando se combinan estos servicios, veremos qué tipo de registros genera la aplicación y dónde se almacenan. Presentaremos temas más cercanos 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