---
term: 'Hosting cloud multi-tenant'
seoTitle: 'Hosting cloud multi-tenant: isolamento, costi e pattern'
headline: 'Che cos''è l''hosting cloud multi-tenant?'
slug: hosting-cloud-multi-tenant
category: cloud-architecture
shortDefinition: 'L''hosting cloud multi-tenant è un modello in cui gli stessi server e software servono molti clienti, con isolamento logico tra i tenant.'
relatedTerms:
  - multi-tenant-database-architecture
  - tenant-isolation
  - infrastructure-as-a-service
  - row-level-security
contrastsWith:
  - multi-tenant-database-architecture
faq:
  - question: 'Che cos''è la multi-tenancy nel cloud computing?'
    answer: 'Un''architettura in cui una singola istanza software – e l''infrastruttura che la sostiene – serve più clienti, chiamati tenant. I tenant condividono calcolo, archiviazione e una stessa codebase, ma i dati di ciascuno sono isolati logicamente e invisibili agli altri. È il modello che fa funzionare l''economia del cloud: aggiungere un cliente è una modifica di configurazione, non hardware in più.'
  - question: 'Qual è la differenza tra hosting multi-tenant e single-tenant?'
    answer: 'Il single-tenant assegna a ogni cliente un''istanza e un database dedicati – controllo massimo e isolamento fisico, a un prezzo più alto, con ogni istanza patchata e aggiornata separatamente. Il multi-tenant condivide un''unica istanza tra tutti i clienti – costo per tenant più basso, un solo ciclo di aggiornamenti per tutti e isolamento imposto in modo logico anziché fisico. La maggior parte dei SaaS gira in multi-tenant; i clienti regolamentati o molto grandi a volte giustificano il single-tenant.'
  - question: 'Un cloud multi-tenant è sicuro?'
    answer: 'Sì, quando l''isolamento è imposto correttamente – i tenant non possono vedere i dati degli altri. I rischi residui sono i bug applicativi che saltano un filtro di tenant e il raggio d''impatto più ampio di un sistema condiviso: una violazione o un disservizio può toccare ogni tenant. Per questo i progetti più solidi spingono l''isolamento fino al livello dati – policy a livello di riga e controllo degli accessi per oggetto – invece di affidarsi al fatto che ogni query si ricordi la clausola WHERE.'
  - question: 'Che cos''è il problema del noisy neighbor?'
    answer: 'L''uso intensivo di CPU, memoria o I/O condivisi da parte di un tenant, che degrada le prestazioni di tutti gli altri sulla stessa infrastruttura. Le contromisure comprendono quote e rate limiting per tenant, lo scheduling delle risorse, l''autoscaling e – quando un tenant gira costantemente a pieno regime – il partizionamento del componente in contesa, di norma il database, in un silo proprio.'
  - question: 'Come si tengono separati i dati dei tenant in un cloud condiviso?'
    answer: 'A livello di database esistono tre pattern canonici: uno schema condiviso in cui ogni riga porta un identificatore di tenant (densità massima, di norma abbinato alla sicurezza a livello di riga), uno schema per tenant in un database condiviso e un database per tenant (isolamento più forte, costo più alto). Sotto, l''infrastruttura aggiunge i propri livelli: macchine virtuali, namespace dei container e micro-VM tengono separati i carichi di lavoro dei tenant.'
  - question: 'La multi-tenancy è la stessa cosa della virtualizzazione?'
    answer: 'No. La virtualizzazione divide una macchina fisica in macchine virtuali isolate; la multi-tenancy condivide una singola istanza applicativa tra molti clienti. Le due sono complementari – la virtualizzazione è uno dei meccanismi con cui i provider isolano i carichi di lavoro dei tenant, mentre la multi-tenancy è il pattern architetturale che decide, a monte, che cosa viene condiviso.'
  - question: 'Quando conviene scegliere invece il single-tenant?'
    answer: 'Quando regimi normativi severi o contratti impongono l''isolamento fisico o la residenza dei dati, quando un cliente ha bisogno di una personalizzazione profonda per istanza, o quando le prestazioni garantite per un account di alto valore contano più del costo. La risposta sempre più diffusa è la tenancy mista: mettere in pool la maggior parte dei tenant su infrastruttura condivisa e in silo i pochi che sono regolamentati, enormi o rumorosi.'
  - question: 'Perché la multi-tenancy conta per il SaaS?'
    answer: 'È l''architettura su cui si regge il software in abbonamento. Un''unica codebase serve ogni cliente, così correzioni e funzionalità arrivano a tutti i tenant nello stesso momento; l''utilizzo dell''hardware si distribuisce su tutta la base clienti; e l''onboarding di un nuovo cliente costa quasi nulla. Senza multi-tenancy, ogni abbonamento porterebbe il prezzo di server dedicati e di una manutenzione per singolo cliente.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'The NIST Definition of Cloud Computing (SP 800-145)'
    url: 'https://csrc.nist.gov/pubs/sp/800/145/final'
  - name: 'Multitenancy (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Multitenancy'
  - name: 'PostgreSQL Row Security Policies'
    url: 'https://www.postgresql.org/docs/current/ddl-rowsecurity.html'
  - name: 'Row-Level Security and Multi-Tenancy on MongoDB (Back4app Engineering)'
    url: 'https://www.back4app.com/multi-tenant-mongodb-row-level-security'
