Amazon Web Services
Amazon Web Services è la piattaforma cloud di Amazon: server, storage, database e reti che si attivano a consumo, senza comprare hardware e senza gestire una sala macchine. È una scelta ragionevole quando il carico di lavoro cresce a strappi, quando serve replicare un ambiente in un’altra area geografica o quando il ciclo di rinnovo dei server è diventato un problema di cassa. Aesir la dimensiona, la configura e la gestisce per conto dell’azienda.
Amazon Web Services in sintesi
Risorse a consumo
Si accendono macchine virtuali, spazio disco e database quando servono e si spengono quando non servono più. Si paga il tempo di utilizzo e il volume di dati, non un impegno fisso deciso tre anni prima. Il dimensionamento non è più una scommessa sul picco, ma una decisione che si può correggere.
Regioni e zone di disponibilità
AWS divide il mondo in regioni geografiche, e ogni regione in più zone di disponibilità: datacenter distinti, alimentati e collegati in modo indipendente. Distribuire un’applicazione su due zone della stessa regione è il modo standard per sopravvivere al guasto di un singolo sito senza costruire un secondo datacenter proprio.
Servizi gestiti
Oltre alle macchine virtuali, AWS offre componenti già pronti: database relazionali amministrati dal fornitore, code di messaggi, bilanciatori, funzioni serverless. Il vantaggio è togliere lavoro sistemistico ripetitivo — patch, backup, failover — dove non porta valore. Lo svantaggio è un legame più forte con la piattaforma, ed è una scelta da fare consapevolmente.
Identità e permessi
Ogni accesso, umano o applicativo, passa da un sistema di identità e policy. Si definisce chi può fare che cosa su quale risorsa, si separano gli ambienti di produzione da quelli di prova e si tracciano le azioni amministrative. È la parte che più spesso viene trascurata in un cloud aperto in fretta, ed è quella che determina quanto danno può fare una credenziale rubata.
Dove risiedono i dati
AWS ha regioni europee, Milano compresa, e il cliente sceglie in quale regione risiedono i propri dati e da quali regioni sono raggiungibili. La scelta va messa per iscritto e verificata: i servizi non sono tutti disponibili ovunque, e alcune funzioni accessorie possono comportare trasferimenti. Approfondiamo il tema nella pagina Sovranità digitale.
Governo della spesa
Il conto cloud cresce da solo se nessuno lo guarda: ambienti di test lasciati accesi, dischi orfani, dati storici su storage veloce. Etichettatura delle risorse, budget con soglie di allarme e revisione periodica del dimensionamento sono parte del servizio, non un controllo annuale.
Funzionalità di Amazon Web Services
Il nucleo della piattaforma è fatto di pochi mattoni che si combinano: capacità di calcolo, spazio di archiviazione, rete privata, identità. Sopra questi mattoni AWS costruisce servizi più specializzati — database gestiti, analisi dei dati, contenitori, funzioni eseguite a evento. Per la maggior parte delle PMI il valore sta nei primi due livelli: portare in cloud i server applicativi e i dati, con una rete disegnata bene, backup verificati e un secondo sito di ripartenza. Le funzioni avanzate hanno senso quando c’è un problema concreto che le richiede.
Sul tema della giurisdizione conviene essere precisi, perché è una domanda legittima che si sente spesso. I dati possono essere ospitati in regioni europee e restarci; il fornitore, però, è una società statunitense, e come tale è soggetta alla normativa degli Stati Uniti, incluso il CLOUD Act, che consente alle autorità americane di chiedere dati nella disponibilità di un’impresa soggetta alla loro giurisdizione anche quando sono conservati all’estero. Ciò non rende il servizio inutilizzabile né illegittimo: esiste un quadro di trasferimento tra Unione Europea e Stati Uniti, AWS pubblica impegni contrattuali sulla localizzazione dei dati e sulla gestione delle richieste delle autorità, e sta sviluppando un’offerta europea con governance separata. Significa però che la scelta va fatta con cognizione, misurando la sensibilità dei dati in gioco e, dove serve, cifrandoli con chiavi che restano sotto controllo del cliente. Ne parliamo apertamente in Sovranità digitale.
- Macchine virtuali (EC2): server Linux e Windows di varie taglie, ridimensionabili nel tempo. Sono la via più diretta per spostare in cloud applicazioni esistenti senza riscriverle.
- Object storage (S3): archiviazione di file e oggetti a costo contenuto, con classi diverse per dati caldi e dati storici. Adatto a backup, archivi documentali e contenuti applicativi.
- Database gestiti (RDS): motori relazionali come PostgreSQL, MySQL e SQL Server con backup, aggiornamenti e replica amministrati dalla piattaforma anziché dal sistemista.
- Rete privata virtuale (VPC): sottoreti, regole di traffico e collegamento cifrato verso la sede. Il cloud non è un’appendice esposta a Internet, ma un’estensione della rete aziendale.
- Identità e accessi (IAM): utenti, ruoli e policy con il principio del privilegio minimo, autenticazione a più fattori sugli account amministrativi e separazione tra ambienti.
- Scalabilità automatica e bilanciamento: il numero di istanze segue il carico e il traffico viene distribuito tra le macchine attive.
- Backup e ripristino: copie pianificate delle macchine e dei database, conservate secondo regole di retention definite e provate con ripristini reali, non solo dichiarate.
- Monitoraggio e log (CloudWatch, CloudTrail): metriche, allarmi e traccia delle azioni amministrative. Serve per accorgersi dei problemi prima degli utenti e per ricostruire cosa è successo.
- Selezione della regione: la collocazione geografica dei dati è un parametro di progetto, dichiarato al cliente e verificabile, non una conseguenza casuale della configurazione iniziale.
Come lo mettiamo in esercizio
Partiamo dal processo, non dalla piattaforma. Guardiamo quali applicazioni sostengono il lavoro quotidiano, quanto tollerano un fermo, quanti dati muovono e quali vincoli hanno — contrattuali, normativi o di integrazione con sistemi che restano in sede. Da qui esce il dimensionamento: quali carichi ha senso spostare, con quale taglia, in quale regione, con quale schema di backup e di ripartenza. Diciamo anche cosa conviene non spostare: un cloud pubblico non è la risposta giusta a tutto, e un progetto che parte da un’analisi onesta costa meno di uno che parte da un preventivo ottimista.
Poi implementiamo e migriamo, di norma per fasi, con una finestra concordata e la possibilità di tornare indietro finché il nuovo ambiente non è stabile. Dopo l’avvio resta la parte più lunga: monitoraggio, aggiornamenti, verifica dei ripristini, revisione periodica di spesa e dimensionamento, supporto agli utenti. Il cliente ha un unico interlocutore contrattuale per la piattaforma, per la rete e per le postazioni, invece di doversi fare da arbitro tra fornitori diversi quando qualcosa non funziona.
Amazon Web Services fa parte di Cloud e Infrastruttura. Vedi anche il metodo Aesir e i casi di successo.
Vuoi capire se Amazon Web Services ha senso per la tua azienda?
Partiamo dal processo che si inceppa, non dal prodotto. Una prima analisi senza impegno.