È uscito il Corso Java Completo
Torna al blog

Cos'è Cloudflare R2 e perché elimina i costi di uscita

Come funziona Cloudflare R2, perché l'assenza di costi di traffico in uscita cambia i conti rispetto a S3 e in quali casi conviene davvero.

Edoardo Midali

Edoardo Midali

Developer · Content Creator

7 min di lettura

Chi archivia file su un servizio cloud scopre presto che la voce più cara della fattura non è lo spazio occupato, ma il traffico che esce: ogni volta che qualcuno scarica un file, paghi. Per un archivio che nessuno tocca è irrilevante, per un sito che serve immagini o video diventa la voce principale. R2 nasce esattamente da qui. In questo articolo trovi come funziona, perché il conto cambia e quando invece non ti serve.

Cos'è

Cloudflare R2 è un servizio di storage a oggetti compatibile con l'API di S3 che non fattura il traffico in uscita.

Due cose in una frase, ed entrambe contano.

Storage a oggetti significa che carichi file — immagini, video, backup, allegati — e li recuperi tramite una chiave. È lo stesso modello di S3, con la stessa logica di bucket e oggetti.

Compatibile con l'API di S3 significa che gli strumenti e le librerie che già usi per S3 funzionano cambiando l'indirizzo del servizio e le credenziali. Non devi riscrivere il codice.

Il punto: i costi di uscita

Qui sta tutta la ragione d'essere del prodotto, e vale la pena capirla bene perché è una voce che sorprende molti.

I fornitori cloud tradizionali fatturano tre cose sullo storage: lo spazio occupato, le operazioni (ogni lettura e scrittura) e il traffico in uscita — i dati che escono dalla rete del fornitore verso internet.

È la terza voce quella che fa i danni. Lo spazio costa poco. Le operazioni costano poco. Ma se hai un sito che serve immagini pesanti, un'applicazione che distribuisce file, o un podcast che la gente scarica, il traffico in uscita cresce con la popolarità — e diventa la voce dominante proprio quando le cose vanno bene.

R2 azzera quella voce. Paghi lo spazio e le operazioni, non l'uscita.

La conseguenza pratica: su un archivio grande che nessuno legge, R2 e i concorrenti si equivalgono. Su un archivio anche piccolo da cui si scarica molto, la differenza sul conto non è marginale — è di categoria.

Quando conviene davvero

Il criterio è uno solo: il rapporto tra quanto scarichi e quanto archivi.

Conviene molto quando servi file pubblici a molte persone: immagini e media di un sito, allegati scaricabili, video, file di un'applicazione, contenuti serviti da un CDN.

Conviene quando i dati devono essere letti spesso da servizi esterni, o da più fornitori cloud diversi — è il caso in cui i costi di uscita si moltiplicano.

Non cambia nulla per un archivio di backup che scrivi e non rileggi quasi mai. Lì il traffico in uscita è vicino a zero e paghi comunque lo spazio: tanto vale scegliere in base ad altro.

Non conviene se il resto della tua infrastruttura è su AWS e i dati vengono letti da lì. In quel caso il traffico resta interno alla rete del fornitore e non è fatturato come uscita: spostare i file su R2 introdurrebbe latenza e traffico che prima non c'era. La regola è la stessa dell'edge computing: tieni i dati vicino a chi li usa.

Come si usa

Perché è compatibile con l'API di S3, la configurazione somiglia a quella che già conosci. Con la libreria ufficiale AWS:

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const r2 = new S3Client({
  region: "auto",
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: {
    accessKeyId: process.env.R2_ACCESS_KEY_ID,
    secretAccessKey: process.env.R2_SECRET_ACCESS_KEY,
  },
});

await r2.send(new PutObjectCommand({
  Bucket: "media",
  Key: "immagini/foto.jpg",
  Body: file,
  ContentType: "image/jpeg",
}));

