Guest: Philip Merry
Company: SIOS Technology
Show: Data Driven
Topic: Cloud Native

There’s a widespread misconception in enterprise IT that’s costing organizations millions in unplanned downtime: the belief that running applications on AWS, Azure, or other major cloud platforms automatically makes them highly available.

It doesn’t. And the gap between what IT teams assume and what’s actually protected is wider than most realize.

Philip Merry, Solutions Engineer at SIOS Technology, draws a critical distinction that every cloud architect needs to understand: cloud providers deliver infrastructure resilience, but application availability remains your responsibility.

“The systems, virtual machines, and infrastructure hosted in the cloud are highly available and managed by the cloud provider,” Merry explains. “However, you are ultimately responsible for your applications and the services they run on in the cloud.”

This isn’t just semantic hairsplitting—it’s the difference between infrastructure uptime and business continuity.

Cloud providers like AWS and Azure ensure that the underlying infrastructure—virtual machines, storage devices, networking components—remains operational. That’s their piece of the shared responsibility model. But what happens when your database crashes at the application level? Or when a disk fills up with log data and chokes your ERP system? The VM is still running. The infrastructure is fine. But your application is down, and your business takes the hit.

“Suppose I’m hosting a database in the cloud—AWS or Azure, my cloud providers, are going to make sure that the virtual machine is available,” Merry says. “However, just because that machine is operational doesn’t mean that my database is actually running on that machine. There could have been an application-level crash. There could have been a drive filling up with data that is preventing my application from running at its full capacity.”

This is where the responsibility gap emerges. IT teams migrate to the cloud expecting automatic high availability, but they’re really only getting infrastructure resilience. Application-level failures—crashes, resource exhaustion, configuration errors—aren’t covered by the cloud provider’s resilience guarantees.

The solution? Application-aware failover mechanisms and disaster recovery strategies that operate at the application layer, not just the infrastructure layer.

“High availability is a joint effort,” Merry explains. “You have to work with your cloud provider to make sure that your infrastructure is available, but you also have to take steps toward ensuring the resilience of your applications within the cloud.”

That means implementing application-aware failover mechanisms that understand dependencies, orchestrate startups, and ensure not just that an application restarts, but that it restarts correctly with all prerequisites met. It means disaster recovery that accounts for application state, not just VM snapshots.

This requirement persists regardless of where you’re running. “That remains true whether you’re running on-premises or in the cloud,” Merry notes. “One way or another, you still have to make sure those applications are running, accessible, and serving the purpose you have set for them.”

The takeaway for enterprise IT teams: cloud migration doesn’t absolve you of responsibility for application availability. Infrastructure resilience is table stakes, but it’s not enough. If you’re running mission-critical workloads—databases, ERP systems, customer-facing applications—you need a layer of application-aware protection that the cloud provider can’t give you.

Without it, you’re one application crash away from downtime. And in that moment, the fact that your VM is still running won’t matter to your business.