VPCs Using Non-Private Address Space

Virtual Private Clouds (VPCs) should utilise private network ranges for their address space to avoid conflicts with external connections.

Details ¶

Virtual Private Clouds (VPCs) are virtualized networks based on the same architectural principles present in traditional physical networks. As such, these architectural patterns have persisted in the realm of cloud networking with the usage of IPv4 addresses as a private address space denoting local network traffic ranges.

IPv4 consists of several million addresses, categorized into public and private segments. Certain portions of the available IPv4 address ranges are designated for specific purposes, including private address space, multicast, testing space and a significant amount for publicly addressable IP addresses. Publicly addressable IP addresses are unique identifiers on the internet, meaning that only one endpoint can possess that specific IP address at any given time. Conversely, local private address ranges are meant solely for internal use; these IP addresses are never available on the public internet and only resolve to locations within a local network.

Using private IP ranges allows for their reuse across multiple networks, including systems that do not connect to the internet. These IP ranges are of varying sizes, enabling you to select a local network range that offers a sufficient number of IP addresses. This flexibility allows private networks to exist as subnetworks within larger private networks, with the internet forming the global top-level network.

The cloud is no different to local networks and should utilise a private IP address range for your VPCs. By failing to use a private IP range, you risk IP address conflicts with existing public addresses or those meant for other uses. Since private IP addresses do not appear on the internet, it’s safe to query and connect to them as they will only resolve to endpoints within local networks. In contrast, using an IP address range that overlaps with internet-accessible addresses can lead to unpredictable behaviours, where network traffic may inappropriately route to either local or external networks depending on the records and routes for the address in question.

Such conflicts can cause certain internet services to become inaccessible and create complex debugging challenges, as caching in DNS and private DNS services may obscure responses. If there is an overlap with public addresses, the outcome can require significant engineering effort to replace the problematic addresses. While the impact of using a non-private IP range may vary - for example, you may not need to connect to public addresses used in your private network - it is never advisable to utilise non-private networking ranges as part of an internal network due to the potential for conflicts alone. The engineering effort required to resolve these conflicts when the arise can be extensive.

In rare cases, large organisations may own the public IP range they use, leased to them via an Internet Registry. However, this scenario is uncommon and doesn’t typically offer advantages over simply using a reliable private address range.

Remediations ¶

As previously mentioned, using a non-private IP address space as an internal network range can be challenging to rectify. There are specific reserved ranges within the IPv4 address space that can be utilized relatively safely, even though private traffic isn’t their primary purpose. This includes reserved ranges starting from 224.0.0.0/8 and above, as well as multicast testing ranges. AWS, for example, suggests using multicast testing ranges for EKS cluster setups and provides sample code for setting up EKS clusters using these ranges.

However, employing address space that is publicly routable typically results in a network that could experience issues unless the intention is for no resources within that network to access the internet. The context can range from requiring no action to needing active monitoring, management, or even total replacement.

As a general rule, it would be prudent to assess the public address ranges in use and have a contingency plan ready in case internet connectivity becomes necessary. Acknowledging that the current network configuration might be insufficient is vital and in the event of conflicts, a clear understanding of response strategies should be established. While implementing these strategies may not always be straightforward, having a defined plan will facilitate an understanding that potential issues can arise and that, if they do, prompt engineering work and resource allocation will likely be required to resolve them.