Our shop is split 60/40 between AWS and Azure. We have legacy on-prem apps, new cloud-native stuff in both clouds, and developers who need access from everywhere. The current VPN is a constant pain point and a security headache.
I need a ZTNA solution that can handle this mess without requiring me to standardize on a single cloud vendor's ecosystem. I've looked at the usual suspects (Zscaler, Cloudflare, Twingate) but the real-world implementation details are fuzzy.
My requirements are non-negotiable:
* Must broker access to private resources in both AWS VPCs and Azure VNets.
* Must integrate with Azure AD (our primary IdP) and ideally support conditional access policies.
* Must be agent-based for managed devices, but have a viable agentless option for contractors/third-parties accessing specific web apps.
* Should not require deploying a gateway VM into every single network segment. I'm not managing 50 little proxies.
What I want to know is what actually works in production at scale. Not the sales sheet.
Specifically:
* How do you handle routing? Does the ZTNA provider have their own backbone, or am I now debugging BGP sessions with them?
* For agent-based access, how is the client configuration managed? If it's just downloading a blob from a portal, that's a non-starter. I need something I can push via Intune.
* What does the actual configuration look like to expose, say, an internal ALB in AWS and an App Service in Azure? Is it just a DNS rewrite, or a true TCP tunnel?
If you've done this, show me the gritty parts. A vendor name is less useful than the actual architecture you built.
Build once, deploy everywhere
I've been running a hybrid setup for three years. The routing question is the key one everyone glosses over.
> How do you handle routing? Does the ZTNA provider have their own backbone
Most do, but you're not off the hook. You still have to peer with them, usually at a few cloud edges. The real headache is app discovery and the phantom "no gateway in every segment" promise. For your private VPC/VNet resources, they'll often push you to deploy a lightweight connector anyway. It's not a full gateway VM, but it's still another service to manage and patch in each cloud environment.
On Azure AD integration, conditional access works until you hit legacy protocols. Be prepared for a subset of apps to need exception policies, which punches a hole in the whole zero-trust model.
Lisa M.
Oh, the routing and connector piece is really good to know, thank you. I was hoping the "no gateway" promise was more true.
So when they say lightweight connector, is that basically a small VM you have to keep an eye on in each VPC? Does that end up creating its own routing complexities between the clouds?
Yeah, that "no gateway" thing is a bit misleading. In my last place, the connector was indeed a small, managed VM or container. It's less work than a traditional VPN gateway, but you're still responsible for the subnet it lives in and the network permissions.
It doesn't really create routing *between* the clouds, though. Each connector just makes resources in its *own* cloud segment visible to the ZTNA service. So you'll likely need one in your main AWS VPC and another in your primary Azure VNet. That's two separate management points.
Does the overhead of managing those connectors outweigh the VPN headaches? That's the real math to do.
Just here to learn.