AWS (Amazon Web Services): cos’è, come funziona, servizi, costi e alternative

AWS, acronimo di Amazon Web Services, è la piattaforma cloud di Amazon. Mette a disposizione risorse informatiche e servizi on demand: capacità di calcolo, storage, database, reti, sicurezza, monitoraggio, analytics, container, intelligenza artificiale e molto altro.

Ridurre AWS a “un hosting di Amazon” o a “un server nel cloud” è però fuorviante. Un server virtuale come Amazon EC2 è soltanto uno dei mattoni disponibili. Il vero punto della piattaforma è poter combinare servizi differenti per costruire un’infrastruttura, pagando in larga parte in funzione delle risorse e delle modalità effettivamente utilizzate.

Questa flessibilità è anche il motivo per cui Amazon Web Services può risultare semplice per un piccolo esperimento e molto più impegnativo quando entrano in gioco identità, rete, alta disponibilità, backup, osservabilità e controllo dei costi. Per capire se fa davvero al caso tuo conviene partire dal modello mentale, non dal catalogo dei prodotti.

Cos’è AWS e cosa significa Amazon Web Services

Amazon Web Services è un ecosistema di servizi di cloud computing erogati attraverso l’infrastruttura globale di Amazon. Invece di acquistare e installare fisicamente server, storage e altri componenti, puoi creare risorse attraverso la piattaforma e modificarle o rimuoverle quando cambiano le esigenze del workload.

Se vuoi approfondire il modello generale prima del singolo provider, la guida al cloud computing spiega la differenza fra risorse on demand, modelli di servizio e deployment. AWS è una delle piattaforme attraverso cui questi principi vengono implementati nella pratica.

AWS non è semplicemente “un server di Amazon”

Amazon EC2 permette di creare macchine virtuali, ma fermarsi a EC2 significa vedere soltanto una parte della piattaforma.

Un’applicazione può usare, per esempio, un servizio DNS per indirizzare le richieste, una CDN per distribuire contenuti, un bilanciatore per smistare il traffico, istanze o container per eseguire il codice, un database gestito per conservare i dati, object storage per file e backup, un sistema IAM per autorizzazioni e servizi di logging per capire cosa succede.

La differenza importante è questa:

server virtuale = una risorsa; AWS = una piattaforma nella quale più risorse e servizi possono lavorare insieme.

Questo cambia anche il modo di ragionare sui costi e sulla gestione. Non stai necessariamente acquistando “un piano” con caratteristiche fisse: spesso stai componendo un’architettura con voci di consumo differenti.

Cloud computing, IaaS, PaaS e serverless: come si collegano

AWS non coincide con un singolo modello di servizio. Nel suo catalogo convivono livelli di astrazione differenti.

Con Amazon EC2 sei vicino alla logica IaaS (Infrastructure as a Service): il provider gestisce data center, hardware e virtualizzazione, mentre tu mantieni responsabilità importanti sul sistema operativo guest, sul software installato e sulla configurazione.

Con servizi più gestiti, invece, una parte crescente dello stack operativo passa al provider. Un database gestito come Amazon RDS riduce il lavoro che avresti amministrando direttamente il database su una VM. Con AWS Lambda puoi eseguire codice senza dover predisporre e mantenere un server persistente per quella funzione.

“Serverless”, infatti, non significa che i server spariscano: significa che non sei tu a doverli provisionare e amministrare direttamente per quel servizio.

La domanda utile non è quindi “AWS è IaaS o PaaS?”, ma: quanto controllo vuoi mantenere e quanta gestione vuoi delegare per ciascun componente?

Come funziona AWS: account, Region, Availability Zone e servizi

Per usare Amazon Web Services crei un account, scegli una Region nella quale distribuire le risorse compatibili e poi attivi i servizi necessari.

A livello operativo puoi lavorare attraverso la console web, le API, la riga di comando e strumenti di Infrastructure as Code. Il modello non ti obbliga quindi a configurare tutto manualmente con il mouse: nelle infrastrutture mature, automazione e configurazione dichiarativa diventano spesso parte essenziale del lavoro.

Region e Availability Zone: dove vengono eseguite le risorse

Una Region è un’area geografica nella quale AWS dispone di infrastruttura. Ogni Region comprende più Availability Zone, cioè località infrastrutturali separate progettate per consentire architetture più resilienti.

