TTechclick ⚡ XP 0% All lessons
Zscaler · ZIA · Bandwidth ControlInteractive · L1 / L2 / L3

Zscaler ZIA Bandwidth Control — Make the Town-Hall Zoom Win the Link

The whole branch is on one internet pipe. A company town-hall Zoom is starting just as half the floor opens YouTube. Without QoS, everyone's call stutters. ZIA Bandwidth Control fixes this in the cloud — guarantee the conferencing app its slice, cap streaming, and let business traffic borrow the rest when the link is quiet. Let's build it, watch it work, and verify the throttle.

📅 2026-05-31 · ⏱ 12 min · 3 live demos · worked 200 Mbps example · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Make a town-hall Zoom survive a congested branch link. Configure ZIA Bandwidth Control end to end — define location bandwidth, build classes, set guaranteed vs maximum percentages and verify throttling in 12 minutes.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Define the link

Set the location's download/upload Mbps — skip this and rules do nothing.

 2

Build classes

Five predefined buckets + a custom class from URL categories & cloud apps.

 3

Guaranteed vs Max

The borrowing model — burst when idle, throttle to the floor under contention.

 4

Verify & gotchas

Prove the throttle in the dashboard. Why your rule "isn't working".

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. You set a bandwidth rule capping streaming at 10%, but nothing changes. What did most engineers forget?

Answered in Path 1 — Define the link. (Spoiler: a percentage of an undefined link is a percentage of nothing.)

2. A Web Conferencing class has Guaranteed 30%, Maximum 100%. The link is quiet. How much can it use?

Answered in Path 3 — Guaranteed vs Max.

3. Your bandwidth rule is perfect, but roaming laptop users still aren't throttled. Why?

Answered in Path 4 — Verify & gotchas. This one trips up everyone once.

Most engineers think…

"Bandwidth Control is just 'block streaming' — I'll cap YouTube to 10% and I'm done."

Wrong, and that half-idea is why people complain "my bandwidth rule does nothing". The real engine is a borrowing model: you don't just cap the bad traffic — you guarantee a floor to the good traffic, and let everyone burst into idle capacity. A class with a 10% cap and a class with a 30% guarantee behave completely differently the moment the link gets busy. Master the guarantee-vs-maximum pair and you can make a town-hall Zoom survive a saturated branch without ever "blocking" anything.

What Bandwidth Control actually is

Think of your branch's internet link like the water supply to an office building. One pipe feeds everyone. When the whole floor opens the tap at once, pressure drops and the important sink — say, the canteen — runs dry. QoS is the plumbing that guarantees the canteen tap a minimum flow no matter how many other taps are open.

Zscaler Bandwidth Control is exactly that plumbing, run in the ZIA cloud instead of on a hardware box. Because all the branch's web traffic already passes through a ZIA Service Edge, Zscaler can see every flow and shape it there. It uses window shaping and throttling instead of brute-force packet drops, so business apps stay smooth.

Crucially, it shapes the traffic ZIA forwards — your web egress through Zscaler. It does not manage your MPLS, your LAN, or traffic that bypasses Zscaler. It's link-level QoS for the Zscaler-forwarded pipe, not a replacement for WAN QoS.

👉 So far: Bandwidth Control = cloud QoS on a location's Zscaler-forwarded link. Next, the four moving parts you'll configure — tap each card.

The four moving parts

Every Bandwidth Control setup is these four pieces, in order. Get them in the wrong order and the rule silently does nothing. Tap each card.

🚰
Location bandwidth
tap to flip

The download/upload Mbps you tell ZIA the link is worth. Percentages mean nothing without it. So what: this is the #1 forgotten step — set it first.

🧺
Bandwidth class
tap to flip

A bucket of URL categories + cloud apps (e.g. Streaming Media). Five are predefined; you add custom ones. So what: a class is the "what" a rule shapes.

🧱
Bandwidth rule
tap to flip

Matches a class (+ locations, time, protocols) and sets Min. and Max. %. So what: the rule is where the guarantee-vs-cap decision lives.

♻️
Default rule
tap to flip

