Why we started CloudFence

CloudFence began with a frustration Arnaud and I were seeing from different sides of the industry.
I spent more than eight years at Fortinet, including several years helping customers secure their AWS and Azure environments with Firewalls.
To inspect cloud traffic with firewall VMs, we often had to route it through a central hub, pulling flows away from the paths the cloud architects had designed. Then came the work of making the firewalls highly available and able to scale, managing complex routing, and dealing with added transit costs and the risk of congestion.
After all that, the firewall could still tell us little more than which IP address talked to which IP address. It couldn’t tell us enough about the workload, identity, or cloud context behind the connection. The cloud had that context. Our network security didn’t.

Meanwhile, Arnaud was at Accenture, seeing the problem from another angle.  His customers had CSPM and CNAPP alerts showing them where access was too broad, but they couldn’t easily see which communications actually used that access.
‍To tighten a rule safely, they needed to know what was actually communicating through it. Without that understanding, leaving a broad rule in place often felt safer than risking an outage.
That's when Arnaud and I connected the dots. we realized both problems came down to the same gap. Teams could see what was configured, but not clearly how each workload behaved. They might know what was exposed to the internet, yet have little visibility into what was leaving their cloud environment, or notice when those outbound communications changed.

That’s why we started CloudFence. We wanted to bring cloud context to network security: show teams which workloads and identities are communicating, understand what’s normal, detect when that changes, and identify unused access they can remove with confidence. And we wanted to do it without installing agents or forcing traffic through another firewall VM.