Amazon CLF-C02: Concetti di Cloud — Guida allo studio

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Fa parte della AWS Cloud Practitioner CLF-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Concetti fondamentali del cloud e la proposta di valore di AWS

Il cloud computing trasforma i problemi di pianificazione della capacità, ad alta intensità di capitale, in un modello operativo in cui elaborazione, storage e rete vengono consumati on demand. AWS offre elasticità (auto scaling per adattarsi al carico), portata globale (Regioni e Zone di Disponibilità per la località e l’isolamento dei guasti) e una gamma di servizi gestiti che eliminano il lavoro pesante e indifferenziato. Concetti architetturali come la progettazione orientata al guasto, l’accoppiamento debole e l’infrastruttura immutabile aiutano i team a sfruttare i vantaggi del cloud: time to market più rapido, un modello economico basato sul pagamento a consumo e la possibilità di operare su scala globale. Primitive di rete come VPC, sottoreti e un Internet Gateway controllano il traffico in entrata (ingress) e in uscita (egress) per i workload, mentre Direct Connect offre un collegamento dedicato ad alta velocità verso i data center on-premise quando sono richieste una larghezza di banda prevedibile o una latenza inferiore. Per migrazioni fisiche di grandi dimensioni o in caso di connettività intermittente, i dispositivi Snowball Edge consentono il trasferimento offline sicuro e persino l’elaborazione edge (edge compute). Le trappole comuni per gli operatori includono presumere che il “lift-and-shift” ridurrà automaticamente i costi, sottovalutare i costi del traffico di rete in uscita (egress) e non progettare per una resilienza multi-AZ. I criteri decisionali dovrebbero ponderare i requisiti di disponibilità del business, la data gravity, i vincoli di latenza e i costi operativi a lungo termine prima di scegliere strategie di rehost, replatform o refactor.

Servizi, pattern di migrazione e decisioni architetturali

La scelta del servizio AWS corretto dipende dalla necessità di avere operazioni gestite, controllo sulle responsabilità a livello di sistema operativo o capacità edge/offline. I pattern di migrazione includono il rehost (lift-and-shift), il replatform (apportare piccole ottimizzazioni) e il refactor (riprogettare l’architettura per il cloud-native). Le scelte di storage riflettono i pattern di accesso: S3 per lo storage a oggetti e i data lake, EBS per lo storage a blocchi collegato a EC2, EFS per file system condivisi POSIX e le varianti di FSx per esigenze di file system gestiti Windows o ad alte prestazioni. I database possono essere eseguiti come servizi gestiti, ad esempio Amazon RDS e Amazon DynamoDB, che si fanno carico delle attività amministrative, oppure possono essere autogestiti su EC2, dove il cliente mantiene le responsabilità relative a sistema operativo, patching, backup e scaling. Per i container, le opzioni gestite riducono l’onere operativo offrendo al contempo diversi compromessi:

Amazon ECS (tipo di avvio EC2): orchestrazione gestita, ma l’utente gestisce gli host EC2.
Amazon ECS / Fargate: container serverless senza gestione degli host.
Amazon EKS: piano di controllo gestito di Kubernetes; l’utente può gestire i nodi o usare Fargate. Per un deployment rapido delle applicazioni senza dover creare manualmente ogni risorsa, AWS Elastic Beanstalk o i template di CloudFormation accelerano la delivery imponendo al contempo architetture standard. Le trappole per gli operatori includono la sottovalutazione dello sforzo operativo richiesto dai database o dagli host di container autogestiti e la dimenticanza di associare i profili di istanza IAM a EC2 per un accesso sicuro ai servizi.

Economia del cloud: modelli di prezzo e pratiche di ottimizzazione dei costi