The catch-all evaluated last — everything not matched lands here. You can edit it but not delete it. So what: it's your safety net for un-classed traffic.

① Define the link — the step everyone skips

Here's the rule that breaks more bandwidth deployments than anything else: a percentage of an undefined link is a percentage of nothing. If you don't tell ZIA how big the location's pipe is, your "cap streaming at 10%" has no 100% to measure against, so it never throttles. Set the link size before you write a single rule.

👉 L2/L3 note: set the value to ~70–80% of the link's real speed (and shave another 10–15% for TCP/IP overhead). Over-stating the link means your "100%" is bigger than the pipe — guarantees then fail under real load.
Admin path — define the location's bandwidth (ZIA Admin Portal)
Administration > Location Management > Locations > [Bengaluru-Branch] > Edit
  ⮑ Enable "Enforce Bandwidth Control"
  ⮑ Download (Mbps): 160      # branch link is 200 Mbps real; use ~80%
  ⮑ Upload (Mbps):   160
Save  ▸  Activate
Expected result
Location "Bengaluru-Branch" : Bandwidth Control = ENABLED
  Download limit = 160 Mbps   Upload limit = 160 Mbps
# Now 100% in every rule = 160 Mbps. Sub-locations can "Use Location Bandwidth"
# (shared, first-come-first-serve) or "Override" with their own Mbps.

Symptom

Sneha at Infosys built a perfect rule to cap Streaming Media at 10%. Users on the Bengaluru branch still saturate the link with video. "The rule isn't working."

Likely cause

The location's bandwidth was never defined. With no download/upload Mbps set, ZIA has no total to apply percentages to, so shaping is effectively off.

DiagnosisAdministration > Location Management > Locations > [branch] → check Download/Upload Mbps are set + "Enforce Bandwidth Control" is on
Fix

Set Download and Upload to ~70–80% of the real link speed and enable Bandwidth Control on the location. Save and Activate.

Verify

Re-test: the Bandwidth Control dashboard now shows Streaming Media flattening at its cap during busy hours.

Quick check · Q1 of 10

A bandwidth rule caps Streaming Media at 10% but never throttles. The class definition and rule look correct. What's the first thing to check?

Correct: a. Bandwidth rules shape a percentage of the location's defined link. With no Mbps set, 10% of an undefined link is meaningless and nothing is throttled. Define the location bandwidth first — it's the single most common cause of "my rule does nothing".
Figure 1 — Where Bandwidth Control sits on the ZIA egress
A left-to-right architecture diagram. Branch users send web traffic over a forwarding tunnel to a ZIA Service Edge. Inside the Service Edge, the traffic is classified into bandwidth classes and shaped against the location's defined download and upload limits, applying guaranteed minimum and maximum percentages, before egressing to the internet. A note states it shapes only ZIA-forwarded traffic, not MPLS or LAN. Shaping happens in the ZIA cloud — on the Zscaler-forwarded link only Branch users Bengaluru · 200 Mbps Zoom · M365 · YouTube GRE/IPSec/ZCC ZIA Service Edge ① Classify → bandwidth class URL category + cloud app → Streaming / M365 / … ② Shape against location limit apply Guaranteed (Min.) % + Maximum % Location bandwidth = the 100% everything is measured against 🌐 Internet business apps stay smooth ✓ In scope: ZIA-forwarded web traffic the pipe through Zscaler is what gets shaped ✗ Out of scope: MPLS · LAN · direct-egress traffic bypassing Zscaler is not shaped here No hardware shaper at the branch — the ZIA edge does the QoS for the Zscaler pipe.
Bandwidth Control lives inside the ZIA Service Edge. The location's defined link is the 100% every percentage is measured against.
ZIA Policy Simulator Location & Bandwidth Lab

② Build the buckets — bandwidth classes

A bandwidth class answers "shape what?". Zscaler ships five predefined classes and lets you build your own from URL categories and individual cloud apps. Predefined: File Share, Finance, General Surfing, Sales/Support Apps, Streaming Media. General Surfing is the catch-all — it grabs everything not matched by the other named buckets, and you can't edit it.