La scelta della Region non è una formalità. La documentazione AWS sulle Region raccomanda di considerare almeno disponibilità dei servizi e funzionalità richieste, vicinanza agli utenti e requisiti operativi o normativi.

È importante anche non confondere “uso una Region con più Availability Zone” con “la mia applicazione è automaticamente in alta disponibilità”. Per sfruttare la ridondanza devi progettare i componenti affinché possano continuare a funzionare quando una parte dell’infrastruttura ha problemi.

Console, API e Infrastructure as Code: come si gestisce la piattaforma

La AWS Management Console è il punto di ingresso più immediato per esplorare servizi e risorse. Per un test o un piccolo ambiente può essere sufficiente.

Quando però l’infrastruttura cresce, le modifiche manuali diventano difficili da riprodurre e controllare. Qui entrano in gioco API, AWS CLI e strumenti come AWS CloudFormation o AWS CDK, che permettono di descrivere e distribuire infrastruttura in modo più sistematico.

Il vantaggio dell’Infrastructure as Code non è soltanto “fare prima”. Serve soprattutto a rendere più chiaro cosa dovrebbe esistere, come è configurato e come ricrearlo in altri ambienti.

Come si combinano i servizi in un’applicazione reale

Immagina una web application senza pretendere che questa sia l’unica architettura possibile.

Il dominio può essere gestito tramite Route 53. CloudFront può distribuire contenuti più vicino agli utenti. Le richieste dinamiche possono arrivare a un load balancer, a un’API o a un livello compute basato su EC2, container o Lambda. I dati possono finire in RDS, Aurora, DynamoDB o S3 a seconda del problema. IAM governa identità e permessi; KMS può entrare nella gestione delle chiavi crittografiche; CloudWatch e CloudTrail aiutano a osservare metriche, log ed eventi.

Il modello mentale diventa quindi:

utente → rete/edge → applicazione/compute → dati → sicurezza e osservabilità

Non tutti i progetti hanno bisogno di tutti questi livelli. L’errore è partire dai servizi e cercare un problema da assegnargli. Conviene fare il contrario: definire workload, dati, disponibilità richiesta, responsabilità operative e budget, poi scegliere i componenti.

AWS in Italia: cosa offre la Region di Milano

Amazon Web Services dispone della Region Europe (Milan), identificata dal codice eu-south-1. La documentazione corrente indica tre Availability Zone.

Per aziende e progetti italiani è un’opzione importante, ma la presenza di una Region nel Paese non rende automaticamente Milano la scelta migliore per qualsiasi workload.

Europe (Milan), eu-south-1, e le Availability Zone

Distribuire risorse nella Region di Milano consente di collocare determinati workload in Italia e può ridurre la distanza di rete rispetto a utenti o sistemi presenti nel Paese.

La Region va però abilitata negli account per i quali non è attiva di default e, soprattutto, non tutti i servizi o tutte le funzionalità sono necessariamente disponibili in ogni Region nello stesso momento. Prima di progettare un’architettura attorno a una località conviene quindi verificare la disponibilità del servizio specifico.

Perché scegliere una Region non significa soltanto scegliere quella più vicina

La latenza è un criterio, non l’unico.

Può essere necessario considerare dove si trovano utenti e sistemi collegati, quali servizi sono disponibili, requisiti legali e contrattuali, costi, strategia di disaster recovery e dipendenze da altre risorse.

Per questo “gli utenti sono italiani, quindi Milano” è una scorciatoia troppo semplice. Può essere la decisione corretta, ma deve arrivare dopo i requisiti.

Latenza, dati e compliance: cosa verificare

Usare una Region italiana può essere rilevante per una strategia di localizzazione dei dati, ma scegliere una Region non equivale da solo a essere conformi al GDPR o ad altri obblighi.

La conformità dipende da come gestisci dati, accessi, contratti, trasferimenti, retention, cifratura, logging e configurazioni. L’infrastruttura del provider è una parte del sistema di controllo, non un sostituto della governance del cliente.

I principali servizi AWS: una mappa per funzione

Il catalogo AWS è troppo ampio e mutevole perché una guida generale debba trasformarsi in un elenco esaustivo. Per orientarsi è più utile associare alcuni servizi ai problemi che risolvono.

