Disparate Subnet Masks

Virtual Private Clouds (VPCs) should be designed with standardized subnet spaces to facilitate maintenance and optimise address space utilization.

Details ¶

VPCs replicate the same networking tools, configurations and processes as internal networks. They are essentially virtualized versions of physical networks found in the real world. As a result, the best practises and architecture for setting up these networks share the same foundational principles. However, the cloud environment makes it significantly easier to create and deploy virtualized networks compared to physical networks, which require appropriate hardware and all associated physical networking components in addition to similar configuration exercises.

One of the critical factors in network design is establishing suitable network sizing. This involves ensuring that there is a reasonable amount of address space that can be sensibly allocated, allowing for scalability without crowding out networking solutions and future extension.

Having disparate subnet masks - where subnets vary considerably in size - is a known anti-pattern in network architecture. This can lead to situations where different parts of the network have varying amounts of IP address resources, often resulting in smaller subnets running out of address space while larger subnets become inefficient. Additionally, sizing a network can become problematic if large portions of previously allocated address space become locked into larger subnets that may not be appropriately utilized.

Using simple, standardized network sizing effectively breaks the network into manageable blocks, enabling subnets to be treated as homogenous resources and allowing for easy calculation and quantification of available space. This becomes increasingly important considering that different subnets often utilise different route tables, affecting their core functionality. Based on these routable configurations, subnets are designed according to their internet access requirements-whether they necessitate public IP addresses, utilise network address translation (NAT) services, or have any internet access at all. This distinction is essential for both security and functionality making appropriate network design a critical functional requirement to ensure that resources have the appropriate routing and minimised exposure.

From a maintenance perspective, having subnets of differing sizes adds complexity when designing and managing networks. This situation complicates calculations for subnet allocations and can make networking rules unnecessarily complex, increasing the risk of misconfiguration and slowing investigations owing to the more complex calculations.

Remediation ¶

Once a VPC has been created, its CIDR range cannot be removed while still providing network access, functionality and uptime to present resources. Therefore, making changes requires careful consideration of the current configuration and the number of active resources within the account and VPC. If the network is overly complex, it is essential to assess the actual impact on services and determine whether security and maintenance concerns warrant a rebuild or re-creation of the network against the engineering costs associated with achieving a better designed network.

There are situations where we have opted to rebuild networks entirely because the existing network lacks scalability and is too complex to reasonably maintain as part of business-as-usual operations. Decisions in these cases have often been influenced by the active services - with AWS EKS network requirements being a notable consideration - as well as the criticality of the resources currently active and planned for that VPC.

For networks that are simply a bit disorganized or have low resource counts, it is possible to recreate subnets within a VPC. This can be achieved by using migratory network space to create new subnets, migrating resources to those subnets and then deleting the old ones to occupy the targeted address space if necessary. An alternative approach is to assign an additional CIDR range within the same VPC, separate from the existing CIDR block, as a destination for rebuilt subnets and migrated resources.

Getting the network architecture right from the start is far more important than attempting to fix it later. The primary functional challenges revolve around scalability, visibility and maintenance. While these aspects may not provide immediate business value, it is crucial to consider whether addressing them will yield a worthwhile return on investment for what can be a resource-intensive redesign. In some cases, it may simply be that your network can remain disorganized without necessitating significant reconfiguration until the time comes when you genuinely require a format, recreation, or refactoring of the network.

Get a clear view of your network with a full calculation and expert consultation via the SkySiege Cloud Assessment which will automatically calculate all of your networks and detect any improper sizing: