The Internet’s New Edge Builders

In The Internet's New Builders I described how content and cloud platforms moved from buying international capacity to financing cables and operating private backbones. The same companies are now moving one layer closer to the user. Google, Meta, Amazon, Microsoft and ByteDance increasingly build or control delivery infrastructure that once would have been bought mainly from independent CDN providers. Traditional CDNs still carry important traffic, but they no longer define the whole delivery architecture.

In this article, I follow the shift from backbone to delivery edge, looking at how content and cloud platforms are taking on roles once associated mainly with traditional CDNs, what public measurements can and cannot show, and what Google and Meta deployments inside one access network reveal about the changing role of operators.

The same shift, one layer closer

The first article began with international capacity. TeleGeography put content and cloud networks at 73% of used international bandwidth in 2024 and the broader content-provider category at 75% in 2025. On the trans-Atlantic, trans-Pacific and intra-Asian routes, their share was already at least 80% in 2024. These figures describe the networks using international capacity, not the share delivered by commercial CDNs, but they show where the demand now sits.

The hatched 2026E band is deliberately simple. Long-range growth assumptions leave the share near 75%, while extending the recent published trend places it near 77%. The range shows direction rather than a precise forecast

The public Internet is only one plane

International bandwidth can be measured in several ways. Total used international bandwidth reached 6.4 Pbps in 2024, while the narrower international Internet bandwidth measure reached 1,835 Tbps in mid-2025. The two figures describe different populations and cannot be combined into a public-versus-private traffic ratio.

That distinction matters because a growing share of delivery takes place across private backbones, direct interconnection and caches inside access networks. A path can leave the public Internet without leaving the Internet infrastructure that supports the service. Public exchanges still carry enormous volumes, but they now operate beside delivery systems that are controlled from inside the platforms.

The long-haul change has continued since the first article. The public list of content-provider cable holdings and investments grew from 20 entries in 2017 to more than 60 in the 2026 refresh, while capacity deployed by content networks more than tripled between 2021 and 2025. Planned submarine systems entering service between 2026 and 2029 represent more than $16 billion in construction value. Google and Meta are among the companies leading that investment.

The same economics applies at the edge. A platform with enough traffic can justify a private cable because it already owns the demand. It can use the same demand to justify a cache inside an ISP, a private peering session or a regional edge site. The customer of the old infrastructure model becomes one of its builders.

The old CDN bargain

The traditional division of roles was straightforward. Operators built access networks, carriers sold transit, Internet exchanges provided meeting points, and commercial CDNs distributed content over a shared server footprint. A single Akamai deployment could serve many unrelated companies, allowing the provider to spread the cost of a global edge across many customers.

That model remains valuable. Independent CDNs provide reach, security, resilience and capacity in markets where a private deployment is not justified. More than 2,300 commercial CDN cache locations were tracked across over 500 cities in early 2025, with Akamai, Cloudflare and CDNetworks among the largest footprints by site count.

A cache, however, is only one component of delivery. A CDN also maps requests, terminates encrypted sessions, applies cache policy, protects the origin and manages failure. An operator cannot simply store third-party encrypted content because the traffic crosses its network. The content owner must authorise the delivery relationship, whether through a CDN contract or a first-party appliance.

What changed was the scale of the largest traffic owners. When one company generates enough predictable demand, it no longer needs a shared CDN for every part of its delivery. It can build around its own applications and keep control of mapping, software and failure policy. For those high-volume flows, first-party and hyperscaler delivery is taking over part of the role once held by traditional CDN providers.

The pressure is visible in the market. AWS, Google and Microsoft sell delivery over their own cloud networks, while Akamai has expanded into cloud infrastructure, compute and security. StackPath closed, Edgio entered bankruptcy and Lumen left the CDN business. These developments do not mean that independent CDNs disappear; they show that the centre of control is moving toward the companies that own the applications and demand.