La tabella serve come orientamento. Ogni servizio ha pricing, limiti, disponibilità regionale e responsabilità differenti.

Compute: Amazon EC2 e AWS Lambda

Amazon EC2 fornisce capacità di calcolo tramite istanze virtuali. È una scelta naturale quando hai bisogno di controllare sistema operativo, runtime e configurazione dell’ambiente.

AWS Lambda sposta invece l’astrazione più in alto: carichi il codice e il servizio gestisce l’infrastruttura necessaria per eseguirlo in risposta a eventi e richieste secondo il modello del servizio.

Non sono semplicemente due modi intercambiabili di “avere un server”. EC2 dà maggiore controllo dell’ambiente; Lambda riduce molta della gestione infrastrutturale, ma introduce un diverso modello di esecuzione, limiti e pricing.

Storage e database: S3, RDS, Aurora e DynamoDB

Amazon S3 è object storage: non va confuso con il disco di una macchina virtuale. È adatto a oggetti come file, asset, archivi e grandi collezioni di dati, con classi e opzioni differenti.

Per i database relazionali, Amazon RDS gestisce diversi motori e automatizza numerose attività operative; Amazon Aurora è il database relazionale cloud-native di AWS compatibile con PostgreSQL e MySQL secondo le opzioni supportate.

DynamoDB risponde invece a un modello NoSQL key-value/document. Non è “più moderno” di un database relazionale in senso assoluto: risolve problemi differenti. Il modello dei dati deve guidare la scelta.

Networking e distribuzione: VPC, Route 53 e CloudFront

Amazon VPC permette di definire l’ambiente di rete virtuale nel quale vivono molte risorse. Route 53 gestisce DNS e funzioni di routing. CloudFront è la Content Delivery Network di Amazon Web Services.

Qui emerge uno dei punti che spesso rendono il cloud più complesso di quanto sembri dalla console: subnet, routing, accessi pubblici e privati, firewall, endpoint e bilanciamento hanno conseguenze concrete su sicurezza, disponibilità e costi.

Container: ECS, EKS e Fargate

Se il tuo software viene distribuito tramite container, AWS offre più opzioni.

Amazon ECS è l’orchestratore container di AWS; Amazon EKS fornisce Kubernetes gestito; AWS Fargate permette di eseguire workload containerizzati senza gestire direttamente i server sottostanti secondo le integrazioni supportate.

Se vuoi separare i concetti dal provider, le guide dedicate spiegano come funziona Docker e che cos’è Kubernetes. Questa distinzione aiuta a non confondere la tecnologia container con il servizio cloud che la ospita.

Identità, sicurezza e monitoraggio: IAM, KMS, WAF, CloudWatch e CloudTrail

AWS IAM è centrale perché stabilisce chi può fare cosa sulle risorse. KMS gestisce chiavi crittografiche utilizzate da numerosi servizi. AWS WAF protegge applicazioni web e API applicando regole al traffico supportato.

CloudWatch raccoglie metriche, log e segnali operativi; CloudTrail registra attività e chiamate API utili anche per audit e investigazione.

Sono servizi differenti, ma insieme mostrano un principio importante: un workload non è finito quando “funziona”. Deve poter essere osservato, protetto e amministrato.

Intelligenza artificiale: Amazon Bedrock e SageMaker AI

Amazon Bedrock è la piattaforma AWS per costruire applicazioni di AI generativa utilizzando modelli di fondazione e strumenti per casi come retrieval, guardrail e flussi agentici. Amazon SageMaker AI è più orientato allo sviluppo, addestramento, personalizzazione e distribuzione di modelli e workflow di machine learning.

È un’area che cambia rapidamente. Servizi, nomi e componenti agentici possono evolvere più velocemente delle parti infrastrutturali classiche: prima di progettare una soluzione attorno a una feature specifica conviene sempre verificare lo stato corrente nella documentazione ufficiale.

Quanto costa AWS: pay-as-you-go, Free Tier e costi da controllare

Non esiste un unico “prezzo di AWS”.

La maggior parte del catalogo segue modelli basati sul consumo, ma ogni servizio ha metriche, livelli e condizioni proprie. Un’architettura può fatturare compute, storage, richieste, database, trasferimento dati, indirizzi e componenti di rete, logging, snapshot e altri servizi.

