（这仅适用于 WCF 中继。对于混合连接来说，消息不收费。）
一般情况下，会使用与上述相同的用于中转实体（队列、主题和订阅）的方法来计算中继的可计费消息。 但是，有一些明显的区别。
向 Azure 中继发送消息被视为“完全通过”式发送，发送到接收消息的中继侦听器。 不会将其视为一个先发送到 Azure 中继然后再传递给中继侦听器的操作。 针对中继侦听器的请求-应答模式服务调用（最大 64 KB）将生成两条可计费消息：一条用于请求的可计费消息，一条用于应答（假设响应也是 64 KB 或更小）的可计费消息。 这不同于使用队列在客户端和服务之间进行协调。 如果使用队列在客户端和服务之间进行协调，则同一请求-答复模式要求先将请求发送到队列，然后再将其从队列交付到服务，或者取消其排队。 随后就是将响应发送至另一队列，再从该队列交付至客户端，或者取消排队。 如果始终使用同一大小作为假设吞吐量（最高 64 KB），则此中介型队列模式会生成 4 条计费消息。 收费的消息数两倍于使用中继实现同一模式时的消息数。 当然，使用队列来实现此模式好处更多，例如持久性和负载分级。 这些好处可能产生额外费用。
使用 netTCPRelay WCF 绑定打开的中继不将消息视为单条消息，而视为流经系统的数据流。 使用此绑定时，只有发送方和侦听器可以识别发送和接收的单条分帧消息。 对于使用 netTCPRelay 绑定的中继，所有数据都会被视为用于计算可计费消息的数据流。 在这种情况下，服务总线每隔 5 分钟计算一次通过单个中继发送或接收的数据总量。 然后会将该数据总量除以 64 KB，得出该中继在该时段的计费消息数。
配额
配额名称作用域说明值 每个 Azure 订阅的中继命名空间数Azure 订阅-1000 中继上的并发侦听器数实体（混合连接或 WCF 中继）系统会拒绝后续的附加连接请求，且调用代码会收到异常。25 服务命名空间中所有中继终结点的并发中继连接数命名空间-5,000 每个服务命名空间的中继终结点数命名空间-10,000 NetOnewayRelayBinding 和 NetEventRelayBinding 中继的消息大小命名空间会拒绝超过这些配额的传入消息，且调用代码会收到异常。64 KB HttpRelayTransportBindingElement 和 NetTcpRelayBinding 中继的消息大小命名空间对消息大小没有限制。无限制