TL;DR
Rapid cloud adoption led to an architectural divide in modern cloud security between the way applications are built and security is enforced.
That divide has led to three major gaps: the fragmentation gap, the ownership gap, and the runtime enforcement gap.
Instead of disparate controls and telemetry, enterprises need a unified cloud security solution to close the gaps and eliminate this divide.
For the last 15 years, I’ve had the opportunity to sit with hundreds of enterprise teams as they’ve gone through cloud transformation. Different industries, different sizes, different cultures—but the conversations almost always converge on the same uncomfortable truth.
The cloud delivered speed. It delivered flexibility. It delivered innovation. But it also introduced a kind of architectural chaos that most organizations weren’t prepared for.
Applications didn’t just move to the cloud. They evolved into multiple clouds and their ecosystems. A single application today might start with a serverless function, call into a containerized microservice, pull data from a managed PaaS database, and then reach back into a VM-based system that was lifted and shifted years ago. And it might do all of that across two or three different clouds.
From the developer’s perspective, that’s progress. It’s powerful. It’s agile. It’s the whole point of cloud.
From a security and networking perspective, it’s a very different story, and can be a nightmare.
What I see in most environments is a growing divide between how applications are built and how security is actually enforced. Applications have become fluid, distributed, and cross-platform. Security, on the other hand, is still largely anchored to individual clouds, individual workload types, and individual tools.
And it’s not just security policy that fell behind. The fundamental networking tools that security teams relied on for decades have degraded in the cloud. L2 visibility is gone. Packet captures and mirrored ports—the bread and butter of network troubleshooting—went away. Flow data is minimal. Even something as basic as ping often requires spinning up a VM.
The teams I talk to feel this loss deeply. They went from having complete visibility into every packet crossing their network to operating in an environment where basic troubleshooting requires workarounds. That erosion of capability adds real friction and makes the security gaps even harder to close.
That mismatch is what I call the Architectural Divide.
It isn’t caused by bad decisions or a lack of effort. In most cases, the teams I work with are smart, experienced, and well-funded. The divide exists because the underlying architecture of security simply hasn’t kept up with the architecture of modern applications.
Here’s an example. I was recently working with an enterprise team mapping the data path for a single business-critical application. That one application spanned a serverless front end on AWS, containerized microservices on Azure, a managed database on GCP, and a legacy VM-based backend that had been lifted and shifted three years earlier. When we audited the security controls, we counted eleven different policy implementations across four workload types and three clouds—all meant to enforce what was essentially the same trust boundary. Eleven policies, zero consistency. That’s the Architectural Divide in practice.
When you look closely, that divide shows up in three persistent gaps.
The first is the fragmentation gap.
1. The Fragmentation Gap
Most enterprises didn’t land in the cloud all at once. They arrived in waves. First came VMs, usually lifted and shifted. Then came containers. Then managed PaaS services. Then serverless. And all of that happened across multiple clouds, often driven by different business units or acquisitions.
What that means in practice is that a single organization might be operating four generations of workloads across three different clouds. That’s at least a dozen different security implementations to design, deploy, and maintain. And the application traffic doesn’t respect those boundaries. A single user request might move across several of those domains in milliseconds.
But there’s no unified abstraction layer for security intent. The same policy has to be rewritten in AWS security groups, Azure NSGs, and GCP firewall rules. Three different languages, three different control models, and no consistent way to express what the business actually wants: “Only these services should talk to each other.”
So complexity grows. Tools accumulate. Teams specialize. And instead of a coherent architecture, you end up with a patchwork of controls that don’t quite line up.
That leads directly into the ownership gap.
2. The Ownership Gap
In the old data center world, there was usually a clear chain of responsibility. The network team owned the network. The security team owned the firewalls. The application team deployed the apps. It wasn’t perfect, but the boundaries were well understood.
In the cloud, those boundaries have blurred.
Developers now provision infrastructure directly through CI/CD pipelines. Platform teams manage landing zones and account structures. Security teams deploy CNAPP, XDR, and compliance tools. Networking teams may only control a portion of the environment, if they control it at all.
When I ask a simple question—“Who owns the end-to-end data path for this application?”—the answer is usually some version of, “Well… it depends.”
And that’s the problem. Attackers don’t care about org charts or which team owns which tool. They follow the path of least resistance through the data plane. If no single team owns that path from end to end, then no single team can truly control it.
Which brings us to the third gap: the runtime enforcement gap.
3. The Runtime Enforcement Gap
Over the last few years, the industry has invested heavily in visibility. Observability platforms, CNAPP solutions, XDR tools—they’re incredibly good at collecting data, correlating events, and telling you what happened.
But most of them don’t actually sit in the data path. They don’t enforce policy as traffic moves between workloads. They don’t stop lateral movement in real time. They tell you that the house is on fire, but they don’t have a hose.
Preventive controls have their own limitations. VM-based firewalls don’t extend cleanly into serverless. Container security tools don’t control traffic to PaaS services. Cloud-native controls are usually confined to a single provider.
So what you end up with is a runtime environment where you can see more than ever before, but you can enforce less than you should. The attack surface expands, and the blast radius becomes harder to contain.
In my experience, modern application security rarely fails inside a single workload. It fails in the spaces between them—where policies are inconsistent, ownership is unclear, and enforcement is missing.
When the fragmentation gap, ownership gap, and runtime gap combine, the outcome is predictable. You get fragmented control planes, inconsistent enforcement, and a growing sense that you’re always reacting instead of controlling.
That’s why I believe the industry needs to move beyond the idea of stacking more point tools on top of an already fragmented environment. What’s needed is a shift in architecture.
Filling the Gaps with Cloud Native Security Fabric
Instead of dozens of disconnected controls, you need Cloud Native Security Fabric—a model where security intent is defined once, enforced consistently, and applied across every cloud and every workload type the application touches.
The goal isn’t just better visibility. It’s restoring authority to the data plane. It’s reducing blast radius. It’s making sure that when something goes wrong—and eventually it will—you’ve already contained the damage.
In practice, that means a single policy language that abstracts across AWS, Azure, and GCP. It means inline enforcement that actually sits in the data path—not just observing traffic, but controlling it. It means consistent microsegmentation across VMs, containers, serverless functions, and PaaS services, managed from one place. And critically, it means giving network and security teams back the visibility and control they lost in the move to cloud—deep flow analytics, real-time policy verification, and the ability to contain blast radius before an incident becomes a breach.
Until that architectural divide is closed, organizations will keep buying more tools, generating more alerts, and spending more money… while the underlying problem remains exactly the same.
Schedule a demo to see how Aviatrix helps with bridging the Architectural Divide.
Learn more about how Cloud Native Security Fabric closes security gaps in complex networks.
