Off Cloudflare, onto gray-cloud AWS — why and how we moved

If you run a hospitality POS, the single worst outage mode is not “we are slow” — it is “we cannot take money”. Cards stop working. Terminals fail to pair. A full table stands up, unsure if they are paying or walking out.

So you care, a lot, about anything in the path between your kitchen and your customer’s bank. Which is why, for the last year, we have been nervous every time Cloudflare blocked a chunk of its own IPs in Spain during a La Liga weekend.

On 16 April 2026 we finished our migration off Cloudflare’s orange-cloud proxy. This post is the long version of why and what we did.

The symptom

Spain’s LaLiga and the Spanish football federation have had a long-running legal battle with Cloudflare over IP-level blocks that target allegedly pirated streaming. The practical effect, for a tenant on shared Cloudflare IPs, is that during match days some Spanish ISPs would return TCP resets or timeouts against a slice of the Cloudflare IP range — including the range your entirely-legitimate POS happens to sit on.

For a customer in Madrid trying to tap their contactless card on a Saturday afternoon kick-off, the failure mode was: “Payment failed. Try again.” Indefinitely.

The blocks were intermittent — not constant — but completely outside our control. The LaLiga season is long. A handful of affected Saturdays per restaurant per year is, commercially, a killer for a POS that has to be boring-reliable.

Why we were on Cloudflare in the first place

There is a lot to like:

• DDoS protection at the edge, for free
• Good DNS, bundled
• WAF / bot rules, easy to reason about
• Quick TLS with their edge certs
• Generous free tier, which is how we ended up there

For a small team, “put the marketing site behind Cloudflare” is a sensible default. We had inherited that default and extended it to the product ALBs as well.

The bit we did not fully appreciate was that putting the application behind a third-party proxy means every request depends on both AWS and Cloudflare being reachable from the customer’s ISP — and the more high-value their outages become, the more acceptable it looks to state actors to temporarily null-route them.

The plan

We did the migration in five visible phases over a few weeks, each one reversible:

1. Move DNS authority from Cloudflare to Route 53. We still had Cloudflare on request paths — this just moved where the NS record pointed. Low blast radius, easy to roll back.
2. Swap CDN functions for AWS-native equivalents or “good enough” gaps. For a blog and help centre this is mostly just S3 + CloudFront (or, for the blog, S3 + ALB-backed Lambda because that is what we already had).
3. Gray-cloud the product domains — change the Cloudflare DNS records from orange-cloud (proxied) to gray-cloud (DNS-only). This is the cutover where traffic stops transiting Cloudflare.
4. Swap WAF to AWS WAF, attached to the ALBs.
5. Revoke Cloudflare’s origin access once traffic was confirmed flowing directly, locking down AWS so only the new path works.

Everything after step 3 is optional if you just want to stop La Liga taking you down. We kept going because the half-way state — using Cloudflare for DNS but nothing else — is not worth paying for.

What we gave up

Edge TLS. With Cloudflare off the path, TLS terminates at the ALB. We already had ACM certs; nothing broke. But every request now pays a full TLS handshake to London rather than the nearest Cloudflare PoP. For a POS running in a single country, that is fine. For a truly global site, it would hurt.

WAF managed rules. Cloudflare’s managed rules are genuinely good. AWS WAF’s are adequate and cheaper per request, but the rule set is less complete. We compensated by being more aggressive about rate-limiting on the Rails side.

Easy cache purging. Cloudflare’s “purge everything” button is a reflex we had to un-learn. With CloudFront, invalidation is still easy — and with a direct-to-ALB setup, there is no cache layer at all.

The free tier. AWS is not free. Our monthly infra bill went up a chunk. It is still tiny compared to the cost of a single bad Saturday in Madrid.

What we kept

DDoS coverage via AWS Shield Standard, which is on by default. We evaluated Shield Advanced; for our traffic profile it was not yet worth the subscription.

Bot management via AWS WAF’s rate-based rules plus the managed common rule set.

Sensible DNS via Route 53. Health-checked failover records for the ALBs, private hosted zones for internal services.

What surprised us

How fast the TCP handshake felt without a proxy. We had quietly accepted a round trip of extra latency as the “price of TLS at the edge”. Going direct to the ALB in London from London is measurably snappier for our actual customers. Our customers are not in Jakarta; they are in Shoreditch. The CDN argument is weaker than it looks when your user base is geographically tight.

How many things depended on Cloudflare headers. We had CF-Connecting-IP baked into some logging and rate-limiting code. That had to be ripped out and replaced with X-Forwarded-For handling against the ALB. Small gotcha, non-trivial to find.

How much we had come to trust an opaque intermediary. There was, honestly, a little grief in losing the bot-scoring and the analytics panel. But the flip side is that we now own the full request path, end to end. When something breaks, the answer is in AWS, not in a support ticket to a company whose incentives do not fully align with ours.

What ORDR does about this

ORDR’s infrastructure is now direct-to-AWS with no third-party proxy in the critical payment path. Our EU restaurants did not see another LaLiga-related incident after the 16 April cutover. Read more on how we run the product on the help centre.