---
term: 'Infrastructure as a Service (IaaS)'
seoTitle: 'IaaS (Infrastructure as a Service): guida completa'
headline: 'Che cos''è IaaS (Infrastructure as a Service)?'
slug: infrastructure-as-a-service
category: cloud-architecture
shortDefinition: 'IaaS è un modello cloud che affitta a richiesta risorse di calcolo fondamentali – macchine virtuali, archiviazione, rete – con fatturazione a consumo.'
relatedTerms:
  - paas-vs-baas
  - baas-vs-custom-backend
  - multi-tenant-cloud-hosting
  - cloud-vendor-lock-in
  - iaas-paas-baas-faas
contrastsWith:
  - paas-vs-baas
faq:
  - question: 'Che cos''è IaaS, in parole semplici?'
    answer: 'Affittare computer invece di comprarli. Un provider IaaS possiede i data center, i server fisici e la rete; si affittano a ore macchine virtuali, archiviazione e reti, e tutto ciò che sta dal sistema operativo in su resta da gestire. La spesa in conto capitale diventa spesa corrente, e il provisioning richiede minuti invece di cicli di acquisto.'
  - question: 'Con IaaS, cosa gestisce il provider e cosa il cliente?'
    answer: 'Il provider manda avanti il livello fisico: data center, server, hardware di archiviazione, rete e la virtualizzazione che affetta tutto questo in unità affittabili. Al cliente resta ciò che sta sopra l''hypervisor: sistema operativo, applicazione delle patch, runtime, middleware, applicazioni e dati. Nel modello di responsabilità condivisa il provider mette in sicurezza il cloud; il cliente mette in sicurezza ciò che ci carica dentro.'
  - question: 'IaaS è la stessa cosa della virtualizzazione?'
    answer: 'No: la virtualizzazione è la tecnologia abilitante, IaaS è il modello di business costruito sopra. Gli hypervisor affettano macchine fisiche in macchine virtuali; IaaS avvolge quel meccanismo in self-service, misurazione dei consumi e consegna a consumo via internet. La virtualizzazione si può far girare anche in cantina: diventa IaaS quando qualcuno la affitta come servizio.'
  - question: 'Qual è la differenza tra IaaS e PaaS?'
    answer: 'La linea di gestione. IaaS consegna infrastruttura grezza e tutto ciò che va dal sistema operativo in su resta a carico del cliente – controllo massimo, carico operativo massimo. PaaS gestisce anche sistema operativo, runtime e middleware, quindi basta portare codice applicativo e dati. IaaS si sceglie per il controllo e gli stack su misura; PaaS per rilasciare più in fretta con meno ops.'
  - question: 'Quali sono i principali vantaggi di IaaS?'
    answer: 'Capacità elastica che segue la domanda, provisioning in pochi minuti, il passaggio dall''acquisto anticipato di hardware al pagamento a consumo, copertura geografica senza costruire data center e opzioni integrate di ridondanza e disaster recovery. Il filo conduttore: le decisioni sull''infrastruttura diventano reversibili, cosa che l''hardware fisico non è mai stato.'
  - question: 'Quali sono gli svantaggi di IaaS?'
    answer: 'L''elenco onesto che i fornitori saltano: fatture che salgono quando le risorse inutilizzate girano a vuoto, costi di egress per far uscire i dati, gli errori di configurazione della sicurezza come prima causa delle violazioni nel cloud, competenze operative da assumere o far crescere e il vendor lock-in attraverso i servizi proprietari adiacenti. IaaS rimuove l''hardware, non le operazioni.'
  - question: 'Quando conviene NON usare IaaS?'
    answer: 'Quando si finirebbe solo per ricostruire ciò che un''astrazione più alta fornisce già. Un backend applicativo standard – utenti, dati, archiviazione, API – assemblato a mano su VM affittate significa settimane di configurazione indifferenziata che un PaaS o un BaaS consegna in pochi minuti. IaaS si merita il posto per gli stack su misura, le migrazioni di sistemi legacy e il controllo imposto dalla conformità; per i carichi standard è di solito la strada più costosa.'
  - question: 'IaaS è pubblico, privato o ibrido?'
    answer: 'Esistono tutti e tre i modelli di deployment. IaaS pubblico raccoglie molti clienti su hardware condiviso – la forma standard e più economica. IaaS privato dedica l''infrastruttura a una sola organizzazione, per controllo o per conformità. L''ibrido mescola i due: tiene i carichi sensibili in privato e sfoga i picchi sulla capacità pubblica. Il modello di servizio è lo stesso; cambia il modello di tenancy.'
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: 'Infrastructure as a service (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Infrastructure_as_a_service'
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'Back4app documentation'
    url: 'https://www.back4app.com/docs'
