When AWS Goes Down, Your Data Shouldn’t
On October 20th, 2025, AWS experienced a significant outage centered in the us-east-1 region. What started as a DNS resolution issue affecting DynamoDB quickly cascaded into widespread failures across major services and applications. From gaming platforms like Fortnite and social apps like Snapchat to enterprise systems and IoT networks, the incident once again revealed just how much of the modern internet depends on the resilience of a handful of cloud regions.
While compute, networking, and identity failures during an outage are challenging, the most critical problem is often data access. If your object store, catalog, or database resides in an unavailable region, even the most sophisticated failover plan grinds to a halt. You can spin up compute in another region, but without access to your data, operations stop.
This is exactly where lakeFS Transactional Mirroring comes in.
What Is Transactional Mirroring?
Transactional Mirroring is a lakeFS Enterprise feature designed for S3-backed repositories that maintains a consistent replica of your repository in another S3 region. Unlike naive replication strategies or one-off copy jobs, lakeFS mirrors your data transactionally, ensuring that every commit applied to your primary repository is reflected atomically in the mirror.
The mirrored repository operates as read-only, meaning no new commits can be added directly to it. Instead, it serves as a consistent, point-in-time replica of the source repository. This design guarantees that during an outage, you have a fully consistent and isolated read-only copy of your data that can continue serving reads and analyses without interruption.
It’s important to understand what Transactional Mirroring is designed for: consistent read availability and fast recovery paths when your primary region becomes unavailable. It’s not about live failover for writes, but rather ensuring your teams can continue accessing and analyzing data when they need it most.
How It Works
Transactional Mirroring leverages S3 cross-region replication combined with lakeFS’s versioning model. Once you configure a mirror repository in lakeFS, the replicator process ensures that every commit in the source repository is consistently reflected in the mirror repository.
This process provides three critical guarantees:
- Atomic replication: Commits either fully replicate or not at all – no partial or inconsistent states
- Consistent history: Both repositories share identical commit lineage, preserving data integrity
- Read availability: The mirror can serve read operations independently of the source region
Setting Up Transactional Mirroring
Configuring transactional mirroring between two S3-backed repositories is straightforward:
1. Create a target repository in the destination S3 region (this will act as the mirror):
lakefs repo create lakefs://my-repo-mirror s3://my-bucket-mirror2. Set up S3 cross-region replication
Between the source and destination buckets using AWS’s native replication features.
3. Configure the mirror in lakeFS
Via the UI or API as described in the Transactional Mirroring documentation. The mirror will automatically track commits from the source repository and apply them transactionally.
Once configured, lakeFS ensures that every commit in the source repository is automatically and transactionally applied to the mirror. Users can read from the mirror repository even when the source region becomes unavailable.
Why It Matters During an Outage
During the October 20th AWS outage, countless services couldn’t access data stored in us-east-1. For organizations with datasets hosted in a single region, this translated directly into downtime, even when their compute infrastructure in other regions remained perfectly healthy.
Imagine a different scenario: If that same data were managed through lakeFS with a mirror in another S3 region, operations could have continued uninterrupted. The mirrored repository in, say, eu-west-1 or us-west-2, would remain consistent and fully readable. Analytics teams could keep running queries, ML pipelines could continue training models, and ETL jobs could process data against the mirror until the primary region recovered.
Transactional Mirroring provides consistent data availability even during infrastructure disruptions, turning what would be complete downtime into business continuity.
Going Further: Building a Best-in-Class Disaster Recovery Plan
Transactional Mirroring is a cornerstone of a robust disaster recovery (DR) strategy, but a complete DR plan needs to address both read and write continuity. lakeFS provides both capabilities.
While Transactional Mirroring gives you immediate read continuity during an outage, lakeFS Import enables full disaster recovery, including the ability to resume writes in a new region.
One of the key advantages of lakeFS Import is efficiency: it does not copy data. Instead, it imports object metadata and creates commits that reference existing data in your object store. This means the import process is fast, cost-effective, and doesn’t duplicate your storage.
Complete DR Recovery Workflow
Using lakeFS Import alongside Transactional Mirroring, you can implement a complete disaster recovery workflow:
1. Create a new lakeFS repository in a different region:
lakefs repo create lakefs://my-repo-new s3://my-bucket-new2. Import existing data from your previous bucket or mirror:
lakectl import --from s3://my-bucket-mirror --to lakefs://my-repo-new3. Continue committing and writing new data to the new repository, restoring full operational capability.
4. Once your original region recovers, you can reconcile changes or reestablish a new mirror relationship to sync back to your primary region.
In essence, Transactional Mirroring ensures immediate data access for reads, while Import provides a path to full write recovery. Together, they form a complete DR strategy that minimizes downtime, protects data consistency, and provides a structured way to restore normal operations after failure.
Building Real Data Resilience
Cloud outages aren’t rare anymore; they’re a regular reality of modern infrastructure. The 2025 AWS incident serves as yet another reminder that resilience must extend beyond compute and networking. Your data layer needs to be resilient too.
With lakeFS Transactional Mirroring and Import, you can:
- Maintain consistent, cross-region S3 replicas with transactional guarantees
- Ensure continuous read access during regional failures
- Rapidly rehydrate or recreate repositories to continue writing when needed
- Preserve complete data lineage and consistency throughout the recovery process
Data versioning and consistency aren’t just about governance or reproducibility—they’re fundamental to reliability. lakeFS provides the building blocks to keep your data and business running, no matter what infrastructure goes down.
Learn More
Ready to implement disaster recovery for your data lake? Check out these resources:
- Transactional Mirroring Documentation – Detailed setup and configuration guide
- Transactional Mirroring Blog Post – Deep dive into the architecture
- Demo Video – See Transactional Mirroring in action
- lakeFS Enterprise – Explore all enterprise features
