IBM Cloud VPC Public Gateways: Choosing Subnet Egress Over Floating IPs

The floating IP reflex

When a virtual server instance in an IBM Cloud VPC needs to reach the internet, the reflex is to attach a floating IP. It works. It also consumes a public address per instance, creates an inbound surface you may not want, and turns egress policy into a per-server checklist. The alternative is a VPC public gateway: a regional resource that gives every instance in an attached subnet outbound access without assigning individual floating IPs. The catch is that a public gateway is an egress path, not a security boundary, and treating it like one leads to accidental exposure.

What a public gateway actually does

A VPC public gateway is a regional resource. You attach it to one or more subnets inside the same VPC. Once attached, any virtual server instance in those subnets can initiate outbound connections to the internet without owning a floating IP. The gateway does not make instances reachable from the internet; inbound traffic still requires a floating IP or a load balancer.

You can mix models. A subnet can have a public gateway for outbound traffic, while specific instances also carry floating IPs for inbound services. The two are not mutually exclusive.

Worked example: subnet egress without floating IPs

Assume you have a VPC with a subnet that hosts application servers. None of them need inbound internet access, but all of them need to pull OS updates and call external APIs.

In the IBM Cloud console, create a public gateway in the same region as your VPC, then attach it to the target subnet. Provision or verify that your virtual server instances have no floating IP assigned.

To confirm the attachment from the command line, run the following in an environment where the IBM Cloud CLI is installed and you are logged in with an account that has VPC management permissions:

ibmcloud is public-gateways
ibmcloud is subnet SUBNET_ID

Replace SUBNET_ID with the identifier of your subnet. The first command lists public gateways in the region; the second shows the subnet detail, including the public gateway reference. Check that the gateway appears in the subnet output.

Next, verify the network path. From one of the instances, attempt an outbound connection to a public endpoint. If the connection fails, inspect the security group attached to the instance's network interface. A public gateway does not override security groups or network ACLs; outbound rules must explicitly allow the traffic.

Trade-offs: convenience is not isolation

The main risk with a public gateway is that it enables outbound access for every instance in the attached subnet by default. If your security groups allow broad outbound traffic, every workload in that subnet inherits that access. The gateway simplifies address management, but it does not simplify firewall policy—it just moves the decision from per-instance floating IPs to subnet-level security groups and ACLs.

Public gateways also do not solve inbound high availability. A floating IP tied to a single instance is a single point of failure. If you need resilient inbound traffic, a load balancer is still the correct pattern.

Regional availability, quotas, and pricing for public gateways vary by region and account entitlement. Before designing a multi-region topology, confirm that the target regions support public gateways and that your account has sufficient quota.

Choosing between egress patterns

Pattern	Best for	Limitation
Public gateway on subnet	Multiple instances needing outbound only	No inbound access; requires security group discipline
Floating IP per instance	Single instance needing direct inbound and outbound	Consumes public IPs; single point of failure for inbound
Load balancer	High-availability inbound traffic	Additional cost and configuration; not a substitute for egress policy

Verify before you trust it

A practical check after configuration is threefold: confirm the subnet references the public gateway, confirm the target instances have no floating IP, and confirm that outbound connectivity works while inbound connections are still blocked. If outbound fails, the problem is almost always a security group or ACL rule, not the gateway attachment itself. If inbound unexpectedly succeeds, check whether a floating IP was left attached or whether a load balancer is routing traffic.