Most UK SaaS founders default to S3 in eu-west-2 and call it GDPR compliance done. It is not.

S3 in London is operated by AWS Inc, a US entity. The data sits in London. The processor sits in Seattle. Under UK GDPR Chapter V and the post-Schrems II ICO position, that is a transfer to a non-adequate third country unless your DPA includes the latest SCCs and a documented Transfer Impact Assessment. Plenty of UK SMBs get away with it. Plenty also fail compliance audits because of it.

We built Beamprobe (a UK virtual data room) on Cloudflare R2 with the EU jurisdiction flag instead. After six months in production, here is what worked, what tripped us up, and what I would do differently.

Why R2 EU jurisdiction is different from "R2 in Europe"

R2 has a jurisdiction setting at the bucket level. You can set it to EU. When you do, three things change:

1. The bucket is pinned to EU member-state data centres. No transparent replication to North America.
2. The bucket lives under Cloudflare's Frankfurt-based entity for billing and processor purposes.
3. Cross-border transfer events (egress to non-EU regions) are logged and surfaced in the audit feed.

For UK GDPR purposes, the second one is the load-bearing detail. The processor entity matters more than the rack location. Cloudflare's EU jurisdiction puts you on a DPA signed against a Frankfurt entity, with Chapter V transfers handled through their EU subprocessor list rather than a US parent.

The setting is buried. You pick it when you create the bucket in the Cloudflare dashboard, or you pass jurisdiction: 'eu' in the S3-compatible API.

# Wrangler example
wrangler r2 bucket create beamprobe-prod --jurisdiction eu

There is no way to migrate an existing bucket to a different jurisdiction. You create a new one, copy, swap. We learned that the hard way after launching with a default-jurisdiction bucket and realising during a customer audit.

The Phoenix / ExAws setup

We use ExAws against the R2 S3-compatible endpoint. Configuration sits in runtime.exs so the same release binary runs in dev with local-disk storage and in prod with R2.

# config/runtime.exs

if storage_adapter == :s3 do
  r2_account = System.get_env("R2_ACCOUNT_ID") || raise "R2_ACCOUNT_ID missing"
  r2_key = System.get_env("R2_ACCESS_KEY_ID") || raise "R2_ACCESS_KEY_ID missing"
  r2_secret = System.get_env("R2_SECRET_ACCESS_KEY") || raise "R2_SECRET_ACCESS_KEY missing"

  config :ex_aws,
    access_key_id: r2_key,
    secret_access_key: r2_secret,
    region: "auto"

  config :ex_aws, :s3,
    scheme: "https://",
    host: "#{r2_account}.eu.r2.cloudflarestorage.com",
    region: "auto"
end

Two non-obvious bits:

• region: "auto". R2 ignores region but ExAws insists on having one. "auto" is the canonical value.
• The host has .eu. baked in for EU-jurisdiction buckets. Default-jurisdiction is <account>.r2.cloudflarestorage.com. Wrong host on either side returns a confusing 404.

R2 access keys are scoped per bucket, not per account. Create one set of credentials per environment. Rotate quarterly.

Encryption at rest: what R2 gives you and what it does not

R2 encrypts at rest using AES-256 with Cloudflare-managed keys. That satisfies Article 32 on its own for most categories of data. For investor-grade documents with NDAs, we add envelope encryption on top:

1. Generate a 256-bit data encryption key (DEK) per file.
2. AES-256-CBC encrypt the file body with the DEK.
3. S/MIME-encrypt the DEK under a per-user key, store separately.
4. Upload the ciphertext to R2.

The result: even a leaked R2 access key does not give the attacker plaintext. They need our user-key store too. That is two distinct breach paths needed for one disclosure, which is the bar UK GDPR Article 32 "appropriate technical measures" actually expects for special-category data.

Cloudflare also offers SSE-C (server-side encryption with customer keys). We do not use it because the key never leaves our Phoenix backend in our model; envelope encryption gives us the same guarantee with one less moving part.

Presigned URLs without leaking the bucket

R2 presigned URLs work the same as S3 presigned URLs. Time-bound, signed with HMAC-SHA256, single-resource.

defmodule Beamprobe.Storage do
  def presigned_url(key, expires_in \\ 3600) do
    full = prefixed(key)
    ExAws.S3.presigned_url(:get, bucket(), full, expires_in: expires_in)
  end
