Torna al blog
ConfrontiTecnologia

Hosting immagini B2B 2026: checklist RFP in 15 punti tecnici

Pubblicato il12 min read
Condividi

Scegliere un servizio di image hosting è come scegliere un database: non puoi basarti solo sull'hero section della landing page.

In azienda mi hanno chiesto di valutare un'alternativa. Ho raccolto tutti gli errori commessi in tre anni di produzione e li ho trasformati in una checklist. Non è un documento per confrontare quanti nodi CDN ha ciascun fornitore. È una tabella da incollare direttamente nella RFP, chiedendo al vendor di rispondere "Sì / No / Parziale" per ogni voce. In superficie tutti gli image hosting sembrano uguali, ma l'architettura sottostante è molto diversa.

Se cerchi semplicemente l'opzione gratuita o la più economica, parti da confronto image hosting gratuiti oppure alternative a Imgur. Questo articolo è pensato per technical lead, responsabili acquisti SaaS e ingegneri DevOps.

Perché la selezione B2B è completamente diversa dall'uso personale

L'utente privato si chiede: "Posso caricare? Il link si condivide facilmente?"

L'azienda ha una lista di preoccupazioni ben diversa. Il contratto include un SLA? Come degrada il rate limit sotto carico? I costi di egress possono raddoppiare in un mese qualsiasi? Se il DPO chiede per quanto tempo vengono conservati i dati EXIF, sapete rispondere?

In sostanza, acquistare un image hosting B2B significa comprare tre cose: una curva di costo prevedibile, garanzie di sistema verificabili e interfacce di protocollo integrabili. Le 15 voci qui sotto ruotano attorno a questi tre pilastri.

L'ho imparato dopo un incidente in produzione: il piano gratuito regge per una demo, non per il traffico reale.

Il contesto europeo: GDPR e data residency

Per le aziende italiane ed europee, il GDPR non è un optional. Nella valutazione di un image hosting B2B vanno considerati aspetti specifici:

  • Data residency: I dati personali (inclusi metadati EXIF con coordinate GPS) devono poter essere conservati in UE. Verificate che il vendor supporti AWS Milan (eu-south-1) o altri data center europei.
  • DPA obbligatorio: Senza un Data Processing Agreement conforme all'Art. 28 GDPR, non potete usare il servizio per dati di utenti europei.
  • Diritto all'oblio: Tempi certi di cancellazione (Art. 17) con evidenza documentale.
  • Trasferimenti extra-UE: Se il vendor conserva backup negli USA, serve una valutazione d'impatto (TIA) e clausole contrattuali standard aggiornate.

In fase di RFP, chiedete esplicitamente: "Avete un data center in eu-south-1 o eu-west-1? Fornite un DPA conforme GDPR?"

15 voci per la checklist RFP (pronte da copiare)

Questa tabella è la versione che ho usato realmente nelle mie valutazioni. Ogni voce ha un metodo di verifica — chiedere solo "lo supportate?" non basta, perché il vendor risponderà sempre Sì.

# Specifica Metodo di verifica Criterio di accettazione
1 Compatibilità API S3 Eseguire s3api list-objects-v2 --prefix Schema risposta identico ad AWS
2 Multipart Upload Upload file 500MB, interruzione e ripresa Supporto part retry
3 Pre-signed URL Generare URL 15 min e verificare firma HMAC-SHA256, TTL configurabile
4 Eventi Webhook Trigger eventi upload/delete Firma HMAC + meccanismo retry
5 Policy Rate Limit Test burst Ritorna 429 + header Retry-After
6 Termini SLA Leggere contratto MSA >=99.9%, con service credit
7 Zone di disponibilità Chiedere lista region >=2 region, sync cross-region
8 Fatturazione Egress Richiedere listino prezzi Prezzi trasparenti, sconti a scaglioni
9 Pipeline elaborazione immagini Testare transform on-the-fly Supporto WebP/AVIF, parametri URL
10 Nodi edge CDN Test ping globale >=50 PoP, nodi Europa inclusi
11 Controllo EXIF / Metadata Upload foto con dati GPS Strip selettivo supportato
12 Metodi autenticazione Consultare docs API OAuth2 + rotazione API Key
13 Log di audit Chiedere retention dei log >=90 giorni, esportabili
14 Certificazioni compliance Richiedere report SOC 2 / ISO 27001 Almeno una certificazione
15 Residenza dati e cancellazione Verificare clausole DPA Selezione region + hard delete

Non limitatevi a spuntare Sì/No. Per ogni voce chiedete al vendor un link alla documentazione o i passaggi di verifica tecnica. Quello che non viene allegato, nella pratica, è quasi sempre "previsto ma non ancora implementato."

Dettagli implementativi delle specifiche chiave

La tabella è lo scheletro. Qui sotto analizziamo le voci dove i vendor tendono a essere più vaghi durante la negoziazione contrattuale.

Compatibilità S3: non si risolve in una riga

"Siamo S3-compatibili" è la frase preferita dei vendor. Ma l'API S3 ha oltre 200 operazioni. Ciò che va verificato sono le operazioni che userete davvero.

GetObject e PutObject base li hanno tutti. Andiamo oltre:

# Test multipart
aws s3api create-multipart-upload --bucket test --key big.mp4 \
  --endpoint-url https://vendor.example.com

# Test versioning
aws s3api put-bucket-versioning --bucket test \
  --versioning-configuration Status=Enabled

# Test lifecycle
aws s3api put-bucket-lifecycle-configuration ...

L'ho provato io: meno del 60% dei vendor supera tutti e tre i test. Soprattutto bucket lifecycle e object lock — senza questi due, l'audit di compliance diventa un problema.

Pre-signed URL: TTL e algoritmo di firma

È il metodo di autenticazione più usato nello scenario B2B. L'utente non ha le vostre credenziali, gli emettete un ticket a tempo.

Il meccanismo sottostante è HMAC-SHA256: method, path, expiry e headers vengono impacchettati in una stringa da firmare con la secret key. Un buon vendor offre:

  • TTL regolabile (da 1 minuto a 7 giorni)
  • Blocco IP sorgente (aws:SourceIp condition)
  • Restrizione metodo HTTP
  • Supporto SigV4 (SigV2 è obsoleto — se un vendor lo usa ancora, scartate)

Un cattivo vendor vi darà un "URL pubblico senza scadenza" e lo chiamerà signed. Per questo i pre-signed URL vanno esplicitamente nella RFP.

Verifica firma Webhook: ci sono cascato anch'io

Il webhook è il cuore dell'architettura event-driven. Upload completato, scansione virus terminata, transcodifica finita — ogni evento deve essere pushato.

La sicurezza dei webhook è dove i vendor tagliano di più. Implementazioni pessime che ho visto:

  1. Nessuna firma, POST nudo
  2. Firma presente ma secret nella query string
  3. Firma con MD5
  4. Firma senza timestamp, vulnerabile a replay

Un webhook corretto deve avere:

  • Firma HMAC-SHA256 nell'header X-Signature
  • X-Timestamp incluso, rifiuto richieste oltre 5 minuti
  • Retry automatico su fallimento (backoff esponenziale, minimo 3 tentativi)
  • Dead letter queue o replay API

Codice Go per verificare un webhook:

func verifyWebhook(body []byte, sig, ts, secret string) bool {
    if time.Since(parseTS(ts)) > 5*time.Minute {
        return false
    }
    mac := hmac.New(sha256.New, []byte(secret))
    mac.Write([]byte(ts + "." + string(body)))
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(sig), []byte(expected))
}

Togliete il controllo sul timestamp e un replay attack buca l'intero sistema eventi.

Rate Limit: due livelli da valutare

Il rate limit va analizzato su due piani: qual è la vostra quota e cosa succede quando la superate.

