Concepts - Public Cloud Networking
Find out what the basic concepts of Public Cloud Networking are
Find out what the basic concepts of Public Cloud Networking are
Last updated 2nd November 2022
This page explains the concepts behind Public Cloud Networking.
A private network enables you to build an isolated, reliable, and high performance network infrastructure for your application in the cloud.
Public Cloud private networks provide the ability to configure your network in a fully managed way, using common networking concepts such as subnets and routing. Combined with network components such as Gateway, Load Balancer and Floating IP, it allows you to quickly and easily build a complete end-to-end infrastructure, from your backend servers to your users.
Public Cloud private networks are being created on top of a vRack - an OVHcloud service providing a global private network that can be assigned to a Public Cloud project.
Public Cloud private network is a regional ressource that can be configured in two different ways: single-region or multi-region, in which the term "region" refers to Public Cloud availability regions. (Find more information on our website.)
Each type can then have subnets attached to allow resources to communicate. Those subnets are simply IP blocks of a private network in the given region.
A subnet (or parts of it) can be assigned to instances using the DHCP protocol for automatic configuration.
Public Cloud private networks use Layer-2 VLANs to separate broadcast domains from each other. For more information, see the VLAN section below.
You can find more information about private networks and subnets in the OpenStack documentation:
Dynamic Host Configuration Protocol (DHCP, RFC 2131) allows easier resource addressing through auto-configuration.
The Public Cloud DHCP service allows autoconfiguration for Floating IPs. It can be enabled in regions where Public Cloud private network is created. It doesn't work for OVHcloud Additional IPs.
OVHcloud vRack a transversal private network. It is designed to allow for complex private architectures on a global scale of multiple data centres, interconnecting different products in different data centres spread over different regions. You can read more about it on the vRack web page.
OVHcloud Public Cloud private networks are created inside a vRack network (VLANs can be used for further clustering if needed). This means that addressing schemas between regions in the same vRack/VLAN cannot overlap to allow communication.
For more advanced use cases, every vRack can be clustered further with Layer-2 VLANs (up to 4000 VLANs are available per single vRack). A Public Cloud private network can be placed in each VLAN.
This way, a number of scenarios are possible.
The OVHcloud infrastructure offers multiple ways to access the Internet or to expose Public Cloud resources to the Internet.
Public Cloud instances use public IP addresses which are attached to a public port for Internet access. As every instance is exposed to the Internet separately, security must be addressed on every single instance.
In this mode you can still connect instances to private networks for interconnection purposes.
OVHcloud Public IP addresses directly attached to instances in Public Mode are not designed to be moved to other instances or network services. For infrastructure-agnostic usage, the suggested way is to use a Floating IP address that is linked to your service but not the specific instance.
Keep in mind that some services (e.g. Load Balancer, Gateway) are not compatible with Public Mode instances.
In this mode, a newly created instance does not have a public IP attached to any port. The instance will remain fully private (no public connectivity) unless:
In private mode, users can define a single entry point (a Gateway) that is managing inbound/outbound traffic rules. This simplifies security management: There is no need to monitor all resources for proper public traffic access rules.
If you want to access your fully private instance from the Internet, the following options are available:
View our Bastion repository on GitHub for more details on creating SSH proxies.
If connectivity from a fully private instance to outside networks (Internet) is needed, then using Gateway with Source Network Address Translation (SNAT) is the appropriate method.
The private IP address of your resource (instance) is being translated into a public one (allowing it to reach public resources). The answer will be in turn translated and forwarded properly to your resource. This way, the public IP can be shared across a number of services.
It is important to note that a resource (instance) remains fully private in this scenario. No kind of access initiated from the outside network is possible.
Gateway currently supports single-region private networks only. This is the recommended private network scope for production grade setups with this service (including public-to-private Load Balancer which requires a Gateway). Other setups are not supported.
OVHcloud offers the Octavia Load Balancer as part of the Public Cloud ecosystem. This provides the most flexibility for scaling your applications.
The Public Cloud Load Balancer remains fully private, therefore it needs a Gateway service to access the public network and Floating IP for outbound service exposure.
Read more about it on our Load Balancer guide page.
OVHcloud Floating IP provides infrastructure-agnostic, cloud-native, flexible public IP addresses for automation use cases. It can be used to expose your Public Cloud services to the Internet by mapping it to either your private instance or a network function (a Load Balancer for example). It requires a Gateway to work (for mapping between public and private IPs) and it is only supporting IP version 4.
With fully automated assignments via DHCP and a pay-as-you-go billing model, the Floating IP service is designed for automated usage (e.g. Ansible, Terraform).
The main purpose of Floating IP is web service exposure to the Internet. This may pertain to a service on a single instance or a cluster of instances with a Load Balancer in front. Floating IP is thus ideal for application version testing and CI/CD automation (e.g. blue-green, canary, active fallback deployments).
The Floating IP logic is aligned with our Public Cloud regional concept which means they can be announced from a single region.
OVHcloud Additional IP is another type of service-agnostic public IP address. Additional IP addresses allow you to switch between attached services, but compared to Floating IPs they are more static as they need additional configuration directly on the host. Therefore they are more suited to interconnect OVHcloud services from different product lines.
For example, you may apply a hybrid-cloud concept based on a mix of Bare Metal servers and Public Cloud resources or other OVHcloud services.
Please note that Additional IP can only be used with instances in Public Mode, as opposed to the usage of Floating IP.
Find out more about Additional IP and Floating IP on the dedicated Concepts page.
Join our community of users on https://community.ovh.com/en/.
Please feel free to give any suggestions in order to improve this documentation.
Whether your feedback is about images, content, or structure, please share it, so that we can improve it together.
Your support requests will not be processed via this form. To do this, please use the "Create a ticket" form.
Thank you. Your feedback has been received.
Access your community space. Ask questions, search for information, post content, and interact with other OVHcloud Community members.Discuss with the OVHcloud community