Le uniche differenze rispetto a S3 sono region: "auto" e l'indirizzo del servizio. Il resto del codice resta identico, ed è il motivo per cui una migrazione è meno dolorosa di quanto sembri.

Le credenziali vanno in variabili d'ambiente, mai nel codice — vedi cosa sono le variabili d'ambiente.

Da riga di comando, lo strumento di Cloudflare:

npx wrangler r2 bucket create media
npx wrangler r2 object put media/foto.jpg --file=./foto.jpg

E se usi i Workers, il collegamento diretto evita del tutto le credenziali:

export default {
  async fetch(request, env) {
    const oggetto = await env.MEDIA.get("immagini/foto.jpg");
    if (!oggetto) return new Response("Non trovato", { status: 404 });
    return new Response(oggetto.body, {
      headers: { "Content-Type": "image/jpeg" },
    });
  },
};

Questa è l'integrazione che rende R2 più comodo dei concorrenti dentro l'ecosistema Cloudflare: il Worker parla con lo storage senza uscire sulla rete pubblica e senza chiavi da gestire.

Errori comuni

Rendere pubblico un bucket senza pensarci. Vale qui quanto vale per S3: un bucket esposto per errore è una delle cause più banali di fuga di dati. Se i file devono essere pubblici, esponili attraverso un dominio dedicato e tieni privato tutto il resto. Per i file riservati, usa URL firmati a scadenza invece dell'accesso aperto.

Dare per scontato che "gratis in uscita" significhi "gratis". Le operazioni si pagano, e un'applicazione che fa molte richieste piccole può costare più di una che ne fa poche e grandi. Il modello premia il traffico, non il numero di chiamate.

Non mettere una cache davanti. Servire ogni richiesta direttamente dallo storage funziona, ma è più lento e genera più operazioni del necessario. Una cache davanti riduce entrambi.

Migrare senza misurare. Prima di spostare tutto, guarda la fattura attuale: se la voce di uscita è piccola, stai risolvendo un problema che non hai.

Trattarlo come un file system. Come per ogni storage a oggetti, non ci sono cartelle vere: le barre nel nome sono parte della chiave. Rinominare una "cartella" significa riscrivere ogni oggetto.

R2, S3 o un disco su un server

R2S3Disco su VPS
Traffico in uscitaNon fatturatoA consumoIncluso, con limiti
SpazioA consumoA consumoFisso, prepagato
ScalabilitàAutomaticaAutomaticaManuale
GestioneNessunaNessunaTua
Ecosistema di serviziEssenzialeVastissimo
Rischio di bloccoBasso (API compatibile)MedioNessuno

S3 resta la scelta obbligata se ti servono le integrazioni dell'ecosistema AWS — sono molte e mature, e R2 non le replica. Il quadro è in cos'è AWS.

Un disco su un VPS ha senso per volumi piccoli e prevedibili, dove la semplicità di avere tutto su una macchina batte l'eleganza. Ma non scala, e i backup li gestisci tu.

R2 conviene quando il traffico in uscita è la voce che pesa e non ti servono i servizi accessori di AWS.

In sintesi

R2 è storage a oggetti compatibile con l'API di S3, con una differenza sostanziale: il traffico in uscita non è fatturato.

Il criterio per decidere è il rapporto tra letture e spazio occupato. Molti download rispetto ai dati archiviati: R2 cambia i conti in modo significativo. Archivio grande e poco letto: la differenza svanisce.

La compatibilità con l'API di S3 è il secondo motivo per considerarlo, ed è quello che si sottovaluta: cambi indirizzo e credenziali, non il codice. Vale anche al contrario — se un domani vuoi tornare indietro, puoi.

Prima di migrare, guarda la fattura. Se la voce di uscita è marginale, il vantaggio è teorico e stai spostando dati per niente.

Per il modello concettuale dello storage a oggetti — chiavi, bucket, classi, sicurezza — parti da cos'è S3. Per il resto della piattaforma, vedi cos'è Cloudflare.