Topic starter
02/08/2026 12:22 pm
TL;DR: Cloud NAT gateways are usually symmetric and optimised for outbound scale, which makes peer-to-peer connectivity difficult across AWS, Azure, and GCP, according to Tailscale. Direct connectivity remains possible through public IPs, configurable NAT behaviour, or controlled relay patterns, but each choice changes the operational burden on security teams.
Editorial analysis by NHI Mgmt Group, based on content published by Tailscale: “NAT traversal improvements, pt. 2: Challenges in cloud environments”.
Key questions
Q: How should teams design direct connectivity when cloud NAT is symmetric?
A: Start by assuming symmetric cloud NAT will block many peer-to-peer flows and design for either public reachability or a managed relay path.
Q: When should organisations use public IPs instead of managed NAT for cloud workloads?
A: Use public IPs when stable peer connectivity, predictable coordination or low-latency direct links matter more than the convenience of outbound-only NAT.
Q: What breaks when cloud NAT cannot preserve stable mappings?
A: Direct peer-to-peer session establishment becomes unreliable because endpoints cannot depend on the same translated port being reachable from multiple peers.
Practitioner guidance
- Assess cloud NAT symmetry before assuming peer reachability Map which workloads sit behind AWS, Azure or GCP NAT services and test whether their mappings are endpoint-independent or symmetric.
- Assign public IPs to critical nodes where direct links matter For workloads that must establish stable direct sessions, consider giving the instance a public IP and tightening UDP access with host firewalls and security groups.
- Treat custom NAT appliances as managed infrastructure If you replace cloud NAT with your own NAT instance, virtual router or firewall VM, document redundancy, patching, throughput limits and failure handling as part of the operating model.
Bottom line: Cloud NAT behaviour can make direct peer-to-peer connectivity unreliable even when the underlying workload is authenticated and encrypted.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:22 pm
Cloud NAT design is now an access-control decision, not only a routing decision: the shape of NAT mappings determines whether workloads can establish direct authenticated sessions or must depend on relays and special-case paths. That matters for identity governance because machine-to-machine access depends on stable reachability as much as it depends on credentials. Teams that treat network translation as a background service often miss the fact that it changes the practical boundary of the service account or workload identity. The practitioner conclusion is to review NAT behaviour as part of access architecture, not just infrastructure architecture.
A question worth separating out:
Q: What should security teams do when direct connection depends on relays or subnet routers?
A: Treat the relay as a controlled dependency, not a convenience feature. Define ownership, monitor throughput and failure modes, and document which services rely on it. If the relay becomes the only path for critical traffic, it should be governed like production infrastructure with clear resilience and recovery expectations.
👉 Read our full editorial: Cloud NAT traversal limits are shaping direct connection design