Compliance en tiempo real para 50+ parques eólicos
Un operador de energía renovable graba la operación de más de 50 parques eólicos repartidos por el mundo y la envía en tiempo real a su backend de cumplimiento. El volumen crece +2 TB cada día y no puede perderse ni un solo registro. Así centralizaron toda esa ingesta en OtterStorage con la API S3 estándar, versionado e inmutabilidad WORM.
parques eólicos conectados
de datos nuevos al día
ingesta en tiempo real
registros inmutables
Cuando tu obligación legal es demostrar qué hizo cada turbina en cada instante, el almacenamiento deja de ser un detalle de infraestructura y se convierte en parte del cumplimiento. Este operador necesitaba un destino capaz de absorber una escritura continua de millones de objetos, garantizar que ningún registro pudiera alterarse y no convertir el crecimiento en una factura impredecible.
El reto
El operador gestiona más de 50 parques eólicos distribuidos por distintos países. Cada parque graba su operación —telemetría de turbinas, eventos de control, mediciones— y la envía en tiempo real, 24/7, al backend central que sostiene sus datos de cumplimiento. El conjunto suma más de 2 TB de datos nuevos al día y sigue creciendo a medida que se incorporan parques.
De ese escenario salían tres exigencias difíciles de cumplir a la vez:
- Cero pérdida de registros. Un dato de cumplimiento que falta es un agujero en la trazabilidad regulatoria. La ingesta no admite huecos ni objetos sobrescritos por error.
- Inmutabilidad demostrable. Para que los registros sirvan como prueba ante un auditor, debe poder garantizarse que nadie —ni un administrador, ni un atacante con credenciales— los ha modificado o borrado después de escribirlos.
- Coste que no se dispare con el volumen. Una escritura continua de millones de objetos pequeños es exactamente el patrón que hace explotar la factura cuando el proveedor cobra por cada petición. El crecimiento de +2 TB/día no podía traducirse en un coste por operaciones imposible de presupuestar.
A esto se sumaba un requisito práctico: los equipos de campo ya emitían sus datos con clientes y SDKs existentes. Reescribirlos para un protocolo propietario habría significado un proyecto de desarrollo a medida en 50+ ubicaciones.
La solución con OtterStorage
La pieza que lo desbloqueó todo fue la compatibilidad con la API S3 estándar. Como OtterStorage expone el mismo endpoint y las mismas operaciones que cualquier servicio S3 (https://s3.otterstorage.io), los equipos de campo se integraron sin desarrollo a medida: bastó apuntar sus clientes existentes al nuevo endpoint y configurar las credenciales. Cualquier herramienta del ecosistema —desde la AWS CLI hasta SDKs propios— habla este lenguaje de fábrica.
El diseño de la ingesta quedó así:
- Buckets S3 como punto central de ingesta. Toda la grabación de los parques se centraliza en buckets dedicados en la región europea más cercana al backend (
EU-MAD, Madrid), con la opción de replicar aEU-FRAmediante replicación para una segunda copia geográfica. - Versionado activado. Con el versionado habilitado, cada PUT crea una versión nueva en lugar de pisar la anterior. Una reescritura accidental no destruye el registro original: queda como versión previa recuperable. Es la primera red de seguridad contra la pérdida de datos.
- Inmutabilidad WORM con Object Lock. Sobre esos buckets se aplica Object Lock en modo WORM (write once, read many). En modo Compliance, ni siquiera un usuario con permisos de administrador puede borrar ni sobrescribir un objeto antes de que venza su retención: el registro grabado es, por diseño, inalterable. Para retenciones abiertas asociadas a un requerimiento concreto, Legal Hold congela el bucket de forma indefinida hasta que se libera explícitamente.
- Access keys aisladas por bucket. Cada flujo de ingesta usa claves de acceso propias y limitadas a su bucket, de modo que las credenciales que viajan a los equipos de campo no dan acceso al resto de la organización.
- Durabilidad por Erasure Coding. Los datos se distribuyen con codificación de borrado, que tolera fallos de disco sin pérdida y sostiene la promesa de que el registro escrito sigue ahí.
La economía cierra el caso. Con OtterStorage no se paga por peticiones (PUT/GET/LIST) ni por borrados (DELETE): la escritura continua de millones de objetos —el patrón exacto de este operador— no añade ni un céntimo de coste por operación. La factura depende solo de los TB almacenados, a un precio por TB claro y publicado en precios, sin permanencia. Eso convierte un crecimiento de +2 TB/día en una previsión presupuestaria sencilla en lugar de una incógnita.
Resultados
- 50+ parques eólicos emitiendo a un único destino de ingesta centralizado.
- +2 TB/día de datos de cumplimiento absorbidos sin coste por petición ni por borrado.
- Ingesta 24/7 en tiempo real sostenida con durabilidad por Erasure Coding.
- Registros WORM inmutables mediante Object Lock, con versionado como red de seguridad adicional y Legal Hold para retenciones indefinidas.
- Integración sin desarrollo a medida: los equipos de campo se conectaron reutilizando la API S3 estándar.
- Coste predecible, ligado solo a los TB almacenados y sin permanencia, pese al crecimiento diario.
Si necesitas garantizar inmutabilidad de registros para cumplimiento, las claves están en Object Lock (WORM), Legal Hold y versionado. Y si quieres revisar el modelo de precios sin coste por operaciones, lo tienes en precios.
¿Un reto de compliance parecido?
Migración asistida con OtterBridge para los Founding Otters.
¿Tu operación también genera datos que no puedes perder?
Cuéntanos tu reto de ingesta y compliance y diseñamos juntos la arquitectura de buckets, inmutabilidad y replicación que lo resuelve.