end

Three things to lock down:

• Short TTL. We use 600 seconds for viewer page rasters, 60 seconds for downloads. Long TTLs end up in browser history and crash dumps.
• Per-object prefix. We path-prefix every object as documents/<user_id>/<room_id>/<random>.pdf. The random suffix is 16 bytes of crypto, base64. Guessing one URL gets you one document, not the bucket.
• CORS off by default. R2 buckets default to no CORS. Do not enable it unless a browser actually needs to fetch the object directly. We serve every public asset through a viewer endpoint that signs URLs server-side.

Lifecycle policies and the egress trap

R2's headline feature is zero egress fees. There is a footnote.

The "no egress" applies to clients of Cloudflare's network: workers, pages, your own zone. Egress to third-party origins via S3 API call is billed. Cross-region replication is billed. Lifecycle transitions to Glacier-equivalent classes (R2 calls them "Infrequent Access") are billed at the transition.

If you write a worker or a server that pulls objects out of R2 to a non-Cloudflare endpoint, you pay normal egress. The zero-egress model assumes your serving plane lives inside Cloudflare.

Our setup: Phoenix on Hetzner Germany. We DO pay egress when Phoenix fetches a document body to decrypt and serve. That is what we are willing to pay for control.

The lesson: model your egress before you bet your unit economics on "R2 = free egress." For most B2B SaaS workloads this is fine. For media streaming or large-file delivery it is not.

Cost comparison vs S3 eu-west-2

Real numbers from a single Beamprobe production month (May 2026):

For our workload R2 is roughly a third the cost. The math flips if you are serving public CDN-style traffic where R2's free egress to Cloudflare zones wins big.

Mistakes we made

1. Created bucket without EU jurisdiction. Lost a week migrating to an EU-jurisdiction bucket.
2. Did not pin region in the access key. Access keys are scoped per bucket, not account. We over-permissioned an early key.
3. Stored presigned URLs in logs. A 1-hour presigned URL is a 1-hour credential. We now redact ?X-Amz-Signature from log lines server-side.
4. Used default CORS off but did not test. Browsers fail silently. Wrap every CORS-bound flow in a Playwright test that hits the actual bucket.
5. Forgot to set lifecycle rules for failed multipart uploads. R2 charged us for orphaned parts for two months before we noticed. Set the lifecycle rule on day one:

wrangler r2 bucket lifecycle put beamprobe-prod \
  --abort-multipart-uploads-after-days=1

What I would do differently

• Pick EU jurisdiction at bucket creation, no exceptions.
• Document the processor relationship in the DPA from day one. Cloudflare publishes a UK GDPR-aware DPA at cloudflare.com/legal/data-processing-agreement. Sign it.
• Bake the envelope-encryption pattern into the storage abstraction, not into individual upload handlers. Less risk of forgetting a code path.
• Use Cloudflare Workers as a thin signing layer for presigned URLs if your serving plane is also on Cloudflare. We did not because Phoenix-on-Hetzner is our model. If you are on Workers anyway, do it.
• Run a quarterly access-key rotation drill. Cloudflare makes rotation easy; the human process of updating env vars across dev/staging/prod is the slow bit.

When R2 is not the right call

• You need single-region S3 endpoint matching for a customer who requires eu-west-2 in their DPA. R2 cannot give you AWS-region semantics.
• You depend on AWS IAM features (resource policies, KMS integration, CloudTrail audit). R2's IAM is simpler. Some compliance auditors prefer the AWS depth.
• You need cross-region replication for disaster recovery. R2 does not yet ship that for EU-jurisdiction buckets at the time of writing.

For everything else, R2 EU is faster to set up, cheaper for our workload, and easier to defend in a UK GDPR audit because the processor entity is in Frankfurt rather than Seattle.

Sources

• ICO Data Sharing Code of Practice (2024 update)
• UK GDPR Chapter V (international transfers)
• Cloudflare R2 jurisdiction documentation
• Schrems II judgement, CJEU C-311/18

I write about UK data residency, document security and Elixir/Phoenix at beamprobe.com. Beamprobe is a UK virtual data room for fundraising teams and M&A advisors. Bootstrapped, built in the UK, used worldwide.