How Cloud Routing Works: A Deep Technical Dive

Understanding the internal mechanics of cloud routing—from virtual switches to SDN controllers—is essential for debugging network issues and optimizing performance. This article explains what happens when a packet leaves your virtual machine.

The Journey of a Packet in the Cloud

When your application sends a packet from a cloud VM, the packet doesn't behave the same way it would on a physical network. Let's trace the complete path of an HTTP request from an EC2 instance to an external API:

Step 1: Application Layer

Your application creates an HTTP request and passes it to the operating system's network stack. The kernel wraps it in TCP headers (with port numbers), then IP headers (with source/destination addresses). At this point, the packet looks identical to any traditional network packet.

Step 2: Virtual Network Interface

The packet reaches the VM's virtual NIC (vNIC). This isn't a physical device—it's a software construct that the hypervisor presents to the guest OS. The vNIC connects to a virtual switch running on the hypervisor.

Step 3: Hypervisor Virtual Switch

Here's where cloud routing diverges from traditional networking. The virtual switch—whether AWS Nitro's networking component, Azure's Virtual Filtering Platform (VFP), or Google's Andromeda—intercepts the packet and makes routing decisions:

Step 4: Encapsulation and Physical Transport

Cloud providers use overlay networking to transport packets across their physical infrastructure. The original packet is encapsulated inside another packet—typically using protocols like:

This encapsulation allows millions of customer VPCs—potentially using the same private IP ranges—to coexist on shared physical infrastructure.

Step 5: Physical Network Transit

The encapsulated packet travels across the cloud provider's physical network—high-speed switches, routers, and fiber links connecting data centers. This is the "underlay" network that customers never see.

Step 6: Decapsulation and Delivery

At the destination host, the process reverses. The hypervisor decapsulates the outer headers, evaluates security groups, and delivers the original packet to the destination vNIC.

SDN Architecture: The Control Plane

Cloud routing is a prime example of Software-Defined Networking (SDN). SDN separates the control plane (the "brain" that decides where packets go) from the data plane (the hardware that actually moves bits).

Centralized SDN Controllers

Each cloud provider operates massive SDN controller clusters that:

Distributed Forwarding

While control is centralized, actual packet forwarding is distributed. Each hypervisor caches the forwarding rules it needs locally. This provides several benefits:

Provider-Specific Implementations

AWS: Nitro and Blackfoot

AWS moved networking from software on the host CPU to dedicated Nitro cards—custom hardware that handles virtualization, storage, and networking. The Blackfoot system manages VPC routing:

Learn more about AWS networking architecture.

Google Cloud: Andromeda

Google's Andromeda SDN has been in production since 2014, powering all GCP networking:

See our guide on Google Cloud networking.

Azure: Virtual Filtering Platform (VFP)

Microsoft's VFP runs as a Windows hypervisor extension:

Explore Azure networking features.

Security Group Processing

Before any routing decision, packets pass through security evaluation. Unlike physical firewalls that operate inline, cloud security groups are distributed:

Stateful Filtering

Cloud security groups are stateful—if you allow outbound traffic to port 443, return traffic is automatically allowed without explicit rules. The hypervisor tracks connection state (TCP sequences, UDP ports) to permit return packets.

Rule Evaluation Order

Route Resolution and Path Selection

When the virtual router evaluates a packet, it uses longest prefix match (LPM)—the same algorithm physical routers use:

# Given these routes:
10.0.0.0/8      -> VPN Gateway
10.0.0.0/16     -> Local
10.0.1.0/24     -> NAT Gateway
10.0.1.50/32    -> ENI (specific instance)

# Packet to 10.0.1.50 matches:
# - 10.0.0.0/8 (8 bits match)
# - 10.0.0.0/16 (16 bits match)
# - 10.0.1.0/24 (24 bits match)
# - 10.0.1.50/32 (32 bits match) <- WINNER

# The /32 route wins because it's most specific

This behavior is critical for designing overlay networks, avoiding routing loops, and implementing traffic engineering.

Performance Characteristics

Latency Overhead

Virtual networking adds latency compared to bare metal:

Throughput Considerations

Network bandwidth is tied to instance size:

For latency-sensitive workloads, choose instance types with dedicated network bandwidth and placement groups for co-located VMs.

Troubleshooting Cloud Routing

When packets don't reach their destination, systematic debugging is essential:

Common Issues

Debugging Tools

For persistent issues, see our cloud routing troubleshooting guide.

Key Takeaways

Need Expert Help?

Our team has deep experience with cloud networking internals. Contact us for architecture reviews and optimization.