DEV Community: Md Tanvir Rahman

How does internet traffic actually find the right EC2 in the first place?

Md Tanvir Rahman — Thu, 14 May 2026 09:37:04 +0000

I launched an EC2 instance in Tokyo region (ap-northeast-1). Opened a browser. Typed the public IP. The page loaded in milliseconds.

But I couldn't stop thinking — how did that packet find my EC2? Out of millions of servers inside AWS datacenters, how did my HTTP request land on exactly the right physical machine?

So I ran some experiments. What I found was a journey across three completely different networks — each with its own rules, its own routing logic, and its own way of saying — The EC2 you want is this way👉
Let me walk you through all of it.

The Setup

Before we trace the packet, here is the EC2 instance I used for this experiment.

The Big Picture — Three Stages — Three Networks

Stage 1 — Public Internet
Stage 2 — AWS Private Backbone
Stage 3 — Inside the Physical Server

Each stage has a completely different routing mechanism. Let me show you each one — backed by actual traceroute data.

Stage 1 — How the Public Internet Finds AWS

Before your packet even left your PC, your ISP's router already knew where to send it. The mechanism is BGP (Border Gateway Protocol). AWS owns large blocks of public IP addresses:

54.0.0.0/8
52.0.0.0/8
35.0.0.0/8
3.0.0.0/8
... and many more

You can find all the latest ranges from here. AWS services IP range

AWS announces all of these ranges to the internet via BGP from their edge routers. Every ISP router in the world learns: "If you want to reach anything in 35.72.0.0/13, send it toward AWS."
So, I ran tracert from my ｗindows machine to the EC2 public IP.

C:\Users\Tanvir>tracert 35.72.2.8

Tracing route to ec2-35-72-2-8.ap-northeast-1.compute.amazonaws.com [35.72.2.8]
The maximum number of hops involved is 30.

  1     2 ms     2 ms     1 ms  172.16.x.x
  2     6 ms     8 ms     6 ms  118.23.140.230
  3    11 ms    12 ms    12 ms  118.23.140.41
  4    19 ms    10 ms    11 ms  180.8.119.165
  5    21 ms    22 ms    21 ms  125.170.96.57
  6    25 ms    24 ms    27 ms  125.170.96.198
  7    22 ms    26 ms    24 ms  221.184.13.2
  8     *        *        *     The request timed out.
  9     *        *        *     The request timed out.
 10     *        *        *     The request timed out.
 11     *        *        *     The request timed out.
 12     *        *        *     The request timed out.
 15  ^C
C:\Users\Tanvir>

Seven visible hops. Then silence. But the EC2 responded perfectly. Let me decode every single hop.

Hop 1 Your Gateway (172.16.x.x | 4ms)

The first hop is always your default gateway — your local router. The 172.16.x.x range is a private IP, which confirms this is the office or home network gateway.

Hop 2 & 3 ISP Backbone (118.23.140.x | 5–11ms)

The 118.x.x.x range belongs to NTT/OCN — one of Japan's major ISPs. These are internal backbone routers inside your provider's network.

Hops 4, 5 & 6 — NTT Communications Transit (180.8.x / 125.170.x | 19–25ms)

Notice the latency jump here — from 11ms to 19ms. This is the moment your traffic left your local ISP and entered NTT Communications, a Tier-1 carrier that operates Japan's backbone infrastructure and has direct peering agreements with major cloud providers including AWS.

Hop 4:  180.8.119.165   NTT transit entry point
Hop 5:  125.170.96.57   NTT backbone routing
Hop 6:  125.170.96.198  NTT backbone, approaching handoff

Hop 7 — The Handoff Point (221.184.13.2 | 22ms)

This is the most interesting hop in the entire trace. 221.184.13.2 is the last publicly visible address before the packet enters AWS's private world.

I ran two follow-up commands on this IP:
Ping

C:\Users\Tanvir> ping 221.184.13.2

Reply: 28ms  TTL=58
Reply: 31ms  TTL=58
Reply: 28ms  TTL=58
Reply: 23ms  TTL=58

nslookup

C:\Users\Tanvir> nslookup 221.184.13.2

Server:   nv-kf591.ocn.ad.jp
Address:  221.113.139.148
*** nv-kf591.ocn.ad.jp can't find 221.184.13.2: Non-existent domain

Three observations from this data:

It responds to ping — so the device is alive and reachable.
TTL = 58 — most routers start TTL at 64, which means 6 hops have been consumed reaching this device from wherever it originates its responses. This tells you the device is 6 routing hops deep inside some network — consistent with an IXP edge router.
No PTR record (no reverse DNS) — this is deliberate. AWS edge and peering routers do not publish DNS names for their interfaces. It is standard practice for Internet Exchange routers — they forward traffic perfectly but stay anonymous. You cannot map AWS's internal topology from outside.

