When should organisations use public IPs instead of managed NAT for cloud workloads?

Use public IPs when stable peer connectivity, predictable coordination or low-latency direct links matter more than the convenience of outbound-only NAT. That choice works best for critical infrastructure nodes and service endpoints that can be tightly restricted at the firewall while still remaining directly reachable.

When public IPs are the right fit for cloud workloads

Public IPs make sense when the workload must be directly addressable, not just reachable from inside the VPC or VNet. That usually means stable partner-to-partner connectivity, inbound service exposure, or low-friction coordination with external systems where managed NAT would add an extra hop, dependency, or translation layer without delivering meaningful security benefit.

The practical test is whether the workload’s communication pattern depends on being identifiable at the network edge. If the service must accept callbacks, participate in peer discovery, or remain reachable by external allowlists, a public IP can be the cleaner design, provided the exposure is narrowly controlled and the workload is operationally meant to be online.

Public IPs are not a default convenience choice. They are a deliberate architecture decision for endpoints that need direct routing and where the surrounding controls, firewall policy, segmentation, and service hardening are strong enough to make that exposure acceptable. If those conditions are not present, managed NAT usually remains the safer outbound-only pattern.

What changes compared with managed NAT

Managed NAT is built for outbound-only communication, which simplifies egress control and hides internal addressing. That is valuable for general workloads, but it becomes a constraint when another system must initiate a connection back to the workload or when identity-by-address matters for coordination, reputation, or allowlisting.

Public IPs remove that translation layer, so the workload can be reached more directly and sometimes more predictably. The trade-off is that the workload now owns the exposure surface at the internet or partner edge. That shifts the burden to host hardening, firewall rules, security groups, service-level authentication, and careful restriction of what can actually connect.

This is why public IPs are often better suited to infrastructure nodes, ingress points, bastions, load-balanced services, or tightly governed endpoints than to ordinary application tiers. If the system does not need to be reachable from outside, NAT still reduces exposure without complicating the application design.

How to decide without overexposing the workload

A good decision process starts with the communication requirement, not the network preference. If the workload only needs to call out to APIs, update packages, or reach managed services, NAT is usually the better default. If it must accept inbound sessions, preserve stable source identity, or support external troubleshooting and coordination, a public IP may be justified.

At the same time, public reachability should be paired with strict scoping. In practice, that means allowlisting known peers, denying broad inbound access, and confirming that the workload has a clear operational owner. The more static and predictable the communication pattern, the easier it is to safely use a public address.

Where the workload participates in direct service-to-service trust, workload identity and certificate-based controls can help keep the decision about reachability separate from the decision about authorization. SPIFFE workload identity specification is a useful reference when the exposure choice is driven by direct connectivity but the access decision still needs strong cryptographic identity.

What practitioners should verify before choosing public IPs

Before assigning a public IP, verify that the workload really needs inbound reachability and that the exposure is intentional, not accidental. A surprising number of systems inherit public access because of a migration shortcut, a vendor requirement, or an architecture pattern that was never revisited after the service stabilized.

What to verify: confirm the exact peers that must connect, the ports and protocols they need, the failure mode if the public address is removed, and the control that prevents anything else from reaching the service. If you cannot name those conditions clearly, the workload probably belongs behind NAT or a managed ingress layer instead.

Trade-off: public IPs can improve simplicity and directness, but they also increase the importance of firewall discipline, logging, and patching. If the workload is hard to harden, changes frequently, or has no strong owner, the extra exposure is usually not worth the convenience.

Practitioner takeaway: choose public IPs only when direct reachability is a requirement, not a preference, and only when the workload can be defended as a deliberately exposed endpoint rather than a general-purpose internet target.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	Direct reachability still needs explicit trust enforcement and segmentation.
Recommendation — Treat network exposure as untrusted and enforce access through explicit policy and segmentation.
NIST SP 800-53 Rev 5	AC-4 — Information Flow Enforcement	Public IP use depends on tightly controlling which peers can reach the workload.
	SC-7 — Boundary Protection	Public IPs move the workload to the network boundary and require strong perimeter controls.
Recommendation — Enforce inbound and outbound flow restrictions for publicly reachable workloads. Place strong boundary filtering around any workload exposed with a public address.
ISO/IEC 27001:2022	A.8.20 — Network security	The decision hinges on securing internet-reachable network paths and exposure.
	A.8.22 — Segregation of networks	Public IPs are safer when exposed services are isolated from internal zones.
Recommendation — Apply network security controls that limit and monitor public exposure paths. Separate publicly reachable services from internal systems by network zone.