Granular transfer bandwidth controls per user, workspace, and or shared folder for AoC / HSTS nodes

Problem
In Aspera on Cloud, every transfer on a node runs as the single system transfer user (xfer). The node’s bandwidth controls in aspera.conf (per-transfer caps, aggregate caps, vlinks) are keyed to the system user, group or node. They can’t be scoped to the AoC user, workspace or shared folder that started the transfer. To the rate-limiting layer, every AoC user looks the same.

• An aggregate cap on xfer is shared by everyone, so one user or workspace can starve the rest.

• A per-transfer cap can’t give different users, groups or workspaces different limits.

• The only workaround is a separate node per bandwidth tier, which adds infrastructure, operational and licensing overhead.

• Changing the system user model isn’t an option, because AoC requires xfer.

Who benefits
Any organization using AoC to share data with multiple internal teams or external collaborators over a shared WAN link.

How it should work
Bandwidth policies, configured in AoC Admin and enforced by the node, scoped to any of:

1. An AoC user or group

2. A workspace

3. A shared folder or access key

Each scope would support:

• Per-transfer and aggregate caps

• Separate upload and download limits

• Hard caps, or defaults that can be locked so clients can’t override them

• Clear precedence rules (for example user, then workspace, then node default)

Why it’s useful

• Fair sharing of WAN capacity across teams and collaborators

• Protects production links from bulk transfers

• Supports tiered service levels and chargeback without extra nodes

• Stays compatible with the required xfer model