Real-time compliance for 50+ wind farms
A renewable energy operator records the operation of more than 50 wind farms around the world and sends it in real time to its compliance backend. The volume grows by +2 TB every day and not a single record can be lost. Here's how they centralized all that ingestion in OtterStorage with the standard S3 API, versioning and WORM immutability.
wind farms connected
of new data per day
real-time ingestion
immutable records
When your legal obligation is to prove what each turbine did at every moment, storage stops being an infrastructure detail and becomes part of compliance. This operator needed a destination capable of absorbing a continuous write of millions of objects, guaranteeing that no record could be altered, and not turning growth into an unpredictable bill.
The challenge
The operator manages more than 50 wind farms spread across different countries. Each farm records its operation —turbine telemetry, control events, measurements— and sends it in real time, 24/7, to the central backend that underpins its compliance data. Together they add up to more than 2 TB of new data per day and keep growing as more farms come online.
From that scenario came three requirements that were hard to meet at once:
- Zero record loss. A missing piece of compliance data is a hole in regulatory traceability. Ingestion allows no gaps or objects overwritten by mistake.
- Demonstrable immutability. For records to serve as evidence before an auditor, it must be possible to guarantee that no one —neither an administrator nor an attacker with credentials— has modified or deleted them after they were written.
- Cost that doesn't explode with volume. A continuous write of millions of small objects is exactly the pattern that blows up the bill when the provider charges for every request. Growth of +2 TB/day could not translate into a per-operation cost impossible to budget.
On top of that came a practical requirement: the field teams already emitted their data with existing clients and SDKs. Rewriting them for a proprietary protocol would have meant a custom development project across 50+ locations.
The solution with OtterStorage
The piece that unlocked everything was compatibility with the standard S3 API. Because OtterStorage exposes the same endpoint and the same operations as any S3 service (https://es-mad-1.s3.otterstorage.io), the field teams integrated with no custom development: it was enough to point their existing clients to the new endpoint and configure the credentials. Any tool in the ecosystem —from the AWS CLI to in-house SDKs— speaks this language natively.
The ingestion design ended up like this:
- S3 buckets as the central ingestion point. All the farms' recording is centralized in dedicated buckets in the European region closest to the backend (
EU-MAD, Madrid), with the option to replicate toEU-FRAvia replication for a second geographic copy. - Versioning enabled. With versioning enabled, each PUT creates a new version instead of overwriting the previous one. An accidental rewrite does not destroy the original record: it remains as a recoverable previous version. It's the first safety net against data loss.
- WORM immutability with Object Lock. On top of those buckets, Object Lock is applied in WORM (write once, read many) mode. In Compliance mode, not even a user with administrator permissions can delete or overwrite an object before its retention expires: the recorded log is, by design, unalterable. For open-ended retention tied to a specific legal request, Legal Hold freezes the bucket indefinitely until it is explicitly released.
- Per-bucket isolated access keys. Each ingestion flow uses its own access keys restricted to its bucket, so the credentials that travel to the field teams do not grant access to the rest of the organization.
- Durability through Erasure Coding. Data is distributed with erasure coding, which tolerates disk failures without loss and upholds the promise that the written record is still there.
The economics close the case. With OtterStorage you don't pay for requests (PUT/GET/LIST) or for deletes (DELETE): the continuous write of millions of objects —this operator's exact pattern— doesn't add a single cent of per-operation cost. The bill depends only on the TB stored, at a clear per-TB price published in pricing, with no lock-in. That turns growth of +2 TB/day into a simple budget forecast instead of a guessing game.
Results
- 50+ wind farms emitting to a single centralized ingestion destination.
- +2 TB/day of compliance data absorbed with no cost per request or per delete.
- 24/7 real-time ingestion sustained with durability through Erasure Coding.
- Immutable WORM records via Object Lock, with versioning as an additional safety net and Legal Hold for indefinite retention.
- Integration with no custom development: the field teams connected by reusing the standard S3 API.
- Predictable cost, tied only to the TB stored and with no lock-in, despite the daily growth.
If you need to guarantee record immutability for compliance, the keys are in Object Lock (WORM), Legal Hold and versioning. And if you want to review the pricing model with no cost per operation, you'll find it in pricing.
A similar compliance challenge?
Assisted migration with OtterBridge for the Founding Otters.
Does your operation also generate data you can't afford to lose?
Tell us about your ingestion and compliance challenge and we'll design together the architecture of buckets, immutability and replication that solves it.