Summary

The first buyer is paying for failed-checkout minutes

Start with a Cape Town retailer that runs 62 stores, an online shop and a card-payment API used by in-store tablets when a queue is moved away from a fixed till. The measurable unit is not "connectivity." It is the number of checkout attempts that stay inside a South African latency and availability budget during the busiest hour of the month. If the retailer processes 3,000 online and assisted-store payment attempts in a peak hour, a one-minute endpoint stall is not an abstract outage; it is dozens of abandoned baskets, cashiers reverting to manual workarounds, fraud checks arriving late, and customer-service staff trying to explain why the site is still visible but payment confirmation is not.

That buyer has a real substitute in the first meeting. It can put the web front end and DNS behind Cloudflare, whose public network page says every service runs in every data center and advertises a global network across hundreds of cities (https://www.cloudflare.com/network/). Cloudflare has a long South African footprint: it announced Johannesburg in 2014 with latency improvements for South African users, Cape Town in 2016, and Durban in 2018 (https://blog.cloudflare.com/johannesburg-cloudflares-30th-data-center/; https://blog.cloudflare.com/cape-town-south-africa/; https://blog.cloudflare.com/durban-and-port-louis/). The same buyer can also simplify procurement by buying one business internet or transit relationship from a large carrier such as Liquid Intelligent Technologies or Dimension Data, both visible as eNetworks AS32653 upstreams in BGP.tools' public view (https://bgp.tools/as/32653).

The case for eNetworks Anycast therefore has to be narrower and sharper than "local provider good, global provider bad." The buyer is deciding whether a South African managed network with route choice, local exchange participation, support accountability and a small anycast resource is worth a premium over a global CDN that may already sit in Johannesburg, Cape Town and Durban, or a single upstream that is cheaper to procure. The premium is rational only when local failure minutes cost more than the incremental monthly network design, support and redundancy bill. For a payment endpoint, that can happen quickly. For a brochure website, it may never happen.

That distinction is the article's main valuation lens. eNetworks Anycast is valuable when the endpoint is small enough that a global CDN contract may be too broad, sensitive enough that route locality and support escalation matter, and operational enough that a generic transit line leaves too much risk in one supplier path. It is weak when the workload is mostly static content, when the buyer already has a mature multi-CDN setup, or when the application can tolerate a few minutes of rerouting pain.

AS37394 is small because the anycast job is narrow

The public record for eNetworks Anycast is deliberately modest. PeeringDB lists "eNetworks Anycast" under eNetworks Pty Ltd, with ASN 37394, the eNetworks website, an open general peering policy, five IPv4 prefixes and five IPv6 prefixes in the PeeringDB profile, but no listed public peering exchange points or interconnection facilities on that profile (https://www.peeringdb.com/net/10746). BGP.tools gives the sharper observed routing picture: AS37394 is registered to eNetworks cc, was registered on 16 November 2011, is active under AFRINIC, is classified there as a content network, originates one IPv4 prefix and one IPv6 prefix, and has AS32653 eNetworks cc as its visible upstream and peer (https://bgp.tools/as/37394). Hurricane Electric's BGP Toolkit similarly shows one IPv4 originated prefix, one IPv6 originated prefix, both RPKI valid, one observed peer, and 256 originated IPv4 addresses (https://bgp.he.net/AS37394). IPinfo also identifies AS37394 as eNetworks cc in South Africa, with 256 IPv4 addresses and AFRINIC as the registry (https://ipinfo.io/AS37394).

Those facts matter because they stop the article from pretending that AS37394 is a standalone South African CDN. It is better read as a special-purpose routing label inside the eNetworks environment. A /24 is the minimum normally routed IPv4 unit on much of the global internet. A /48 is a typical IPv6 site-scale block. That does not prove which application runs there, which customers depend on it, or how many locations announce it. It does show that the anycast asset is sized for a focused function, not for broad consumer-content distribution.

Small can be economically attractive. A payment status endpoint, DNS resolver, authentication callback, customer API, monitoring endpoint or control-plane service may need reachability and locality without needing a Netflix-scale cache. Anycast lets the same address be advertised from more than one place so routing can take a user to a nearby or surviving node. The engineering work is not only the address. It is route policy, health withdrawal, monitoring, capacity planning, DDoS behavior, escalation, and customer-specific design. A small anycast AS can therefore be useful even when its prefix count looks unimpressive.

The risk is exactly the same fact in reverse. Because public routing records show only a tiny resource and because PeeringDB does not list direct public exchange presences for AS37394, the market should not assign a broad infrastructure premium to "Anycast" as a word. The premium has to be earned by the larger eNetworks network and by the managed service wrapped around the endpoint. Without that wrapper, AS37394 is a narrow routing fact, not a durable moat.

Catchment discipline is what converts anycast into margin

The commercial value of anycast is not created when the same address is announced from more than one place. It is created when the operator can make the right users land on the right node, withdraw a bad node quickly enough, and keep the buyer's most valuable transaction inside a tolerable failure window. For a South African payment endpoint, that means catchment discipline. A Cape Town shopper on fibre, a Durban branch tablet on LTE backup, a Johannesburg call-centre user and a bank redirect path should not all be treated as one generic "South Africa" route. They sit behind different access networks, exchange fabrics, mobile paths, bank dependencies and last-mile contracts. The buyer pays for anycast only if that diversity is actively managed rather than left to default BGP luck.

This is where a small anycast resource can produce margin without being a full CDN. The provider does not need to cache every image, script and video asset in the country. It needs to keep a narrow operational address reachable from the users who matter most. In a checkout setting, that address might support token confirmation, order status, stock reservation, risk scoring or payment retry logic. In a SaaS setting, it might support authentication, tenant routing, health probes, API callbacks or a customer-facing status service. The unit of value is not aggregate traffic volume; it is avoided failure at the point where the buyer's revenue, trust or support burden changes.

The same logic explains why a global CDN can be both a substitute and an incomplete answer. Cloudflare's South African presence is a serious benchmark because the company has announced Johannesburg, Cape Town and Durban deployments and says its global network runs every service in every data center (https://blog.cloudflare.com/johannesburg-cloudflares-30th-data-center/; https://blog.cloudflare.com/cape-town-south-africa/; https://blog.cloudflare.com/durban-and-port-louis/; https://www.cloudflare.com/network/). For static and dynamic web traffic, that is a powerful default. But the payment-endpoint buyer may still ask who controls the private link to the back office, who sees the branch circuit fault, who can test failover against local access networks, and who will explain why one bank redirect path is healthy while another is not. A CDN can improve edge performance; it does not automatically become the operator of the buyer's store network, fibre diversity, voice continuity, cloud handoff and payment dependency map.

Single-upstream simplicity has the opposite shape. It can be cheaper and easier than both anycast and CDN layering, especially when the application is small or traffic is predictable. Yet it leaves the buyer exposed to one route policy and one escalation path. If the upstream has congestion into one access network, or if a route change sends payment traffic through a longer path during a local exchange issue, the buyer has fewer levers. Anycast does not magically solve that. It gives the operator a lever only if the endpoint can be announced, withdrawn and measured across more than one useful path. eNetworks' broader AS32653 evidence therefore matters more than the AS37394 prefix count: PeeringDB shows AS32653 at South African exchange fabrics and facilities, while BGP tools show many observed peers and multiple upstreams (https://www.peeringdb.com/net/4416; https://bgp.tools/as/32653; https://bgp.he.net/AS32653).

The margin question is whether eNetworks can price that operating work. A commodity internet product prices bandwidth, contract term, contention, access medium and support tier. A local anycast product should price route testing, node health, failover evidence, exchange participation, DDoS posture, local cloud adjacency and incident explanation. The retailer should not accept a vague resilience claim. It should ask for a pre-launch test in which a Johannesburg path is degraded, a Cape Town path remains healthy, a Durban branch reaches the surviving endpoint, and the provider can show the route and timing after the event. If eNetworks can sell and deliver that evidence, the premium is not a mystique around a small ASN. It is paid engineering labor attached to a measurable reduction in failed transactions.

There is also a locality angle that affects revenue quality. South African buyers increasingly have local cloud choices, including AWS in Cape Town, Microsoft South Africa North and South Africa West, and Google Cloud in Johannesburg (https://aws.amazon.com/blogs/aws/now-open-aws-africa-cape-town-region/; https://learn.microsoft.com/en-us/azure/reliability/regions-list; https://cloud.google.com/blog/products/infrastructure/heita-south-africa-new-cloud-region). That means the buyer can keep more application work in-country, but it also makes the network path between users, cloud regions, private facilities and payment partners more visible. If the application is local but the route is poor, the buyer has paid for data locality without getting operating locality. A regional anycast and managed-connectivity offer can fill that gap when it is designed around actual user catchments.

The valuation-changing uncertainty is therefore precise. AS37394 would be worth much more in the article's economic model if eNetworks can prove that the anycast address is announced from multiple South African metros or from a South African and offshore fallback combination, that unhealthy endpoints are withdrawn automatically, that customer traffic is measured by access-network catchment, and that payment or SaaS customers buy the service for revenue continuity. It would be worth much less if the address is only a legacy technical convenience, if all meaningful resilience sits in the parent network without any separate anycast behavior, or if customers never see a contracted endpoint service tied to AS37394. In one case, the small AS is a focused margin tool. In the other, it is mostly a label attached to a normal managed-network sale.

This distinction also shapes how a buyer should compare proposals. A Cloudflare-led design should be asked to show local edge behavior, origin reachability, private interconnect options and what happens when the origin or payment partner is the weak point. A single-upstream design should be asked to show route alternatives and escalation rights when that upstream is the weak point. An eNetworks Anycast design should be asked to show where the anycast value begins and where ordinary AS32653 managed connectivity begins. The best answer may combine all three: a CDN for broad web edge, local cloud for application placement, and eNetworks for route-aware connectivity and narrow endpoint resilience. The weakest answer is whichever supplier cannot explain which failure it actually owns.

The larger eNetworks network is the economic engine behind the label

The stronger public evidence sits in AS32653, the broader eNetworks network. PeeringDB describes AS32653 as eNetworks, with network notes that include ISP, network service provider, enterprise services, fibre access and hosting provider, and geographic scope marked regional (https://www.peeringdb.com/net/4416). That profile lists public peering at CINX, DINX, JINX, NAPAfrica Cape Town, NAPAfrica Durban and NAPAfrica Johannesburg, with multiple 10G entries and route-server participation across South Africa's major exchange fabrics (https://www.peeringdb.com/net/4416). It also lists interconnection facilities in Cape Town, Johannesburg, Durban and Centurion, including NTT Data sites, Teraco CT1, Teraco DB1, Teraco Johannesburg Campus and xneelo JNB1 (https://www.peeringdb.com/net/4416).

BGP observation tools reinforce the scale difference. BGP.tools shows AS32653 with hundreds of peers, four upstreams, seven downstreams, valid RPKI markers across visible prefixes, and upstream exposure to Liquid Intelligent Technologies, Dimension Data, Hurricane Electric for IPv6, and Cybersmart for IPv4 (https://bgp.tools/as/32653). Hurricane Electric's AS32653 page shows six internet exchanges, 37 originated prefixes, 40,960 originated IPv4 addresses, 411 observed peers, and 37 RPKI-valid originated prefixes (https://bgp.he.net/AS32653). IPinfo's AS32653 page identifies eNetworks cc in South Africa, shows 40,960 IPv4 addresses, 355 hosted domains and AFRINIC registry context (https://ipinfo.io/AS32653).

That is the cost-stack base behind the smaller anycast asset. The buyer is not really buying "a /24." It is buying a local operator that can reach South African exchanges, peer with many local and global networks, combine fibre, hosting, voice and managed services, and troubleshoot a path when a route turns ugly. eNetworks' own site frames the company as "Internet Service and Network Specialists," selling cloud hosting, connectivity and voice, and says its priority is technical stability and skilled support (https://www.enetworks.co.za/). Its about page says the business was established in 1999, became known for internet access, security and email systems, and built a client base around high-uptime internet services (https://www.enetworks.co.za/about-enetworks).

The economic question is whether the parent network converts that technical base into buyer-specific resilience. Peering count alone does not guarantee a good payment-endpoint experience. A network can have many peers and still have poor internal processes. But the opposite is also true: a small anycast service without a dense parent network has little bargaining power when a route or upstream fails. eNetworks Anycast is therefore a derivative asset. Its value rises and falls with AS32653's route diversity, exchange participation, operational discipline and ability to support critical buyers.

Peering changes the price of South African locality

South Africa is not a market where every local service has to hairpin through Europe by default. That matters for the economics of eNetworks Anycast. NAPAfrica says it operates IXPs in Cape Town, Durban and Johannesburg, is a not-for-profit neutral exchange point, does not charge membership, port or cross-connect fees to access its infrastructure, and allows enterprises, network operators, CDNs and cloud providers to peer locally, keeping African traffic within the continent (https://www.napafrica.net/). Teraco's NAPAfrica page says the exchange offers direct access to over 650 unique networks across more than 25 countries in the southern African region, has 6.0 Tbps of traffic, 2,319 ports, three locations and 44 Tbps of connected capacity (https://www.teraco.co.za/platform-teraco/africa-peering/).

INX-ZA adds another local fabric. Its site describes JINX, CINX, DINX and NMBINX as neutral, data-centre-agnostic, community-run internet exchange points, with JINX operating since 1996 and a 100% uptime claim (https://www.inx.net.za/). ISPA's INX-ZA page says the exchanges are 100% community driven and available 24x7x365, with JINX established in 1996, CINX in 1997 and rebooted in 2008, DINX in 2012 and NMBINX in 2023 (https://ispa.org.za/our-impact/inx-za/). The public INX member portal lists eNetworks Pty Ltd with ASN 32653 and a 2017-09-25 member date among the exchange participants (https://portal.inx.net.za/customer/details).

This infrastructure changes what the retailer or payment endpoint is buying. Without local peering, an endpoint provider can be forced into expensive transit paths and long round trips. With local exchange participation, the buyer can ask more precise questions: Which local access networks can reach the endpoint through a short path? Which CDNs and cloud providers are nearby? Which routes are private, exchange-based or transit-based? Which paths survive a single carrier fault? Which endpoints remain reachable when Johannesburg is healthy but Cape Town has a local failure, or vice versa?

Peering also changes supplier economics. The first cost saving is avoided transit, but that is not the full story. Local peering can reduce latency, lower packet loss, give operators more routing control and make failure diagnosis more local. NAPAfrica explicitly lists reduced latency, increased fault tolerance, reliable exchange of traffic, increased routing control and improved performance among IXP advantages (https://www.napafrica.net/). For a retailer, those benefits are not academic. A checkout flow may depend on short API calls to fraud scoring, bank redirect pages, inventory lookup, confirmation email and customer support software. Shaving a few milliseconds off one call is nice; avoiding a complete detour during failure is the real premium.

That is where eNetworks Anycast can be more than a small routing record. If the anycast endpoint is tied to a parent network that already sits on the relevant fabrics, the buyer can create a South African service surface that is neither entirely self-built nor entirely outsourced to a global CDN. The hard part is that this value is invisible on a simple price sheet. It has to be sold as risk-weighted economics: lower transit dependency, better local path control and faster accountable escalation.

A global CDN is a substitute, but it is not the same purchase

The strongest substitute is Cloudflare, not a weak local competitor. Cloudflare's public network page says its global network is built so every service runs in every data center, with customer traffic processed at the closest data center and no backhauling tradeoff in its stated design (https://www.cloudflare.com/network/). Its 2014 Johannesburg announcement said the South African deployment was its first data center in Africa and could reduce South African latency from over 300 ms to as low as 3 ms in measurements cited by the company (https://blog.cloudflare.com/johannesburg-cloudflares-30th-data-center/). Its 2016 Cape Town announcement said Cloudflare was expanding on existing peering at JINX and NAPAfrica Johannesburg and was joining NAPAfrica Cape Town (https://blog.cloudflare.com/cape-town-south-africa/). Its 2018 Durban and Port Louis announcement said Durban was Cloudflare's third South African deployment after Johannesburg and Cape Town (https://blog.cloudflare.com/durban-and-port-louis/).

Cloudflare can also be bought in a private-connectivity form. NAPAfrica's Cloudflare Network Interconnect page says Cloudflare partnered with Teraco to offer private secure links with fast turn-up of ports over high-performance cabling infrastructure in Johannesburg, Durban and Cape Town (https://www.napafrica.net/technical/cloudflare-network-interconnect/). For a large enterprise, that can look cleaner than paying a regional ISP to build custom route logic. The global provider brings scale, DDoS surface, web security, bot mitigation, application acceleration and a recognizable procurement story.

That does not make eNetworks irrelevant. It narrows the job. If the buyer wants broad website acceleration, WAF, bot management and global content distribution, Cloudflare or another global CDN will often be the default. If the buyer wants a South African operational endpoint, with local routing behavior, local access-provider relationships, fibre and hosting integration, voice or WAN dependency, and an engineer who understands the buyer's last-mile mix, the purchase is different. A global CDN can sit at the edge of an application; eNetworks can sit in the buyer's network operating reality.

The price comparison is therefore not CDN versus no CDN. It is multi-layer design versus single-provider convenience. A payment endpoint might use Cloudflare for the public web tier, a cloud region for application servers, eNetworks for local managed connectivity and anycast reachability, and a separate bank or payment processor path. A small SaaS firm might choose Cloudflare only. A retailer with branch connectivity and hosted voice might value a provider that can see the branch link, the data-center handoff and the endpoint route in one escalation chain.

The judgment should stay practical. eNetworks Anycast is not likely to beat Cloudflare on global scale. It can win where South African buyer context matters more than global feature breadth: store network routes, branch failover, Cape Town versus Johannesburg catchment, local DNS or API reachability, support in business language, and the ability to combine peering with managed connectivity.

Single-upstream simplicity is cheap until the buyer needs route choice

The second substitute is less glamorous: buy one upstream and stop thinking about it. BGP.tools' AS32653 page shows Liquid Intelligent Technologies, Dimension Data, Hurricane Electric and Cybersmart in the upstream set visible for eNetworks (https://bgp.tools/as/32653). A buyer can decide that one large provider is enough. A single contract is easier for procurement, easier for accounts payable and easier for a small IT team. For a SaaS company with one cloud region, one office and modest traffic, that can be the right decision.

The trouble starts when the buyer's risk is not average availability but failure concentration. A single upstream can give a clean monthly price and still concentrate exposure in one supplier policy, one NOC escalation queue, one commercial dispute path and one route-selection view. The buyer might discover that the cheapest line is adequate during normal traffic and painful during the exact hour when a route leak, DDoS mitigation, exchange issue, fibre cut or congested handoff changes the path to payment users.

eNetworks' own material sells against that risk. The main website says eNetworks focuses on quality bandwidth, technical stability and skilled support (https://www.enetworks.co.za/). The connectivity page says it offers connectivity services from hospitality Wi-Fi to ADSL, fibre and security, and promises unshaped fibre bandwidth and efficient service (https://www.enetworks.co.za/connectivity). The Datacentrix eNetworks page describes eNetworks as a dedicated connectivity specialist and licensed ISP inside Datacentrix, holding ICASA IECNS and IECS licences, and designing, building and managing resilient network infrastructure for bandwidth-intensive applications, cloud platforms and unified communications (https://www.datacentrix.co.za/enetworks.html).

The 2017 eNetworks brochure goes further. It says the company had presence in eight data centres across South Africa, core network uptime above 99.997%, dedicated connectivity with zero contention and a minimum 99.997% SLA, and mission-critical DNS and email on three independent platforms, separate networks and two continents (https://www.datacentrix.co.za/uploads/8/3/1/1/83111140/enetworks_brochure_final_102017.pdf). Those are marketing claims from an older brochure, not audited current performance data, so they should not be treated as today's guaranteed service levels for every product. They still show how eNetworks has historically sold itself: not as lowest-cost bandwidth, but as engineered continuity.

For the Cape Town retailer, the question becomes whether that continuity is observable in the contract and architecture. Does the provider commit to multiple upstreams? Does it explain when traffic uses NAPAfrica versus INX-ZA versus transit? Does it show how an anycast endpoint is withdrawn when unhealthy? Does it test failover under load? Does the SLA cover the endpoint the buyer actually depends on, or only the access circuit? A single upstream wins when those questions do not matter. eNetworks wins only when the buyer forces those questions into the procurement process and gets better answers.

Datacentrix turns a boutique ISP into a managed-network channel

Ownership and channel matter because small network names can be hard for enterprise buyers to underwrite. eNetworks' own about page says it began in 1999 as a niche internet service provider, built expertise in access, security and email systems, and made its skills available without a call-centre or voice-interactive layer (https://www.enetworks.co.za/about-enetworks). Its BBBEE page says Datacentrix acquired eNetworks in August 2013, giving Datacentrix access to skilled resources, electronic communications networks and licences, and strengthening Datacentrix's capability to build, operate and provide network services (https://www.enetworks.co.za/bbbee-info). Datacentrix's 2013 acquisition notice said Datacentrix would acquire 100% of eNetworks, an internet and networks specialist, with an effective date of 1 May 2013 subject to conditions (https://www.datacentrix.co.za/uploads/8/3/1/1/83111140/20130827_acquisition_of_enetworks.pdf).

The current Datacentrix page positions eNetworks as an operational business unit and dedicated connectivity specialist, with service areas including edge-to-anywhere connectivity, cloud connectivity, security and secure access, digital services, voice and unified communications, colocation, and monitoring and managed connectivity (https://www.datacentrix.co.za/enetworks.html). A Datacentrix connectivity brochure says Datacentrix designs and builds network infrastructure using eNetworks as a wholly owned subsidiary and operational business unit, with eNetworks holding ICASA IECNS and IECS licences and Datacentrix remaining telco agnostic across available connectivity media (https://www.datacentrix.co.za/uploads/8/3/1/1/83111140/datacentrix_connectivity_brochure_06022020_website.pdf). A Datacentrix blog post makes the same point in prose: software-defined connectivity to cloud is built using eNetworks, with the licence and telco-agnostic position enabling access to many connectivity media (https://www.datacentrix.co.za/blog/how-software-defined-connectivity-securely-connects-desk-to-cloud).

That matters for buyer economics. A standalone niche ISP can be nimble, but a retailer or bank-adjacent SaaS company may worry about support coverage, credit, procurement rules, compliance documentation and integration with broader managed services. Datacentrix gives eNetworks a channel into larger enterprise deals where connectivity is part of a wider digital operations contract. It also changes the margin model. The network can be sold as part of managed connectivity, cloud access, colocation, unified communications and security, not merely as transit.

There is a tradeoff. A boutique provider's advantage can be personal engineering attention. A larger integrator's advantage can be process, scale and procurement acceptability. The buyer wants both. The value of eNetworks Anycast is highest when Datacentrix gives the account enterprise confidence without burying the network problem under generic managed-service layers. If escalation becomes slower or less technical, the anycast premium weakens. If Datacentrix gives the buyer one contract and keeps eNetworks engineers close to the route problem, the premium strengthens.

Locality has a compliance and customer-trust premium

South African locality is not only about speed. It is also about data, operational control and institutional trust. The Information Regulator describes the Protection of Personal Information Act as South Africa's framework to promote protection of personal information processed by public and private bodies, including conditions for lawful processing and enforcement by the regulator (https://inforegulator.org.za/). That does not mean every workload must be hosted only in South Africa. It does mean buyers handling customer identity, payment-adjacent records, support logs or account information have to understand where data is processed, who can access it and what contractual protections exist when information leaves the country.

Local cloud availability has improved the buyer's menu. AWS opened the Africa (Cape Town) Region in 2020 and said customers could deploy workloads and store data in South Africa under the af-south-1 region (https://aws.amazon.com/blogs/aws/now-open-aws-africa-cape-town-region/). Microsoft lists South Africa North in Johannesburg and South Africa West in Cape Town in its Azure region list, with South Africa North paired to South Africa West (https://learn.microsoft.com/en-us/azure/reliability/regions-list). Google Cloud announced its Johannesburg cloud region in 2024, its first cloud region in Africa (https://cloud.google.com/blog/products/infrastructure/heita-south-africa-new-cloud-region). These hyperscale regions reduce the old argument that serious workloads must leave the country.

That makes local network engineering more important, not less. If the application servers, customer database or payment-support systems are in a South African cloud region, the path between users, branches, banks, payment processors, SaaS APIs and data centres becomes a quality-control surface. A global cloud region can keep compute local, while a poor route can still add delay, jitter or failure concentration. A CDN can keep static content close, while an API call to the origin can still bottleneck. A local anycast endpoint can help only if it is placed, monitored and routed in a way that matches the buyer's geography.

The compliance premium is therefore practical. A retailer does not buy eNetworks Anycast because POPIA is a slogan. It buys local routing and managed connectivity because those controls can support a defensible architecture: customer requests enter locally, fail over predictably, and can be explained to auditors, banks, acquirers or enterprise clients. The same principle applies to SaaS providers selling to South African corporates. Locality can be a sales feature, but only when backed by a credible design. eNetworks' licence position, local exchange presence and Datacentrix channel are useful ingredients; they are not sufficient by themselves.

The cost stack is fibre, exchange fabric, engineering time and support

The cost stack behind eNetworks Anycast begins with access. eNetworks' connectivity page talks about fibre, dark-fibre to cross-country metro-fibre solutions, business fibre, hospitality Wi-Fi, ADSL and security (https://www.enetworks.co.za/connectivity). The cloud-hosting page says eNetworks provides Linux and Windows virtual servers, redundant hardware for dynamic server migration, scalable CPU, RAM and disk, built-in firewalling, load balancing, fast deployment and scheduled backups (https://www.enetworks.co.za/cloud-hosting). The voice page shows another recurring-service layer, advertising end-to-end VoIP, per-second billing, itemised billing and number porting, with example South African fixed and mobile rates (https://www.enetworks.co.za/voice).

This range matters because anycast is rarely bought alone. The buyer may need a business fibre circuit, backup wireless, hosted firewall, private cloud handoff, DNS, monitoring, voice failover and a public endpoint. Each layer adds revenue opportunity and operational cost. The margin comes from bundling engineering knowledge across layers. The risk is that each extra layer creates another place for support to fail.

Support is visible in the company's public posture. The older eNetworks site says support staff handle queries and emphasizes no call-centre or voice-interactive systems in its founding story (https://www.enetworks.co.za/about-enetworks). The 2023 eNetworks code of conduct says its Electronic Communications Network Monitoring Centre operates 24 hours a day, seven days a week, and that a dedicated customer-service centre handles customer queries and service problems, while the call centre is available Monday to Friday from 08h00 to 18h00 (https://www.datacentrix.co.za/uploads/8/3/1/1/83111140/enetworks_code_of_conduct_2023.pdf). That distinction is important for buyers: 24x7 network monitoring is not the same as 24x7 account support, and a payment-endpoint buyer needs to know which escalation path applies at midnight.

Exchange fabric is another cost and value layer. NAPAfrica says access is free of membership, port and cross-connect fees, but that does not mean peering is free to operate (https://www.napafrica.net/). Routers, optics, data-centre presence, engineers, monitoring, route filtering, RPKI practice, DDoS response and change management still cost money. AS32653's PeeringDB and BGP records show a network participating in multiple exchanges and facilities, which implies ongoing operational expense (https://www.peeringdb.com/net/4416; https://bgp.he.net/AS32653).

The buyer should therefore not ask only for the cheapest megabit. It should ask what is inside the megabit: how many handoffs, which facilities, what route policy, which failover tests, what health checks, what time-to-withdraw for an unhealthy anycast node, what support channel and what post-incident reporting. If eNetworks prices those answers into a managed service, the premium can be justified. If the buyer only needs commodity internet, the same answers may be overkill.

Competitors can copy coverage faster than they can copy accountability

Competition comes from several sides. The hyperscale cloud providers now give local compute and storage options, with AWS in Cape Town, Microsoft in Johannesburg and Cape Town region structures, and Google in Johannesburg (https://aws.amazon.com/blogs/aws/now-open-aws-africa-cape-town-region/; https://learn.microsoft.com/en-us/azure/reliability/regions-list; https://cloud.google.com/blog/products/infrastructure/heita-south-africa-new-cloud-region). Cloudflare offers a global network with South African data-center history and private interconnect options through Teraco (https://www.cloudflare.com/network/; https://www.napafrica.net/technical/cloudflare-network-interconnect/). Large carriers and access providers can sell a single pipe, a managed SD-WAN product or a cloud-connect service. Local ISPs can compete on support and price.

Coverage is not enough to defend eNetworks. South Africa's exchange ecosystem makes local presence more attainable for serious networks, not less. NAPAfrica's scale, INX-ZA's community-run exchanges and Teraco's interconnection model lower the barriers for content, cloud and access networks to meet locally (https://www.teraco.co.za/platform-teraco/africa-peering/; https://www.inx.net.za/). Internet Society Pulse listed 11 South African IXPs in PeeringDB as of June 2026, including NAPAfrica sites, JINX, CINX, DINX and NMBINX, showing that local interconnection is a broad ecosystem rather than one provider's private advantage (https://pulse.internetsociety.org/en/ixp-tracker/country/ZA/).

The harder thing to copy is accountability in a mixed environment. A global CDN may own the edge but not the branch link. A hyperscaler may own the region but not the retailer's last mile. A carrier may own the access circuit but not the application endpoint. A systems integrator may own the project plan but not the BGP table. eNetworks' potential advantage is that, through Datacentrix and its own network, it can sit between those layers and make one practical design work.

That advantage is fragile. If the buyer's architecture moves entirely into a hyperscale cloud with managed global load balancing and CDN security, local ISP differentiation shrinks. If the buyer has strong internal network engineers, they may prefer to buy transit and exchange ports directly. If Cloudflare, AWS, Microsoft or Google can provide the same operational assurance with better dashboards and procurement terms, the local premium falls. If South African access networks keep improving peering and default paths, the need for bespoke route design declines for simpler workloads.

But high-dependency buyers are not simple workloads. A payment endpoint, retail checkout surface or business-critical SaaS tenant may need someone to explain why Telkom users in one province are timing out while mobile users are fine, why a payment redirect path is leaving the country, why an upstream is preferred during failure, or why a DNS endpoint is reachable from Johannesburg but not Durban. Competitors can copy POP locations. They cannot instantly copy the trust earned by answering those questions well.

Market signals should change valuation, not sit in a caveat

The public material leaves major gaps. eNetworks does not disclose revenue, product-level gross margin, customer concentration, exact anycast use cases, node count, current SLA attainment, DDoS incident history, churn, support-ticket volume or contract length. AS37394's public routing record is narrow. PeeringDB for AS37394 has no listed public exchange points, while the parent network has extensive exchange participation (https://www.peeringdb.com/net/10746; https://www.peeringdb.com/net/4416). That means valuation cannot rest on the word "Anycast" alone.

The better approach is to treat uncertainty as a pricing variable. If AS37394 is used only for internal DNS or a small control-plane function, the article's economic premium should be modest. If eNetworks can show multiple active South African announcement sites, clear health-check withdrawal, branch-to-endpoint failover tests and paying enterprise customers, the premium rises. If most resilience depends on AS32653 and there is no independent anycast catchment strategy, the value belongs to managed connectivity rather than the anycast label.

Public third-party records provide some positive market signals. INX's member page lists eNetworks among exchange participants (https://portal.inx.net.za/customer/details). PeeringDB lists AS32653 across South Africa's main exchange fabrics and facilities (https://www.peeringdb.com/net/4416). BGP.tools and HE both show a substantial parent network compared with the small anycast AS (https://bgp.tools/as/32653; https://bgp.he.net/AS32653). The Datacentrix page confirms licence-backed managed connectivity and cloud-connect positioning (https://www.datacentrix.co.za/enetworks.html).

There are also caution signals. Some official eNetworks web pages carry older copyright or dated brochure material, so a buyer should ask for current service descriptions rather than relying on archived marketing language (https://www.enetworks.co.za/; https://www.datacentrix.co.za/uploads/8/3/1/1/83111140/enetworks_brochure_final_102017.pdf). The B-BBEE page contains historical claims that should be refreshed against current certificates and procurement documents, even though the linked certificate names eNetworks (Pty) Ltd among Datacentrix entities (https://www.enetworks.co.za/bbbee-info; https://www.enetworks.co.za/images/Datacentrix_BEE_Certificate.pdf). ICASA's transfer-control page for eNetworks licences to DCX Bidco is another reminder that licence and control records matter in South African telecom procurement and should be verified in live diligence (https://www.icasa.org.za/legislation-and-regulations/applications-for-the-transfer-of-control-of-an-individual-electronic-communications-service-and-individual-electronic-communications-network-service-licences-from-enetworks-pty-ltd-to-dcx-bidco-pty-ltd).

The market signal that would most improve the case is customer proof around critical endpoints. A named retailer, payment processor, SaaS platform or bank-adjacent buyer using eNetworks for resilient local endpoint design would turn a plausible mechanism into a stronger commercial thesis. The signal that would most weaken it is evidence that AS37394 is dormant, single-site, or operationally irrelevant to customer contracts. Until then, the correct stance is not skepticism for its own sake. It is a conditional premium: pay for demonstrated route resilience, not for a label.

The premium is for South African operating control, not for generic bandwidth

For the Cape Town retailer, the final decision can be reduced to a procurement sentence: pay eNetworks when the cost of losing South African route control is higher than the cost of managed local resilience. That sounds narrow, but it covers a meaningful slice of buyers. Retailers with store networks, payment gateways with customer-facing callbacks, SaaS companies selling to South African corporates, call centres with hosted voice, logistics platforms with branch devices and hospitality groups with guest Wi-Fi all have moments when "the internet is up" is not a sufficient answer.

eNetworks' public materials fit that operating-control story. The company sells connectivity, cloud hosting, voice, monitoring and managed services (https://www.enetworks.co.za/connectivity; https://www.enetworks.co.za/cloud-hosting; https://www.enetworks.co.za/voice). Datacentrix positions eNetworks as a licensed specialist for resilient network infrastructure, cloud platforms and unified communications (https://www.datacentrix.co.za/enetworks.html). AS32653 gives the routing base, with peers, exchanges, facilities and upstream diversity visible in public records (https://bgp.tools/as/32653; https://www.peeringdb.com/net/4416). AS37394 gives a small anycast marker that can be valuable if used for the right endpoint (https://bgp.tools/as/37394; https://bgp.he.net/AS37394).

The substitutes remain formidable. Cloudflare can provide global security and CDN reach with South African locations. AWS, Microsoft and Google give local cloud regions. A single carrier can provide cheaper simplicity. A buyer should not buy eNetworks Anycast because it sounds locally patriotic or technically sophisticated. It should buy it only if the design answers measurable questions: how many payment attempts remain under the latency budget during a failure; how quickly an unhealthy node is withdrawn; which South African networks reach the endpoint locally; which provider takes the first call at 02h00; and what incident evidence the buyer receives afterward.

That is why the smallness of AS37394 is a feature of the analysis. It prevents inflated claims. eNetworks Anycast is best understood as a focused resilience instrument attached to a broader South African managed network. Its commercial value is highest when a buyer's application is too operationally important for one cheap upstream, too local and account-specific for a generic CDN-only answer, and too small or specialized to justify building a full in-house anycast practice. In that zone, the South African resilience premium is real. Outside that zone, eNetworks has to compete like every other network provider: on price, service and proof.