IP Transit Vs Peering In Malaysia: A Cost Model For A 10G Network

IP transit vs peering comes down to one calculation. Take the share of your traffic that can be exchanged locally, multiply it by what you pay to carry that traffic today, and subtract the fixed cost of reaching an exchange. This guide works through the model for a 10G Malaysian network, with blanks for your own prices.

IP transit is paid access to the whole internet through an upstream provider, usually billed per megabit at the 95th percentile. Peering is the direct exchange of traffic between two networks, usually settlement-free, over an internet exchange or a private link. Our FAQ on transit and peering covers the basics.

The Two Costs Peering Replaces

Peering removes two costs for the traffic it carries.

The first is transit. Every megabit sent to a network you peer with no longer passes through your upstream provider, so offloaded traffic reduces the transit bill directly.

The second is long-haul capacity. Many Malaysian networks carry traffic to Singapore to hand it over. Open DC’s managing director, Wong Weng Yew, has put the cost of a 10G link from Delapan in Kedah to Singapore in the region of RM100,000 a year (TechWire Asia, 23 Sep). It is an indicative figure for a link lease, not a transit price, but it shows what the journey costs. Traffic exchanged in Malaysia does not need to make it.

In return, peering adds fixed costs: an exchange port, a cross-connect, router interfaces and optics, and either rack space at the exchange or backhaul to reach it.

Six Inputs And One Formula

Every price in the model is yours to fill in. We give only the traffic figures for the example.

In the example, A × B is 2,400 Mbps moved off transit. That means every RM1 of transit rate per Mbps per month is worth RM28,800 a year to this network (2,400 × 12). Multiply that by your own rate to get the transit term. If the offload also lets you defer one 10G long-haul link, D adds about RM100,000 at the indicative Delapan figure.

If your current transit rate is above the break-even figure, peering pays for itself on transit alone. For networks outside the Klang Valley and Johor Bahru, the long-haul term can matter as much as the transit term, so do not leave it out.

The table below shows how the transit term scales with the peerable share for the same 6,000 Mbps network.

Estimating Your Peerable Share

The peerable share is the input most networks guess. It is better measured, in six steps:

Export flow data (NetFlow, sFlow or IPFIX) for a typical week, including the evening peak.
Group traffic by destination network, identified by its autonomous system number (ASN), inbound and outbound.
Match those networks against the list of networks connected to DE-CIX Malaysia, counting route-server peers and the networks you could peer with bilaterally.
Add Google’s public services. DE-CIX is one of the first Internet Exchange operators globally with Google VPP Gold status, so traffic to services such as Search, YouTube and Workspace can move to the exchange. See peering with Google in Malaysia.
Sum the matched traffic at peak and divide by A. That is B.
Size the port for that traffic with enough headroom that the evening peak does not congest it.

Keep the first-year figure conservative. A model that assumes every matched network peers from day one will overstate the saving, so many teams show three cases: conservative, expected and upper.

Peering Locations In Malaysia

DE-CIX Malaysia gives access in three regions, so a network can peer close to where its traffic starts.

Private Links Suit High-Volume Peers

Public peering through the route servers, which DE-CIX calls GlobePEER, suits most traffic. For a single network that sends several gigabits at peak, a dedicated link is cleaner to manage and monitor. VirtualPNI gives you a private connection to that network over your existing DE-CIX port, with its own capacity and no new physical cross-connect. In the model, treat that traffic as peered: it leaves transit, and its cost sits inside E.

Cloud traffic needs its own row. Public application traffic, private cloud workloads and partner connections take different paths and carry different security requirements. If a large share of your traffic goes to AWS or Azure, a private on-ramp such as DirectCLOUD belongs in the model as a separate line, not inside the public peering share.

Five Mistakes That Skew The Model

Using average traffic. Transit is billed on the peak, so model the 95th percentile, not the daily mean.
Counting one direction. Inbound content usually dominates for access networks; outbound matters for hosting and content networks. Count both.
Ignoring the return path. If your prefixes lack route objects or RPKI records, peers may filter them and return traffic stays on transit.
Undersizing the port. A small port congested at peak can cost more in support than it saves.
Dropping transit entirely. Peering reaches the networks at the exchange, not the whole internet. Keep transit for everything else and as a backup path.

The Case Is Strongest For Northern Networks

The long-haul term matters most outside the main metros. A network in Penang or Kedah that hands its traffic over in Singapore pays for each gigabit twice: once in long-haul capacity and again in transit. Local peering in Penang today, and in Kedah once the D8-1 node is live, can reduce both.

Run the model twice, once for your largest site and once for the whole network. The second run shows whether a port in a second region pays for itself. Before moving material traffic, test the BGP sessions, prefix filters and failover behaviour, then check the real peerable share against the model after a few weeks of live data.

Interconnect in Malaysia. Scale Across ASEAN. Connect Globally.

Working Hours: Monday – Friday, 9am – 6pm

Call Us: +603 9212 5961

Email Us: enquiry@de-cix.my