This hop is the NTT ↔ AWS peering point — physically located at an Internet Exchange Point (IXP) in Tokyo such as JPIX, JPNAP, or Equinix Tokyo. NTT hands your packet to AWS right here.

Hop 8 — The AWS Black Hole (* * *)

From Hop 8 onward, traceroute returns nothing. But the EC2 was responding to HTTP requests the entire time. So the route did not break — AWS simply blocks ICMP TTL-exceeded messages inside their network. It indicates:

It hides AWS's internal network topology
Nobody can map the AWS backbone from outside
Your traffic flows perfectly — traceroute just loses visibility

Everything from Hop 8 onward is inside AWS's private world. And this wrap-up stage 1.

Stage 2 — Inside AWS | From Edge Router to Physical Server

Once your packet crosses the IXP handoff and reaches the AWS edge router, it enters a completely different world — AWS's private backbone. This part is invisible to traceroute, but we can reason through it from AWS's published architecture.

How Does the AWS Edge Router Know Which Server Your EC2 Is On? ー Actually, when you launch an EC2 instance, AWS's central SDN controller builds a complete internal mapping.

Public IP:   35.72.2.8
Elastic IP mapped to → ENI: eni-abc123
ENI lives on         → Physical Server #XXXX
Server is in         → Rack R-22
Rack is in           → AZ: ap-northeast-1a
* * * *              → * * * *
* * * *              → * * * *
* * * *              → * * * *

The moment your packet arrives at the AWS edge router with destination 35.72.2.8, initially the router looks up this mapping and knows exactly which physical server to route toward. Then it wraps your packet inside another packet for internal transport. The new packet's header consist with new source IP (AWS Edge Router internal IP) & new destination IP (Physical Server #XXXX internal IP). This is called Overlay Tunneling (VXLAN). The inner packet is unwrapped only when it reaches the Nitro card on the destination server.

Stage 3 — Inside the Physical Server: Nitro Finds Your EC2

Now the packet has arrived at the physical server. Now the Nitro card takes over. The ENI is fingerprint of Your EC2's Network Identity. Every EC2 instance has an Elastic Network Interface (ENI) — a virtual NIC that carries everything needed to identify ownership. A detailed blog also been published, you can read it from here.

The Complete Journey — Every Hop Mapped

Key Takeaways

BGP is what makes the internet find AWS. AWS announces its IP ranges globally via BGP. Every ISP router learns the path. Your ISP routes toward AWS the same way it routes toward any destination — pure BGP.
ISP does not connect directly to the AWS edge location. The handoff happens at a neutral IXP facility. After that, the packet enters AWS's fully private backbone.
AWS blocks ICMP inside their network. You can see the handoff point but nothing beyond it. This hides internal topology from the public internet.
The Nitro card does the final delivery.

Where Do Your AWS Network Rules Actually Live?

Md Tanvir Rahman — Mon, 11 May 2026 13:40:49 +0000

After spending years climbing into server racks, cabling switches, and staring at Cisco IOS prompts, the first time I opened the AWS console felt oddly disorienting.
Everything I knew was still there — subnets, routing tables, firewall rules — but the physical devices had completely vanished. No chassis to open. No cable to trace. Just a browser tab. So I went digging. And what I found changed how I think about networking entirely.

AWS did not reinvent networking. It took every concept we already know and rebuilt it as distributed software — invisible to us, managed entirely by Amazon, running across thousands of physical servers.

Let me show you exactly what that means.

Same Concepts, Different World

In an on-premises environment, the path from the edge router to a client's server runs through a private internal network — thousands of L2/L3 Switches, Next-Gen Firewalls, Load Balancers. We group them by service or client type, rack the devices, cable everything, SSH in, and configure VLANs, routing protocols, ACLs, and firewall policies directly on each device. We have full physical access & control.

Inside AWS, the physical hardware still exists. There is a massive private internal network fabric connecting Amazon's datacenters — they call it the AWS Backbone. And every concept you know from on-prem has a direct AWS equivalent. The terminology shifts slightly, but the logic is identical. A route table is still a route table. A firewall rule is still a firewall rule. Also —

But here is where most network engineers hit a wall. If the concepts are the same, then:

On-prem physical router == AWS's physical router?
On-prem physical firewall == AWS's physical firewall?
Are we somehow reaching their internal devices from the public internet?

AWS says everything lives in a private network — so how does any of this work?
The answer flips everything you expect on its head.

Your Rules Don't Live Where You Think