cta:
  title: 'Isolamento dei tenant senza impianti da costruire'
  text: 'Back4app impone l''accesso per tenant nel livello dati – ACL su ogni oggetto, ruoli per tenant e permessi di classe – così l''isolamento non dipende dal fatto che ogni query si ricordi un filtro. Avvia un backend multi-tenant sul piano gratuito.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-14'
translationKey: multi-tenant-cloud-hosting
---

**L'hosting cloud multi-tenant è un modello in cui gli stessi server e software servono molti clienti, con isolamento logico tra i tenant.** Vale l'immagine del condominio: gli appartamenti condividono struttura, impianto idraulico ed elettricità, ma ogni porta ha la sua chiave. L'alternativa – l'hosting single-tenant – è una casa indipendente: controllo totale, affitto più alto e una quota di manutenzione più grande che resta in capo a chi la abita.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Server e software condivisi, molti clienti, dati separati logicamente |
| Perché esiste | Condividere l'infrastruttura è ciò che rende possibili i prezzi del cloud |
| La parte difficile | L'isolamento – un tenant non deve mai vedere i dati degli altri né sentirne il carico |
| vs. single-tenant | Più economico, onboarding più rapido, un solo ciclo di aggiornamenti – al prezzo della separazione fisica |
| Dove va l'isolamento | Nel livello dati – non nella clausola WHERE di ogni query |

## Come restano separati i dati dei tenant

Ogni sistema multi-tenant risponde prima di tutto a una domanda: dove vive l'isolamento? A livello di database esistono tre pattern canonici – schema condiviso, uno schema per tenant e un database per tenant. Lo schema condiviso è il cavallo da tiro, ed è più sicuro quando è *il database stesso* a imporre il confine:

```sql
-- Modello 1: schema condiviso – ogni riga porta il suo tenant
CREATE TABLE invoices (
  id        bigserial PRIMARY KEY,
  tenant_id uuid NOT NULL,
  amount    numeric(10,2) NOT NULL
);

-- L'isolamento si impone nel database, non in ogni query
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);
```

