Amazon EC2

La transizione da Xen al sistema Nitro

Nelle sue fasi iniziali, l'infrastruttura di virtualizzazione di EC2 si basava esclusivamente sull'hypervisor Xen. Una transizione epocale si è compiuta il 6 novembre 2017 con l'annuncio della famiglia di istanze C5, fondata sul nuovo sistema AWS Nitro. Tale architettura hardware personalizzata, incentrata su un hypervisor derivato da KVM, scarica le operazioni critiche di virtualizzazione, networking e storage dall'host primario su schede dedicate, massimizzando le risorse di calcolo a disposizione dell'utente finale.

Ogni istanza virtuale agisce a tutti gli effetti come un Virtual Private Server (VPS). La potenza di elaborazione viene quantificata in "Elastic Compute Units" (ECU), sebbene le prestazioni tra macchine con specifiche omologhe possano evidenziare minime oscillazioni operative legate alle caratteristiche dei chip sottostanti. Il 28 novembre 2017, AWS ha esteso la propria offerta introducendo istanze "bare-metal", garantendo l'accesso diretto e senza intermediari all'hardware fisico sottostante, superando per la prima volta i vincoli di qualsiasi livello di virtualizzazione.

Tipologie e famiglie di istanze specializzate

Le istanze EC2 sono categorizzate in famiglie progettate per soddisfare scenari di carico specifici:

Uso generale (General Purpose): Garantiscono un bilanciamento ideale tra risorse di calcolo, memoria volatile e prestazioni di rete, ideali per ambienti di sviluppo, web server e database di medie dimensioni (famiglie A1, T3, T2, M5, M5a, M4 e T3a).

Ottimizzate per il calcolo (Compute Optimized): Progettate per carichi ad alto assorbimento di CPU, come server di gioco, transcodifica video ed elaborazioni scientifiche (famiglie C4, C5, C5n, affiancate dalla serie C8gn, alimentata da processori Graviton4 con throughput di rete fino a 600 Gbit/s e un incremento prestazionale di circa il 30% rispetto alla serie C7gn).

Ottimizzate per la memoria (Memory Optimized): Pensate per gestire enormi dataset caricati direttamente nella RAM, come database relazionali complessi e memorie cache in-memory (famiglie R4, R5, R5a, X1, X1e, High Memory e z1d).

Calcolo accelerato (Accelerated Computing): Sfruttano la potenza parallela di GPU o chip programmabili (FPGA) per l'elaborazione grafica 3D, l'addestramento di modelli di machine learning e l'High-Performance Computing (famiglie P2, P3, G3, F1, nonché le istanze con partizionamento GPU G6f, in grado di allocare quote frazionarie di un ottavo, un quarto o metà di una GPU NVIDIA L4).

Ottimizzate per lo storage (Storage Optimized): Sviluppate per fornire altissimi livelli di throughput e latenze di I/O minime su unità flash NVMe integrate, ideali per architetture NoSQL, data warehouse e filesystem distribuiti (famiglie H1, I3 e D2).

Struttura dei costi e piano gratuito

La spesa associata alle istanze EC2 è consultabile nel dettaglio per mezzo del report sui costi e sull'utilizzo (AWS Cost and Usage Report). I costi complessivi scaturiscono dall'aggregazione di più voci: la tariffazione oraria delle istanze, il traffico di rete in uscita, l'allocazione dei volumi EBS, la conservazione degli snapshot e il routing gestito dai gateway NAT.

I prezzi partono da importi minimi per le istanze t2.nano operanti su Linux o Windows (circa 0,0058 USD all'ora, pari a 4,176 USD mensili), fino a configurazioni per lo storage intensivo come le i3.16xlarge (4,992 USD l'ora) e nodi di calcolo estremi che raggiungono fatturazioni di 3.997,19 USD al mese. Il trasferimento di dati in ingresso (inbound) è interamente gratuito su tutta l'infrastruttura AWS, mentre il traffico uscente (outbound) è soggetto a scaglioni progressivi fino a 0,12 USD per gigabyte. Dal dicembre 2010, per agevolare l'adozione della piattaforma, è attivo il piano AWS Free Tier: un pacchetto promozionale valido per i primi 12 mesi che offre 750 ore mensili su istanze micro, 30 GB di storage a blocchi EBS e una quota base di larghezza di banda, con la clausola che i crediti non consumati non possono essere accumulati per i periodi successivi.

Supporto ai sistemi operativi

Al debutto nel 2006, il servizio garantiva la compatibilità con le distribuzioni Linux, per poi estendersi alle varianti OpenSolaris e Solaris Express Community Edition di Sun Microsystems. Nell'ottobre 2008 sono stati integrati i sistemi Windows Server 2003 e 2008, seguiti nel marzo 2011 dal supporto alle AMI basate su NetBSD e nel novembre 2012 dalla compatibilità con Windows Server 2012.

Grazie alle sollecitazioni e al contributo tecnico portato avanti sin dal 2006 da Colin Percival (sviluppatore di FreeBSD e fondatore del servizio di backup Tarsnap), Amazon ha integrato formalmente FreeBSD all'interno di EC2 nel novembre 2012. Parallelamente, AWS ha ingegnerizzato la propria distribuzione, denominata Amazon Linux AMI, fondata su pacchetti Fedora e Red Hat Enterprise Linux, dotata di kernel ottimizzato per il cloud, ambiente runtime Java OpenJDK e suite di compilatori GCC. Il 30 novembre 2020 l'offerta si è arricchita con l'introduzione dell'ambiente macOS (a partire dalle edizioni Mojave e Catalina), eseguito direttamente su hardware bare-metal basato su macchine Mac mini.

