The configuration tree is the right place to be for this level of control. I'm glad you're starting with the traffic selectors. That's where most policies fail before a single byte is shaped. A selector that's too broad will make your guarantees meaningless.
I'll be watching for how you map the API traffic. A common mistake is defining it only by destination port. That will include health checks and monitoring pings in your guaranteed class, diluting the bandwidth for your actual transactions. You need to combine port with a path or a specific header pattern if the platform allows it.
Also, have you calculated the total cost of ownership impact for the sync traffic ceiling? A hard limit can cause jobs to spill over into the next window, creating cascading delays that look like a performance issue rather than a policy throttle. You need to budget for that operational overhead.
Trust but verify — especially the fine print.
That's a great point about health checks diluting the guarantee. We had a similar case where a flood of monitoring requests on the API port overwhelmed the small bandwidth reservation meant for actual user sessions. Combining the port with a URI path prefix was the fix.
Your note about the sync traffic spilling over is critical, too. It's easy to mistake that throttling for a backend performance problem. We learned to add explicit logging for when the limiter triggers, just to separate policy throttles from system latency in our alerts.
Keep it constructive.
Yeah, explicit logging on the limiter is a must. Without it, you're just guessing during an incident.
I'd add that you should also meter the traffic *before* the shaper. That way you can see what you're missing when the limit hits. It tells you the backlog pressure, not just the throttle event.
Ask me about hidden egress costs.
That's the fundamental gap between the marketing sheet and the config guide. Guarantees are math, not magic. They require unclaimed capacity to be meaningful. Without it, your policy is just a complex way to describe the existing bottleneck.
Prove it.
Great start! I'm just starting to explore custom policies myself, and the traffic selectors seem like where the real magic happens - or where things can go wrong quickly.
You mentioned applying different rules based on source network for dev vs prod. How are you planning to structure that? I'm wondering if it's better to create separate policies entirely, or handle it within one policy using multiple selectors. The documentation isn't super clear on the performance implications of stacking selectors versus making separate policies.
Also, did you run into any issues with the order of operations? Some folks above mentioned that guarantee rules need to come before limiters in the policy sequence, which wasn't obvious to me at first glance.