Cloud Connector: Simple Multi-Cloud Routing Without the DNS Headaches
Cloudflare has introduced Cloud Connector, a new feature that lets customers route traffic from a single hostname to multiple public cloud storage providers — AWS S3, Google Cloud Storage, Azure Blob Storage, or Cloudflare R2 — without requiring those services to be the DNS target for the hostname. The tool is available in beta to all plans at no cost, with rollout beginning in August and continuing through 2024. No beta registration is required; eligible users will see the product under the Rules > Cloud Connector tab in their zone dashboard.
The feature is designed to close a longstanding gap for Free, Pro, and Business customers. Previously, routing requests for a hostname like example.com/images to an S3 bucket while keeping the rest of the site on origin web servers was a multi-step ordeal. Enterprise plans had access to Host Header and Resolve Override features, but those capabilities were withheld from other tiers due to security and abuse risks associated with Host Header modification. Some users resorted to Workers or hostname chaining as workarounds, adding complexity and operational overhead.
How configuration works
Setting up a Cloud Connector rule involves a few straightforward steps in the dashboard:
- Navigate to Rules > Cloud Connector and select your cloud provider.
- Configure the destination hostname of your object storage bucket, ensuring the URL matches the provider’s expected schema — for example,
.amazonaws.comfor AWS S3 orstorage.googleapis.comfor Google Cloud Storage. For R2, the bucket must be public and associated with a custom domain. - Define which traffic should be routed using the standard rule builder interface, filtering by hostname, URI path, headers, cookies, source IP, AS number, or other criteria.
Once deployed, the rule takes effect immediately. Cloud Connector is intentionally positioned at the end of the Ruleset Engine phase sequence, ensuring it works out of the box even if active origin or configuration rules match the same traffic.
Under the hood
Rather than building an entirely new routing system, Cloudflare extended the existing “route” action within its Ruleset Engine to handle a defined set of pre-approved cloud provider endpoints. A new request phase, http_request_cloud_connector, was introduced as the final request phase, giving Cloud Connector rules the last say in routing decisions and preventing conflicts with other rules.
To keep the core Ruleset Engine control plane free of product-specific abstractions, Cloudflare built a thin API translator layer on Workers. This intermediary sits between the user-facing Cloud Connector API and the underlying Ruleset Engine API. When a user creates a Cloud Connector rule, the translator decomposes it into a series of existing Ruleset Engine actions — for instance, adjusting the host header and origin settings to point to an S3 endpoint. The decomposed rules are processed in reverse order following a “last rule wins” approach, and a “skip” action prevents subsequent rules from altering the traffic (which could otherwise cause unintended behavior like disabling SSL for traffic bound for a different provider). When users retrieve their Cloud Connector rules, the system reverses the process, reconstructing the original configuration so the interface reflects exactly what was defined.
Roadmap
The current version focuses exclusively on object storage endpoints, but Cloudflare says the longer-term vision is broader. The company plans to expand Cloud Connector to support all types of HTTP cloud services, including load balancers and compute services. The stated goal is to make Cloud Connector the primary means for Cloudflare users to discover and manage cloud services across multiple providers — without needing to worry about DNS settings, Host headers, or SSL implementation details.
Documentation for setup and usage is available in the developer documentation, and feedback can be submitted via the Cloudflare community forums.