Questo rende il costo molto flessibile, ma anche meno intuitivo di un hosting con canone fisso.

Da cosa dipende realmente la fattura

Prendiamo una semplice applicazione. Il costo della VM non coincide necessariamente con il costo dell’ambiente.

Potrebbero incidere:

• tempo e dimensione delle risorse compute;
• capacità e classe dello storage;
• operazioni e richieste;
• database e relative configurazioni;
• trasferimento dati;
• bilanciamento e componenti di rete;
• backup e snapshot;
• logging e monitoring;
• servizi di sicurezza;
• supporto e servizi aggiuntivi.

Il punto non è memorizzare tutte le voci. È capire che l’unità di costo segue l’architettura.

Come funziona oggi il piano gratuito AWS

Il Free Tier di AWS per i nuovi clienti permette di esplorare la piattaforma gratuitamente fino a sei mesi attraverso un piano gratuito e prevede fino a 200 dollari in crediti: una parte viene assegnata alla registrazione e una parte può essere ottenuta completando attività previste dal programma.

Sono inoltre disponibili offerte “always free” entro limiti specifici per diversi servizi.

“Free Tier”, però, non significa “qualsiasi infrastruttura AWS è gratuita”. Durata, crediti, servizi disponibili e soglie vanno verificati nell’account e nella documentazione corrente. Se un progetto deve andare in produzione, il budget va valutato sul pricing reale del workload, non sul periodo promozionale.

Pricing Calculator, Cost Explorer, Budgets e Savings Plans

Prima di distribuire un’architettura articolata conviene modellare una stima con AWS Pricing Calculator.

Dopo il deployment, AWS Cost Explorer aiuta ad analizzare spesa e utilizzo, mentre AWS Budgets permette di definire budget e notifiche. I prezzi e Savings Plans di AWS prevedono, per determinati workload, condizioni differenti rispetto all’uso on demand in cambio di un impegno di consumo; i Savings Plans possono essere sottoscritti per uno o tre anni.

Questo significa che la scelta non è soltanto “on demand oppure server tradizionale”. Esistono strumenti e formule differenti, ma richiedono una buona previsione del workload.

Perché pay-as-you-go non significa automaticamente spendere meno

Pagare in base all’uso è efficiente soltanto se l’uso è governato.

Una risorsa sovradimensionata che rimane attiva senza necessità continua a consumare budget. Lo stesso vale per ambienti di test dimenticati, storage che cresce senza policy, snapshot conservati indefinitamente o servizi aggiunti senza comprenderne la tariffazione.

La cost optimization è infatti uno dei pilastri del framework AWS Well-Architected, insieme a sicurezza, affidabilità, efficienza delle prestazioni, eccellenza operativa e sostenibilità.

Il vantaggio del cloud non è che “costa sempre meno”; è poter collegare in modo più dinamico capacità e spesa ai requisiti. Per farlo servono misurazione e disciplina.

AWS è sicuro? Cosa protegge Amazon e cosa resta responsabilità tua

AWS può mettere a disposizione un’infrastruttura molto sofisticata, ma non rende automaticamente sicura un’applicazione mal configurata.

La chiave per capire la sicurezza della piattaforma è il modello di responsabilità condivisa di AWS.

Security of the cloud e security in the cloud

AWS distingue fra sicurezza del cloud e sicurezza nel cloud.

Amazon è responsabile della protezione dell’infrastruttura che esegue i servizi: hardware, software infrastrutturale, networking fisico e strutture sottostanti. Il cliente è responsabile delle parti che dipendono dal servizio scelto e dalla propria configurazione.

Con EC2, per esempio, devi gestire il sistema operativo guest, patch, applicazioni e configurazioni di sicurezza della macchina. Con servizi più astratti come S3 o DynamoDB AWS gestisce una porzione maggiore dello stack, ma dati, classificazione, autorizzazioni e configurazioni di accesso restano comunque responsabilità del cliente.

La divisione cambia in base al servizio. Più il servizio è gestito, più attività operative possono passare ad AWS; non passa però automaticamente anche la responsabilità di decidere chi può accedere ai tuoi dati e come devono essere protetti.

IAM, MFA, privilegi minimi, cifratura e logging

Una delle prime regole pratiche è evitare di utilizzare l’utente root come normale identità amministrativa.

Le best practice AWS per l’utente root richiedono la protezione del root con autenticazione a più fattori e raccomandano di non creare access key di lunga durata per quell’utente. Per l’operatività quotidiana conviene usare identità e ruoli appropriati, privilegi minimi e credenziali temporanee quando disponibili.

A questo si aggiungono cifratura, gestione delle chiavi, segmentazione di rete e logging. Non esiste un singolo interruttore “rendi sicuro AWS”: la sicurezza emerge da identità, configurazioni, dati, rete, software e processi.

Backup, alta disponibilità e disaster recovery non sono automatici

Essere nel cloud non equivale ad avere automaticamente backup affidabili o disaster recovery.

Una singola istanza EC2 resta un singolo punto di esecuzione. Un database può offrire opzioni di replica e Multi-AZ, ma devi scegliere configurazioni coerenti con i requisiti. I backup devono avere policy e retention adeguate e, soprattutto, il ripristino va testato.

Alta disponibilità, backup e disaster recovery rispondono a problemi differenti. Confonderli è uno degli errori più costosi quando un incidente arriva davvero.

Come iniziare con AWS evitando costi e rischi inutili

Per imparare Amazon Web Services non serve attivare dieci servizi contemporaneamente. È più utile scegliere un workload piccolo e costruire attorno a quello un percorso controllato.

1. Proteggi subito l’account e l’utente root

Configura l’autenticazione a più fattori, evita di usare il root per le attività quotidiane e crea un modello di accesso con privilegi coerenti.

La sicurezza dell’account viene prima dell’esperimento tecnico.

2. Definisci il workload prima di scegliere il servizio

Scrivi cosa devi eseguire, quali dati gestisci, quali utenti lo useranno, quanta disponibilità serve e quali vincoli hai.

Solo dopo valuta EC2, Lambda, container, database o altri componenti. La domanda “quale servizio AWS devo imparare?” è meno utile di “quale problema devo risolvere?”.

3. Scegli la Region verificando disponibilità e requisiti

Controlla che i servizi necessari siano disponibili nella Region scelta e valuta latenza, localizzazione dei dati, integrazioni e recovery.

La Region di Milano può essere molto sensata per alcuni workload italiani, ma non è una risposta automatica.

4. Configura il controllo dei costi prima di sperimentare

Prima di creare molte risorse, verifica il Free Tier applicabile, configura budget e alert e usa il Pricing Calculator per gli scenari che possono generare spesa significativa.

Imparare il cloud senza guardare la fatturazione è un’abitudine da correggere subito.

5. Osserva e rimuovi ciò che non utilizzi

Verifica risorse attive, log, errori e consumo. Quando l’esperimento termina, elimina ciò che non serve più invece di limitarti a “non usarlo”.

È una piccola disciplina che evita sia costi inutili sia infrastruttura dimenticata.

Vantaggi, limiti e quando conviene usare AWS

Il vantaggio reale di AWS non è avere il maggior numero possibile di nomi nel catalogo. È poter scegliere livelli diversi di controllo e servizi gestiti all’interno dello stesso ecosistema, collegandoli attraverso rete, identità, automazione e osservabilità.

Questa libertà ha però un costo cognitivo e operativo.

Quando scalabilità, servizi gestiti e automazione fanno davvero la differenza

AWS tende ad avere molto senso quando il progetto richiede una o più di queste caratteristiche:

• infrastruttura componibile e automatizzabile;
• workload variabili o con crescita difficile da prevedere;
• servizi gestiti per database, code, storage, analytics o AI;
• architetture distribuite e requisiti di resilienza;
• integrazione fra molti componenti cloud;
• controllo granulare di rete, identità e sicurezza;
• più ambienti gestiti tramite automazione.

In questi casi la piattaforma può evitare di costruire o amministrare internamente componenti che esistono già come servizio.

Complessità, competenze, cost governance e vendor lock-in

La stessa ampiezza che rende AWS potente può renderlo difficile da governare.

Ogni nuovo servizio introduce configurazioni, permessi, metriche di costo e dipendenze. Usare servizi proprietari molto specifici può accelerare lo sviluppo, ma rende anche più costosa una futura migrazione se l’applicazione dipende profondamente da quelle API e da quei modelli.

Il vendor lock-in non è quindi un motivo automatico per evitare il cloud. È un trade-off da conoscere: più valore ottieni dai servizi gestiti e proprietari, più devi capire quanto sarebbe difficile sostituirli.

Quando un PaaS, un SaaS o un hosting gestito possono essere più sensati

Se il problema è semplice, AWS può essere eccessivo.

Per pubblicare un normale sito aziendale, gestire un’applicazione standard o usare una funzione già disponibile come SaaS, scegliere la piattaforma più flessibile non è automaticamente la scelta più razionale. Un hosting gestito o un PaaS può ridurre configurazione, patching, monitoring e curva di apprendimento.

La domanda non è “qual è la tecnologia più potente?”, ma quanta infrastruttura devi davvero possedere e governare per raggiungere il risultato?

Se il tuo caso d’uso è specificamente l’hosting, può essere utile distinguere prima cloud hosting, VPS, hosting condiviso e server dedicato: sono modelli differenti e non rappresentano una scala obbligatoria dal peggiore al migliore.

WordPress su AWS: possibile, ma non automaticamente la scelta migliore

WordPress può essere installato su Amazon Web Services e il sito contiene una guida specifica su come installare WordPress su AWS.

Per un normale sito WordPress, tuttavia, il fatto che AWS possa ospitarlo non significa che debba essere la prima scelta. Un hosting WordPress gestito può essere molto più semplice da amministrare.

La piattaforma diventa più interessante quando esistono requisiti infrastrutturali concreti: controllo dell’ambiente, integrazione con altri servizi, architetture particolari, automazione o esigenze di scalabilità e resilienza che giustificano la complessità aggiuntiva.

AWS vs Microsoft Azure vs Google Cloud: quale scegliere

AWS, Microsoft Azure e Google Cloud coprono tutti le principali categorie del cloud pubblico: compute, storage, networking, database, container, sicurezza, dati e intelligenza artificiale.

Per questo una classifica assoluta “miglior cloud” è poco utile. La scelta dovrebbe partire dal workload e dal contesto tecnologico.

La tabella non è un ranking: descrive aree da investigare.

Quando AWS ha più senso

Metterei AWS in cima alla shortlist quando vuoi un ecosistema molto ampio, hai bisogno di molte opzioni architetturali e il team possiede — o è disposto a costruire — competenze specifiche per governare rete, sicurezza, costi e automazione.

È particolarmente convincente quando il progetto non si limita a una VM, ma sfrutta servizi gestiti che evitano di costruire internamente pezzi di infrastruttura.

Quando Azure può essere più coerente

Azure merita una valutazione prioritaria quando l’organizzazione è già profondamente basata su tecnologie Microsoft, Windows Server e SQL Server, oppure quando l’integrazione fra ambienti on-premise, hybrid e cloud è un requisito centrale.

Questo non significa che AWS non possa gestire workload Microsoft. Significa che il costo di integrazione e le competenze già presenti nel team possono cambiare il verdetto.

Quando Google Cloud merita maggiore attenzione

Google Cloud è un candidato forte quando il progetto ruota attorno a data analytics, BigQuery, container/Kubernetes o servizi AI dell’ecosistema Google.

Anche qui il criterio corretto non è il logo. Se una singola capability è critica per il prodotto, conviene confrontare direttamente disponibilità regionale, pricing, SLA, integrazioni e limiti di quella capability sui provider candidati.

Conclusione

AWS è una scelta forte quando ti serve una piattaforma cloud componibile, non semplicemente “un server online”. Il suo valore cresce quando puoi sfruttare servizi gestiti, automazione, infrastruttura globale e integrazione fra compute, dati, rete, sicurezza e osservabilità.

La stessa libertà diventa però un limite se il progetto non la richiede. Per un sito semplice o un’applicazione con esigenze standard, un servizio gestito più verticale può ridurre tempi, responsabilità e costi operativi. Per workload complessi, distribuiti, data-intensive o fortemente automatizzati, Amazon Web Services merita invece una valutazione seria insieme ad Azure e Google Cloud.

Il passo successivo più utile non è aprire la console e scegliere un servizio a caso. È scrivere i requisiti del workload — dati, traffico, disponibilità, sicurezza, competenze e budget — e poi verificare quali componenti soddisfano davvero quei requisiti. È lì che AWS passa da catalogo enorme a infrastruttura progettata con criterio.