From your office
to the cloud.

01 / Inside the business

The journey starts with a name.

When an application connects to a hostname, it commonly asks a DNS resolver for an IP address. That address tells the network where to send packets; it does not necessarily identify the physical location of every system involved in answering the request. See our business DNS guide for how name resolution works.

The packets travel from the device over a wired or wireless network, through the business router or firewall, and to its provider. A VPN or security service may add another location to the path. The route used by a remote employee can differ from the route used at the office.

02 / Between networks

How does traffic move beyond your provider?

The Internet is made up of independently operated networks. They exchange information about which address ranges they can reach and apply their own routing policies. Border Gateway Protocol, or BGP, is one way networks exchange that information. A route can change as networks make operational or policy decisions.

Peering is an arrangement in which networks connect to exchange traffic. They may connect at an Internet exchange point or through another direct interconnection. Transit is a service in which one network carries traffic toward destinations beyond the customer network. A route may use peering, transit, both, or neither if the destination is already on the same network.

A local interconnection can reduce distance for some traffic, but proximity or the number of visible hops alone does not guarantee the lowest latency or best performance. See BGP for businesses for more about routing.

03 / At the service

The first cloud system may not be the last.

A cloud service can use an edge location, content delivery network, load balancer, or other front-end system to receive a connection. That system may answer the request itself or pass work to an application, database, or model elsewhere. The address returned by DNS or seen in a trace does not by itself reveal where an AI model is running.

Large services may use multiple addresses or locations for the same hostname. The address selected for one user can differ from another user’s, and it can change over time. Record the actual destination address used when comparing tests.

04 / The experience

Why do two services feel different?

Distance, routing, congestion, equipment, and the destination’s workload can all affect the time a user waits. Latency is the delay across a measured path; bandwidth is the rate at which data can be carried. A congested link can add queueing delay, while a larger link can reduce transfer time when the rest of the path can use it.

A low network round-trip time is useful, but it does not establish how quickly a service will process a request. For a streaming AI response, teams may measure the time until the first output and the time to complete the response. Those measurements include different work depending on where and how they are taken.

Higher bandwidth does not make signals travel faster over the same route or remove model processing time. Our AI network planning guide covers workload sizing and data movement.

05 / A closer look

Tools that help you investigate.

Use tests from an affected device or comparable network, against a destination your organization is permitted to test. Replace example.com below with the relevant service hostname. Tool availability, privileges, and options vary by operating system; not all services answer diagnostic probes.

ping -c 4 example.com

For command examples, sample output, and more on interpretation, see latency, jitter, and packet loss.

06 / Read with care

What a trace can and cannot tell you.

Each displayed hop time is a round trip from the test device to that responding hop and back. It is not a one-way measurement, and hop times should not be added together to calculate end-to-end latency. Intermediate replies may take a different return path from the destination’s replies.

Asterisks, apparent loss, or a high response time at one intermediate hop can occur because that device filters, limits, or deprioritizes its diagnostic replies. If later hops and the destination respond normally, the intermediate response alone is not evidence of forwarding loss. Conversely, an unresponsive final hop does not prove a service is down if it does not answer the chosen probe.

Routing can use multiple paths, and traces can change between tests. A traceroute hop is a responding router or interface, not a count of BGP autonomous systems; a hop address or hostname does not always establish which company or physical location is responsible. Compare the destination and the actual application experience before assigning a cause.

07 / Compare observations

Make the next test useful.

When an application becomes slow, record the time and time zone, affected user or location, service hostname, resolved destination address, address family, protocol, and whether the connection uses Wi-Fi, a VPN, or another path. Capture a test while the problem is happening and, if available, a comparable test when it is working well.

Compare like with like: the same device, destination address, test method, and similar conditions. A changed DNS answer, route, VPN, or service endpoint can make results different without revealing the cause. Share the application symptoms and complete relevant output with your IT team or provider; redact sensitive details before sharing.

08 / Design & expectations

Plan for the path you depend on.

Ask a provider how it measures performance, which endpoints and network boundaries are covered, and what happens when service falls outside an agreement. A commitment for one part of a connection does not automatically cover another network or the cloud application. Our Internet SLA guide explains the questions to ask.

For critical applications, consider diverse connections, equipment, power, and a tested failover plan. Separate providers do not necessarily mean separate facilities or paths; the Internet redundancy guide helps identify shared dependencies. Private cloud connectivity is another design choice and needs its own capacity, routing, security, and resilience review.