VLAN

When all devices in an office or data center are connected to a single switch, broadcast packets from one device are delivered to every other device on that switch. With a few dozen devices this is barely noticeable, but once the count reaches hundreds, broadcast traffic alone wastes meaningful bandwidth. The more serious issue is security. If development servers and HR systems share the same network, a mistake or attack originating in the dev environment can reach HR data. Solving this physically means buying separate switches and running separate cables for each department. But re-cabling every time a department reorganizes or a server moves is unrealistic in both cost and time. VLANs divide the network logically through software configuration alone, without changing physical wiring.

In the early days of networking, physical wiring was the network structure. Separating departments meant deploying separate switches and running separate cables. This worked when the number of devices was small and the organization was stable, but every time the organization changed, servers moved, or new environments were needed, the physical wiring had to be redone. As networks scaled up, broadcast storms became a real problem. When hundreds of devices shared one broadcast domain, a single ARP request was delivered to every device, and the accumulation caused meaningful bandwidth loss. VLANs emerged as a response to these two pressures: the need for logical reconfiguration without physical changes, and the need to shrink broadcast scope. The reason VLANs are a default design element in today's data centers is not convenience, but the need to overcome the flexibility limits of physical infrastructure through software.

A VLAN assigns a VLAN ID number to each switch port, allowing only ports with the same ID to communicate directly at Layer 2. Devices on different VLAN IDs are isolated as if they were on separate physical switches, even though they are plugged into the same one. When the same VLAN needs to span multiple switches, trunk ports are used. A trunk port follows the IEEE 802.1Q standard by inserting a 4-byte VLAN tag into the Ethernet frame, identifying which VLAN the frame belongs to. The receiving switch reads the tag and forwards the frame only to ports in that VLAN. Because VLANs are Layer 2 isolation, devices in different VLANs must go through a Layer 3 router to communicate. This is called Inter-VLAN routing, handled by an L3 switch or a separate router. Access control lists (ACLs) at this point can allow or block traffic between specific VLANs.

VLANs and subnets both logically separate a network, so they can look similar. The difference lies in the layer they operate at. VLANs divide broadcast domains at Layer 2 (Data Link) using switch ports and Ethernet frame tags, while subnets create routing boundaries at Layer 3 (Network) using IP address ranges. In practice, the most common approach is to map VLANs and subnets 1:1. Assigning the 10.0.10.0/24 subnet to VLAN 10 provides both Layer 2 isolation and Layer 3 address separation at the same time. In cloud environments, you almost never configure VLANs directly, and subnets become the basic unit of isolation. In on-premises data centers and hybrid environments, however, subnets alone cannot split broadcast traffic within the same switch, so the two must be used together.

VLANs appear most frequently in on-premises data centers, office networks, and hybrid cloud connections. In a server farm, separating web server groups, DB server groups, and management networks into different VLANs creates security boundaries on a single physical switch infrastructure. When departments reorganize or servers relocate, you only need to change the VLAN assignment on switch ports rather than re-cabling. However, once the number of VLANs exceeds a few dozen, management complexity rises sharply. Consistent VLAN configuration must be maintained across switches, and trunk port misconfiguration can lead to traffic leaks. VLANs are also a Layer 2 technology within the same physical network, so extending a VLAN to a geographically distant site requires additional tunneling or overlay technology. In pure cloud environments, VLANs are rarely configured directly; the cloud provider's subnets and security groups serve a similar role.