> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/networking/qos-policy-group.md).

# QoS Policy Group

A **QoS Policy Group** lets you apply a shared bandwidth limit across multiple IP resources — Elastic IPs (EIP), IPv6 addresses, and unmanaged egress IPs — within the same region. Instead of managing per-IP caps individually, you group the IPs together and set a single aggregate limit that the entire group shares.

## How It Works

When you create a QoS Policy Group, you choose a region and set a bandwidth limit. Every IP resource you add to the group contributes traffic toward — and is constrained by — that shared cap. If the combined traffic from all members approaches the limit, the platform enforces it according to the rate limit mode you have selected.

All IP resources in a group must belong to the same region as the group itself. An IP resource can be a member of only one QoS Policy Group at a time.

## Rate Limit Mode

Traffic for a QoS Policy Group is forwarded through a fleet of distributed forwarding servers. Because any server in the fleet may handle traffic for a given IP, the platform must decide how to distribute the bandwidth cap across those servers. The two modes differ in this initial allocation strategy.

### LOOSE (default)

| Phase             | Behavior                                                                                                                                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Initial limit** | Each forwarding server is set to the **full group cap** — e.g. 1,000 Mbps cap, 4 servers → each server starts at 1,000 Mbps. A single flow can immediately reach the full cap. |
| **Trigger**       | When the **total bandwidth across all IPs reaches or exceeds the group cap**.                                                                                                  |
| **After trigger** | The platform redistributes each server's limit based on its current traffic share.                                                                                             |

The total may briefly overshoot the cap by a few seconds before redistribution takes effect.

**Use LOOSE when:** your workload depends on a single high-throughput connection reaching the full cap as fast as possible — for example, large file transfers, video streaming, or latency-sensitive tunnels.

### STRICT

| Phase             | Behavior                                                                                                                                                                                          |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Initial limit** | Each forwarding server is set to `group cap ÷ number of cluster nodes` — e.g. 1,000 Mbps cap, 4 servers → each server starts at 250 Mbps. A single flow is initially limited to one node's share. |
| **Trigger**       | When **any single node reaches its initial per-node limit** — even if the overall total has not yet reached the group cap.                                                                        |
| **After trigger** | The platform redistributes each server's limit based on its current traffic share.                                                                                                                |

The total never exceeds the group cap. Use multiple parallel flows (≥ 10 recommended) to aggregate across nodes and approach the full cap quickly.

**Use STRICT when:** the group cap is a hard cost or isolation boundary that must never be exceeded — for example, controlling shared egress costs or enforcing a contracted bandwidth ceiling.

## Supported IP Resource Types

| Resource Type | Description                                             |
| ------------- | ------------------------------------------------------- |
| **EIP**       | Elastic IPv4 addresses bound to ZEC instances           |
| **IPv6**      | Public IPv6 addresses assigned to ZEC instances         |
| **Unmanaged** | Egress IPs not directly managed through the ZEC console |

## Constraints

* The bandwidth limit is enforced independently on both **inbound and outbound** traffic at the same value — for example, a 10 Gbps cap means up to 10 Gbps inbound and up to 10 Gbps outbound. Per-direction caps are not supported. The minimum value is **10 Gbps (10,000 Mbps)**.
* All member IP resources must be in the **same region** as the policy group.
* One IP resource can belong to **at most one** QoS Policy Group. Adding a resource that is already in another group returns an error.

{% hint style="info" %} <mark style="color:blue;">**Note**</mark>

* <mark style="color:blue;">A QoS Policy Group is region-scoped. A single group cannot span multiple regions.</mark>
* <mark style="color:blue;">By default, each account can create up to 1 QoS Policy Group per region. Contact Zenlayer support if you need a higher quota.</mark>
  {% endhint %}

## Traffic Monitoring

You can query bandwidth usage for a QoS Policy Group over a specified time range, with separate metrics for inbound and outbound traffic. Monitoring data is available in granularities of 1 minute, 5 minutes, 1 hour, or 1 day.