It's worth asking Google (or any peer) if they're willing to share XC costs. Usually this is in the form of "I buy one, you buy the other"
Generally yes, lots of people do this, but it's not going to change Google's calculus on this. Again it's mostly about GCP, specifically GCP network tiers. If you have stuff in GCP, you have 2 network tier options. Standard and Premium. Standard : Ingress/Egress is to/from the *closest Google POP* to where your stuff is. (Hot potato out, cold potato in) Premium : Ingress : Into Google POP closest to the other endpoint ( Hot potato in) Egress : rides the Google network to the closest POP to where the other side is. ( Cold potato out ) Ingress traffic is still free, the network tier you select specifies what you pay for outbound. Premium tier is about 1.5x more expensive than Standard, so you can probably assume way more people are using that. As you would expect, this means Google needs lots of external connectivity at the POPs closest to the GCP regions, so they're buying TONS of transit there. This is requiring a lot of hardware investment from both Google and the transit providers. What happens when transit providers have to buy new hardware for one customer? They put minimum traffic commits in the contract to better amortize the payback on the hardware costs. Google has a ton of transit capacity that there is a cost floor on due to min commits. They are now financially incentivised to move as much traffic over to those links as they can because they're paying for them anyways. They are now financially *disincentivised* to peer in many circumstances. - Peering costs require a router, port, MRC for cross connect , and MRC for IX if that. Then you get the traffic for free. - If you connect this peering to a router that you already have in a location you already are, it's marginal cost to do it, so why not. - If you have to have hardware / cage space / power somewhere that only exists for peering, it might be different. Moving that traffic to transit may cost you say $1M MRC , but if you can delete $100k a month in amortized hardware costs / cage / power / MRCs , that pays for itself in 10 months and then you're green. Less so if that traffic goes towards a min commit that you're not reaching traffic wise, but paying for. This makes MBA's wake up at 2am with tingles. It's just shifting network needs and traffic patterns since GCP has taken off. Google search/ads revenue growth has been under threat for years, so they have been trying to build up different revenue streams. GCP is up to around 20% of search/ads revenue, and growing something like 35-40% year over year. As a result they seem to be reorganizing their network to make sure GCP is most performant since that is what they believe is their future longer term cash cow. On Thu, Sep 4, 2025 at 10:47 AM Chris via NANOG <nanog@lists.nanog.org> wrote:
It's worth asking Google (or any peer) if they're willing to share XC costs. Usually this is in the form of "I buy one, you buy the other"
On Thu, Sep 4, 2025 at 2:07 AM Will OBrien via NANOG < nanog@lists.nanog.org> wrote:
We recently turned up a new IXP and I’m going through the motions of arranging the usual peers, etc. I’m extremely surprised by this one:
Public Peering
Google no longer accepts new peering requests at internet exchanges (IXPs). However, Google maintains dedicated connectivity to the internet exchanges (IXPs) listed in our PeeringDB entry< https://www.peeringdb.com/asn/15169>. We also maintain existing BGP sessions across internet exchanges where we are connected. For networks who do not meet our PNI requirements Google will serve those networks via indirect paths.
I can only presume that someone who doesn’t pay for cross connect fees came up with this plan. This feels short sighted at the least. Considering the benefits of peering, I have to express some dismay at this disservice to the internet in general.
Anyone from Google care to explain what appears to be a willful withdrawal of support for the IXP community? _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/77ZSJJ65...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DVZKZSDU...