TL;DR: Deploy identity-based access to AWS, GCP, and Azure resources without touching your VPC topology, rotating static IPs, or standing up new gateways. See the Twingate documentation for deployment specifics.

Every multi-cloud platform team eventually hits the same wall.

You've got IAM roles configured cleanly in AWS, workload identity federation in GCP, and conditional access policies in Azure AD. Then someone asks: "How does our staging database in GCP get accessed by an engineer whose laptop is on a coffee shop wifi?" The answer usually involves a bastion host, a jump box, a site-to-site VPN, or a hardcoded IP allowlist.

None of which your cloud IAM has any visibility into.

That gap between "who is this user" and "what network path did they take to reach the resource" is where cloud-native access control breaks down.

Your IdP knows the person. Your cloud IAM knows the workload. But the connectivity layer between them is still 2015-era networking held together with security groups and Terraform modules nobody wants to touch.

The problem with bolting network access onto cloud IAM

Cloud IAM is excellent at what it does: authorizing API calls, service-to-service communication, and workload identity. It's not designed to answer the question "should this human, on this device, from this location, be allowed to reach this private resource right now?"

So teams paper over the gap with a mix of:

• Site-to-site VPN tunnels between corporate networks and each cloud VPC

• Bastion hosts or jump boxes exposed via SSH

• Client VPN endpoints (AWS Client VPN, GCP IAP, Azure P2S VPN)

• Static IP allowlists in security groups, referencing office IPs or NAT gateways

• Cloudflare or similar reverse proxies fronting internal apps

Each of these creates its own IAM-adjacent policy surface. AWS security groups don't know your Okta groups. GCP firewall rules don't know if MFA was completed in the last hour. Azure NSGs can't revoke access when someone's device fails a posture check.

The result is a policy sprawl where the identity signal (which is the most useful signal you have) never actually reaches the network layer. You end up with duplicated policies, drift between clouds, and a permanent operational tax on the platform team.

What "identity-based connectivity" actually means

The shift is treating network access itself as an identity decision, not a topology decision. Instead of "this IP range can reach this subnet," the policy becomes "this identity, satisfying these conditions, can reach this specific resource."

Zero Trust Network Access (ZTNA) is the category name. The important architectural properties are:

1. No inbound firewall rules. Resources aren't exposed to the internet. Access happens through outbound-only connections initiated from inside the private network.

2. Deny-by-default at the resource level. Users can't scan a network for services because there's no network to scan. They can only reach resources explicitly granted to their identity.

3. Identity provider as the source of truth. Access decisions consult your IdP in real time. Group membership changes, device posture failures, and revoked sessions take effect immediately.

4. Per-resource enforcement, not per-network. A user granted access to one database in GCP doesn't gain implicit access to anything else in that VPC.

This is different from mesh VPN overlays (which put every device on a virtual network and rely on ACLs to restrict lateral movement) and from traditional VPNs (which grant broad network access after a single authentication event).

How Twingate fits into multi-cloud environments

Twingate is a ZTNA layer that sits between your identity provider and your private resources, regardless of where those resources live. The architecture has four components worth understanding for a multi-cloud deployment:

• Controller: Multi-tenant coordination service. Handles authentication delegation to your IdP, generates access control lists, issues signed authorizations. Never touches actual traffic.

• Connector: Lightweight software you deploy inside each private network (VPC, on-prem, etc.). All connections are outbound-only. No inbound firewall rules required. Deployable as a container, systemd service, or via Helm chart in Kubernetes.

• Client: Runs on user devices. Intercepts DNS queries that match resources the user has access to, and only those.

• Relay: Facilitates encrypted peer-to-peer connections when direct paths fail. Does not decrypt traffic.

The Controller talks to your IdP (Okta, Entra ID, Google Workspace, JumpCloud, etc.). Connectors sit in each cloud VPC. Clients run on user devices. Nothing about the topology of your VPCs changes.

Reference architecture: Multi-cloud

The deployment pattern for a typical AWS + GCP + Azure environment looks like this:

The Connector in each cloud makes outbound connections only. No public IPs on resources, no inbound NACL rules, no bastion hosts. The Controller never sees traffic, it only issues authorizations that both the Client and Connector verify independently.

Migrating from VPN plus static IPs

Most teams start from some combination of client VPN and IP allowlists. The migration path doesn't require touching your VPCs. It runs in parallel until you're ready to cut over.

Phase 1: Deploy Connectors alongside existing access

In each cloud, deploy at least two Connectors per network for redundancy. On AWS, this is typically an ECS task or a couple of EC2 instances. On GCP, a GKE deployment or GCE VMs. On Azure, an AKS deployment or VMs. The Helm chart is straightforward for Kubernetes environments:

Install the Twingate Connector on Kubernetes using Helm:

Connectors need outbound HTTPS (443) and UDP (for QUIC/WireGuard-style peer connections). No inbound rules on the security group. That's the entire firewall configuration.

Phase 2: Define Resources by DNS name, not IP

This is where the architecture shift becomes concrete. Instead of writing security group rules that say "allow 10.0.5.0/24 to reach 10.0.10.4:5432," you define a Resource as db-prod.internal.aws.example.com and grant access to a group of users.

Resources can be defined by:

• Fully qualified domain names (db.prod.internal)

• Wildcard DNS patterns (*.staging.gcp.internal)

• IP addresses or CIDR ranges (still supported, but less useful)

• Specific ports or port ranges per resource

Because the Client intercepts DNS queries locally and only for resources the user is authorized to reach, there's no split-tunnel routing configuration to maintain. Traffic to non-Twingate destinations goes out the normal internet path.

Phase 3: Map IdP groups to Resource access

Security policies in Twingate reference IdP groups directly. If your platform-engineers group in Okta already exists, you use it as-is. When someone leaves that group in Okta, their access to the Resources associated with it is revoked at the next policy sync.

Policies can also require:

• Specific device trust posture (managed device, disk encryption, OS version)

• MFA within a defined recency window

• Minimum usage requirements

• Time-bound restrictions

This is where the identity-based model starts replacing the static-IP model. You no longer need to update security groups when someone joins the on-call rotation. The IdP group membership is the policy.

Phase 4: Deprecate the VPN and remove static IP allowlists

Once Resources are defined and access is granted, users install the Client and authenticate through the IdP. Access to defined Resources routes through Twingate automatically. At this point you can:

• Remove client VPN endpoints from each cloud

• Remove office IP ranges from security groups

• Remove NAT gateway IPs from allowlists (nothing needs to come from a fixed IP anymore)

• Decommission bastion hosts

The migration doesn't require a big-bang cutover. You can leave the VPN running for weeks while you validate that all necessary Resources are reachable through Twingate. When the audit shows no one has connected to the VPN in 30 days, turn it off.

What this changes for your platform team

The concrete operational differences:

The other consequence, which is easier to feel than to measure: your VPC topology stops being an access control mechanism. Subnets exist for the reasons subnets should exist (blast radius, routing, service placement) rather than because "the finance app subnet needs different firewall rules than the eng app subnet."

The parts that are genuinely harder

Being honest about the tradeoffs:

DNS resolution needs to work. Resources are defined by hostname, so your internal DNS (Route 53 private zones, Cloud DNS, private DNS zones in Azure) needs to be reachable by the Connector. This is usually already true, but it's worth verifying before you start.

Long-lived TCP connections need care. Some databases and admin tools hold connections for hours. Test your specific workloads early. Twingate handles this well in general but every environment has edge cases.

You're now dependent on your IdP being available. This is true of any identity-based system. If Okta is down, new authentications fail. Existing sessions continue to work within their token lifetime, but this is a real dependency to plan for.

Connectors are your responsibility to run. Two per network minimum, monitor them like you'd monitor any other production service, and update them on a reasonable cadence. This is a small operational cost, but it's not zero.

Where to go from here

The migration path is deliberately incremental. Deploy Connectors, define a handful of Resources, invite a small pilot group, verify everything works, then expand. There's no forced re-architecture, and you keep the VPN running until you don't need it.

For the specific mechanics, Connector deployment options per cloud, IdP configuration, DNS setup, and policy examples, the Twingate documentation covers each cloud provider with reference implementations. The Kubernetes Operator docs are particularly useful for teams already running GKE, EKS, or AKS.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.