Multi-cloud was supposed to give us flexibility, along with:
- Best-of-breed services.
- Cloud-native innovation.
- Freedom from vendor lock-in.
But when a cyber incident hits, that flexibility often becomes complexity.
In this episode of STRIVE, I sat down with Senior Director of Product Management Akshay Joshi – whose career spans IBM, AWS, Microsoft, Clumio, and now Commvault – to unpack one uncomfortable truth: Most organizations think they’re ready for multi-cloud recovery.
Until they’re not. Watch the full episode.
Key Takeaways: What Multi-Cloud Recovery Really Demands
- Backup at the service level doesn’t equal recovery at the application level. Protecting individual data sources is not the same as restoring a synchronized application ecosystem.
- Recovery complexity multiplies across clouds. Different recovery points, different accounts, different admin teams – each adds friction when time matters most.
- Native hyperscaler tools are necessary – but not sufficient. They protect within their own cloud but don’t orchestrate across clouds.
- Isolation is the first domino in a cyber event. The larger the environment’s aperture, the harder it is to contain impact.
- Resilience must be designed in – not retrofitted later. Dependency mapping and recovery planning should begin at application design, not after deployment.
- AI-enabled automation adds power – and new risk. Agentic workflows require tight permission controls and governance discipline.
The Gap Between “On Paper” and Reality
On paper, recovery seems simple: When do you recover to? What do you recover? Where do you recover it?
But, as Akshay explains, each of those questions fractures in a multi-cloud world. Different services may have different recovery points. Some microservices may be impacted while others aren’t. Recovery may require re-architecting if restored cross-regionally or cross-account.
What looks straightforward in documentation becomes deeply complex in execution. And when ransomware hits, teams don’t calmly reference playbooks – they scramble.
The First Domino: Isolation
Each threat vector expands proportionally with environmental complexity. Multi-cloud doesn’t just diversify infrastructure – it expands operational aperture.
Service-Level Backup vs. Application-Level Recovery
Here’s where most organizations get caught.
They back up:
- Azure data with Azure Backup
- AWS data with AWS Backup
- Google Cloud data with a separate tool
Individually, each service may be protected. Collectively, the application may not be recoverable in a synchronized state.
Native tools don’t communicate across clouds. They aren’t inherently multi-cloud in orchestration. They aren’t tuned to optimize recovery time objective (RTO) or recovery point objective (RPO) at scale for cross-cloud architectures.
And when recovery depends on aligning multiple data sources across hyperscalers, orchestration becomes the difference between hours and days. This is exactly why unified recovery strategies exist – not to replace hyperscalers, but to coordinate them.
Dependency Mapping Isn’t Optional Anymore
We’ve been talking about application dependency mapping for more than a decade. But in a multi-cloud world, it’s no longer a “nice to have.” Applications now span multiple hyperscalers, multiple DevOps teams, multiple admin domains, and multiple vendor backup tools.
Fragmented ownership slows recovery. Vendor fragmentation complicates orchestration. Operational silos create delays at the worst possible time. Resilience must be operationalized from the beginning – not bolted on after deployment.
Sneak Peek: Why Multi-Cloud Recovery Fails Without Dependency Mapping
In this moment from the STRIVE conversation, Akshay explains why operationalizing resilience at the architecture stage is critical for surviving real-world cyber events.
Designing for Recovery – Not Just Protection
One of the most powerful points in this episode: Modern applications should be designed not only around performance and scale – but around recoverability. That means:
- Thinking about RTO as much as RPO.
- Architecting with cross-cloud orchestration in mind.
- Consolidating visibility where possible.
- Reducing vendor and admin fragmentation.
- Testing recovery across environments.
Recovery speed impacts revenue. Recovery clarity impacts reputation. Downtime impacts customer trust. Multi-cloud innovation must be matched by multi-cloud recovery discipline.
The AI and Automation Layer
No discussion is complete without addressing AI. Agentic workflows are increasingly embedded in enterprise SaaS platforms. But automation introduces new considerations:
- What permissions do agents have?
- How frequently are backups being triggered?
- What cost implications arise from automation decisions?
- Are agents treated as identities with governed access?
AI can accelerate resilience – but without guardrails, it also can amplify risk. The key is controlled delegation.
Why We Had This Conversation on STRIVE
STRIVE isn’t about repeating what everyone already knows. It’s about confronting the gaps that surface during real-world cyber events. Multi-cloud adoption isn’t slowing down. But unless recovery strategies evolve alongside architecture, complexity will outpace preparedness.
That’s why this discussion matters. And that’s why we brought Akshay in – someone who’s operated across hyperscalers and understands both their power and their limitations.
Watch the Full Episode
In the full STRIVE episode, you’ll discover:
- The real gap between service-level backup and application-level recovery.
- Why isolation is the first domino in ransomware events.
- How vendor fragmentation complicates orchestration.
- What CISOs and DevOps leaders must align on.
- How AI changes the resilience equation.
If you operate across AWS, Azure, or Google Cloud – this conversation is essential.
FAQs
Q: Why isn’t native hyperscaler backup enough?
A: Native tools protect data within a specific cloud but don’t orchestrate recovery across clouds. Multi-cloud applications require coordinated restoration across services and providers.
Q: What is the biggest gap in multi-cloud recovery?
A: The disconnect between how backups are made (service-by-service) and how recovery must happen (application-wide).
Q: What does “environmental aperture” mean?
A: It refers to the breadth of accounts, clouds, identities, and services in an environment. As aperture expands, risk and complexity increase proportionally.
Q: Why is dependency mapping critical?
A: Applications now span multiple clouds and teams. Without mapping service dependencies, recovery sequencing becomes guesswork.
Q: How does AI impact disaster recovery?
A: AI-enabled workflows can help automate backup and recovery decisions but require strong access controls, cost governance, and oversight.
Q: Where should organizations start improving multi-cloud recovery?
A: Begin by evaluating:
-
- Application-level recovery alignment.
- Vendor consolidation opportunities.
- Cross-team synchronization.
- Isolation strategy during incidents.
- Cross-cloud testing frequency.
Chris Mierzwa is Senior Director, Portfolio Marketing, at Commvault.