AWS offre molteplici modelli di prezzo per adattarsi alla prevedibilità del workload e alla tolleranza alle interruzioni. Il modello On-Demand è flessibile e senza impegno, le Reserved Instance e i Savings Plan offrono sconti significativi per un utilizzo stazionario, le Istanze Spot sono fortemente scontate ma possono essere interrotte, e gli Host Dedicati soddisfano esigenze normative o di licenza. La visibilità e il controllo dei costi si basano su tagging, Cost Explorer, AWS Budgets e AWS Cost Anomaly Detection; strumenti di rightsizing come AWS Compute Optimizer e le raccomandazioni sulle risorse di Cost Explorer aiutano a identificare le istanze EC2 sovradimensionate. Trusted Advisor espone ottimizzazioni di costo e performance ed evidenzia le risorse orfane, mentre AWS Budgets può attivare avvisi SNS quando la spesa supera le soglie impostate. Le trappole comuni includono l’acquisto di Reserved Instance o Savings Plan senza analizzare l’utilizzo storico, l’uso di Istanze Spot per workload critici e non interrompibili, e la mancata implementazione di un tagging coerente, che compromette la ripartizione dei costi (chargeback) e gli sforzi di ottimizzazione. I criteri decisionali dovrebbero combinare i pattern del workload, la tolleranza alle interruzioni e le previsioni di utilizzo: usare il modello On-Demand per carichi imprevedibili, i Savings Plan o le RI per baseline di utilizzo sostenute, e le Istanze Spot per l’elaborazione flessibile e tollerante ai guasti.

Sicurezza, responsabilità condivisa e best practice operative

La sicurezza in AWS è un modello condiviso: AWS protegge l’infrastruttura cloud (hardware, rete, regioni, zone di disponibilità e servizi fondamentali), mentre i clienti proteggono nel cloud. Ciò include dati, controllo degli accessi, crittografia a livello di applicazione, applicazione di patch al sistema operativo e al software per IaaS e federazione delle identità. Utilizzare i ruoli IAM associati ai profili di istanza EC2 per concedere un accesso temporaneo con privilegi minimi a servizi come S3; evitare di incorporare credenziali a lunga durata nelle istanze. Le funzionalità di protezione dei dati includono il versioning di S3 e Object Lock per la conservazione (retention), la crittografia lato server (SSE) e la crittografia lato client per i record sensibili. Il monitoraggio e l’auditabilità si basano su CloudTrail per la registrazione delle API, AWS Config per la conformità della configurazione, Amazon Inspector per la valutazione delle vulnerabilità dei carichi di lavoro EC2, GuardDuty per il rilevamento delle minacce e Amazon Macie per l’individuazione di dati sensibili in S3. Il Well-Architected Framework guida le considerazioni operative, di sicurezza, affidabilità, prestazioni e costi; gli errori comuni dei professionisti includono l’uso eccessivo dell’account root, la trascuratezza dei backup automatici e la mancata implementazione di architetture multi-AZ o di piani di Disaster Recovery. Le decisioni operative dovrebbero dare priorità all’automazione, al principio del privilegio minimo e alla registrazione centralizzata per ridurre l’errore umano e accelerare la risposta agli incidenti.

Problema Pratico: Scenario d’Uso

Scenario: Acme Analytics gestisce una pipeline di elaborazione dati stagionale in una singola regione AWS. Il loro ambiente include istanze EC2 per il calcolo, un archivio on-premise e un data lake S3. Devono importare 50 TB dall’ambiente on-premise ogni stagione, garantire un’elevata disponibilità durante le esecuzioni e controllare i costi tra una stagione e l’altra.

Sfida: Trasferimento di dati in blocco (bulk) di 50 TB con larghezza di banda limitata e necessità di un’importazione durevole e verificabile; la capacità di calcolo deve essere ad alta disponibilità per una finestra di elaborazione di due mesi e conveniente dal punto di vista dei costi quando inattiva.

Approccio Raccomandato:

Ordinare un Amazon Snowball Edge per importare in modo sicuro i 50 TB in Amazon S3, utilizzando la capacità di calcolo edge se è richiesta una pre-elaborazione.
Archiviare i dati importati in un bucket S3 con il versioning abilitato e applicare S3 Object Lock per la conservazione (retention) dei record di origine.
Eseguire l’elaborazione su gruppi di Auto Scaling di istanze EC2 distribuiti su più Zone di Disponibilità o utilizzare AWS Batch/ECS Fargate per una scalabilità gestita durante la finestra di due mesi.
Implementare Cost Explorer, AWS Budgets con avvisi e applicare Savings Plans o Reserved Instances solo per le risorse di base persistenti; terminare o ridurre la capacità di calcolo dopo la stagione.

Motivazione: Snowball Edge minimizza i tempi di trasferimento e i costi di rete per importazioni una tantum di grandi dimensioni, mentre S3 fornisce uno storage durevole e verificabile. L’utilizzo di Auto Scaling o di capacità di calcolo gestita durante i mesi di picco offre disponibilità e comporta costi solo durante l’elaborazione, mentre gli strumenti di gestione dei costi prevengono spese impreviste.

Tutti i domini · Infrastruttura Globale AWS →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →