Stai predisponendo un server dedicato a SQL Server e ti chiedi se acquistare CAL per i PC che si connetteranno? Questa guida pratica spiega quando servono le CAL, come scegliere tra Per Core e Server + CAL e come restare compliant in ambienti fisici, virtualizzati e cloud.
Domanda principale
Devo acquistare CAL per i PC che accederanno ai database? Dipende dal modello di licenza scelto per SQL Server:
- Se licenzi Per Core: non servono CAL. Il diritto d’accesso è incluso nei core licenziati, indipendentemente dal numero di utenti o dispositivi.
- Se licenzi Server + CAL: sì, serve una CAL per ogni utente oppure dispositivo che accede (anche indirettamente) al motore SQL.
La scelta del modello determina quindi se devi o meno gestire e acquistare le CAL per i client.
Modelli di licenza disponibili
| Modello | Quando si usa | Impatto CAL |
|---|---|---|
| Per Core | Scenari con numero elevato, variabile o non prevedibile di utenti/dispositivi (es. applicazioni web, API pubbliche, molte postazioni) | Nessuna CAL da acquistare: il diritto d’accesso è già incluso nei core licenziati. |
| Server + CAL | Contesti con un numero limitato e facilmente quantificabile di utenti o dispositivi (es. reparto specifico, piccole aziende) | Una CAL per ogni utente o dispositivo che accede direttamente o indirettamente al motore SQL. Scegli: • User CAL se le persone usano più dispositivi • Device CAL se più persone condividono pochi PC |
Regola generale — Paga i core se vuoi semplicità e scalabilità “illimitata”; scegli Server + CAL se il numero di accessi è ridotto e stabile, perché può risultare economicamente più vantaggioso.
Come scegliere tra User CAL e Device CAL
- User CAL: ideale se il personale accede da più dispositivi (PC, laptop, smartphone, terminal server) o in mobilità. Si licenzia la persona, non i device.
- Device CAL: efficace in scenari con pochi dispositivi condivisi da molti utenti (es. postazioni a turni, chioschi, reparti produttivi).
- Mix consentito: nelle realtà miste, è legittimo combinare User e Device CAL per ottimizzare i costi, purché ogni accesso sia coperto da una delle due.
Accessi indiretti, multiplexing e “utenti finali”
Nel modello Server + CAL, conta chi sta dietro l’applicazione. Anche se gli utenti si connettono tramite un middleware (web server, servizio REST, ETL, reportistica), se l’azione genera query verso SQL Server è richiesto che l’utente finale disponga di una CAL. Il cosiddetto multiplexing (pool di connessioni, code, servizi che “mediano” gli accessi) non elimina il fabbisogno di CAL. Analoga logica per bot e utenze di servizio: se l’accesso rappresenta un individuo o dispositivo reale, la CAL va dimensionata di conseguenza.
Eccezioni e integrazioni utili
- Uso puramente interno — Anche le connessioni “interne” richiedono CAL con il modello Server + CAL; non esiste un’esenzione automatica solo perché i database non sono esposti verso l’esterno.
- SQL Express e Developer
- Express è gratuita ma ha limiti significativi (tipicamente 10 GB per database, memoria ridotta e limitazioni CPU). Va bene per micro-scenari o learning, non per carichi produttivi crescenti.
- Developer è gratuita solo per sviluppo e test; non è licenziata per produzione.
- Software Assurance (SA) — Oltre agli upgrade di versione, in molte edizioni concede diritti di fail‑over per istanze passive e vantaggi in ambienti virtualizzati. È un fattore da includere nella comparazione.
- AmbientI virtualizzati
- Per Core: licenzia i core logici della VM (minimo 4 core per VM/istanza) oppure tutti i core fisici dell’host (con SA si ottiene la flessibilità di eseguire un numero illimitato di VM SQL sull’host coperto, secondo i termini dell’edizione).
- Server + CAL: ogni VM che esegue SQL richiede una licenza server, più le CAL per tutti gli utenti/dispositivi che vi accedono.
- Alternative PaaS — Se la compliance è onerosa, valutare soluzioni gestite (es. Azure SQL Database o servizi equivalenti) dove la componente di licensing è generalmente inclusa nel costo del servizio. Attenzione però a limiti, modelli di scalabilità e feature set rispetto a SQL Server “full”.
Procedura consigliata
- Censisci numero di utenti e dispositivi che accederanno al database, oggi e nei prossimi 3–5 anni (inclusi partner/esterni, turni, smart working).
- Stima i costi: confronta (a) somma di licenza Server + CAL obbligatorie vs. (b) licenza Per Core necessaria (minimo 4 core per istanza/VM).
- Valuta l’espansione: se l’organizzazione può crescere rapidamente o se esistono applicazioni web pubbliche, il modello Per Core è in genere più sicuro e lineare.
- Allinea all’hardware: CPU con molti core ma pochi utenti? Server + CAL potrebbe risultare più economico. Viceversa, tanti accessi imprevisti → Per Core.
- Documenta le scelte: conserva le evidenze (inventario utenti/dispositivi, diagrammi d’architettura, contratti e fatture). In caso di audit, servono prove.
Casi pratici (confronti guidati)
Piccola azienda con 20 utenti interni
Scenario: un’unica istanza Standard, carichi leggeri, nessun accesso esterno. Il reparto usa due PC condivisi in magazzino, tutti gli altri hanno laptop personali.
- Server + CAL con 18 User CAL e 2 Device CAL ottimizza i costi e copre i turni sui PC condivisi.
- Per Core avrebbe senso solo se si prevede crescita a breve (nuovi utenti, portale clienti o API).
E‑commerce e API pubbliche
Scenario: il database è alimentato da un sito B2C e da API esposte a partner. Gli accessi sono estesi e fluttuanti.
- Per Core è la scelta naturale: nessun conteggio utenti/partner, niente CAL da gestire, scalabilità semplificata.
Produzione con 50 postazioni su tre turni
Scenario: 25 terminali fissi in reparto, 10 PC back‑office, 15 palmari. Gli operatori ruotano.
- Server + CAL con 25 Device CAL per i terminali + 10 Device CAL per i PC + 15 Device CAL per i palmari può costare meno di licenziare i core, perché i device sono noti e stabili.
Business Intelligence interna con report distribuiti
Scenario: SSRS/Power BI Report Server pubblica report generati da SQL Server. 120 dipendenti consultano i report via intranet.
- In Server + CAL ogni utente che visualizza report basati su dati SQL richiede una User CAL (accesso indiretto). Se gli utenti crescono, valutare Per Core.
Ambienti virtualizzati & container
La virtualizzazione sposta il focus da “server” a “core”. Tre modelli tipici:
- Licenza per VM (Per Core): licenzia i core assegnati alla VM (minimo 4). Flessibile e prevedibile se il numero di VM è contenuto.
- Licenza per host fisico (Per Core + SA): licenzi tutti i core fisici e ottieni diritti di eseguire più VM SQL sullo stesso host, entro i limiti contrattuali. Ideale per cluster e densi ambienti virtuali.
- Server + CAL in VM: ogni VM che esegue SQL richiede una licenza server, e tutti gli utenti/dispositivi che accedono devono avere CAL. Con molte VM e molti utenti, la complessità cresce rapidamente.
Container: se SQL Server gira in container, la logica segue quella delle VM: licenzi i core allocati al container/host secondo il modello scelto; il conteggio delle CAL in Server + CAL non cambia.
Alta disponibilità e disaster recovery
- Replica/istanza passiva: con SA, è in genere consentita una istanza di fail‑over passivo senza licenza core addizionale per ogni istanza attiva coperta, purché non serva carichi di lavoro in lettura.
- Replica di sola lettura: se usata per reporting o query, richiede licenze (core o server+CAL) come una istanza attiva.
- Always On: conta quante repliche servono richieste applicative reali; le passive di puro standby con SA possono avere trattamento distinto rispetto alle attive o di sola lettura.
Annota nella documentazione di licensing quali repliche sono attive, di sola lettura e passive. È cruciale in audit.
Reportistica, ETL e analitiche
- SSRS: se installato sullo stesso server della tua istanza SQL, è coperto dalla stessa licenza. Se è su un server separato, anche quel server va licenziato. In Server + CAL, gli utenti che consultano report basati su dati SQL necessitano di CAL.
- SSIS: i pacchetti che estraggono/caricano dati in SQL attivano regole di accesso indiretto. Se l’esecuzione è su macchina separata, valuta la licenza di quell’host.
- SSAS: analoghe considerazioni; in Server + CAL, gli utenti che consumano dati originati da SQL possono ricadere nel fabbisogno di CAL.
Utenti esterni, partner e filiali
- Partner/fornitori: se accedono ai tuoi dati SQL (anche via portali), sono “utenti” ai fini delle CAL. Con volumi non prevedibili, Per Core semplifica.
- Consociate/filiali: la condivisione tra entità legali diverse può richiedere contratti specifici. Mappa fin da subito chi usa cosa.
- Account di servizio: non “nascondono” gli utenti finali. La CAL serve per la persona o il device reale che origina la richiesta.
Checklist di conformità
- Inventario aggiornato di istanze, VM e host (con numero di core, edizione/versione).
- Elenco di utenti e dispositivi che accedono (diretti e indiretti), con nota su esterni/partner.
- Documentazione di architettura (middleware, reportistica, API), con indicazione degli accessi indiretti.
- Fatture, contratti e diritti SA associati a ogni licenza.
- Registro di repliche (attive, sola lettura, passive) e relativo modello di licenza.
- Procedura per onboarding di nuovi utenti/progetti che accedono a SQL.
Guida rapida alla scelta (albero decisionale in testo)
- Accessi imprevedibili o numerosi (web, API, clienti esterni)? → Per Core.
- Numero ristretto e stabile di utenti/dispositivi noti? → Server + CAL.
- Molti dispositivi condivisi? → Prediligi Device CAL.
- Molti utenti multi‑device? → Prediligi User CAL.
- Virtualizzazione intensa/cluster? → Per Core su host con SA per massima flessibilità.
Strumenti di stima (formule e metodo)
Per non vincolarti a listini variabili, usa un approccio parametrico con valori ipotetici:
- Scenario Server + CAL = PrezzoLicenzaServer + (NumeroCAL × PrezzoCAL)
- Scenario Per Core = (NumeroCore arrotondato a multipli consentiti, min. 4) × PrezzoPerCore
Confronta i due risultati, includendo eventualmente il costo/valore di SA (aggiornabilità, fail‑over, mobilità VM) e i costi gestionali di mantenere un inventario CAL accurato.
Template di inventario (esempio)
| Ambiente | Istanza/VM | Core/CPU | Edizione | Modello | Utenti/Dispositivi | Note (repliche, SA, ecc.) |
|---|---|---|---|---|---|---|
| Produzione | SQL‑PRD‑01 | 4 vCore | Standard | Per Core | — | API pubbliche; niente CAL |
| Produzione | SQL‑PRD‑02 | — | Standard | Server + CAL | 35 User CAL | Reportistica interna |
| DR | SQL‑DR‑01 | 4 vCore | Standard | Per Core | — | Replica passiva con SA |
Errori da evitare
- Sottostimare gli accessi indiretti (report, servizi, automazioni) e quindi il numero di CAL necessarie.
- Confondere ambiente di test con produzione: Developer è solo per dev/test.
- Dimenticare il minimo di 4 core per VM/istanza nel modello Per Core.
- Repliche di sola lettura non licenziate: se servono query reali, vanno licenziate.
- Non allineare la scelta di licensing alla roadmap di crescita e ai requisiti di disponibilità.
Domande frequenti
Le CAL servono anche se accedo solo tramite un’app interna?
Sì, nel modello Server + CAL gli utenti dietro l’app sono comunque “accessi” verso SQL.
Gli utenti temporanei vanno conteggiati?
Sì. Se accedono, necessitano della relativa CAL (o conviene passare a Per Core).
Un bot o un servizio schedulato richiede CAL?
La CAL si riferisce al soggetto che origina la richiesta (utente o dispositivo). Se il servizio rappresenta accessi di più persone o device, vanno contati.
Posso miscelare User e Device CAL?
Certamente. È una buona pratica per ottimizzare i costi, purché ogni accesso sia coperto da una delle due.
Se metto SQL in cloud IaaS cambia qualcosa?
In IaaS valgono le stesse regole del licensing tradizionale. In PaaS gestito, la licenza è generalmente inclusa nel prezzo del servizio.
Riepilogo operativo
- Non è obbligatorio comprare CAL se adotti il licensing Per Core.
- Serve una CAL per ogni utente o dispositivo se scegli il modello Server + CAL, anche per accessi indiretti (applicazioni, servizi, report).
- Valuta attentamente crescita, numero di connessioni e il valore di SA/alta disponibilità prima di decidere.
Checklist finale per decidere oggi
- Conta utenti e device che accedono a SQL (inclusi partner e futuri progetti).
- Mappa gli accessi indiretti (report, API, ETL, RPA, servizi schedulati).
- Disegna lo scenario di virtualizzazione (VM/container, cluster, host) e la strategia di HA/DR.
- Confronta i costi: Server + CAL vs Per Core (4 core min per istanza/VM).
- Decidi e documenta (inventario, contratti, topologia, repliche).
Conclusioni
La domanda iniziale (“servono le CAL?”) ha una risposta netta: dipende dal modello di licenza scelto. Per Core azzera la gestione delle CAL e protegge da picchi e imprevedibilità degli accessi; Server + CAL premia gli scenari stabili e misurabili, specie quando i dispositivi sono pochi o condivisi. Il punto chiave è allineare licensing, architettura e prospettiva di crescita, includendo i benefici di Software Assurance e la natura degli accessi indiretti. Con un inventario accurato e un confronto numerico trasparente, la scelta giusta diventa evidente e sostenibile nel tempo.
Appendice compatta
- Per Core: licenzia i core (min 4 per VM/istanza). Nessuna CAL.
- Server + CAL: licenza server + una CAL per ogni utente o dispositivo (anche indiretti).
- Express/Developer: gratis ma con limiti (Express) o non in produzione (Developer).
- SA: upgrade, mobilità e diritti di fail‑over su istanze passive in molte edizioni.
- Virtualizzazione: per VM (core logici) o per host (core fisici con SA); in Server + CAL ogni VM SQL richiede la sua licenza server.
- PaaS: licensing normalmente incluso nel prezzo del servizio, ma attenzione a feature e limiti.