Understanding Autonomous Systems and BGP: The hidden architecture behind every internet connection

Every time you load a webpage, your request travels through dozens of independently managed networks called Autonomous Systems (AS). The protocol that decides how traffic moves between them is Border Gateway Protocol (BGP). Understanding how AS and BGP work together is the foundation of understanding why internet performance varies and why monitoring them matters.

Think about the last time you sent a package through a courier service. You handed it off at one counter, it passed through a regional hub, transferred to a local depot, and eventually arrived at the door. At no point did you control any of those handoffs. You trusted a chain of organizations — each with their own rules, routes, and reliability — to carry your package to the right place.

The internet works the same way. Only instead of packages, it's your data. Instead of courier depots, it's Autonomous Systems. And instead of a dispatcher deciding which route your package takes, it's BGP.

What is an Autonomous System?

An Autonomous System (AS) is a collection of IP address ranges managed and controlled by a single organization. That organization could be an internet service provider (ISP), a cloud provider, a university, a large enterprise, or a content delivery network (CDN). What makes it "autonomous" is simple: the organization makes its own decisions about how traffic moves within its network.

Every AS is assigned a globally unique identifier called an Autonomous System Number (ASN). These numbers are issued by Regional Internet Registries (RIRs) — organizations like ARIN in North America, RIPE NCC in Europe, and APNIC in the Asia-Pacific region. When you see an ASN in a traceroute result, you're seeing a fingerprint that identifies exactly which organization was handling your traffic at that point in the journey.

Some well-known ASNs you might recognize:

AS15169 — Google

AS32934 — Meta (Facebook)

AS16509 — Amazon Web Services

AS36647 — Yahoo

Every packet your network sends will pass through multiple Autonomous Systems before reaching its destination. The path it takes — and the performance you experience — depends entirely on how those AS networks are connected and how they decide to route your traffic.

How do Autonomous Systems connect to each other?

Autonomous Systems don't operate in isolation. They connect to each other through a process called peering or transit, and they exchange routing information using a protocol called Border Gateway Protocol (BGP).

There are two main types of AS relationships:

Transit: A smaller network pays a larger network to carry its traffic. A regional ISP in Southeast Asia, for example, might pay a global backbone carrier like Lumen (AS3356) or Tata Communications (AS6453) to reach destinations its own network can't. Think of it as a local courier handing off a parcel to a national freight company where the local courier doesn't have the infrastructure to reach every address, so it pays someone who does.

Peering: Two networks agree to exchange traffic directly, usually at no cost, because it benefits both. This typically happens at Internet Exchange Points (IXPs), which are physical facilities where multiple networks come together to swap traffic efficiently. DE-CIX in Frankfurt, the world's leading Internet Exchange by traffic volume, and Equinix IX locations across North America and Asia-Pacific are where thousands of these peering agreements are active. When Google (AS15169) and a European ISP peer at DE-CIX, traffic between their networks takes a direct path rather than transiting a paid backbone carrier.

The combination of transit relationships and peering agreements forms the backbone of the internet. Traffic never travels in a straight line. It takes the path BGP routing tables say is best at that moment — and that path runs through a chain of organizations, handoffs, and agreements that most teams never see until something breaks.

What is BGP and why does it matter?

Border Gateway Protocol (BGP) is the routing protocol that makes the internet work. It's often called the "postal service of the internet" and for good reason. BGP is responsible for one thing: deciding the best path for your traffic to travel between Autonomous Systems.

Every AS maintains a BGP routing table — a constantly updated map of which AS numbers to pass through to reach any given destination. When your data leaves your network, BGP looks at that table and says: to reach this destination, go through this AS, then this one, then this one.

BGP makes routing decisions based on a set of attributes, the most important of which is the AS path (the sequence of AS numbers your traffic will traverse to reach its destination). Shorter AS paths are generally preferred, though network operators can apply policies that override this.

Here's what makes BGP both powerful and fragile: it's built on trust. When an AS announces that it can reach a set of IP addresses, other networks take that announcement at face value and update their routing tables accordingly. There's no automatic verification. This is why BGP misconfigurations and hijacking incidents can propagate across the global internet in minutes.

How BGP route changes affect your network performance

Under normal conditions, BGP routing is invisible. Traffic flows, applications perform, users are happy. But when something changes in the BGP routing table (intentional or not) the effects can be significant and immediate.

BGP route changes happen when an AS announces a new or modified path to a destination. This can be legitimate. For instance, a network operator optimizing traffic flows, a new peering agreement taking effect, or a failover to a backup path. But it can also be the result of a misconfiguration or, in more serious cases, aBGP hijacking attack.

BGP hijacking occurs when a malicious or misconfigured AS announces that it can reach IP addresses it doesn't actually own. Other networks update their routing tables based on that false announcement, and traffic that should reach its intended destination gets redirected — sometimes to a network controlled by a threat actor. The 2010 China Telecom incident, where traffic from dozens of US government and military networks was briefly rerouted through Chinese AS infrastructure, remains one of the most cited examples of how consequential a BGP route change can be.

