## Summary During incident https://gitlab.com/gitlab-com/gl-infra/production/-/issues/16423 we saw a big increase in requests with the goal of causing an outage (DDoS). While Cloudflare DDoS protections eventually blocked the majority of traffic, we were still affected, causing errors and latency for customers. ## Related Incident(s) Originating issue(s): https://gitlab.com/gitlab-com/gl-infra/production/-/issues/16423 ## Desired Outcome/Acceptance Criteria Investigate updating our global rate-limit rules from using the action `block` to `throttle`. https://blog.cloudflare.com/new-rate-limiting-analytics-and-throttling/ The new `throttle` action does not wait for the time-window before blocking requests, which can be very helpful in situations like this where we want to block requests as soon as possible. It might also be an improvement in user experience as it won't block traffic for the full monitoring window. ## Associated Services ~"Service::Cloudflare" ## Corrective Action Issue Checklist * [x] Link the incident(s) this corrective action arose from * [x] Give context for what problem this corrective action is trying to prevent re-occurring * [x] Assign a severity label (this is the highest sev of related incidents, defaults to 'severity::4') * [x] Assign a [priority](https://about.gitlab.com/handbook/engineering/infrastructure/team/reliability/issues.html#issue-priority) (this will default to 'Reliability::P4' but should match the severity of the related incident) * [x] Assign a [service label](https://about.gitlab.com/handbook/engineering/infrastructure/team/reliability/issues.html#service-labels)