1. Google has an open peering policy subject to a few technical, commercial and legal considerations. As a general statement, we will agree to offer peering, so long as it's consistent with our peering policy.

  2. Please see the Google (AS15169) entry in PeeringDB for Internet Exchanges we are connected to, along with private peering facilities.

  3. Google will optimize delivery of content to users by considering a number of components including latency, quality of user experience, capacity constraints within Google and in other networks, and other factors.

  4. Google aims to deliver as much traffic as possible via Google Global Cache and peering, as this will generally provide the optimal user experience and lowest cost delivery for both the operator and Google. However, there may be reasons why this is not the case and some traffic may flow over indirect paths. Please contact us to discuss traffic delivery options for your network.

  5. Please see our Traffic Management page.

  6. In some locations, part of Google's content delivery network is also reachable through AS 36040. This ASN serves a subset of eligible of Google content. Due to the unique nature, AS36040 does not have the same peering policy.
    • If you do not already peer with Google, please contact your Google peering coordinator to discuss connecting with AS15169 and/or AS36040
    • If you do not know who to contact, send an email to

  7. AS43515 is a subset of Google's backbone network. It is not possible to peer with AS43515. If you are receiving traffic from AS43515, please contact us to discuss your peering arrangements.

Google Global Cache

  1. There are certain legal limitations to doing businesses in some countries, but as a general statement, we will agree to offer GGC to qualified ISPs, so long as it's in an area where there are no restrictions, and so long as it's consistent with our policy.

  2. GGC was designed for eyeball-heavy networks with greater than 1Gbps peak Google traffic. Google encourages networks with less than 1Gbps peak traffic to Google to join a local Internet Exchange, where combined traffic levels from multiple ISPs are sufficient to support the deployment of a cache node.

  3. Cache hit rate will vary by network based on the number of users served by the cache, their usage patterns, the size and type of GGC node, and the number of nodes deployed in your network. We have typically seen hit rates of 70% to 90%.

  4. Typically, a majority of the traffic routed through the GGC node is static content such as YouTube videos and Android Market downloads. Other Google web services, such as Google Search, may also be proxied and/or cached based on a number of factors, including legal requirements, available capacity and expected improvement in performance for end users. These services could include (but are not limited to):
    • YouTube
    • Google Search
    • Google Plus
    • Google Maps (including map tiles and street view)
    • Google Earth
    • Google Docs
    • Google Scholar
    • Google News
    • Android Market
    • Picasa Web Albums
    • DoubleClick by Google

    Note: Exact services cached and/or proxied by GGC will vary based on Google's legal and commercial requirements, and Google's discretion on possible performance impact of serving traffic through the node. Please understand that Google's intent is to serve users from the best possible location for each service, which may or may not be the local GGC node.

  5. The local cache is filled on a read-through basis when content is requested by the end user. If the GGC node already has the requested content in its local cache, it will serve the content via your network to the end user, improving the user experience and saving bandwidth. If the content is not stored on the GGC node, and the content is cache-eligible, the node will retrieve it from Google, serve it to the user, and store it for future requests. Otherwise, the request will be served from the nearest upstream node which has the content. No content is pre-loaded.

  6. No, users do not have to make any changes to take advantage of the GGC node. Requests are routed to the node automatically by Google's servers. If the GGC node is unavailable for any reason, user requests will be sent to another node or directly to Google.

  7. Google does not ask for preferential treatment of Google traffic. GGC is a way of bringing content closer to the end user and bringing delivery costs down for everyone.

  8. Yes, Google works with operators during node activation to set the maximum bandwidth level for each GGC node deployed in an operator's network. This process takes into account the node's configuration and network capacity available to the GGC node. This is generally ramped up over several days. After activation, this maximum can be changed by contacting the GGC Operations team.

  9. No. Non-Google caching on shared infrastructure is currently forbidden for most requests by Google's HTTP response headers (we set Cache-Control: private, max-age=6h). This indicates "that all or part of the response message is intended for a single user and must not be cached by a shared cache." As such, in-browser caching is allowed for up to 6 hours, while shared-caching is never allowed. According to RFC2616, Cache-Control headers "MUST be obeyed by all caching mechanisms along the request/response chain," so any shared caching mechanism intercepting Google content is not standards-compliant, and not conforming to our published policy towards caching."


  1. Google optimizes the content delivery path to users based on a number of metrics, including observed network path latency and quality of experience for the end user. Google does not recommend relying on ping time to [or any other Google service] as a measure of the actual user performance of Google services:
    • ICMP ping traffic can be discarded or delayed en-route
    • The termination point of the TCP session with Google may not represent the full network path between a user and the service
    • User content may often be served from other locations (possibly closer to the user) than the destination of a ping request

  2. Google uses complex load balancing and content delivery platforms. An individual IP address may serve multiple Google services, and the services served from that IP address may change over time without notice, as may the IP addresses used to serve specific Google services. Also, our content delivery platforms are both inside and outside our network, so at times certain Google services may appear to be served from outside IP address space allocated to Google. Exceptions include: