Public Gateways FAQ

What is a Public Gateway?Link to this anchor

Public Gateways sit at the border of Private Networks. They provide services to deal with traffic entering and exiting the network (NAT), and SSH bastion. A Public Gateway can be attached to up to 8 Private Networks, and up to 50 Public Gateways are supported per Organization.

The Public Gateway can be configured through the console or the API.

Does the Public Gateway require a public IPv4 address?Link to this anchor

No. A public IPv4 address (aka. flexible IP) must be assigned to the Public Gateway at creation time, but you can detach it and delete it afterward if you do not require it to be publically accessible.

Can my Instances and other resources access the internet via a Public Gateway without a public IP address?Link to this anchor

Yes. The Public Gateway can advertize itself as the default route to the internet over the Private Network it is attached to, so that Instances and other resources on the same Private Network, can access the internet via the gateway. Moreover, the Public Gateway supports static NAT (aka. port forwarding), so that ingress traffic from the public internet can reach Instances on the Private Network. This works by mapping pre-defined ports of the public IP address of the gateway to specific ports and IP addresses on the Private Network.

What happened to static leases (DHCP reservations) when DHCP moved from the Public Gateway to Private Networks?Link to this anchor

On 12 July 2023, DHCP functionality moved from Public Gateways to Private Networks. See our dedicated migration documentation for full details.

Pre-existing static leases created via the Public Gateway were fully migrated and still work for your attached resources on a Private Network. Manual static lease configuration is still available via the API v1 and other developer tools, but this functionality is now deprecated, and does not exist in v2 of the API.

Read our dedicated documentation to learn how to put your gateway into IPAM-mode and replicate static DHCP reservation functionality with Scaleway IPAM.

Why is my Public Gateway labeled as Legacy?Link to this anchor

Legacy Public Gateways use a workaround to ensure compatibility with Scaleway’s IPAM (I P Address Management) tool. IPAM acts as a single source of truth for the IP addresses of Scaleway resources

Your gateway is a legacy gateway if you created it prior to 17 October 2023 and you never recreated it in IPAM mode. Legacy gateways are now deprecated, as they are incompatible with v2 of the Public Gateways API. Such gateways must be moved to IPAM mode before October 2025 to ensure ongoing functionality.

I received a message about v1 of the Public Gateways API being deprecated, do I need to take action?Link to this anchor

The Public Gateways API v1 is now deprecated, and will be removed on 1 October 2025. Only IPAM-mode gateways will be compatible with the new version of the API (v2). Whether or not you need to take action depends on the following two points:

• Consider whether you manage your Public Gateway uniquely via the Scaleway console, or via calls to the API/devtools in code and scripts:

  • Code and scripts: If you have any code or scripts that call v1 of the API, or use devtool functionality that is removed from v2 such as DHCP object or entries, you must take action before 1 Oct 2025. Update your code and scripts so they point to v2 of the API. Follow the examples provided for tools such as Terraform to rewrite your devtool templates so they do not refer to removed functionalities. Do this in synchronization with moving your gateway to IPAM mode (if necessary).

  • Console-only: You do not need to take any action, except ensuring that your gateway is in IPAM mode.

• Check in the Scaleway console whether your Public Gateway is in IPAM mode or legacy mode:

  • Legacy mode: You must move the gateway to IPAM mode. Only IPAM mode gateways are compatible with v2. Use the Move to IPAM mode button in the console, the dedicated API call, or the move_to_ipam flag in Terraform.

  • IPAM mode: You do not have any action to take, except updating any code and scripts that you have (see above).

See our dedicated documentation for full details.

Do I need a Public Gateway for each Availability Zone (AZ)?Link to this anchor

VPC and Private Networks are both regional, meaning they span all AZs across a given region. Even though Public Gateways are zoned and not regional, one Public Gateway attached to a regional Private Network is functionally enough, and will cover the whole region. That is to say a Public Gateway created in PAR-1 can serve Instances in PAR-2 and PAR-3, as long as they are all attached to the same PAR-region Private Network.

How can I achieve truly High Availability (HA) networking when the Public Gateway is a zoned resource?Link to this anchor

Notwithstanding the answer to the previous question, if you have a single Public Gateway in, for example, PAR-1, serving resources from other AZs on the same Private Network and there is an outage in the PAR-1 zone, the gateway will not be able to serve the resources from other unaffected AZs. We are working to improve and develop our Public Gateway product to counteract this.

In the meantime, if this is a concern, you could consider attaching several Public Gateways from different AZs to a single Private Network, each advertising a default route to the internet. As long as you are using a recent kernel (e.g. Ubuntu Jammy, Debian bookworm), the traffic will be spread across the different gateways. In the case of an outage in one AZ, you will only lose the gateway in that zone, and the others will continue to serve traffic.

I need more than 1Gbps bandwidth for my Public Gateway, what can I do?Link to this anchor

We have introduced a VPC-GW-L offer with 3Gbps bandwidth, and a VPC-GW-XL offer with 10Gbps of bandwidth, to accommodate customers with this type of need. For pricing details, see our dedicated page. You can upgrade your existing Public Gateway to one of these new offers via the Public Gateways API or the Scaleway console.