Ecosistemi di container e orchestrazione Kubernetes

Per agevolare l'impiego di architetture orientate ai microservizi, AWS mette a disposizione Amazon Elastic Container Registry (ECR), un registro Docker ad alta disponibilità che consente alle istanze EC2 di memorizzare, gestire e scaricare immagini di container in modo sicuro e a bassa latenza. Con la stessa finalità, Amazon Elastic Kubernetes Service (EKS) fornisce un ambiente Kubernetes interamente gestito ed eseguibile sull'infrastruttura EC2, sollevando gli amministratori di sistema dall'onere di configurare, aggiornare e manutenere il piano di controllo (control plane) dei cluster.

Archiviazione temporanea e persistente su volumi a blocchi

All'atto del provisioning di un'istanza, la configurazione del volume di avvio (root device) prevede due alternative: l'impiego di un'unità locale "instance-store" o l'aggancio di un volume gestito tramite Amazon EBS. I dischi instance-store rappresentano memorie temporanee collegate direttamente al server fisico ospitante; i dati memorizzati persistono durante i riavvii del sistema operativo, ma vengono irrimediabilmente azzerati qualora l'istanza venga arrestata, terminata o nel caso in cui si verifichi un guasto hardware dell'host.

Al contrario, Amazon Elastic Block Store (EBS), reso disponibile al pubblico nell'agosto 2008, offre volumi di archiviazione a blocchi persistenti e indipendenti dal ciclo di vita dell'istanza alla quale sono connessi. Tali dispositivi consentono la formattazione con qualsiasi filesystem, la configurazione di array RAID per massimizzare la velocità di lettura/scrittura o la tolleranza ai guasti, e il distacco e riaggancio dinamico tra diverse macchine virtuali per capacità comprese tra 1 GB e 16 TB. Grazie a un'architettura interna ridondata e replicata, il guasto di un singolo componente hardware non compromette l'integrità dei dati salvati, permettendo al contempo la creazione di snapshot incrementali archiviati su Amazon S3.

Integrazione con Simple Storage Service e indirizzi Elastic IP

Amazon Simple Storage Service (S3) è un'infrastruttura di object storage accessibile sia dalle istanze EC2 sia da client esterni autenticati tramite chiamate API su protocollo HTTP. La comunicazione tra le istanze EC2 e i bucket S3 localizzati all'interno della medesima regione geografica è esente da costi per il traffico di rete. I framework per l'analisi di Big Data (come Apache Hadoop) supportano nativamente il protocollo s3: per elaborazioni MapReduce, oppure consentono il montaggio di S3 come filesystem su istanze Linux (sebbene non sia supportata l'intera conformità POSIX, inclusi i lock sui file).

In ambito di connettività, la funzione Elastic IP assegna indirizzi IPv4 statici e pubblici legati all'account utente anziché alla singola istanza virtuale. Tale implementazione consente di riassociare via software un indirizzo IP a un server di riserva in caso di avaria, aggirando i tempi di propagazione e aggiornamento dei record DNS su scala globale.

Il servizio di telemetria Amazon CloudWatch

Amazon CloudWatch fornisce un monitoraggio in tempo reale sull'utilizzo delle risorse computazionali di EC2, rilevando parametri quali l'impegno della CPU, i volumi di I/O sul disco, il traffico di rete e i ritardi di replica sulle istanze database RDS. Nella sua configurazione standard, CloudWatch non estrae metriche interne del sistema operativo quali l'utilizzo della memoria RAM o lo spazio libero su disco. A partire dal dicembre 2017, AWS ha reso disponibile il CloudWatch Agent per ambienti Windows e Linux, abilitando la raccolta diretta di questi indicatori e rimpiazzando i precedenti script personalizzati. Il sistema è compatibile con metriche personalizzate inviate tramite API sin dal maggio 2011 e supporta la raccolta centralizzata dei registri operativi (CloudWatch Logs) dal luglio 2014, con funzionalità essenziali incluse nel piano AWS Free Tier.

Scalabilità dinamica e tolleranza ai guasti

Le soglie di telemetria definite su CloudWatch fungono da trigger per il modulo di Auto Scaling, preposto all'adattamento automatico del numero di istanze EC2 operative sulla base del traffico rilevato o di politiche preimpostate. Tuttavia, il tempo di avvio di una nuova istanza può richiedere diversi minuti in funzione delle dimensioni dell'AMI e dell'allocazione del data center, rendendo necessaria una pianificazione per i carichi di lavoro ad altissima criticità temporale.

La tolleranza strutturale ai guasti si fonda sulla suddivisione dell'infrastruttura globale in Zone di Disponibilità (Availability Zones - AZ) all'interno di ciascuna regione. Ciascuna AZ racchiude data center fisicamente separati, provvisti di impianti elettrici, circuiti di raffreddamento e connessioni di rete isolati e indipendenti. Distribuendo le applicazioni su molteplici Zone di Disponibilità, i servizi rimangono operativi anche a fronte di interruzioni impreviste o disastri fisici che colpiscano una specifica struttura.