cta:
  title: 'Salta del tutto l''infrastruttura'
  text: 'Back4app sta quattro pioli sopra le VM grezze: database, autenticazione, archiviazione e API arrivano pre-costruiti e gestiti, con Cloud Code per la logica personalizzata. Ottieni in pochi minuti, gratis, ciò che su IaaS avresti assemblato in settimane.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-02'
translationKey: infrastructure-as-a-service
---

**IaaS è un modello cloud che affitta a richiesta risorse di calcolo fondamentali – macchine virtuali, archiviazione, rete – con fatturazione a consumo.** La [definizione del NIST](https://csrc.nist.gov/pubs/sp/800/145/final) traccia il confine con precisione: il provider controlla l'infrastruttura fisica; il cliente controlla sistemi operativi, archiviazione e applicazioni distribuite. È il piolo più basso della scala del cloud – quello che sostituisce l'acquisto dei server con il loro affitto.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Macchine virtuali, archiviazione e reti a richiesta – l'hardware come servizio a consumo |
| Cosa resta da fare | Tutto ciò che sta dal sistema operativo in su: applicare patch, mettere in sicurezza, scalare, gestire |
| Il problema che risolve | Comprare, montare in rack e ammortizzare hardware fisico |
| Modello di fatturazione | Per ora-risorsa – flessibile, e implacabile con la capacità che gira a vuoto |
| L'avvertenza onesta | IaaS rimuove l'hardware, non le operazioni |

## Che aspetto ha l'uso di IaaS

L'esperienza per eccellenza è una macchina in pochi minuti – seguita da tutto ciò che una macchina ha sempre richiesto:

```bash
# Minuto uno: si affitta la macchina
$ cloud compute create --size medium --image ubuntu-24.04
   ✓ vm-7f3a running — 203.0.113.40

# Dal minuto due in poi: tutto il resto resta in casa
$ ssh admin@203.0.113.40
$ apt update && apt upgrade          # le patch: in casa
$ apt install nginx postgresql       # lo stack: in casa
$ ufw allow 443 && configure-tls…    # la sicurezza: in casa
$ crontab -e                         # backup, rotazione, monitoring: in casa
```

Questo scambio – hardware in pochi minuti, operazioni per sempre – è tutto il modello. Per contrasto, ecco lo stesso obiettivo "mettere in piedi un backend" in cima alla scala, dove l'infrastruttura non affiora mai:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const note = new Parse.Object('Note');
note.set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched, no firewall rules
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final note = ParseObject('Note')
  ..set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var note = Note()
note.text = "Shipped without touching a VM"
note.save { result in
  if case .success = result { print("saved — zero infrastructure managed") }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val note = ParseObject("Note").apply {
  put("text", "Shipped without touching a VM")
}
note.saveInBackground { e ->
  if (e == null) Log.d("Note", "saved — zero infrastructure managed")
}
```

## Chi gestisce cosa

```mermaid
flowchart LR
  accTitle: La divisione delle responsabilità con IaaS
  accDescr: Il provider gestisce data center, server fisici, archiviazione, rete e virtualizzazione; il cliente gestisce sistema operativo, runtime, applicazioni e dati che stanno sopra.
  subgraph P["Gestisce il provider"]
    p1["Data center · server fisici<br/>archiviazione · rete · virtualizzazione"]
  end
  subgraph Y["Gestisce il cliente"]
    y1["OS · patch · runtime<br/>middleware · app · dati"]
  end
  P --> Y
```

Questa divisione è anche il modello di sicurezza: il provider mette in sicurezza *il cloud*, il cliente mette in sicurezza tutto ciò che sta *dentro*. Gli errori di configurazione sul lato cliente – bucket di archiviazione aperti, regole di firewall permissive, sistemi senza patch – sono la prima causa delle violazioni nel cloud, ed è per questo che il riquadro "gestisce il cliente" merita più rispetto di quanto se ne prenda di solito.

## IaaS vs. PaaS vs. BaaS vs. on-premises

| Dimensione | On-premises | IaaS | PaaS | BaaS |
| --- | --- | --- | --- | --- |
| Cosa si compra o affitta | L'hardware | Infrastruttura virtuale | Una piattaforma gestita | Un backend gestito |
| Cosa resta da gestire | Tutto | Dal sistema operativo in su | App + dati | Logica personalizzata + dati |
| Tempo di provisioning | Settimane–mesi | Minuti | Minuti | Minuti, backend incluso |
| Forma del costo | Spesa in conto capitale | Per ora-risorsa | Per istanza o fascia | Piano gratuito + piani |
| Controllo | Totale | Alto | Medio | Basso, per scelta |
| Carico operativo | Totale | Alto | Basso | Minimo |

Una precisazione che ritorna in ogni confronto "IaaS vs.": i [modelli serverless](https://martinfowler.com/articles/serverless.html) non sono una quarta colonna dello stesso tipo – astraggono l'*unità di calcolo* (per invocazione) invece del *livello di gestione*, ed è per questo che una piattaforma serverless può a sua volta girare su IaaS al di sotto.

## Casi d'uso tipici

- **Migrazioni lift-and-shift.** Le applicazioni server esistenti si spostano su VM affittate quasi senza modifiche – stesso stack, niente più cicli di rinnovo dell'hardware.
- **Stack su misura e legacy.** Runtime inusuali, software sotto licenza o messa a punto al livello del sistema operativo che le piattaforme gestite non permettono.
- **Controllo imposto dalla conformità.** Regimi normativi che richiedono di sapere e configurare esattamente che cosa gira sotto l'applicazione.
- **Carichi ad alte prestazioni e specializzati.** Flotte di GPU, elaborazione dati su larga scala e tutto ciò che ha requisiti a forma di hardware.
- **Disaster recovery e capacità di picco.** Ambienti di standby e margine per i picchi di traffico che sarebbe rovinoso possedere come hardware a riposo.

## Conviene costruire su IaaS? Matrice decisionale

| Scegliere IaaS quando… | Scegliere un piolo più alto quando… |
| --- | --- |
| Serve il controllo al livello del sistema operativo o uno stack su misura | Le esigenze di backend sono standard (utenti, dati, file, API) |
| Esiste già un team di ops competente | Il team è composto solo da sviluppatori |
| Si migrano carichi server esistenti così come sono | Si costruisce qualcosa di nuovo da zero |
| La conformità impone il controllo dell'infrastruttura | Il time-to-market domina ogni altra considerazione |
| Una scala costante rende decisivi i prezzi unitari grezzi | Il carico è piccolo, a picchi o esplorativo |

Il motivo che vale la pena interiorizzare: IaaS raramente sbaglia quando si tratta di *spostare* sistemi esistenti, e raramente ha ragione quando si tratta di *avviarne* di standard – un backend applicativo nuovo assemblato a mano su VM sono settimane di lavoro che i pioli più alti consegnano prima di pranzo.

## Limiti e trade-off

- **Le operazioni restano in casa.** Applicazione delle patch, hardening, scalabilità, backup, monitoring: il runbook sopravvive intatto, è cambiato solo l'hardware sotto di esso.
- **Lo shock da fattura è un problema di competenze che si eredita.** Istanze a riposo, VM sovradimensionate e archiviazione dimenticata fatturano ventiquattr'ore al giorno; la gestione dei costi diventa una disciplina permanente.
- **L'egress è il pedaggio di uscita.** I dati entrano gratis ed escono a pagamento – un meccanismo che si accumula in silenzio fino a diventare [vendor lock-in](https://en.wikipedia.org/wiki/Vendor_lock-in) man mano che i dati si depositano.
- **Gli errori di configurazione della sicurezza sono la modalità di guasto numero uno.** La metà del provider nella responsabilità condivisa è eccellente; le violazioni avvengono in modo schiacciante nella metà del cliente.
- **La tassa sulle competenze.** Gestire bene l'infrastruttura richiede persone che la gestiscano bene – un requisito di assunzione che la pagina dei prezzi a consumo non menziona.

## IaaS 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. Rispetto a IaaS è l'estremo opposto dello scambio: nessun accesso al sistema operativo, nessun controllo sull'infrastruttura – e nessun runbook, perché l'intero riquadro "gestisce il cliente" del diagramma qui sopra è lavoro della piattaforma. I team che hanno bisogno di infrastruttura grezza per un singolo carico specializzato possono farla girare accanto a un backend BaaS; i team che costruiscono backend applicativi standard possono saltare del tutto il piolo più basso. E poiché lo stack è open source, scendere la scala in un secondo momento – ospitare in proprio la piattaforma su un'infrastruttura IaaS controllata direttamente – resta un'opzione reale, non una riscrittura.