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)
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
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
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.
Note
A QoS Policy Group is region-scoped. A single group cannot span multiple regions.
By default, each account can create up to 1 QoS Policy Group per region. Contact Zenlayer support if you need a higher quota.
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.
Last updated