Data Center under machine traffic: is self-protection now a security feature, not a performance one?

[#1]

Hi DC lovers,

The traffic profile of a Data Center instance has changed shape, and most capacity planning hasn't caught up.

We still size instances around concurrent users. But the requests that actually hurt increasingly aren't human: CI pipelines polling for issue status, automation rules fanning out, reporting tools pulling the same JQL every fifteen minutes, integration middleware syncing both ways, and now AI assistants and MCP connectors that will happily walk an entire project via the REST API because nobody told them not to. None of that shows up in a concurrent-user estimate, and all of it lands on the same nodes.

The tool for this has been in the product since Jira 8.6, and hardly anyone I meet has it configured. Rate limiting lets Jira self-protect against automated integrations sending requests in huge bursts, and it deliberately targets only external REST API traffic, so people moving around the UI aren't affected. The design is sensible — token bucket, 429 with Retry-After. The reason nobody turns it on is fear: no admin wants to be the person who broke the release pipeline at 2am.

I've started treating it as a security control rather than a performance one, and that changes the conversation. As a tuning knob it's optional and competes with "just add a node." As a security control it's the same category as an account lockout: it bounds the blast radius of a compromised token or a runaway script. A leaked PAT with no expiry against an unlimited API is an exfiltration channel; the same token against a configured limit is a slow, noisy, logged nuisance you'll notice.

That also lines up with where DC has been heading generally — secure endpoint defaults, tighter anonymous access, the move from "hardening is what you configure afterwards" to "the safe posture is the default."

Questions for people running larger instances:

1. Is rate limiting enabled in your production instance? If not, what's blocking it — fear of breakage, no baseline data, or no mandate?
2. How did you set the initial limits? I'd like to hear from anyone who derived them from real access-log analysis rather than guessing.
3. Do you treat service accounts differently from human ones? Every instance I audit has integration users with far more privilege and volume than any person, governed by identical rules.
4. Has your security team ever asked for this, rather than the platform team?

For context, I do DC upgrades and migrations for a Solution Partner, so my sample skews toward instances that were already in trouble. Happy to be told this is over-thought.

Thanks!

--Hugo