This is more than a wider choice of suppliers. The content owner can now combine its private network, its own edge and one or more external CDNs under a single delivery policy. The independent CDN remains part of the stack, but it is increasingly selected by the traffic owner rather than defining the stack by itself.

From CDN customer to delivery builder

Google is the clearest first-party example. Its delivery infrastructure includes data centres, edge points of presence and Google Global Cache nodes installed inside qualifying operator networks. The operator hosts and connects the appliance, while Google controls what is stored and how users are mapped to it. Google also sells Cloud CDN and Media CDN to external customers over its platform network.

Meta follows the same direction. It operates a private backbone, hundreds of points of presence and appliances inside access networks. These systems bring media for services such as Facebook and Instagram closer to users while the wider Meta network carries dynamic application traffic. An edge appliance can deliver media and relay selected traffic, but it should not be described as caching every Facebook, Instagram or WhatsApp interaction.

Netflix built an even more specialised system. Open Connect Appliances deliver Netflix video and images from ISP networks or nearby interconnection sites. Netflix does not sell a general CDN. It replaced a large part of its external delivery requirement with infrastructure designed around one predictable workload.

Microsoft shows the transition from customer to builder. In 2015 it offered Azure CDN over Akamai's network. Today Microsoft operates a global WAN, sells Azure Front Door over that infrastructure and is developing Connected Cache for deployment on operator hardware. External CDNs can still appear in individual services, but Microsoft now controls the architecture instead of depending on one provider for it.

Amazon combines the same roles through AWS. CloudFront runs over Amazon's private backbone and is sold as a commercial CDN. Embedded POPs extend that platform into ISP and mobile-operator facilities, with AWS owning the delivery system and the partner providing the location and connectivity.

Apple and ByteDance make the overlap visible. Apple supplies Edge Cache equipment to selected operators but also uses external delivery networks for some software objects. ByteDance operates platform delivery infrastructure and sells BytePlus CDN, while TikTok can still appear behind Akamai in a measured market. Owning an edge does not require one exclusive path.

The direction is nevertheless clear. Google, Meta and Netflix built around first-party demand. Microsoft and Amazon turned their global networks into delivery products. Apple and ByteDance combine private and external layers. The companies that were once mainly CDN customers are now building the infrastructure, selling it or deciding how the remaining CDN capacity is used.

The edge is selected, not simply located

A map of cache locations cannot show this change by itself. A server can be physically present in a city but available only to selected networks. A neighbouring site can be closer in network terms, and two users in the same building can reach the same platform through different cities because their access providers and the platform make different routing and mapping decisions.

The unit of analysis should therefore be the service and selected endpoint, not the company name. A YouTube video can come from a GGC inside the ISP while another Google service remains regional. Microsoft can use Azure Front Door and still deliver a particular object through Akamai. Apple can operate Edge Cache while software downloads use CloudFront. Asking whether an entire company is "local" or "on one CDN" hides the delivery policy that made the choice.

What public measurement can and cannot see

PeeringDB, BGP and RIPE Atlas describe different parts of this system. They can show declared presence, announced reachability and the path selected from a probe. They cannot reveal the volume carried inside a private backbone, a platform's internal mapping rules or the cache-hit ratio of an appliance that is not visible from the public Internet.

In June 2026 I ran a small RIPE Atlas round across ten countries. Landing points varied by hostname and source network, including between probes in the same country. The result was useful as a diagnostic snapshot, but it did not explain the platform's internal decision. Public measurement shows the route that was selected; it does not expose the complete delivery system behind that route.

Two first-party edges in one access network

First-party edge infrastructure is common in mature operator networks. The SkyTel example is useful because it shows two such systems from the operator side. Google GGC and Meta MNA are hosted inside the same access network, but each platform controls its own delivery relationship, mapping and content policy. They are not services supplied by one commercial CDN.

From 5 August to 4 September 2026, named GGC assets represented 72% of the delivery included in the Google portal split. From 29 August to 5 September, the Meta appliance represented 77% of its portal split. The periods and definitions differ, but the operational pattern is the same: most delivery shown in each portal used a platform-managed edge inside the access network.

