Come funziona il compute as a service su AWS, differenza tra instance types, spot vs on-demand, e un’introduzione ad ECR come registry privato per container images
Articolo di Andrea Mengato – Full-stack Developer in AzzurroDigitale
Una guida introduttiva al compute as a service su AWS: come funziona Amazon EC2, come scegliere tra le principali famiglie di instance type e quando conviene usare On-Demand, Spot, Reserved Instance o Savings Plans. Chiude una panoramica su Amazon ECR, il registry privato per immagini container integrato con l’ecosistema AWS.
Se dovessi indicare il servizio da cui è partito tutto, nel cloud, punterei senza troppi dubbi sul compute. Prima ancora di arrivare a database gestiti, serverless o AI, c’è un’idea abbastanza semplice che ha cambiato le regole del gioco: poter accendere una macchina in pochi secondi, usarla il tempo che serve, e spegnerla senza doverla comprare né gestire fisicamente. Su AWS questo si chiama Amazon EC2, ed è probabilmente il servizio più “storico” di tutta la piattaforma.
In questo numero cerco di mettere ordine su qualche concetto che spesso si dà per scontato: cosa vuol dire davvero “compute as a service”, come orientarsi tra i vari instance type, quando ha senso usare le Spot Instance al posto delle On-Demand, e chiudo con una parte su Amazon ECR, il registry privato per le immagini container, utile soprattutto se lavorate già con Docker o Kubernetes.
Compute as a service, in pratica
L’idea di base è che AWS mette a disposizione capacità di calcolo (CPU, RAM, storage, rete) senza che tu debba possedere o gestire l’hardware sottostante. Ogni istanza EC2 gira virtualizzata su un hypervisor (oggi principalmente il Nitro System), che si occupa di isolare le risorse tra clienti diversi che magari condividono lo stesso host fisico.
La parte interessante non è tanto la virtualizzazione in sé, che esiste da prima del cloud, quanto il fatto che tutto questo si può richiedere on demand: console, CLI, SDK o infrastructure as code, in pochi minuti hai una macchina pronta all’uso. E puoi scalare sia orizzontalmente, aggiungendo istanze (magari con un Auto Scaling Group), sia verticalmente, passando a un’istanza più grande. Il billing segue lo stesso principio: paghi in base al tempo di utilizzo, al tipo di istanza e al modello di pricing scelto, di cui parliamo tra poco.
Da tenere a mente: AWS gestisce la sicurezza e la manutenzione dell’infrastruttura fisica, tu resti responsabile di quello che ci gira sopra, cioè sistema operativo, patching, configurazione di rete. È il classico modello di responsabilità condivisa.
Come scegliere l’instance type giusto
Le famiglie principali con cui avrete a che fare più spesso sono queste:
| Famiglia | Ottimizzata per | Esempi d’uso |
|---|---|---|
General Purpose (t, m) |
Bilanciamento CPU/RAM/rete | Web server, microservizi, ambienti di sviluppo |
Compute Optimized (c) |
Alto rapporto CPU/RAM | Batch processing, encoding video, carichi HPC |
Memory Optimized (r, x, z) |
Grandi quantità di RAM | Database in-memory, cache, analytics real-time |
Storage Optimized (i, d, h) |
I/O locale ad alte prestazioni | Data warehouse, NoSQL DB, file system distribuiti |
Accelerated Computing (p, g, inf, trn) |
GPU/acceleratori dedicati | Machine learning, rendering, training/inference |
Spot vs On-Demand: dove sta il vero risparmio
Se la scelta dell’instance type incide sui costi, la scelta del pricing model incide anche di più, spesso
On-Demand
- Paghi a consumo, senza impegni di nessun tipo.
- Prezzo fisso e prevedibile, ma il più alto tra tutte le opzioni disponibili.
- Ha senso per workload imprevedibili, picchi di traffico, ambienti di test che vivono poco.
Spot Instances
- Sfruttano capacità di calcolo che AWS ha inutilizzata in un certo momento, per questo il prezzo può scendere anche del 90% rispetto all’On-Demand.
- Il prezzo oscilla in base a domanda e offerta della capacità disponibile.
- Il rischio: AWS può reclamarsi l’istanza con appena due minuti di preavviso, se quella capacità serve altrove per workload On-Demand.
- Vanno bene solo per carichi stateless, tolleranti ai guasti o comunque interrompibili: batch job, rendering, elaborazione dati distribuita con Spark o EMR, runner CI/CD, training ML non critico.
- Best practice: abbinarle a un Auto Scaling Group con una mixed instances policy, così l’infrastruttura ripiega automaticamente su On-Demand quando le Spot non sono disponibili, e costruire l’applicazione in modo che regga interruzioni improvvise (checkpoint, retry, quel genere di cose).
Vale la pena citare anche le Reserved Instance e i Savings Plans, giusto per completezza: sono impegni di uno o tre anni in cambio di sconti importanti, fino al 72%, e hanno senso per workload stabili che sapete già gireranno a lungo, tipo un database sempre acceso.
In pratica: On-Demand quando serve flessibilità, Spot quando il workload tollera le interruzioni e volete risparmiare, Reserved o Savings Plans per tutto ciò che è prevedibile e di lungo periodo. Nella maggior parte degli account reali questi tre modelli convivono tranquillamente.
Amazon ECR: dove finiscono le vostre immagini container
Con la diffusione di Docker e Kubernetes, il compute non è più solo “macchine virtuali”: una fetta crescente di workload gira dentro container. Amazon ECR (Elastic Container Registry) è il servizio che AWS mette a disposizione per archiviare, gestire e distribuire queste immagini in modo privato.
Rispetto a un registry generico tipo Docker Hub, il valore aggiunto sta soprattutto nell’integrazione con l’ecosistema AWS:
- Integrazione con IAM: l’accesso ai repository passa da policy IAM, non dovete gestire credenziali separate.
- Repository privati e pubblici: privati di default, ma potete anche pubblicarne su ECR Public Gallery.
- Scansione delle vulnerabilità: scanning automatico dei layer, basato su Amazon Inspector, alla ricerca di CVE note.
- Lifecycle policy: regole automatiche per eliminare immagini vecchie o senza tag, così i costi di storage restano sotto controllo.
- Integrazione diretta: ECS, EKS, Lambda con container image e CodePipeline possono pullare direttamente da ECR senza configurazioni particolari.
Il flusso tipico, per chi non l’ha mai usato, è più o meno questo:
Da qui in poi l’immagine è pronta per essere usata da un task ECS, un pod EKS o una funzione Lambda basata su container, senza dover spostare l’immagine altrove.
Tutto sommato, il compute on demand resta il pezzo su cui poggia il resto del cloud, e capire come muoversi tra instance type e modelli di pricing fa davvero la differenza sui costi finali. Con i container sempre più centrali, un servizio come ECR completa il quadro dando un modo sicuro di distribuire quello che gira sopra quel compute.