Assume you discovered a breach, stood up a clean room, and were ready to restore … and then realized your cloud tenant itself is wrecked. Where does the data even go?
Most data protection technologies still think server-by-server and most BC/DR planners underestimate what it would take to recreate their infrastructure. Let’s talk about that
video transcript
Assume that your next cyber incident started with an identity breach that gave the attacker access to your cloud-hosted infrastructure. As the attacker (potentially at agentic speed) traverses the environment, they eventually encrypt or destroy your data. You discover it, so you bring up your cyber recovery tools, you stand up your clean room, and you’re ready to restore … until you realize that your cloud tenant itself is wrecked or even just questionable. What is your plan to rapidly rebuild your hybrid infrastructure, SO THAT you have a place for the data to be restored to?
When we talk about resilient architecture, consider traditional server, storage, networking interdependencies that exist within on-prem datacenters and also cloud-hosted infrastructure. Most data protection technologies address a server-by-server point of view without recognizing distributed architectures: where is the storage? Where is the compute? Which networks does each instance connect to? As if each of those virtualized servers will figure it out, no matter how they’re recovered (especially to alternative infrastructure).
All of those ideas get radically more complex when you think about cloud-hosted infrastructure. If your AWS or Azure tenant was destroyed, recovering server instances wouldn’t get you resilience … just virtual black boxes with blinky lights.
So, an often-overlooked question is “How are you routinely capturing the configuration of the interdependencies between your storage tiers, your compute, your networking, and all the other stuff that wraps around to give you the modern hybrid IT infrastructure that your organizations rely on?” You might be able to cobble some of the hyperscale clouds’ migration tools as a one-time activity, but that’s not going to address real resilience preparedness … and it will be hard to maintain for preparation … and that would limit your resilience to which permutations of clouds that you are using.
The more that I look at infrastructure-as-code as a foundational part of a resilience strategy, meaning your ability to discover, document, and prepare to reconstitute your infrastructure, so that you can then use your data recovery tools to repopulate the servers themselves … the more that I think a lot of data protection vendors and BC/DR/cyber planners have gaps that they are underestimating.
What gets me excited is thinking about where those blueprints and runbooks, whether for initial deployments, IT modernization, or disaster recovery and cyber resilience, can be informed and invoked by AI – and integrated into the resilience workstreams and processes of your data protection frameworks.
So, when the bad thing happens, how would you re-instantiate (or migrate) your infrastructure, not just the server instances, from one platform or instance to another?
Leave your thoughts on the LinkedIn article.