Gestione file multi-cloud: evita il vendor lock-in

Il GDPR e i requisiti sempre più stringenti del Garante per la protezione dei dati personali impongono di sapere esattamente dove risiedono i propri dati — e affidarsi a un unico fornitore cloud significa accettare prezzi imposti, rischio di interruzioni e potenziale non conformità se quel provider modifica le sue politiche di elaborazione nell'UE. La gestione file multi-cloud risponde a questa esigenza distribuendo i dati su due o più provider — AWS S3, Cloudflare R2, Backblaze B2 — dietro un'astrazione unica. I vantaggi concreti: protezione contro i guasti del fornitore, leva contrattuale al rinnovo e costi di egress quasi azzerati scegliendo il provider giusto per ogni carico di lavoro.

Cosa costa davvero il vendor lock-in

Il lock-in raramente si manifesta come una bolletta enorme: si tratta di cento piccole frizioni. Quando il codice usa aws s3 cp, hardcoda us-east-1, dipende da S3 Select o da DynamoDB Streams, trasferirsi altrove richiede la riscrittura di tutto questo. Le spese di egress sono la tassa più visibile: AWS addebita 0,09 $ per GB in uscita per i primi 10 TB. Spostare 50 TB fuori da AWS costa circa 4.000 $ solo di banda, senza contare il tempo degli ingegneri.

Meno ovvie: funzionalità proprietarie come Glacier vault lock, Lambda trigger su eventi S3 o IAM Access Analyzer diventano tutti progetti di migrazione. Il multi-cloud non significa usare tutti i cloud per tutto — significa tenere aperta la via d'uscita in modo che prezzi e affidabilità rimangano onesti.

L'API S3-compatibile come denominatore comune

Quasi tutti i provider di object storage parlano ormai l'API S3: AWS, Backblaze B2, Cloudflare R2, Wasabi, Google Cloud Storage (in modalità interoperabilità), Azure Blob (tramite gateway di terze parti) e MinIO o Ceph RGW self-hosted. Ciò significa che un unico SDK li copre tutti:

import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
const r2 = new S3Client({
  region: 'auto',
  endpoint: 'https://account.r2.cloudflarestorage.com',
  credentials: { accessKeyId, secretAccessKey }
});
await r2.send(new PutObjectCommand({
  Bucket: 'transfers', Key: 'file.zip', Body: stream
}));

Restare al sottoinsieme dell'API S3 (PUT, GET, LIST, DELETE, multipart, presigned URL) garantisce piena portabilità. Evita le chiamate specifiche del provider come s3:GetObjectLegalHold a meno di non avere un piano per quella funzionalità su ogni backend.

Astrarre i provider dietro un router

Costruisci un router minimale che mappa percorsi logici a bucket fisici:

interface Store { put(key, stream); get(key); delete(key); }
class MultiCloudRouter implements Store {
  constructor(private index: Index, private stores: Record<string, Store>) {}
  async put(key: string, stream: ReadableStream) {
    const provider = chooseProvider(key);
    await this.stores[provider].put(key, stream);
    await this.index.record(key, provider);
  }
  async get(key: string) {
    const provider = await this.index.lookup(key);
    return this.stores[provider].get(key);
  }
}

chooseProvider può essere guidato da policy: affinità di regione, fascia di costo, requisito di replica o semplice round-robin tra provider. L'indice (tabella Postgres o DynamoDB) è la fonte di verità unica per la posizione degli oggetti.

Ottimizzazione dei costi tra provider

I prezzi variano molto:

AWS S3 Standard: 0,023 $/GB archiviazione, 0,09 $/GB egress
Cloudflare R2: 0,015 $/GB archiviazione, 0 $ egress
Backblaze B2: 0,006 $/GB archiviazione, 0,01 $/GB egress
Wasabi: 0,0069 $/GB archiviazione, egress gratuito (fino a 1x volume archiviato al mese)
AWS S3 Glacier Deep Archive: 0,00099 $/GB archiviazione, 0,02 $/GB egress + spese di recupero

Una policy di routing intelligente:

Download rivolti agli utenti: R2 (egress zero azzera la concorrenza)
Archivio freddo: S3 Glacier Deep Archive
Ridondanza regionale: B2 (economico, affidabile, profilo di rischio aziendale diverso da AWS)
Copia di conformità con retention lunga: Wasabi con object lock

Per un servizio di trasferimento file che gestisce 50 TB in uscita al mese, passare l'egress da S3 a R2 risparmia 4.500 $ mensili prima di fare qualsiasi altra cosa.

Mantenere i dati sincronizzati tra provider

Per i dati critici da replicare tra provider, usa la sincronizzazione o bisync di rclone:

rclone sync r2:transfers b2:transfers-mirror --transfers 16 --checksum

Per la replica continua, utilizza AWS S3 Cross-Region Replication (che supporta destinazioni esterne via Lambda) o un replicatore basato su code: invia ogni PUT a SQS/Kafka, il consumer legge dalla coda e scrive sul provider secondario. Consistenza eventuale, con un RPO di minuti.

Non replicare tutto. Replica solo ciò che non puoi ricreare: i byte caricati dagli utenti sì; gli artefatti di build probabilmente no; i log di analytics che esistono anche nel tuo data warehouse assolutamente no.

Gestione delle credenziali senza sorprese

Il multi-cloud significa più credenziali, e le credenziali trapelate sono la causa delle violazioni. Due pratiche fondamentali:

Store segreti centralizzato: HashiCorp Vault, AWS Secrets Manager o Google Secret Manager. Non commettere mai chiavi su Git; scansiona con gitleaks in CI.
Token a breve durata e a scope limitato: preferire i token STS alle access key permanenti. Limita ogni credenziale a un bucket e ai soli verbi necessari.

Ruota automaticamente ogni 90 giorni per le chiavi a lunga durata, ogni ora per gli STS. Tagga ogni chiave con owner, purpose ed expiry. Controlla gli orfani mensilmente.

Monitoraggio e logging unificati

L'osservabilità tra provider conta più di quella all'interno di uno solo. Invia tutti i log di accesso dei provider a un unico sink:

S3 Server Access Logs → CloudWatch → OpenSearch
R2 access log → Cloudflare Logpush → S3 → OpenSearch
B2 Event Notifications → webhook → Loki

Le dashboard unificate mostrano: richieste per provider, tassi di errore, latenza p99, byte di egress per bucket, accumulo dei costi in quasi-tempo reale. Avvisa se un singolo provider supera del 2x l'egress giornaliero atteso — buon segnale di presigned URL trapelate o abuso da scraper.

Governance e conformità GDPR in ambienti multi-cloud

Il multi-cloud moltiplica la superficie di conformità. Ogni provider necessita di un proprio accordo sul trattamento dei dati, una propria revisione dei sub-responsabili e una propria traccia di audit. Passi pratici:

Mappa ogni classificazione dei dati (pubblico, interno, riservato, ristretto) ai provider consentiti
Documenta la residenza: i trasferimenti al di fuori dell'UE ai sensi dell'Articolo 44 del GDPR richiedono un meccanismo valido (SCC, decisione di adeguatezza). Mantieni i dati con scope UE nella regione R2 EU o in OVH Object Storage.
Tieni traccia dei sub-responsabili. Quando un provider aggiunge un nuovo sub-responsabile, potrebbe essere necessario notificarlo ai clienti ai sensi dell'Articolo 28(2) del GDPR.
Replica i log di audit fuori dal provider primario: un incidente AWS che abbatte CloudTrail non dovrebbe portare via anche la storia degli audit.

Costruire un piano di uscita prima di averne bisogno

Un piano di uscita credibile ha tre parti: un inventario di ogni dipendenza, uno script di migrazione testato e un budget per l'egress. L'inventario include codice, IaC (moduli Terraform vincolati a risorse specifiche del provider), policy IAM, bucket e qualsiasi configurazione CDN origin. Gli script di migrazione devono essere eseguibili trimestralmente in modalità dry-run per non degradarsi. Budget egress: pianifica 1,2x del volume archiviato, poiché probabilmente rielaborerai durante la migrazione.

Anche se non lasci mai un provider, l'esistenza di un piano provato significa che i negoziati di rinnovo contrattuale hanno peso, e un aumento improvviso dei prezzi non paralizza il team.

HexaTransfer gira su uno strato di storage S3-compatibile proprio per mantenere aperta la scelta del provider — una strategia che funziona ugualmente bene per qualsiasi team che sposta file di grandi dimensioni. Provalo su https://hexatransfer.com — gratuito, senza account, max 10 GB.

Quando il multi-cloud è eccessivo

Il multi-cloud non è gratuito. Paghi in complessità ingegneristica, tooling duplicato e superficie operativa ampliata. Per team con meno di 10 ingegneri e un unico prodotto, scegli un provider, negozia prezzi a volume e investi la complessità risparmiata nel prodotto. Il multi-cloud vale il suo costo quando si raggiunge una di queste tre soglie: la conformità richiede la residenza dei dati in più giurisdizioni, l'affidabilità esige ridondanza a livello di provider, o la leva contrattuale verso un unico vendor è importante per il business. Al di sotto di quelle soglie, il single-cloud con un livello di astrazione pulito e un piano di uscita documentato è di solito la scelta pragmatica.