Multi-Cloud Asset Replicationfor Global Delivery
Stop managing complex S3 replication rules and cross-region copy jobs. Upload to a single Rilavek endpoint and we fan-out your assets to AWS, Cloudflare R2, and Backblaze B2 concurrently — at the byte level, not after the fact.
From single upload to multi-cloud in three steps
Create a Pipe
Define your source protocol (SFTP, FTP, or HTTP) and add two or more cloud storage destinations — across different providers.
Upload Once
Your application or users upload to a single Rilavek endpoint. No changes to existing clients or workflows.
Instant Fan-out
Rilavek streams the file to all destinations simultaneously. Each transfer is independent — a failure on one does not block the others.
Inline fan-out vs post-upload copy jobs
The biggest difference is timing. Traditional replication happens after the upload. Inline fan-out starts every destination write during the upload itself.
| Question | Rilavek Fan-out | S3 CRR / Copy Jobs |
|---|---|---|
| When does the second copy begin? | During the original upload | After the source object already exists |
| Cross-provider support | Yes, any S3-compatible mix | Usually provider-specific |
| Replication lag | No separate lag window | Can be minutes or longer |
| Failure isolation | Each destination handled independently | Depends on your replication tooling |
| Operational model | Single ingestion path | Upload path plus separate replication layer |
Stop serving the world from one region
Serving global assets from a single origin bucket is a latency and availability liability. AWS Cross-Region Replication helps, but it is asynchronous — there is a replication lag, and it only covers the AWS ecosystem. Adding Cloudflare R2 or Backblaze B2 means writing your own post-upload copy logic.
Rilavek does the replication synchronously at the ingestion layer. The moment the first byte arrives, all destination writes begin in parallel. By the time the upload completes, the file is already available in every region — no lag, no copy job to schedule.
Async Replication Has a Gap
AWS Cross-Region Replication is asynchronous. A file uploaded to us-east-1 may not appear in eu-west-1 for several minutes. For serving media assets globally or maintaining a true redundant copy, that gap is often a problem. Rilavek's inline fan-out starts all configured writes as part of the same upload flow instead of waiting for a later copy job.
Egress Cost Trap
Copying from S3 to another provider means paying AWS egress fees on top of the second provider's ingress. With Rilavek, the upload happens once and we stream to all destinations from our infrastructure. Depending on your previous architecture, that can reduce or avoid some inter-cloud copy costs.
Stream to multiple regions concurrently. Upload once, copies land globally at the same time.
S3-compatible origin-pull backend for Cloudflare or Fastly. Point your CDN at the nearest copy.
Copies begin during the original upload flow instead of waiting for a separate replication job.
Simultaneous delivery to AWS, R2, and B2 makes it easier to operate across providers and reduce dependence on a single vendor.
Common destination patterns
Teams usually mix destinations by purpose, not just geography.
Primary + Edge
Keep AWS S3 as the system of record and push a second copy to Cloudflare R2 for CDN-adjacent delivery.
Primary + Archive
Write to a hot production bucket and a lower-cost secondary provider for long-term retention.
Multi-Region Active
Place copies near major user clusters so application downloads and origin pulls hit a closer region.
Vendor Diversification
Reduce dependence on a single cloud by keeping independent copies across provider ecosystems.
What inline multi-cloud replication actually requires
Cross-region replication scripts collapse under these real-world conditions.
Zero-lag Fan-out
Destination writes begin during the original upload flow instead of waiting for a sequential copy step after upload.
Independent Failure Handling
A timeout or error on one destination does not cancel the others. Each leg is independently managed and retried.
Any S3-Compatible Target
AWS S3, GCS, Azure Blob, Cloudflare R2, Backblaze B2, Wasabi — mix and match without writing provider-specific code.
Cross-Provider Coverage
Go beyond AWS replication. A Cloudflare R2 copy in a different provider ecosystem is a true redundancy layer.
Reduced TTFB
Serve assets from the S3 bucket closest to your users. Regional copies reduce Time to First Byte globally.
Lower Copy Overhead
Streaming to multiple destinations during ingestion can reduce the extra copy steps and fees that come with post-upload replication workflows.
What teams usually care about after the demo
Replication is only useful if the copies are observable, independently managed, and simple to reason about during incidents.
Per-destination status
See which copy succeeded, which one retried, and which destination needs attention.
No single replication queue
Each destination leg can proceed independently instead of serializing behind one copy job.
Cloud-neutral design
Add or swap providers without rebuilding the source-side upload workflow.
Better delivery timing
By the time the upload is complete, the additional copies are already in motion or already finished.
Common questions
Is replication synchronous or asynchronous?
Inline and synchronous. All destination writes begin in parallel with the first chunk received. By the time the upload completes, all copies are already written — not queued for a later job.
What happens if one destination fails during upload?
Each destination transfer is managed independently. A failure on one destination triggers retries on that leg only, without affecting the other destinations. You see per-destination status in the transfer log.
Do I have to pay inter-cloud egress fees?
You still pay the normal transfer and storage costs associated with the providers you use. Compared with a post-upload copy workflow, streaming to multiple destinations during ingestion can reduce some inter-cloud copy costs, but the exact outcome depends on your architecture and providers.
How many destinations can I add to a single Pipe?
Multiple destinations per Pipe are supported. In practice, 2–4 is most common (e.g., a primary S3 bucket, a CDN-optimized R2 bucket, and a cold B2 archive).
Can I use this as a CDN origin?
Yes. Each destination bucket can serve as a CDN origin-pull target independently. Point Cloudflare or Fastly at the nearest regional bucket and serve assets from the edge.
Upload once. Land everywhere.
Configure a Pipe with multiple destinations and start replicating globally in minutes. No copy scripts and no separate replication cron jobs.
Free plan includes 10GB of transfer. No credit card required.