In this blog
Three things happened in September 2026 that should change everything you think you know about hyperscaler backup.
First, the durability assumption broke. AWS confirmed that customer data held exclusively in its Bahrain region and in UAE availability zone mec1-az2, is permanently unrecoverable after drone strikes damaged the facilities during the conflict with Iran. By AWS's own account, the damage exceeded what its regional and multi-AZ services are designed to withstand. Anyone whose only copy lived inside that region has no recovery path and AWS has said Bahrain customers will hear nothing further until Q1 2027.
Second, the regulatory floor moved. OSFI's Guideline E-21 now requires Canadian financial institutions to have concentration-risk mapping and impact tolerances fully operational by September 2026. That comes on top of the EU's DORA, which has already placed 19 providers—including AWS, Microsoft, and Google Cloud—under direct supervisory oversight because regulators designated them as systemically important.
Third, the threat model got a very public, very concrete update. An AI model running an internal evaluation found a real zero-day, escalated privileges, and broke into production infrastructure at Hugging Face before anyone noticed. Detailed post-mortems of the incident flagged the risk AI now poses to system and platform security.
Together, these incidents raise a simple question: if something goes wrong inside your cloud account—a misconfiguration, a compromised identity, a regional event, a zero-day in the provider's own storage subsystem—where does your recovery data actually live and whose blast radius is it sitting in?
Today, Rubrik answers that question for AWS customers. Rubrik now supports archiving AWS data into the Azure cloud (either your own Azure storage account or a Rubrik-managed Azure RCV instance) and restoring back to AWS. It's a genuine second storage domain for your AWS backup data, using a different provider's infrastructure, with independent encryption and independent access controls/paths from your primary AWS environment.
Why This Matters
Cross-cloud archival isn't just a technical checkbox, it's a decision that pays off across compliance, security, cost, and geography. But what specific benefits make putting a copy of your data in a second cloud provider worth the added complexity?
Regulatory alignment: DORA and OSFI both put real weight on data portability and on reducing concentration in a single ICT provider. A cross-cloud archive is a direct, tangible answer when an auditor or examiner asks how you're addressing that requirement—not a workaround, but an actual second copy in actual second infrastructure.
Blast-radius isolation: Your archived copy lives under a separate provider's storage domain, secured with separate keys and separate access policies. Whatever happens to the storage layer of your primary AWS account, that copy is sitting outside the blast radius. It can't be reached by an incident that’s confined to the account or platform it left.
Cost diversification: You're no longer locked into a single provider's storage pricing and tiering for your entire backup footprint. Azure and AWS storage economics move independently, and splitting your archive across both gives you room to optimize and negotiate instead of taking one vendor's price.
Regional protection: Some geographies are served by only a single availability zone from a given cloud provider, which makes true in-region redundancy impossible within one vendor. Cross-cloud archival lets you place a second copy with a different provider in the same jurisdiction—multi-provider redundancy while keeping data inside the border your sovereignty framework requires. That benefit depends on choosing a target region in the same jurisdiction, so it's a configuration you set deliberately, not an automatic outcome of turning the feature on.
What This Release Is (And What It Isn't)
In this release, cross-cloud archival is a storage-layer capability. Your snapshot data lands in Azure and can be restored back into AWS.
It is deliberately not a path to standing up a live, running instance directly in Azure from that archive.
Storage diversification and compliance is the problem most teams hit first and it's one modern cloud economics and operations can absorb cleanly. Cross-cloud restoration and availability for infrastructure and platform services is a far more complex problem, one that most mature teams already design into the application layer rather than the storage layer.
Where you draw that line is worth thinking through against the backdrop of the shared responsibility model: the more of the stack your provider manages, the more operational lock-in you inherit. Running MySQL as a managed PaaS service generates far more lock-in than running the same database on Kubernetes or a VM, where you keep granular control over the things that make cross-provider portability realistic in the first place. We built for the layer where that trade is cleanest today and the foundation extends upward from here.
If GRC or Cloud Architecture teams have flagged your workloads for concentration or data portability risk, or are asking the harder question "What happens if our cloud provider can no longer guarantee confidentiality, integrity, and availability," we built the tooling to address these concerns.
Note: Any unreleased services or features referenced in this presentation are not currently available and may not be made generally available on time or at all, as may be determined in our sole discretion. Any such referenced services or features do not represent promises to deliver, commitments, or obligations of Rubrik, Inc. and may not be incorporated into any contract. Customers should make their purchase decisions based upon services and features that are currently generally available.