Data residency EU: come architettarla senza raddoppiare i costi cloud

Data residency EU: come architettarla senza raddoppiare i costi cloud

Un cliente ci ha presentato un preventivo del proprio provider cloud: +73% di costi annui per spostare l'intera infrastruttura in region EU e soddisfare i requisiti di data residency. Il problema non era la normativa. Era l'architettura.

Il malinteso di fondo

Data residency EU non significa "tutto in Europa". Significa che i dati personali e sensibili dei cittadini UE non possono essere processati o archiviati in modo persistente fuori dai confini UE senza garanzie adeguate (Schrems II, GDPR Art. 44-49).

La maggior parte delle aziende interpreta questo requisito come: sposta ogni componente applicativo in EU. Il risultato è una duplicazione completa dello stack su region EU, con latenze peggiori per utenti non-EU, costi infrastrutturali raddoppiati e nessun reale vantaggio competitivo.

Cosa va effettivamente in EU (e cosa no)

Il primo passo è una data classification rigorosa. Non tutti i dati sono uguali sotto GDPR.

| Categoria | Esempio | Vincolo residency | |---|---|---| | Dati personali identificativi | Nome, email, CF | Sì, storage persistente EU | | Dati pseudonimizzati | UUID, token | Dipende dalla reversibilità | | Dati aggregati/anonimizzati | Analytics aggregate | No | | Metadati tecnici | Log infrastrutturali senza PII | No | | Dati di business generici | SKU prodotto, prezzi | No |

Se il tuo database principale contiene una tabella users con PII e una tabella products con catalogo, non devi spostare l'intero database in EU. Devi separare i due domini.

Pattern architetturali concreti

1. Database sharding per residency

Il pattern più diretto per applicazioni multi-region è separare lo storage dei dati personali in un cluster dedicato EU, mantenendo il resto su region con migliori performance/costo.

# Esempio: due connection string in configurazione applicativa
databases:
  core_business:
    host: db-us-east-1.internal
    region: us-east-1
    contains_pii: false
  user_profiles:
    host: db-eu-west-1.internal
    region: eu-west-1
    contains_pii: true
    encryption_at_rest: AES-256
    backup_region: eu-central-1

L'applicazione risolve i dati utente sempre verso il cluster EU, il resto viaggia sulla region più conveniente. La complessità aggiuntiva è reale ma contenuta: un'astrazione a livello di repository pattern gestisce il routing.

2. Tokenizzazione dei PII nel flusso dati

Per pipeline di analytics, ML o eventi (Kafka, Kinesis), i PII non devono mai entrare nel flusso grezzo. Si tokenizzano a monte, si processano i token, i dati reali restano in EU.

# Pseudocodice: tokenizzazione prima di inviare a pipeline non-EU
def emit_event(user_id: str, event: dict) -> None:
    token = tokenizer.get_or_create(user_id)  # chiamata a vault EU
    sanitized_event = {
        **event,
        "user_id": token,           # token opaco, non reversibile senza vault EU
        "email": None,              # PII rimosso esplicitamente
        "ip_address": mask_ip(event.get("ip_address")),  # pseudonimizzazione
    }
    kafka_producer.send("events", sanitized_event)  # region qualsiasi

Il vault di tokenizzazione vive in EU. Il resto della pipeline può girare ovunque.

3. CDN e edge: attenzione ai log

Molti team non considerano che i CDN log (Cloudflare, Fastly, CloudFront) contengono IP degli utenti, che sono PII sotto GDPR. Se questi log vengono scritti su S3 in us-east-1 senza configurazione esplicita, si viola la residency.

Soluzione: abilitare il log forwarding verso un bucket EU e configurare una retention policy corta (7-30 giorni) per i log raw. I log aggregati (metriche, percentili) possono andare ovunque.

# Terraform: S3 bucket per CDN logs con residency EU
resource "aws_s3_bucket" "cdn_logs_eu" {
  bucket = "company-cdn-logs-eu"
  
  # Forza region EU
  provider = aws.eu-west-1
}

resource "aws_s3_bucket_lifecycle_configuration" "cdn_logs_eu" {
  bucket = aws_s3_bucket.cdn_logs_eu.id
  rule {
    id     = "expire-raw-logs"
    status = "Enabled"
    expiration { days = 14 }
  }
}

Quanto si risparmia davvero

Tornando al cliente con il +73%: dopo la data classification e l'adozione dei pattern sopra, il delta reale è stato +18% rispetto alla configurazione originale. La maggior parte del workload continuava a girare su region US con costi inferiori. Solo il 15-20% dei dati era effettivamente PII e richiedeva storage EU.

I costi aggiuntivi principali, nell'ordine:

1. Cross-region data transfer: minimizzabile con caching aggressivo e design che riduce i round-trip EU↔US nel critical path.
2. Doppio backup: necessario solo per i cluster EU. Non per tutto lo stack.
3. Complessità operativa: il costo nascosto. Monitoraggio, runbook, on-call devono coprire più region. Questo si affronta con automazione e non con persone.

Take-away operativo

1. Fai la data classification prima di toccare l'infrastruttura. Senza sapere cosa è PII e cosa no, qualsiasi decisione architetturale è un'approssimazione.
2. Separa i domain di storage. Un database monolitico con PII mischiati a dati di business è il problema più comune e più costoso da risolvere a posteriori.
3. Tokenizza ai bordi del sistema. Qualsiasi dato che attraversa una boundary (API esterna, pipeline, CDN) deve essere ripulito da PII prima di uscire dal perimetro EU.
4. Non è un problema legale, è un problema di design. Il GDPR non dice come costruire i sistemi. Dice cosa proteggere. L'architettura è una scelta tecnica.

---

Se stai valutando una revisione dell'infrastruttura cloud con vincoli di data residency, il team di Evviva Group può affiancarti nell'assessment e nel design architetturale.