DEV Community

Cover image for How does internet traffic actually find the right EC2 in the first place?
Md Tanvir Rahman
Md Tanvir Rahman

Posted on

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

#aws #internet #routing #ec2

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

web-page

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.

EC2 Info

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
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Three observations from this data:

  1. It responds to ping β€” so the device is alive and reachable.

  2. 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.

  3. 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
* * * *              β†’ * * * *
* * * *              β†’ * * * *
* * * *              β†’ * * * *
Enter fullscreen mode Exit fullscreen mode

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.

vxlan

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

the journey

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.

Top comments (0)