# Bandwidth Cap ## What it is The **bandwidth cap** is an optional upper bound on how many Mbps an EIP is allowed to push. It is a shaping limit, not a meter — it does not change what you pay for a given billing method, it just prevents traffic from going above the configured ceiling. On the EIP creation form, the cap appears as *"(Optional) Set bandwidth cap"* with a hint that the **default bandwidth upper limit is 10 Gbps**. If you don't set a cap, you get that default. The 10 Gbps ceiling is the default on the console, not a platform-wide hard limit. ZEC fully supports EIPs larger than 10 Gbps — if your workload needs it, open a ticket and the ceiling can be raised on your account. *** ## Why it matters for each billing method The cap plays a different role depending on what's metering your traffic: * **Data Transfer** — nothing in the meter protects you from a runaway workload: you pay per GB, so a saturated line is an expensive line. The cap is your runaway-prevention. * **Flat Rate** — the cap *is* what you pay for. You select a bandwidth in Mbps, that's your cap, and traffic is clamped at it. No bursting above it. * **Aggregated Burstable 95th** — per-EIP caps bound the per-EIP contribution to the aggregated 95th. Useful when one instance shouldn't dominate the pool. *** ## Directional caps Ingress (inbound) and egress (outbound) caps are sized independently. On the console you usually set one symmetric value; on the API you can split them. If you leave a direction's cap unset, it defaults to the platform default (10 Gbps on the console). For Flat Rate, the cap you select is the bandwidth you pay for. *** ## Validation rules Two hard rules apply to every direction: * **Minimum bandwidth is 0.1 Mbps.** Smaller values are rejected. * **Cap must be ≥ the billing method's minimum.** The platform rejects values that conflict with the billing configuration. On the EIP form specifically, the console shows the cap in Mbps with a default upper-limit hint of 10 Gbps — that is the ceiling applied when you do not explicitly set a cap. *** ## Limit modes — loose vs. tight The cap has a shape. You can choose one of two behaviors for how shaping acts: * **Loose mode.** The shaper allows short bursts approaching the cap before clamping down. Good for workloads that spike briefly. * **Tight mode.** The shaper splits bandwidth across flows evenly, converging on a stable throughput. Good when fairness between flows matters. In both modes, traffic cannot exceed the cap. *** ## How to tell you are being rate-limited Because the ZEC data plane is fully self-developed, every EIP exposes a dedicated **dropped** counter that only increments when shaping has actually discarded packets at the cap. If `dropped` is zero, nothing was ever shaped — you have not hit the cap in the window you're looking at. If it is non-zero, you did. The counter is exposed through the EIP monitoring metrics, split by direction: | Metric | Meaning | | ------------------------------------------------ | -------------------------------------------------------------- | | `ingress_dropped_packets` | Inbound packets dropped because the ingress cap was hit | | `egress_dropped_packets` | Outbound packets dropped because the egress cap was hit | | `ingress_dropped_bytes` / `egress_dropped_bytes` | Same thing, in bytes | | `ingress_dropped_bits` / `egress_dropped_bits` | Same thing, in bits (handy for comparing against the Mbps cap) | Every counter is **per EIP, per direction**. They pair with `ingress_fwd_packets` / `egress_fwd_packets` (the packets the EIP actually forwarded), so a useful signal is the ratio: ``` drop_rate = dropped_packets / (fwd_packets + dropped_packets) ``` A sustained non-zero drop rate on egress means traffic wants to exceed your egress cap and is being trimmed. The fix is either to raise the cap (if the workload genuinely needs the headroom) or to reduce the load upstream. Because the counter only exists once shaping has run, a missing or always-zero value is the *expected* state for most EIPs — it is not a bug. *** ## Console defaults Putting the pieces together for the most common case — creating an EIP with Data Transfer, not touching any cap fields — you get: * Bandwidth cap defaults to **10 Gbps** unless you set it explicitly (raisable by ticket for larger workloads). * Limit mode is the platform default (loose). * For Flat Rate, the cap you select is the bandwidth you pay for. *** ## When to raise the cap, when to lower it * **Raise the cap** if you're on [Data Transfer](/welcome/elastic-compute/networking/01-overview/03-data-transfer.md) or [Aggregated Burstable 95th](/welcome/elastic-compute/networking/01-overview/05-aggregated-95th.md) and your workload needs more headroom. * **Lower the cap** if you're on [Data Transfer](/welcome/elastic-compute/networking/01-overview/03-data-transfer.md) and want a hard runaway-prevention. A 500 Mbps cap means even if something goes wrong you cannot move more than about 5.4 TB in a day. * **For Flat Rate**, the cap is the bandwidth you're buying — pick the size that matches your workload. --- # 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/07-bandwidth-cap.md?ask= ``` 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.