# Network Types

Every EIP picks a **network type** at creation time. Network type is fixed for the lifetime of that object — switching network types means creating a new EIP on the other network and cutting over.

It matters for billing because **different networks have different per-Mbps prices**. It matters for performance because the network type decides which autonomous system actually carries your packets between the POP and the rest of the internet.

The available values are:

| Network Type     | Who operates it                                       | Typical use                                      |
| ---------------- | ----------------------------------------------------- | ------------------------------------------------ |
| **Premium BGP**  | Zenlayer AS21859 + AS4229 backbone                    | Real-time, interactive, low-latency user traffic |
| **Standard BGP** | Zenlayer, blended transit (Cogent, regional carriers) | CDN origin egress, VPN, backup, bulk traffic     |

The console shows only the network types available in your selected region.

***

## Zenlayer BGP — Standard vs. Premium

Zenlayer operates the `BGP` network type in two tiers. Both are ZEC-native; the difference is which autonomous systems carry your packets.

### Premium BGP — AS21859 edge + AS4229 backbone

The premium tier uses **AS21859** as the public-facing transit ASN at the POP, and **AS4229** as the private inter-POP backbone. The split is visible in public routing data, and it explains where the latency and reach advantages come from:

| Source                                  | AS21859 (peering edge)                                                                    | AS4229 (backbone)                                                       |
| --------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| PeeringDB declared traffic              | 10–20 Tbps                                                                                | 20–50 Tbps                                                              |
| PeeringDB declared IPv4 / IPv6 capacity | 20 000 / 10 000 prefixes                                                                  | 100 000 / 50 000 prefixes                                               |
| Public peering exchanges                | \~170                                                                                     | \~24 (selective, with hyperscalers)                                     |
| Scope                                   | Global                                                                                    | Global                                                                  |
| Traffic ratio                           | Heavy outbound                                                                            | Heavy outbound                                                          |
| Peering policy                          | Selective                                                                                 | Selective                                                               |
| Network type (PeeringDB)                | Content                                                                                   | Content                                                                 |
| Upstreams observed                      | Arelion (1299), Cogent (174), NTT (2914), Tata (6453), Lumen (3356)                       | Arelion (1299), PCCW Global (3491), NTT (2914), GTT (3257), Zayo (6461) |
| Notable direct peers                    | 800+ peers — regional ISPs across APAC/EMEA (Bharti Airtel, Viettel, Etisalat, many more) | Google, AWS, Microsoft, Cloudflare, Meta, Apple, Netflix, ByteDance     |

Read that table as two layers of one product:

* **AS4229 is where the hyperscaler peering lives.** It is present at fewer public IXes (\~24) but those are the high-value ones where Google/AWS/Microsoft/Meta/Apple/Netflix/ByteDance peer directly. Traffic to those destinations lands in one AS hop.
* **AS21859 is the broader peering fabric.** It joins \~170 exchanges and peers with hundreds of regional ISPs — the networks that actually carry last-mile traffic to users in Southeast Asia, the Middle East, Africa, and LATAM.

What that buys you on the wire:

* Lower median RTT for most destinations reachable via a direct peer.
* Tighter p95/p99 latency, since backbone transport does not share fate with the public internet between POPs.
* Shorter AS paths to APAC and EMEA consumer networks.

**Pick Premium BGP for:** real-time and interactive workloads — gaming, VoIP, trading, SaaS APIs, user-facing web traffic where tail latency matters.

### Standard BGP — Zenlayer-operated, blended upstreams

Standard BGP is still Zenlayer's network — same POP, same EIP primitive, same set of billing methods — but the path under the EIP is built from **more cost-effective upstreams and transit arrangements**. You give up some of the peering density and path length that Premium gets from AS4229 + AS21859; in exchange the per-Mbps price is materially lower.

Characteristics:

* Uses a blend of commercial transit in addition to private peering.
* Routing typically takes more AS hops for some destinations compared with Premium.
* Connectivity and latency are not as tight — the degradation is most visible on consumer last-mile networks in Asia-Pacific.
* Per-Mbps price is noticeably lower than Premium.

**Pick Standard BGP for:** CDN origin egress, VPN backhaul, backup and replication, batch ETL, software distribution, log/telemetry egress — any workload where bytes dominate and an extra few milliseconds of RTT does not change the user experience.

### Regions where Standard BGP is available

Standard BGP is currently exposed on these ZEC regions:

| Area                   | Region             | POP              |
| ---------------------- | ------------------ | ---------------- |
| Americas               | `na-west-1`        | Los Angeles      |
| Americas               | `na-central-2`     | Dallas           |
| Americas               | `na-east-1`        | Washington, D.C. |
| Americas               | `na-south-1`       | Miami            |
| Europe and Middle East | `europe-central-1` | Frankfurt        |
| Europe and Middle East | `europe-south-1`   | Marseille        |

Premium BGP is available on all ZEC regions. If a region you need is not listed above, Premium BGP is the default path; the console shows only the network types applicable to the region you pick.

### The quick rule

* Does an extra 20–40 ms of RTT break an SLO or degrade UX? → **Premium BGP**.
* Is the workload dominated by bytes, not by handshake latency? → **Standard BGP**.

***

## How this interacts with billing

The network type is picked at creation — it is an attribute of the EIP. Once picked:

* **It sets the per-Mbps unit price.** Each network has its own rate card. Premium BGP is at the top; Standard BGP is lower. The billing *method* ([Data Transfer](/welcome/elastic-compute/networking/01-overview/03-data-transfer.md) / [Flat Rate](/welcome/elastic-compute/networking/01-overview/04-flat-rate.md) / [Aggregated 95th](/welcome/elastic-compute/networking/01-overview/05-aggregated-95th.md)) is orthogonal to the network type — each method bills against the rate of whatever network you picked.
* **It decides the path and the latency.** Switching meter does not move traffic; switching network type does.
* **It is fixed per object.** If you need to change network type, create a new EIP on the other network and migrate.

***

## Rule of thumb

* **User-facing, interactive, global?** Premium BGP.
* **CDN / VPN / backup / bulk egress?** Standard BGP.

Start with the network type that matches the workload's latency tolerance, and let the billing method decide how that bandwidth is metered on top.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview/02-network-types.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
