Cloudflare Queues now let you lock a queue to a specific jurisdiction—EU, US, or FedRAMP—when you create it. The jurisdiction is set at creation via the --jurisdiction flag in the Cloudflare CLI or the jurisdiction field in the Create Queue API, and it cannot be changed later. This gives you a built‑in data‑residency boundary that aligns with regulations such as GDPR or FedRAMP.
Enabling jurisdiction on a new queue
Use the CLI flag to bind a queue to a region, for example:
cf queues create --queue-name my-eu-queue --jurisdiction euOr call the API with a JSON payload that includes the jurisdiction key:
{
"queue_name": "my-eu-queue",
"jurisdiction": "eu"
}Supported values are eu, us, and fedramp. The setting is immutable after the queue exists.
Operational impact
Because the data location is fixed, you must decide the appropriate jurisdiction before provisioning. Existing queues cannot be retrofitted, so any change requires creating a new queue and migrating messages. The three supported regions may affect latency and routing; workloads that span multiple regions need to account for the chosen queue’s location when designing data pipelines.
Automation scripts, IaC templates, and CI/CD pipelines should be updated to include the --jurisdiction flag or the API field, preventing accidental default‑region deployments.
Security and compliance considerations
Binding a queue to a jurisdiction ensures that messages are stored and processed only within the selected data centers, reducing exposure to cross‑border data transfer requirements. This helps satisfy GDPR residency clauses for EU queues and FedRAMP‑moderate requirements for FedRAMP queues.
Jurisdictional control does not replace existing security controls. You still need to enforce proper IAM policies, encrypt data at rest and in transit, and monitor access logs. Mis‑configuring the jurisdiction at creation could lead to non‑compliant data placement, so validation steps should be added to deployment pipelines.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Review any regulatory or contractual data‑location mandates that apply to your workloads. Update queue‑creation scripts to include the appropriate --jurisdiction flag or API field. Audit existing queues for compliance; if a queue resides in the wrong jurisdiction, plan a migration to a newly created, correctly‑located queue. Finally, incorporate jurisdiction checks into your CI/CD validation to catch omissions before they reach production.
