Bajada
AWS habilitó Derived Source en Amazon OpenSearch Serverless para reducir la huella de almacenamiento de índices, especialmente en cargas de logs y analítica de series temporales. La función evita guardar una copia completa del _source y lo reconstruye dinámicamente cuando hace falta, lo que abre una palanca concreta de ahorro para equipos de plataforma con crecimiento acelerado de datos.
Introducción
En la mayoría de entornos DevOps maduros, el problema no es “si vamos a generar más telemetría”, sino cuánto va a costar conservarla y consultarla con latencias razonables. Logs de aplicaciones, eventos de seguridad, trazas parciales, auditoría de pipelines, métricas de plataforma y actividad de identidades terminan convergiendo en motores de búsqueda analítica. En ese contexto, cualquier mejora que reduzca costo de almacenamiento sin romper flujos operativos reales merece atención inmediata.
Amazon anunció soporte de Derived Source en OpenSearch Serverless. La novedad puede parecer pequeña a primera vista, pero toca una zona sensible: la duplicación de datos dentro del índice. Para equipos que operan observabilidad o SIEM sobre OpenSearch, esta decisión impacta directamente en finanzas técnicas (FinOps), arquitectura de índices y prácticas de consulta.
Qué ocurrió
Amazon OpenSearch Serverless incorporó la capacidad de activar derived source por índice. En términos simples, el motor deja de almacenar la copia tradicional del campo _source y, cuando una operación la necesita, la reconstruye a partir de estructuras ya indexadas (como doc values y/o campos almacenados).
Según documentación de AWS y OpenSearch, este enfoque puede reducir de forma significativa el tamaño de índice en cargas de logs y series temporales. AWS habla de reducciones “de hasta 50%” en ciertos patrones, y OpenSearch publica benchmarks con mejoras de almacenamiento entre ~41% y ~58% según dataset. No es una promesa universal: depende del tipo de campo, del patrón de consulta y de cuánto se requiera recuperar documentos completos.
La función está disponible en las regiones donde OpenSearch Serverless ya opera y se configura en el momento de crear el índice mediante un ajuste estático: index.derived_source.enabled=true.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para DevOps y SRE, el impacto más inmediato es el costo total de retención. Menos bytes por documento implica más margen para conservar histórico útil sin disparar presupuesto. Esto es clave cuando las organizaciones intentan equilibrar observabilidad profunda con límites de gasto mensuales.
Para equipos de infraestructura cloud, Derived Source agrega una nueva variable de diseño. Ya no alcanza con definir “qué indexamos”; también hay que decidir “qué costo aceptamos para reconstruir documentos en lectura”. Esto obliga a segmentar índices por comportamiento de consulta: no es lo mismo un índice orientado a agregaciones masivas que uno de investigación forense donde se inspecciona documento completo constantemente.
Para seguridad y respuesta a incidentes, hay que mirar el trade-off con cuidado. Si el caso de uso prioriza búsquedas, agregaciones y detección estadística, el ahorro puede ser muy atractivo. Pero si las investigaciones requieren recuperar grandes volúmenes de eventos crudos con baja latencia, la reconstrucción dinámica puede introducir penalizaciones en algunos escenarios. La decisión, entonces, no es binaria: convive mejor con políticas por tipo de dato y criticidad operativa.
Detalles técnicos
OpenSearch históricamente guarda el JSON original en _source además de las estructuras de índice necesarias para buscar. Esa duplicación facilita operaciones como get, search, update, reindex y ciertos flujos de recuperación, pero incrementa consumo de disco. Derived Source cambia ese comportamiento: evita persistir _source y lo recompone en el momento de la consulta.
Hay varios puntos técnicos que vale la pena subrayar:
- Configuración estática: la bandera se define al crear el índice y no se puede alternar en caliente. Migrar implica planificar reindexación o nuevos índices.
- Compatibilidad de campos: no todos los tipos y parámetros son compatibles. Existen limitaciones en campos con ciertos parámetros (por ejemplo, algunos casos con
copy_to,normalizero estructuras no soportadas). - Diferencias de representación: fechas con múltiples formatos, arrays multivalor, geo_point y precisión pueden devolver resultados con formato normalizado respecto del documento original.
- Latencia de lectura: al recuperar muchos documentos completos, puede haber regresión frente al modelo tradicional, porque la reconstrucción requiere más trabajo por campo.
- Efectos positivos colaterales: índices más pequeños pueden mejorar tiempos de transferencia, recuperación de shards y presión de I/O, según patrón de carga.
También conviene relacionar esto con el modelo operativo de OpenSearch Serverless (OCUs para ingest/query y almacenamiento desacoplado): reducir tamaño de índice no reemplaza una estrategia de capacidad, pero sí mejora la eficiencia estructural del plano de datos.
Qué deberían hacer los administradores o equipos técnicos
Una adopción responsable de Derived Source debería hacerse por fases:
- Clasificar índices por patrón de uso: separar los orientados a agregación de los orientados a recuperación intensiva de documento.
- Probar en staging con carga real: comparar p95/p99 de búsquedas,
get, reindex y tiempos de recuperación, no solo métricas promedio. - Validar mapeos y pipelines: confirmar compatibilidad de tipos de campo y evitar sorpresas de ingestión fallida.
- Definir política de consulta: cuando no se necesita documento completo, forzar
_source: falsey consumir campos puntuales para evitar sobrecostos de reconstrucción. - Ajustar gobierno FinOps: medir ahorro real por colección e incorporar esa señal en decisiones de retención y tiering.
- Documentar rollback operativo: como es configuración estática, tener plan de reversión vía nuevo índice y reindexación controlada.
En equipos de plataforma, la regla práctica es clara: activar Derived Source donde predominen agregaciones y dashboards, y evaluar con más cautela en índices de investigación profunda o auditoría legal.
Conclusión
Derived Source en OpenSearch Serverless no es una novedad cosmética: es una mejora con efecto directo en costo y diseño operacional. Bien aplicada, permite almacenar más señal útil por el mismo presupuesto y sostener crecimiento de telemetría sin degradar gobernanza técnica. Mal aplicada, puede introducir fricción en consultas de recuperación documental intensiva. Para DevOps, SRE y equipos de seguridad, la oportunidad está en convertir esta función en una política por carga de trabajo, no en una configuración global indiscriminada.
Fuentes
- AWS What’s New: OpenSearch Serverless now supports Derived Source
- AWS Documentation: Save storage by using Derived Source
- OpenSearch Blog: Save up to 2x on storage with derived source