For a Zoom/Teams priority, the predefined buckets aren't enough — you build a custom class. You pick the Web Conferencing URL category and the specific cloud apps (Zoom, Microsoft Teams, Webex) so the class catches exactly the conferencing traffic and nothing else.

Admin path — create a custom "Web Conferencing" bandwidth class
Policy > Bandwidth Control > Bandwidth Classes > Add Bandwidth Class
  ⮑ Name: Web-Conferencing
  ⮑ URL Categories:  Web Conferencing
  ⮑ Cloud Apps:      Zoom, Microsoft Teams, Cisco Webex
Save  ▸  Activate
Expected result
Bandwidth Class "Web-Conferencing" created
  Matches: URL category [Web Conferencing] + cloud apps [Zoom, Teams, Webex]
# Predefined classes still available: File Share, Finance, General Surfing,
# Sales/Support Apps, Streaming Media. General Surfing = catch-all (non-editable).

Symptom

Rahul at TCS wants to prioritise Teams calls, but his rule using the predefined "Sales/Support Apps" class doesn't catch Teams traffic at all.

Likely cause

Teams isn't in that predefined bucket. The predefined classes are coarse — to shape conferencing precisely you need a custom class with the Web Conferencing category + the Teams/Zoom cloud apps.

DiagnosisPolicy > Bandwidth Control > Bandwidth Classes → confirm which categories/cloud apps each class actually contains
Fix

Create a custom Web-Conferencing class with the Web Conferencing URL category and the Zoom/Teams/Webex cloud apps, then point the rule at it.

Verify

Web Insights now logs Teams flows under the Web-Conferencing class, and the dashboard shows that class consuming bandwidth.

Pause & Predict

A class has Guaranteed 30% and Maximum 100%. Right now the link is almost empty. Before you read on: how much bandwidth can this class actually use this instant? Type your guess.

Answer: Up to 100%. The Guaranteed 30% is only a floor under contention — when nobody else is competing, the class is free to borrow idle capacity all the way up to its Maximum. The guarantee only kicks in the moment higher-priority traffic shows up. That's the whole borrowing model — Path 3.
Quick check · Q2 of 10

Which class is the predefined catch-all that grabs everything not matched by the other named buckets — and can't be edited?

Correct: b. The five predefined classes are File Share, Finance, General Surfing, Sales/Support Apps and Streaming Media. General Surfing is the catch-all and is non-editable — anything not in another class falls into it.

③ Guaranteed vs Maximum — the borrowing model

Now the heart of it. A bandwidth rule sets two numbers on a class:

The magic: a class can burst above its guarantee up to its maximum when others are idle, but is throttled back down to its guarantee the moment higher-priority traffic competes. Idle bandwidth is shared out by rule priority. That's why the same rule looks like "unlimited" at 3 a.m. and "capped" at 11 a.m.

▶ Watch the link fill — then watch classes throttle

A 200 Mbps branch (defined as 160 Mbps in ZIA). Press Play to walk the stages, then Squeeze it to start the town-hall + a streaming surge and see the guarantees enforce.

① QUIETMorning. Only Web-Conferencing is active — it borrows idle bandwidth up to its Maximum
▼
② BUSYTown-hall Zoom starts; M365 sync runs; streaming surges — total demand > 160 Mbps
▼
③ CONTENTIONGuarantees enforce: Conferencing floor 30%, M365 30%; Streaming throttled to its 10% Max
▼
④ RESULTTown-hall stays smooth; streaming is squeezed, not blocked. QoS held
Press Play to step through a quiet-to-busy link. Then press Squeeze it to trigger contention.
Figure 2 — One flow's journey: classify → apply Min/Max → forward or throttle
A left-to-right flow. A new flow arrives and is classified into a bandwidth class. The matching bandwidth rule reads its guaranteed minimum and maximum percentages. A decision checks whether the link is under contention. If idle, the flow may borrow up to its maximum and is forwarded. If under contention, the flow is throttled down to its guaranteed minimum. Unmatched flows fall to the default rule. Same rule, two outcomes — it all depends on contention New flow e.g. a Zoom call Classify → Web-Conferencing Read rule Min 30% · Max 100% Link busy? idle Borrow → up to Max forwarded fast contention Throttle → to Min floor still guaranteed No class match? → the Default Rule (Min 0% · Max 100%) catches it, evaluated last.
The guarantee is a floor, the maximum is a ceiling. Idle → borrow up to the ceiling; contention → throttle to the floor.