On-premises, a network engineer touches everything — from the edge router all the way down to the Top of Rack (ToR) switch — for any configuration task. In AWS, it is the complete opposite.

No physical router, firewall, or switch inside the AWS datacenter holds your configuration. Not a single one.

Instead, every networking rule you apply through the AWS console or CLI — your Security Groups, your Route Tables, your VPC settings — is picked up and enforced by something running directly on the physical server where your EC2 instance lives. That something is the AWS Nitro Hypervisor.

Think of it this way➝ in on-prem, your rules live in the network. In AWS, your rules live in the server. Right there on the same physical machine as your VM, before any packet can reach it.

This is the key insight that unlocks everything else.

Nitro Hypervisor — The Real Game changer

To understand why Nitro matters, you first need to see the problem with traditional hypervisors.

In on-premises environments, hypervisors like VMware ESXi or Microsoft Hyper-V run as a software layer on the main CPU. They manage VMs, networking, storage, and security — but they do all of it by competing with your VMs for the same CPU and RAM. Every packet your VM sends, every disk write it makes, the hypervisor jumps in on the main CPU to process it. Under heavy load, that overhead can silently consume 10–30% of compute resources.

AWS looked at this problem at the scale of millions of EC2 instances and asked a simple but radical question:

What if we moved every hypervisor function completely off the main CPU?

The answer was Nitro — three dedicated hardware chips (ASICs), each responsible for one job and one job only.

Nitro Network Card : Handles Security Groups, VPC routing, NAT translation, packet filtering, and VPC traffic isolation.
Nitro Storage Card : Handles EBS volume I/O, NVMe processing, AES-256 encryption, compression, and snapshot management.
Nitro Security Chip : Enforces hardware-level isolation, secure boot, encryption key management at the hardware level. This chip is why AWS can make announcement loudly that even their own employees cannot access your VM. It is not a policy — it is physically impossible at the hardware level.

※ The result : your EC2 instance gets nearly 100% of the physical CPU and RAM. The hypervisor's resource utilization drops to almost zero. That is why AWS EC2 on Nitro performs close to bare-metal speeds — because there is barely any hypervisor overhead left to subtract.

But There Are Thousands of EC2s on One Server — How Does Nitro Know Which Rules Are Yours?

This is the question that always comes next, and it is a good one.

A single physical server inside an AWS datacenter can run EC2 instances belonging to dozens of different customers. When a packet arrives at the physical NIC, the Nitro card needs to know instantly : whose packet is this, and which rules apply to it?

The Answer — Everything has a unique ID. When you create ANYTHING in AWS, it gets a unique identifier burned into it. Like ——

Your EC2              → i-0a1b2c3d4e5f
Your VPC              → vpc-0a1b2c3d4e5f
Your Subnet           → subnet-0a1b2c3d4e5f
Your Route Table      → rtb-0a1b2c3d4e5f
Your Security Group   → sg-0a1b2c3d4e5f
Your ENI              → eni-0a1b2c3d4e5f

These IDs form a chain of ownership stored in AWS's central SDN controller database. When your EC2 launches on a physical server, the SDN controller pushes your complete rule set — Security Groups, Route Tables, VPC boundaries — directly into the Nitro card's dedicated memory on that server. But the real-time traffic matching happens through something more fundamental : the ENI and its MAC address.

Every EC2 instance has an Elastic Network Interface (ENI) — think of it as its virtual NIC. The ENI carries everything: private IP, public IP, Security Group assignment, subnet, VPC, and a unique MAC address.

Here is what happens the moment a packet arrives:

The packet hits the physical NIC carrying a destination MAC address inside its Layer 2 frame.
The Nitro card reads that MAC address and looks it up in its internal ENI table.
It instantly knows: this MAC belongs to ENI eni-abc123, which belongs to Customer A's VPC, protected by Security Group sg-xxx, routed by Route Table rtb-xxx.
It applies those rules in hardware — in nanoseconds — and either delivers the packet to the right EC2 or drops it.

Two customers can even share the same private IP address (say, 10.0.1.5) on the same physical server — because the VPC ID in the ENI chain keeps them completely isolated. The Nitro card never confuses them. It is not working from IP alone; it is working from the full ownership chain burned into its memory.

So What Does This Actually Mean for You?

If you have spent years in on-prem networking, here is the mental model that ties everything together —

In on-premises, your rules live in the network — in the router, in the firewall, in the switch ACL. Traffic hits those devices and gets filtered there.
In AWS, your rules live in the server — in the Nitro card's dedicated memory, enforced before any packet reaches your VM. There is no physical firewall in the path. There is no router to SSH into. The entire network policy is distributed to every physical server that runs your workloads. That is not a limitation. That is the design.