Con una [policy a livello di riga](https://www.postgresql.org/docs/current/ddl-rowsecurity.html), una query che dimentica il filtro del tenant non restituisce nulla invece di restituire tutto – la modalità di guasto passa dalla fuga di dati alla pagina vuota.

Su un Backend as a Service lo stesso principio si esprime come controllo degli accessi per oggetto anziché come policy SQL. Ogni record porta una ACL che nomina il ruolo del tenant autorizzato a vederlo, e la piattaforma la impone a ogni richiesta:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const doc = new Parse.Object('Invoice');
doc.set('amount', 480);

const acl = new Parse.ACL();
acl.setPublicReadAccess(false); // invisible to every other tenant
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final doc = ParseObject('Invoice')..set('amount', 480);

final acl = ParseACL();
acl.setPublicReadAccess(allowed: false);
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var doc = Invoice()
doc.amount = 480

var acl = ParseACL()
acl.publicRead = false
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
doc.ACL = acl
doc.save { _ in }
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val doc = ParseObject("Invoice").apply { put("amount", 480) }

val acl = ParseACL().apply {
  publicReadAccess = false
  setRoleReadAccess("tenant-acme", true)
  setRoleWriteAccess("tenant-acme", true)
}
doc.acl = acl
doc.saveInBackground()
```

## L'isolamento è uno spettro, non un interruttore

Tra "tutto condiviso" e "tutto dedicato" stanno le tre forme di deployment tra cui sceglie la maggior parte dei sistemi reali:

```mermaid
flowchart LR
  accTitle: Spettro di isolamento dei tenant
  accDescr: Tre forme di deployment, da pool, dove tutti i tenant condividono l'app e il database, passando per bridge, con app condivisa ma dati isolati, fino a silo, uno stack dedicato per tenant.
  A["Pool<br/>tutti i tenant condividono app + database<br/>(densità massima, costo minimo)"] --> B["Bridge<br/>app condivisa, dati isolati<br/>(uno schema o un database per tenant)"]
  B --> C["Silo<br/>stack dedicato per tenant<br/>(isolamento massimo, costo massimo)"]
```

Le piattaforme mature li combinano: pool per i molti tenant piccoli, bridge per quelli di taglia media, silo per i pochi che sono regolamentati, enormi o rumorosi. L'errore è trattare la scelta come globale – si può fare per fascia di offerta, e anche per singolo componente.

## Hosting multi-tenant vs. single-tenant

| Dimensione | Multi-tenant | Single-tenant |
| --- | --- | --- |
| Costo per tenant | Basso – l'infrastruttura è ammortizzata | Alto – stack dedicato per cliente |
| Isolamento dei dati | Logico (policy, ACL, schemi) | Fisico (istanza e database separati) |
| Raggio d'impatto | Un incidente può toccare molti tenant | Circoscritto a un solo cliente |
| Noisy neighbor | Possibile; richiede quote e throttling | Assente – le risorse sono private |
| Aggiornamenti | Un solo rollout aggiorna tutti | Ogni istanza va patchata separatamente |
| Onboarding | Modifica di configurazione, minuti | Provisioning, da ore a settimane |
| Personalizzazione | Configurazione e feature flag | Modifiche profonde, possibili per istanza |
| Aderenza alla compliance | Adeguata nella maggior parte dei casi; attriti sotto regimi severi | Preferito dove l'isolamento stretto è un obbligo |
| Uso tipico | SaaS, BaaS, piattaforme cloud condivise | Settori regolamentati, fasce enterprise premium |

## Due significati da tenere distinti

"Hosting cloud multi-tenant" si usa a due altitudini diverse, e gran parte delle spiegazioni le confonde:

- **Come fascia di hosting:** l'hosting condiviso – il proprio carico di lavoro gira sulle stesse macchine fisiche di quelli di altri clienti. È la modalità predefinita di ogni cloud pubblico; la [definizione del NIST](https://csrc.nist.gov/pubs/sp/800/145/final) elenca il pooling delle risorse tra tenant come caratteristica essenziale del cloud computing stesso.
- **Come architettura applicativa:** il *proprio* prodotto serve i suoi clienti da un unico backend condiviso – il modo in cui si costruisce il software in abbonamento. Qui il padrone di casa è chi sviluppa, e l'isolamento dei tenant diventa una sua responsabilità: è il punto in cui entrano in gioco i pattern descritti sopra.

I due si compongono: un prodotto SaaS – multi-tenancy, cioè la condivisione di una stessa istanza tra più tenant, a livello applicativo – gira di norma su infrastruttura cloud condivisa, multi-tenancy a livello di hosting, e ogni livello isola i propri tenant.

## Il problema del noisy neighbor

Condividere significa contesa: l'importazione massiva di un tenant può rallentare il checkout di un altro. Le contromisure standard, in ordine crescente:

1. **Quote e rate limiting per tenant** – mettere un tetto a quanto ogni tenant può consumare per finestra temporale.
2. **Scheduling delle risorse e autoscaling** – assorbire i picchi prima che diventino la latenza di qualcun altro.
3. **Separazione dei carichi di lavoro** – spostare i job pesanti (export, analytics) su code in background, fuori dal percorso della richiesta.
4. **Siloing parziale** – quando un tenant gira costantemente a pieno regime, dare al componente in contesa (di norma il database) una partizione propria e lasciare il resto in pool.

## Casi d'uso tipici

- **Prodotti SaaS.** Ogni app in abbonamento che serve tutti i clienti da un'unica codebase – il caso canonico, e la ragione per cui il pattern esiste.
- **BaaS e hosting di piattaforma.** Le piattaforme fanno girare migliaia di app su infrastruttura condivisa e isolata, così che il provisioning di ogni app costi quasi nulla – è il modello dietro le offerte gratuite.
- **Applicazioni B2B con spazi di lavoro per tenant.** Un solo deployment, molte organizzazioni clienti, ciascuna con i propri utenti, ruoli e confine dei dati.
- **Piattaforme interne.** Un unico deployment di analytics o di strumenti condiviso tra i reparti, isolato per team.
- **Agenzie che gestiscono molte app per i clienti.** Piattaforma condivisa sotto, un backend isolato per cliente sopra.

## Multi-tenant, single-tenant o misto? Matrice decisionale

| Scegliere multi-tenant quando… | Scegliere single-tenant quando… | Scegliere il misto quando… |
| --- | --- | --- |
| Si servono molti clienti con un unico prodotto | Normative o contratti impongono l'isolamento fisico | La maggior parte dei tenant è standard, pochi sono regolamentati |
| Il costo per cliente deve tendere a zero | L'SLA di un cliente giustifica capacità dedicata | Un tenant è 100× più grande della mediana |
| Serve un solo ciclo di aggiornamenti per tutti | La personalizzazione profonda per cliente è il prodotto | Serve una fascia di prezzo premium "dedicata" |
| L'onboarding deve essere self-service e istantaneo | I clienti si contano sulle dita di una mano | Un tenant rumoroso ha bisogno di un database proprio |

Conviene partire dal multi-tenant e guadagnarsi l'uscita un tenant alla volta – innestare la tenancy a posteriori su una codebase single-tenant è molto più difficile che mettere in silo, più avanti, un singolo cliente troppo esigente.

## Limiti e trade-off

- **L'isolamento vale quanto la sua applicazione.** Un filtro di tenant dimenticato nel codice applicativo è la classica fuga di dati tra tenant. Il confine va spinto nel livello dati – policy a livello di riga, ACL per oggetto – così che la piattaforma fallisca in modo chiuso.
- **Raggio d'impatto condiviso.** Un disservizio, un deployment sbagliato o una violazione possono colpire tutti i tenant insieme. I rollout a scaglioni e i backup per tenant riducono l'impatto, non la condivisione.
- **I noisy neighbor sono strutturali.** Quote e scheduling gestiscono la contesa; solo il siloing parziale la elimina, ai prezzi di un silo parziale.
- **Tetto alla personalizzazione.** I tenant condividono un'unica codebase, quindi il comportamento specifico di ciascuno vive nella configurazione e nei feature flag – un vincolo che i clienti single-tenant non hanno.
- **Contesto del tenant in ogni punto.** Ogni query, chiave di cache, job e riga di log deve conoscere il tenant; la complessità si sposta dall'infrastruttura all'applicazione, ed è esattamente il peso che l'isolamento gestito nel livello dati esiste per assorbire.

## L'hosting multi-tenant su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È multi-tenant a entrambe le altitudini. Come piattaforma, fa girare migliaia di backend applicativi isolati su infrastruttura condivisa – è la ragione per cui il provisioning di un nuovo backend richiede pochi minuti sull'offerta gratuita. Per i tenant dell'applicazione di chi sviluppa, l'isolamento è una feature del livello dati e non una convenzione: ogni oggetto porta una ACL, i ruoli raggruppano gli utenti per tenant e i permessi di classe fissano regole valide per tutto lo schema, tutto imposto da Back4app a ogni richiesta. L'[approfondimento tecnico sulla sicurezza a livello di riga](https://www.back4app.com/multi-tenant-mongodb-row-level-security) mostra il pattern completo su un database documentale – senza richiedere alcuna disciplina sulla clausola WHERE.