5G MEC vs CDN: When to Use Each for Edge Workloads

# 5G MEC vs CDN: When to Use Each for Edge Workloads

MEC and CDN both push compute and content closer to the user. Sales decks treat them as competing categories. They are not. They solve different problems, at different distances from the user, for different traffic types. Picking between them — or correctly using both — comes down to understanding where each actually sits in the network.

What a CDN Actually Is

A CDN is a globally distributed cache plus increasingly capable compute, hosted at internet exchange points (IXPs), tier-1 transit POPs, and in some cases inside ISP networks. A user request hits a DNS-resolved POP, the POP serves cached content or executes lightweight compute (Cloudflare Workers, Akamai EdgeWorkers, Fastly Compute@Edge), and only cache misses traverse to origin.

Latency floor: usually 10–30 ms from end user to POP, depending on geography and ISP routing. The POP is on the public internet — users reach it through their ISP, then through public peering or transit.

CDNs scale to billions of users because they are simple at the data plane: HTTP cache and a sandboxed compute runtime. The economic model is mature.

What MEC Actually Is

MEC — Multi-access Edge Computing — sits inside the operator network, behind the User Plane Function (UPF) in 5G or the SGW/PGW in LTE. The MEC host is reached via the operator's transport network, not the public internet. Traffic from a UE to a MEC application traverses RAN to UPF to MEC and back, all inside the mobile network's data plane.

Latency floor: 5–15 ms in well-deployed mid-band 5G, RAN-to-MEC. The radio is the dominant component. With URLLC configurations and a co-located MEC host, sub-5 ms RTT is achievable.

The key architectural piece is local breakout at the UPF. The 5GC SMF can install rules that send certain traffic (matched on DNN, S-NSSAI, or destination IP) to a local UPF that breaks out to the MEC application instead of routing back to a central data center. This is what makes MEC actually low-latency — without local breakout, you still go through a centralized UPF and gain nothing.

The Latency Math That Decides

For a user on 5G mid-band:

• UE to gNB: ~1–4 ms one-way (depends on scheduling, slot timing).
• gNB to local UPF (co-located or near-edge): ~1–5 ms.
• UPF to MEC application (same host or rack): <1 ms.
• MEC processing + return path: same numbers in reverse.

Total RTT: 5–20 ms is typical for a MEC deployment.

For the same user reaching a CDN:

• UE to gNB: ~1–4 ms.
• gNB through operator transport, UPF, peering or transit: 10–30 ms.
• CDN POP processing: 1–5 ms.

Total RTT: 20–60 ms typical for a major CDN.

MEC saves 15–40 ms. That delta only matters for specific workloads.

When Each Wins

CDN wins:

• Static content delivery, video streaming, web acceleration. The whole reason CDNs exist. MEC adds nothing.
• API caching, edge auth, geo-routing. Workers/EdgeWorkers do this at scale. MEC has no advantage.
• Anything that the user reaches across multiple networks. CDN works for users on home Wi-Fi, mobile, corporate. MEC only helps users on the operator hosting the MEC.
• Scale to global audience. CDN POPs everywhere. MEC is per-operator-per-region.

MEC wins:

• Real-time control of physical systems. Industrial automation, AGV control, AR/VR rendering offload — workloads where 30 ms vs 10 ms is the difference between working and not.
• Cellular-attached IoT with strict latency. Connected vehicles for V2X cooperative perception. Drone control beyond visual line of sight. Remote operation of equipment.
• Localized data processing for privacy or sovereignty. Video analytics on factory cameras processed inside the operator network, never traversing public internet.
• Workloads tied to a specific physical site. Stadium AR experiences, port logistics, hospital workflows where the users are on the operator's 5G and the application is geographically pinned.
• Network-aware applications using 5G APIs. CAMARA QoD, location, slicing — these are operator APIs that are exposed at the MEC, not from a CDN.

Deployment Models

Operator MEC: the operator builds and runs the MEC platform. AWS Wavelength, Azure Edge Zones, GCP Distributed Cloud Edge are operator-cloud partnerships where the cloud provider's stack runs in the operator's edge. Developers deploy AWS/Azure/GCP services that happen to be physically close to UEs. Private MEC: an enterprise's private 5G has its own MEC alongside the private UPF. This is the cleanest model for industrial deployments — the data plane never leaves the campus. Federated MEC: multiple operators expose MEC capabilities through standardized APIs (GSMA Open Gateway, ETSI MEC). Still maturing.

A Practical Decision Framework

Ask:

1. What is the latency budget end-to-end? If it is greater than 50 ms, you do not need MEC — CDN is fine.
2. Are users known to be on a specific operator's 5G? If no, MEC's benefits are limited to the subset of users on that operator.
3. Is the workload local to a physical site? If yes (factory, port, hospital, stadium), MEC fits naturally.
4. Does the application need network APIs (QoS-on-demand, location, slice)? Those live at MEC, not CDN.
5. Do you need global scale and cache hit ratios? CDN.

The two are also genuinely complementary. A connected-vehicle service might use MEC for safety-critical messaging and a CDN for map tile delivery. A stadium might use MEC for live AR overlays and a CDN for the regular streaming app. Use each for what it does best, instead of picking sides.