In early 2025, internet users across Spain began experiencing something unexpected: legitimate websites going dark, developer tools becoming unreachable, and businesses losing access to their own online services. GitHub, GitLab, Docker registries, corporate websites, and e-commerce platforms all affected not by a cyberattack, not by a provider outage, but by a court-ordered IP block targeting illegal football streaming.
The mechanism was straightforward. A ruling from the Commercial Court No. 6 of Barcelona, issued in December 2024, authorised Spanish ISPs to block IP addresses identified as sources of illegal IPTV broadcasts during football matches.
The problem was that many of those addresses were Cloudflare IPs shared simultaneously by thousands of unrelated websites and services. When ISPs blocked the flagged addresses, they didn’t take down one streaming site. They took down everything behind the same shared IP.
The football piracy angle captured headlines. The infrastructure lesson is what matters for organisations operating critical services anywhere in the world.
What happened technically and Why Shared IP Blocking Scales So Broadly
To understand why IP-level blocking caused collateral damage at this scale, it helps to understand how large CDN and edge-delivery infrastructures work.
Cloudflare, like most major content delivery networks, operates a shared global edge infrastructure. When a company routes its traffic through Cloudflare, it passes through Cloudflare’s distributed network of nodes rather than reaching the origin server directly. From the outside, that service’s visible IP address is a Cloudflare IP pooled across many other customers simultaneously. A single IP address in a shared CDN infrastructure can front hundreds or even thousands of completely unrelated domains.
This is the multi-tenant model applied at the network edge: multiple organisations share the same underlying infrastructure resources, including IP address ranges, reverse proxy layers, TLS termination systems, and WAF infrastructure. Clients are logically separated; the network layer beneath them is not.
The consequence follows directly. Any action operating at the IP level (a court-ordered block, a blacklist entry, an ISP-level firewall rule) doesn’t target a single service. It targets every service resolving through that address. Developers found they couldn’t pull packages. Companies found their websites unreachable. None of them had any connection to the reason for the block.
It is important to note that this operational model is not unique to Cloudflare. Most large CDN, WAF, and edge delivery providers rely on shared, multi-tenant infrastructure to deliver scalability and cost efficiency globally. This architectural model is deeply embedded across much of the modern internet delivery stack.
The Spain case became a highly visible example of shared infrastructure risk in modern cloud delivery architectures.
The court order didn’t create this vulnerability. It revealed one that was already there.
The tradeoffs of multi-tenant architecture that rarely get discussed
Multi-tenant architecture is not inherently flawed. It became the dominant model in cloud computing for legitimate, well-understood reasons.
For providers, it enables resource pooling, centralised maintenance, elastic scalability, and cost efficiency at scale. For customers, it translates into lower entry costs, faster deployment, and freedom from managing infrastructure directly. Most organisations don’t need (or want) to operate their own edge networks, WAF layers, or global traffic distribution systems. Consuming those capabilities as a shared service makes practical and economic sense.
The issue isn’t that multi-tenancy is inefficient. The issue is that shared infrastructure creates shared operational exposure and that exposure is rarely top of mind when organisations choose SaaS platforms or CDN services.
In a multi-tenant environment, organisations can inherit operational risk from events that have nothing to do with their own services:
- An IP address is blacklisted because another tenant was abusing it
- DDoS traffic targeting a neighbouring tenant is degrading shared network performance
- A legal or regulatory action that catches shared IPs in its scope
- A provider-level policy change applied uniformly across the customer base
Under normal conditions, these risks remain invisible. Most of the time, shared infrastructure works exactly as advertised. But under stress (a security incident, a large-scale abuse event, a court order), the shared layer is precisely where failures propagate.
This is what infrastructure engineers refer to as a shared blast radius: the operational scope of an incident isn’t defined by the intended target, but by the boundaries of the shared environment.
Why infrastructure isolation is becoming a resilience decision
Single-tenant architecture reverses the model. Each client operates a dedicated environment: isolated IP addresses, independent compute resources, and exclusive security policies that are not shared with other organisations.
The tradeoff has traditionally been cost and operational overhead. Dedicated infrastructure is more resource-intensive than shared SaaS deployments. That gap is why multi-tenancy became the default.
But the relevant question is not which model is architecturally superior. It is the operational risks that the organisation is prepared to carry.
For many workloads, multi-tenant SaaS remains the correct and efficient decision. For critical applications (platforms where availability directly affects revenue, SLA compliance, customer trust, or operational continuity) the calculation looks different.
Consider the practical implications. An e-commerce platform that becomes unreachable during peak sales hours due to a shared IP block loses revenue that it cannot recover. A SaaS provider whose service goes dark due to an incident involving a neighbouring tenant faces SLA breach conversations with its own customers. A financial service or healthcare platform that loses availability (even briefly, even for reasons entirely outside its control) faces reputational and regulatory consequences that extend well beyond the technical incident itself.
These aren’t theoretical edge cases. They represent the downstream business impact of shared operational exposure.
This is why infrastructure isolation is increasingly appearing in resilience discussions rather than just security or compliance contexts. The growing interest in dedicated environments, private edge infrastructure, and hybrid deployment models reflects a broader recognition: that shared platforms also mean shared operational exposure, and that for critical services, reducing that exposure is a legitimate architectural strategy, not just a premium option.
Managed single-tenant deployments (where the provider handles infrastructure operations on dedicated resources) narrow the practical gap between SaaS convenience and isolated control, without requiring organisations to operate everything themselves.
Questions worth asking before relying on shared infrastructure
The Spain controversy highlighted something important: many organisations don’t fully understand how shared their infrastructure actually is. Before deploying critical services on SaaS or CDN platforms, the following questions are worth examining carefully.
Are IP addresses shared with other tenants? If multiple customers share the same edge IPs, reputation issues, legal restrictions, or blocking measures targeting one tenant can affect others.
What is the actual isolation boundary? Logical separation and operational isolation are not equivalent. Understanding how traffic, policies, rate limits, and security rules are enforced or shared across tenants matters for availability planning.
What is the provider’s blast radius during incidents? Every platform experiences incidents. The relevant question is how broadly those incidents propagate across the customer base.
Can another tenant’s actions affect your availability? This includes abuse-triggered IP restrictions, DDoS spillover, shared WAF rate limiting, and legal or compliance measures applied at the infrastructure level without tenant-specific granularity.
Is an isolated or hybrid deployment available? For critical services, the ability to deploy on dedicated infrastructure (on-premise, private cloud, or dedicated cloud instances) reduces dependency on shared operational models and gives organisations direct control over their exposure.
How transparent is the provider about its architecture? Providers that clearly document whether they operate as multi-tenant SaaS, isolated instances, or dedicated environments enable informed infrastructure decisions. Opacity here is itself a risk signal.
The debate in Spain will evolve through legal appeals, technical adjustments, and regulatory review. But the infrastructure question that surfaced isn’t tied to football season.
Organisations have spent years consolidating digital operations onto shared, efficient, globally distributed platforms. That consolidation brought genuine benefits: lower costs, faster deployment, and reduced operational complexity. It also created dependencies on shared infrastructure that those organisations do not control — and cannot protect themselves from when something goes wrong on the shared layer.
The Spain controversy is not fundamentally a story about piracy enforcement or internet freedom. It is a visibility event for a problem that already exists across large parts of modern cloud infrastructure: organisations are increasingly dependent on shared operational layers they neither fully control nor fully understand.
For critical services, resilience is no longer only about redundancy or scalability. It is also about understanding where infrastructure boundaries actually exist and whether an event targeting someone else can reach you through a layer you assumed was yours.
SKUDONET has extensively explored the architectural and operational differences between multi-tenant and isolated application delivery environments, particularly for organisations running critical services, APIs, or high-availability infrastructure.