La quota è negoziabile, di solito scritta nel piano come per-second / per-minute. Ciò che conta davvero è il comportamento al superamento:

Comportamento Valutazione
503 diretto, connessione chiusa Non accettabile
429 senza Retry-After Parziale
429 + header Retry-After Accettabile
429 + Retry-After + quota header Eccellente

Punto bonus: fornire header come X-RateLimit-Remaining per consentire il throttling proattivo invece di subire i 429.

SLA: il diavolo nei dettagli

Tutti scrivono 99.9%. Che equivale a 43.2 minuti di downtime al mese. 99.95% sono 21.6 minuti, 99.99% sono 4.3 minuti.

Ma il vero valore dello SLA non sta nel numero, sta nella exclusion clause. Verificate voce per voce:

  • La manutenzione programmata conta come downtime?
  • Le interruzioni regionali contano?
  • Gli attacchi DDoS contano?
  • Le dipendenze terze (DNS upstream, ecc.) contano?

Ancora più importante: il meccanismo di service credit. Quanto viene rimborsato se lo SLA non viene rispettato? Credit sull'account o denaro? Il credit si accumula o scade?

Onestamente, la maggior parte degli SLA è scritta bene sulla carta, ma al momento della contestazione le exclusion clause bloccano quasi tutto. Per questo in fase di procurement non guardate solo la percentuale: chiedete la storia reale degli incidenti degli ultimi 12 mesi — ottenibile sotto NDA.

Fatturazione Egress: il buco nero del budget

L'egress (traffico in uscita) è la voce che fa esplodere il budget nell'image hosting. La tattica preferita dei vendor: storage economico, egress costoso.

Guardando i dati, la differenza di prezzo egress tra i principali vendor può superare le 10 volte. Cloudflare R2 offre zero egress (nella propria rete), Cloudinary usa un modello a crediti, imgix fattura per request. Quale conviene dipende interamente dal vostro profilo di traffico.

Prima dell'acquisto, chiarite tre punti:

  1. Esistono sconti a scaglioni? Di solito sopra i 10TB/mese c'è uno sconto significativo
  2. Il traffico interno cross-region conta come egress?
  3. I cache hit CDN contano come egress? Alcuni vendor li includono nel traffico fatturato

Ci sono cascato: ambiente di test con 200GB/mese, nessun problema. Al lancio in produzione il traffico è schizzato a 8TB, la fattura aveva uno zero in più. Non avevo chiarito il comportamento di overage prima della firma del contratto.

Tre specifiche spesso trascurate nel procurement italiano

Queste tre voci non compaiono nelle classiche tabelle comparative, ma fanno male nell'uso reale.

EXIF e Metadata: dal GDPR alle foto condivise su WhatsApp

L'EXIF contiene coordinate GPS, numero di serie della fotocamera, data e ora dello scatto. Caricando su un image hosting pubblico, questi dati viaggiano di default.

Nel contesto B2B chiedete:

  • Rimozione EXIF selettiva (togliere GPS, mantenere copyright)?
  • Supporto operazioni IPTC / XMP metadata?
  • Elaborazione metadata in fase di upload o on-the-fly?

Il GDPR classifica le coordinate GPS come dati personali. Un trattamento inadeguato trasferisce il rischio di compliance direttamente alla vostra azienda.

Autenticazione mista: OAuth2 + API Key

I vecchi servizi di image hosting offrono solo API Key. Il B2B moderno richiede un approccio misto:

  • Sistema a sistema interno: API Key + IP allowlist
  • Frontend SPA per l'utente: OAuth2 PKCE flow
  • Accesso temporaneo: Pre-signed URL

Se il vendor vi dà una singola API Key permanente e vi lascia gestire gli scope, sta scaricando il rischio di sicurezza su di voi. Una soluzione adeguata deve supportare scoped token, rotazione automatica e API di revoca.

Hard delete e conservazione dati