Even without malicious intent, an uninformed BGP route change can:

• Increase latency as traffic takes a longer or more congested path
• Cause packet loss if the new path is less reliable
• Route your traffic through a transit provider you didn't agree to and whose SLA commitments may not match your own

Unlike hijacking, BGP route leaks are accidental but equally disruptive to network performance.

Reading a traceroute through the lens of Autonomous Systems

A traceroute is one of the most useful tools for understanding how your traffic moves through Autonomous Systems. Each line in a traceroute output represents one hop i.e., one network device your packet passed through on its way to the destination. But if you know what to look for, a traceroute tells you far more than just hop count and latency.

Look for the AS number associated with each hop. When the AS number changes between two hops, you're seeing the exact point where your traffic crossed from one organization's network to another. A sudden latency spike at that boundary is a signal worth investigating. It may indicate congestion or a performance issue at a specific AS handoff point.

Here's what a meaningful traceroute analysis looks like:

Hops 1–3: Your own network (same ASN throughout)

Hop 4: Transition to your ISP's AS — first external handoff

Hops 5–7: Your ISP's internal infrastructure

Hop 8: Transition to a transit provider AS — second handoff

Hops 9–12: Transit provider's backbone

Hop 13: Transition to destination AS — final handoff

Hop 14: Destination server

If latency jumps sharply between hops 7 and 8, you know the problem is at the boundary between your ISP and their transit provider. Definitely not in your own infrastructure, and not at the destination.

Why AS and BGP monitoring matters for network teams

When a basic understanding of Autonomous Systems tells you what the internet is, monitoring them tells you what your slice of it is actually doing right now.

Here's why:

You can't fix what you can't see. When users report slow application performance, the cause could be anywhere. It could be in your infrastructure, your ISP, a transit provider, or the destination network. Without AS-level visibility, you're guessing. With it, you can trace the problem to a specific organization and a specific hop.

Your ISP controls only part of the path. Your ISP's SLA covers their network. Once your traffic leaves their AS and enters a transit provider's network, you're outside the scope of that SLA. Monitoring AS handoffs tells you exactly where your ISP's responsibility ends and a transit provider's begins, which is a critical piece of information when you're preparing for an SLA dispute.

BGP route changes happen without notice. Transit provider changes, new peering agreements, and network optimizations happen constantly. Most of them are invisible to your team until they start affecting performance. Monitoring AS numbers at every hop means you know the moment your traffic starts taking a different path, whether it's authorized or not.

Multi-ISP environments need comparative data. Organizations running multiple ISPs across different regions need to know which providers are consistently delivering on their commitments and which are falling short. But comparative data only has value when it is specific. In practice, comparing ISP performance means tracking latency, jitter, packet loss, AS path length, and availability across every provider simultaneously, from the same monitoring locations, over the same time window. Packet loss above 1% on any path warrants investigation. Above 3%, it is actively degrading application performance.

Jitter exceeding 10ms on a path carrying VoIP or video is enough to produce noticeable degradation for end users. AS-level monitoring gives you the longitudinal data to identify which provider degrades under load, which one reroutes traffic during peak hours, and which one consistently meets its SLA targets across every region you operate in.

What good AS monitoring looks like in practice

The monitoring tool detects that the AS number at hop 8 has quietly changed. The expected transit provider is gone. An unrecognized AS is now handling the traffic. An alert fires — before a single user notices, before the tickets start flooding, before the damage compounds. That is the difference between watching the path and hoping for the best.

Effective AS path monitoring is not about running traceroutes when something feels wrong. It is about knowing what normal looks like at every hop, from every location, at every hour — and catching the moment it changes.

The key metrics to track at the AS level include:

• AS path length — the number of AS hops between source and destination. An unexpected increase often signals a route change.
• AS number at each hop — which organization is handling your traffic at every point along the path. A change here means your traffic is transiting a different provider.
• Latency per hop — where delays are accumulating and in which AS they originate.
• Packet loss per hop — whether loss is occurring within an AS or at the handoff between two.
• AS number at the last hop — the final transit provider delivering your traffic. If this changes to an organization you don't recognize or trust, that's worth an immediate alert.

When you can track all of these continuously, from 130+ global locations, not just one, you stop reacting to BGP events and start catching them before they reach your servers.

Your answer may be three AS hops away

The internet is not a single network. It's a mosaic of tens of thousands of Autonomous Systems, each independently managed, each making its own routing decisions, and all held together by the trust-based handshakes of BGP. For most users, that complexity is invisible until something goes wrong.

For network teams, the invisible is exactly where the work happens. Understanding how AS and BGP work is the foundation of getting a clear picture of where your traffic goes, who's handling it, and how the paths are decided.

The next time a user reports that an application is slow, the answer may not be in your infrastructure at all. It may be in a BGP routing table, three AS hops away, in a network you've never heard of. The teams that find that answer fastest are the ones who never stopped watching the path.