The worked 200 Mbps branch

Let's make Sneha's town-hall survive. The Bengaluru branch link is 200 Mbps; we defined it as 160 Mbps in ZIA (80%). Here's a clean allocation:

Bandwidth rules (evaluated top-down; default rule is last)
Rule 1  Web-Conferencing    Min 30%  Max 100%   # Zoom/Teams town-hall — protected
Rule 2  Microsoft 365       Min 30%  Max 100%   # Outlook/SharePoint sync — protected
Rule 3  Streaming Media     Min  0%  Max  10%   # YouTube/Netflix — squeezed, never starves others
Rule 4  Large Files         Min 10%  Max  50%   # big downloads — bounded
Default Rule  (Any)         Min  0%  Max 100%   # everything else — catch-all, evaluated last
The math during a busy town-hall (160 Mbps link)
Guaranteed floors:  Conf 30% = 48 Mbps   M365 30% = 48 Mbps   Large 10% = 16 Mbps
Streaming is capped at Max 10% = 16 Mbps  (can't climb higher even if it wants to)
→ Town-hall Zoom is guaranteed 48 Mbps minimum and borrows more if M365 is idle.
→ When the link is quiet at night, Conferencing/M365 can each burst toward 100%.

Pause & Predict

In the table above, Streaming Media has Max 10% but Min 0%. During a quiet night with nothing else running, can streaming use 80% of the link? Predict before reading on.

Answer: No. The Maximum is a hard ceiling applied at all times — busy or idle. Streaming can never exceed 10% (16 Mbps on a 160 Mbps link), even with the whole pipe free. The Min 0% just means it gets no guaranteed floor under contention. Max caps; Min guarantees — they're independent.
Quick check · Q3 of 10

On a 160 Mbps (defined) link, a Web Conferencing class has Guaranteed 30%, Maximum 100%. During a busy contention window, what is its guaranteed floor?

Correct: b. Under contention the Guaranteed (Min.) % is the reserved floor: 30% of 160 Mbps = 48 Mbps. The Maximum 100% only matters when the link is idle and the class can borrow up to the full pipe.
The over-allocation trap

Don't push guarantees so high they sum past 100%. If you guarantee Conferencing 40%, M365 40%, Sales 30% and Large Files 20%, that's 130% of a link that only has 100% — the math can't hold and the floors fail under load. Best practice: raise a Min. by 5% at a time, test, then repeat. Keep total guarantees comfortably under 100% so there's idle room to borrow from.

Figure 3 — Guaranteed % vs Maximum %: the same classes, idle vs contention
Two horizontal bar lanes for a 160 Mbps link. The top lane, link idle, shows Web Conferencing and Microsoft 365 each able to borrow up to high usage while Streaming stays capped at its 10 percent maximum. The bottom lane, under contention, shows Web Conferencing and Microsoft 365 throttled down toward their 30 percent guaranteed floors and Streaming pinned at its 10 percent cap. A note explains borrowing versus throttling. 160 Mbps link — borrow when idle, throttle to the floor under contention 🌙 LINK IDLE — classes borrow up to their Maximum Web Conferencing — borrowing ~60% (Max 100%) M365 ~30% Streaming pinned at 10% Max — can't borrow more 🔥 UNDER CONTENTION — throttle to Guaranteed floors Conf floor 30% = 48 Mbps ✓ town-hall safe M365 floor 30% = 48 Mbps Streaming still 10% Max = 16 Mbps — squeezed, not blocked Guaranteed % = floor under contention · Maximum % = ceiling at all times Borrowing makes the link efficient; guarantees make business apps safe.
Top lane = quiet link (classes borrow). Bottom lane = busy link (classes snap back to their guaranteed floors). Streaming never moves — its cap holds in both.
QoS Allocation Calculator Lab Bandwidth Rule Builder

④ Verify, and why your rule "isn't working"

Never claim a class is throttled because the rule "looks right". Prove it. The truth lives in two places: the Bandwidth Control dashboard (top bandwidth classes and usage over time) and Web Insights logs (which class each transaction matched). For standard reports, Analytics > Interactive Reports.

Verification path — confirm the throttle is real
Analytics > Bandwidth Control dashboard
  ⮑ Watch "Streaming Media" flatten at ~16 Mbps during busy hours (its 10% Max)
  ⮑ Watch "Web-Conferencing" never drop below ~48 Mbps under load (its 30% floor)
Analytics > Web Insights > Logs
  ⮑ Filter the user/location → "Bandwidth Class" column names the matched class
Expected output (Web Insights extract)
User: sneha@infosys.example  Location: Bengaluru-Branch
  flow: teams.microsoft.com   Bandwidth Class: Web-Conferencing   action: shaped(floor 30%)
  flow: youtube.com           Bandwidth Class: Streaming Media     action: throttled(cap 10%)
# If the class column is blank/"General Surfing" for Teams → your custom class didn't match.

Symptom

Aditya at Wipro has a flawless bandwidth rule, link defined, classes correct. Branch users on GRE are throttled fine — but roaming laptop users on ZCC are never shaped.

Likely cause

Bandwidth Control enforces against a location with a defined link. Roaming users on Z-Tunnel 2.0 don't map to a branch's bandwidth-defined location, so the per-location shaping doesn't apply to them.

DiagnosisWeb Insights → compare a branch (GRE) user vs a roaming (ZCC) user → only the location-mapped user shows a Bandwidth Class action
Fix

Scope expectations: Bandwidth Control is per-location link QoS. For roaming users, manage app experience with ZDX/forwarding design, not branch bandwidth rules. Confirm GRE/IPSec locations have the link defined and "Enforce Bandwidth Control" on.

Verify

Branch users show shaping in the dashboard; roaming users don't — which is expected, not a bug.

▶ Prove the throttle — the verification walk

Karthik confirms the cap is real instead of guessing. Play the healthy verification, then Squeeze it to see the "class blank" failure mode.

① DEFINEConfirm the location's Download/Upload Mbps are set + Bandwidth Control enabled
▼
② DASHBOARDBandwidth Control dashboard — Streaming flattens at its 10% cap during peak
▼
③ WEB INSIGHTSLogs show each flow's matched Bandwidth Class + shaped/throttled action
▼
④ CONFIRMEDFloors held, caps held — QoS proven, not assumed
Press Play for a clean verification. Then press Squeeze it to see the common mismatch.
Quick check · Q4 of 10

Branch (GRE) users are shaped correctly, but roaming ZCC laptop users are never throttled by the same bandwidth rule. Most likely reason?

Correct: b. Bandwidth Control shapes a location's defined link. Roaming users on Z-Tunnel 2.0 aren't tied to a branch's bandwidth-defined location, so the per-location guarantees/caps don't reach them. That's expected behaviour, not a misconfiguration.
Pro tips that save tickets

Upload and download are separate. A video upload to a partner portal can saturate the upstream even when download looks fine — set both limits. Shave overhead. ~5–7% of TCP traffic is overhead; defining the link at 70–80% of the real speed leaves headroom so guarantees actually hold.

Pause & Predict

A flow that doesn't match any of your custom bandwidth classes arrives at peak hour. What shapes it, and what are its Min/Max? Predict before reading the reveal.

Answer: The default rule shapes it. Out of the box it's Min 0% / Max 100%, evaluated last after all your numbered rules. It's the safety net for un-classed traffic — tighten its Max if you want un-classed traffic to never crowd out your guaranteed apps.

Common-mistake flips — tap the fix

These four cause the bulk of "bandwidth control isn't working" tickets. Tap to reveal the first thing to check.

🚰
No effect at all
tap

Location bandwidth not defined → percentages have no total. So what: set Download/Upload Mbps + "Enforce Bandwidth Control" first.

➗
Floors fail under load
tap

Guarantees sum past 100% — the link can't honour them. So what: keep total Min % under 100%, raise by 5% and test.

⬆️
Uploads still choke
tap

You set download but not upload. So what: upload and download are independent — define and shape both.

💻
Roaming users unshaped
tap

Z-Tunnel 2.0 roaming users aren't on a bandwidth-defined location. So what: it's per-location QoS — expected, not a bug.

Verify it worked — the dashboard that ends the argument

Whatever you changed, open Analytics → Bandwidth Control dashboard during a busy window. A capped class should flatten at its Maximum; a guaranteed class should never dip below its floor. Cross-check Web Insights → Logs for the per-flow Bandwidth Class column. If the dashboard disagrees with what you expected, your class definition or location link is wrong — not the cloud.

Figure 4 — ZIA Bandwidth Control cheat-sheet (screenshot this)
A grid of six cheat-sheet tiles. Tiles cover: step one define the location link in Mbps; step two build classes from URL categories and cloud apps with five predefined classes; step three set guaranteed minimum and maximum percentages; the borrowing model where idle borrows and contention throttles; verification via the Bandwidth Control dashboard and Web Insights; and the top gotchas. A footer states the golden rule that a percentage of an undefined link is nothing. Build order + key facts (the one card to keep) ① Define the link Locations → Download/Upload Mbps use ~70–80% of real speed skip this = rules do nothing ② Build classes URL categories + cloud apps 5 predefined + custom General Surfing = catch-all ③ Min vs Max % Guaranteed = floor (contention) Maximum = ceiling (always) keep total Min < 100% ♻️ Borrowing model idle → borrow up to Max contention → throttle to Min default rule last: 0% / 100% ✓ Verify Bandwidth Control dashboard Web Insights → Bandwidth Class cap flattens · floor holds ⚠ Top gotchas upload ≠ download (set both) roaming Z-Tunnel = not shaped shapes ZIA pipe, not MPLS/LAN GOLDEN RULE A percentage of an undefined link is a percentage of nothing. Define the link first, then shape. Rule match = Classes AND [Location Groups OR Locations] AND Time AND Protocols | rules run in ascending order
Six tiles, one golden rule. Screenshot this — it's the card you'll glance at when a "bandwidth isn't working" ticket lands.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from Zscaler Help docs + community Q&A, scoped to ZIA Bandwidth Control. For a live prod issue, paste your dashboard/Web Insights export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

What are the two percentage values a Bandwidth Control rule sets on a class?

Correct: a. A rule sets a Guaranteed (Min.) % — the floor under contention — and a Maximum % — the ceiling applied at all times. Together they drive the borrowing model.
Q6 · Apply

Priya needs a town-hall Zoom to survive a busy 200 Mbps branch while YouTube is squeezed. Which allocation is sound?

Correct: a. Guarantee the conferencing class a floor (30%) so the town-hall holds under contention, and cap streaming with a low Maximum (10%) so it's squeezed but not blocked. Option c inverts the priorities; b is heavy-handed; d is impossible (sums past 100%).
Q7 · Apply

You need a class that catches exactly Zoom, Teams and Webex — the predefined classes don't. What do you build?

Correct: d. Custom bandwidth classes are built from URL categories and cloud apps. Add the Web Conferencing category plus the specific conferencing cloud apps. You can't edit General Surfing (c) — it's the non-editable catch-all.
Q8 · Analyze

A class with Max 10% never exceeds 16 Mbps on a 160 Mbps link, even at 3 a.m. with the pipe empty. Is this a bug?

Correct: b. The Maximum % is a ceiling enforced busy or idle. Only the Guaranteed (Min.) % is conditional (a floor under contention). A capped class staying at its cap during idle is correct behaviour — that's what the Max is for.
Q9 · Analyze

Branch GRE users are shaped correctly, but roaming ZCC users on Z-Tunnel 2.0 are never throttled by the same rule. Root cause?

Correct: c. Bandwidth Control shapes the link of a location with a defined download/upload limit. Roaming users on Z-Tunnel 2.0 don't map to a branch's bandwidth-defined location, so the per-location guarantees and caps don't apply — expected, not a bug.
Q10 · Evaluate

An engineer proposes guaranteeing Conferencing 40%, M365 40%, Sales 30% and Large Files 20% on a single 160 Mbps link. Sound design?

Correct: a. Guaranteed minimums can't exceed the link. 40+40+30+20 = 130% of a 100% pipe — the floors can't all be met under contention. Keep total guarantees comfortably under 100%, leave idle room to borrow, and increment by 5% with testing.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why does a class with Guaranteed 30% / Maximum 100% look "unlimited" at night but "capped" at noon? Then compare to the expert version.

Expert version: The Maximum (100%) lets the class borrow all the idle bandwidth when nobody else is competing — so at night it looks unlimited. The Guaranteed (30%) is only a floor that kicks in under contention — at noon, when other classes compete, this class is throttled down toward its 30% floor. Same rule, two behaviours, driven entirely by whether the link is busy. If your answer mentioned "borrow when idle, floor under contention", you've got it.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Bandwidth Control
A ZIA policy that shapes how much of a location's internet link each traffic class can use — cloud-enforced QoS on the Zscaler-forwarded pipe.
QoS (Quality of Service)
Controlling which traffic gets bandwidth priority so business-critical apps stay usable when the link is congested.
Location bandwidth
The download/upload Mbps you tell ZIA a location's link is worth — the 100% every rule percentage is measured against.
Bandwidth class
A named bucket of URL categories and cloud apps that a rule shapes together. Five are predefined; you add custom ones.
Bandwidth rule
Matches a class (plus locations, time, protocols) and sets its Guaranteed (Min.) and Maximum bandwidth percentages.
Guaranteed (Min.) %
The floor a class is reserved during contention — it always gets at least this share of the defined link.
Maximum %
The ceiling a class can ever use, enforced at all times, even when the link is idle.
Contention
When total demand exceeds the link and multiple classes compete for bandwidth at once — when guarantees enforce.
Borrowing
A class using more than its guaranteed floor by consuming idle bandwidth other classes aren't using, up to its Maximum.
Default rule
The catch-all bandwidth rule (Min 0% / Max 100%) evaluated last — editable but not deletable.

📚 Sources

  1. Zscaler Help — About Bandwidth Control (borrowing model, location bandwidth requirement, default rule Min 0% / Max 100%, rules evaluated in ascending order). help.zscaler.com/zia/about-bandwidth-control
  2. Zscaler Help — About Bandwidth Classes (five predefined classes: File Share, Finance, General Surfing, Sales/Support Apps, Streaming Media; custom classes from URL categories + cloud apps; General Surfing catch-all). help.zscaler.com/zia/about-bandwidth-classes
  3. Zscaler Help — Bandwidth Control Policy Example & Configuring / Adding Rules to the Bandwidth Control Policy (Microsoft 365 40% / Streaming 10% Max 25% worked example; Min./Max. fields; match logic Classes AND [Location Groups OR Locations] AND Time AND Protocols). help.zscaler.com/zia/bandwidth-control-policy-example
  4. Zscaler — Bandwidth Control Deployment and Operations Guide (verification via Bandwidth Control dashboard + Web Insights; 10–15% overhead; raise Min by 5% and test; remote/Z-Tunnel users not enforced; upload vs download). help.zscaler.com/.../bandwidth-control-deployment-and-operations-guide
  5. Zscaler Community (Zenith) — "Bandwidth Control and Z-Tunnel 2.0" (real practitioner thread on per-location enforcement vs roaming users). community.zscaler.com — Bandwidth Control and Z-Tunnel 2.0
  6. Zscaler product page + data sheet — Bandwidth Control (window shaping/throttling to avoid packet drops; prioritise Microsoft 365, Zoom, Teams, Salesforce over recreational traffic). zscaler.com/products-and-solutions/bandwidth-control
  7. Zscaler ZDTA Certification Exam Guide (2025/2026) — Connectivity & Platform Services objectives (policy frameworks, traffic shaping). zscaler.com — ZDTA Certification

What's next?

You can now make business apps win a congested branch link without blocking anything. Next, zoom out to the whole policy stack — how Cloud Firewall, DNS Control, URL Filtering and IPS chain together inside one ZIA hop, and where Bandwidth Control sits among them.

Next · ZIA Security Controls Deep-Dive → Practice on exam.techclick.in →