Il GDPR impone che il "diritto all'oblio" venga eseguito entro 30 giorni. Molti image hosting dichiarano "cancelleremo i dati," ma in realtà fanno soft delete — l'oggetto resta in S3, nella cache CDN, nei nastri di backup.

In fase di acquisto verificate:

  1. La cancellazione è prevista nel DPA?
  2. Il ciclo di backup prevede un meccanismo di cancellazione corrispondente?
  3. Possono fornire una prova di avvenuta cancellazione?

Ho gestito un caso reale: il cliente ha ricevuto una richiesta di cancellazione GDPR, ma il cold storage backup del vendor aveva una retention di 365 giorni non modificabile. Tre mesi di scambi con l'ufficio legale.

Posizionamento di lpic.cc

Devo essere onesto: lpic.cc al momento non è una soluzione enterprise B2B.

Ci posizioniamo per sviluppatori individuali, blogger e condivisione nei forum — upload gratuito, protezione con password, retention 30 giorni. Il backend usa cloud object storage + API custom. L'architettura implementa alcune delle specifiche discusse qui (pre-signed URL, webhook, elaborazione EXIF), ma non offriamo SLA enterprise, certificazione SOC 2 né DPA.

Se siete technical lead alla ricerca di un image hosting production-grade, usate questa checklist per valutare Cloudinary, imgix, Cloudflare Images, ImageKit. Se cercate una soluzione leggera per uso personale o piccoli team, lpic.cc può fare al caso vostro — provate un upload gratuito per capire se risponde alle vostre esigenze.

FAQ

Q1: Un piccolo team ha bisogno di un image hosting enterprise?

Non necessariamente. Con utenti attivi mensili sotto i 10.000 e traffico inferiore a 500GB/mese, Cloudflare R2 + Workers basta. Il costo si mantiene sotto i $5/mese. Il valore di una soluzione enterprise sta nello SLA, compliance e supporto — cose di cui un piccolo team potrebbe non avere bisogno. Ma se servite clienti B2B e il loro contratto prevede requisiti DPA, non c'è alternativa.

Q2: La compatibilità S3 conta davvero?

Moltissimo. L'API S3 è lo standard de facto: supportarla significa poter usare SDK maturi, Terraform provider, strumenti di backup. Non supportarla significa restare bloccati nell'API proprietaria del vendor, con costi di migrazione futuri elevatissimi. È il classico indicatore di vendor lock-in.

Q3: Webhook vs polling — perché servono i webhook?

Il polling interroga il server ogni N secondi con "hai finito?", il webhook è il server che vi notifica al completamento. La differenza sta nella latenza (secondi vs millisecondi) e nel costo (le vostre API call vs zero). Per eventi come upload completato, transcodifica terminata o scansione virus, senza webhook la UX in tempo reale è impossibile.

Q4: 99.9% vs 99.99% di SLA: fa davvero differenza?

In numeri: 43 minuti vs 4 minuti al mese. L'impatto reale dipende dal business. Se sono immagini prodotto nel flusso di checkout e-commerce, ogni minuto è fatturato perso. Se sono immagini del manuale interno dipendenti, anche il 99% va bene. Allineate il requisito SLA all'impatto reale sul business, senza inseguire il numero più alto.

Q5: Cloudflare R2 con zero egress è la scelta ovvia?

No. Lo zero egress di R2 vale solo all'interno della rete Cloudflare (tramite Workers o CDN). Se estraete dati da un altro cloud, i costi ci sono. Inoltre le operazioni Class A (scrittura) di R2 non sono economiche — in scenari write-heavy e read-light potrebbe non convenire. Calcolate il costo totale in base al vostro rapporto read/write.

Riferimenti

#Image Hosting API#S3 Compatibile#SLA#CDN#Webhook#Procurement Aziendale#DevOps#Signed URL#GDPR
H

Scritto da

Harvey Zhang

Co-Fondatore & CTO

Ingegnere backend diventato architetto, offre un'analisi tecnica approfondita dell'infrastruttura di hosting di immagini.