SkyTel provides space, power, routing and local connectivity. Google and Meta decide what the appliances can serve, which users reach them and how traffic moves when the local system is unavailable. Independent CDNs, peering and transit remain beside them. The example shows the new division of roles: the operator connects the edge, while the traffic owner increasingly controls it.

What this changes for operators

The growth of platform-owned delivery does not remove the access operator. The operator still owns the last mile and chooses which edges and interconnection points its customers can reach. What changes is that international capacity alone no longer explains the performance or cost of the largest applications. Each platform can place and steer its delivery differently.

Network planning therefore has to begin with measured traffic rather than a catalogue of available cache products. Operators need to separate the content owner, the network serving the object, the physical ingress or local appliance, the subscriber region and the time of peak demand. Destination ASN alone is not enough because a shared CDN or cloud platform can carry another company's content.

The commercial calculation should use eligible bytes and the bottleneck that actually changes. A local appliance can reduce upstream peaks and improve delivery without reducing the bill if traffic remains below a committed transit level. It also consumes space, power, ports, internal transport and operational time, and the network must be able to carry the full load when the appliance fails.

The available models should be evaluated separately. A first-party cache or direct peering can be justified by one platform's traffic. An Open Caching system needs publishers that will use it. An operator-run CDN can serve only content the operator owns or is authorised to deliver. Each option moves a different cost and gives a different party control.

Operators also need to make themselves useful to the new builders. Cache hosting, direct peering, reliable interconnection and credible demand data can attract platform investment. The relationship is no longer only with an upstream carrier or a general-purpose CDN; it is increasingly negotiated platform by platform and sometimes service by service.

The same builders, closer to the user

The first transition moved content and cloud companies from buying international capacity to building cables and private backbones. The second moves many of the same companies from buying CDN delivery to building first-party edges and cloud delivery platforms. Both follow the same logic: once demand is large enough, infrastructure becomes part of the platform's production system.

The replacement is not uniform, but the direction is clear. Google, Meta, Netflix, Apple and ByteDance build around their own traffic. Google, Microsoft, Amazon and BytePlus also sell delivery to external customers. Akamai, Cloudflare, Fastly and other independent providers still supply shared reach, security and additional capacity. Yet for the largest flows they no longer define the edge by themselves; the traffic owner increasingly decides where and how they are used.

For operators, the question is no longer simply whether a cache is available. It is which demand is eligible, who controls the mapping, which path carries the traffic and what changes when the local system fails. The answer may be a first-party appliance, direct peering, an independent CDN or a combination of them.

The largest traffic owners have become infrastructure builders at both ends of the network. The firms building the cables are moving closer to the user.

Notes and sources

Figure 1 combines published values from different years and definitions. The 2016 figure is approximate, while 2026E is my estimate based on published growth assumptions and the recent trend, not an observed value or provider forecast.

The RIPE Atlas result is a single diagnostic snapshot: it shows the selected path, not the platform’s internal mapping logic. Figure 4 uses aggregate exports from the Google and Meta operator portals. Each percentage is calculated within that provider’s own data and should not be compared directly with the other. SkyTel authorised publication of these aggregate values.

The global bandwidth and cable-investment figures draw on TeleGeography’s State of the Network 2026, Connecting the AI Revolution, International Internet Bandwidth, 2026 cable-investment update and content-provider cable holdings list. Historical context also draws on Caoui and Steck, “Content Providers and the Deployment of Internet Infrastructure”.

Provider descriptions use primary documentation from Google, Meta, Netflix Open Connect, Microsoft Connected Cache, Amazon CloudFront, Apple Edge Cache and BytePlus CDN. Recent CDN market changes are supported by sources from Akamai, Data Center Dynamics on StackPath, Edgio’s Chapter 11 filing and Lumen’s announcement.