Amazon SOA-C02: Gestione dei costi e tagging delle risorse — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fa parte della AWS SysOps Administrator Associate SOA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

La gestione dei costi e l’assegnazione di tag alle risorse sono attività operative fondamentali che mantengono la spesa per il cloud visibile, prevedibile e governata. Una fatturazione e una reportistica accurate consentono agli operatori di attribuire i costi a team, progetti e ambienti; l’uso di tag e policy applicate in modo forzato abilita l’addebito automatico (chargeback) e la pulizia delle risorse. L’uso attivo di Cost Explorer, Cost and Usage Reports, Budgets e degli strumenti di ottimizzazione limita gli sprechi e supporta le decisioni su impegni a lungo termine come i Savings Plans o le Reserved Instances. Comprendere i fattori di costo specifici dei servizi (rete, storage, load balancer, NAT) previene costi imprevisti per il traffico in uscita (egress) e per i servizi gestiti.

Fatturazione, report sui costi e nozioni di base su Cost Explorer

Abilitare la fatturazione consolidata tramite AWS Organizations e inviare il Cost and Usage Report (CUR) a un bucket S3 con granularità oraria e ID di risorsa per supportare un’attribuzione dettagliata. Nella console di Billing, abilitare i tag di allocazione dei costi (sia quelli generati da AWS che quelli definiti dall’utente) in modo che Cost Explorer e il CUR includano le colonne dei tag. Per l’accesso programmatico, utilizzare l’API o la CLI di Cost Explorer: ad esempio,

undefined

Utilizzare Cost Explorer per l’analisi interattiva dei trend e per le viste di dimensionamento corretto (rightsizing): abilitare il report Rightsizing Recommendations, filtrare per tag o account collegato ed esportare le raccomandazioni in formato CSV. Per i flussi di lavoro automatizzati, ingerire il CUR in Athena (creando una tabella esterna sui file del CUR) per eseguire query SQL su varie dimensioni (linkedAccountId, productName, usageType, resourceId, tags). Combinare le query di Athena con i crawler di Glue per creare dashboard in QuickSight o per alimentare automazioni basate sulla fatturazione.

Criteri decisionali per la scelta della granularità e della conservazione dei report:

Utilizzare il CUR orario se si necessita di addebiti per singola istanza (chargeback) o di automazione basata su istanze di breve durata.
Utilizzare il CUR giornaliero per l’analisi dei trend su base mensile, quando il dettaglio orario non è necessario.
Attivare gli ID di risorsa quando si desidera unire i dati di fatturazione con l’inventario (Tag Editor, Resource Groups) per un’attribuzione accurata.

Strategie di tagging per l’allocazione dei costi e la governance

Adottare una tassonomia disciplinata per le chiavi dei tag (ad esempio: CostCenter, Owner, Project, Environment, Lifecycle) e imporla al momento della creazione. Attivare queste chiavi come Cost Allocation Tags in Billing in modo che appaiano in Cost Explorer e nel CUR. Implementare l’applicazione forzata con:

Tag Policies di AWS Organizations per prescrivere chiavi e valori consentiti.
La regola gestita required-tags di AWS Config per rilevare i tag mancanti.
Permessi IAM o Service Control Policies per negare la creazione di risorse senza i tag richiesti (usando le chiavi di condizione aws:RequestTag e aws:TagKeys).

Utilizzare l’API di Resource Groups Tagging e il Tag Editor per verificare e correggere i tag tra le varie regioni: ad esempio,

undefined

. Automatizzare la propagazione dei tag da CI/CD o CloudFormation associando tag a livello di stack e utilizzando hook basati su Lambda per aggiungere metadati di runtime (instanceId, launchTime) alle risorse.

Compromessi nella scelta dell’applicazione forzata dei tag:

Applicazione rigorosa (nega la creazione senza tag): previene la deriva di risorse non taggate ma può bloccare i flussi di lavoro effimeri degli sviluppatori se non esistono eccezioni.
Rilevamento e correzione (Config + automazione): ha un impatto minore ma introduce un ritardo tra la creazione e la correzione.

Savings Plans, Reserved Instances e rightsizing

Decidere tra on-demand, Savings Plans e Reserved Instances in base alla prevedibilità dell’utilizzo di calcolo e alle esigenze di flessibilità. Differenze principali:

Savings Plans: I Compute Savings Plans si applicano a EC2, Fargate e Lambda e offrono flessibilità tra dimensioni di istanza e regioni; gli EC2 Instance Savings Plans si rivolgono a famiglie di istanze in una regione specifica, con sconti maggiori ma minore copertura tra servizi.
Reserved Instances (RI): Le Standard RI offrono gli sconti maggiori per tipi di istanza fissi e possono essere regionali o zonali; le Convertible RI consentono di cambiare famiglia di istanza ma richiedono una riconfigurazione.
On-demand: Nessun impegno, costo orario più elevato, ideale per carichi di lavoro con picchi (bursty) o sconosciuti.

Utilizzare i report di rightsizing di Compute Optimizer e Cost Explorer per identificare istanze sottoutilizzate (CPU, rete, throughput EBS) e storage sovradimensionato. Combinare le metriche di CloudWatch (

undefined

) con le raccomandazioni di Compute Optimizer per giustificare il ridimensionamento (downsizing) o il cambio di famiglia di istanza. Quando l’utilizzo è stabile (ad es. ore-vCPU di base per la produzione), calcolare il punto di pareggio (break-even) e la copertura: acquistare Savings Plans o RI per il carico di base prevedibile e mantenere un buffer di istanze on-demand per i picchi di utilizzo.

Budget, allarmi e previsioni

Creare budget in AWS Budgets per costi, utilizzo e copertura di RI/Savings Plan con tipi di soglia Actual (effettivo) e Forecasted (previsto). Utilizzare la console o la CLI (

undefined

) e associare notifiche tramite topic SNS, e-mail o azioni Lambda. Per la correzione programmatica, collegare SNS a Lambda per taggare o arrestare risorse effimere, o per aprire ticket in sistemi ITSM quando le previsioni superano le soglie.

Aggiungere Cost Anomaly Detection per rilevare picchi di spesa improvvisi e collegare le anomalie a SNS/SQS per flussi di lavoro di indagine automatizzati. La previsione in Cost Explorer utilizza la spesa storica; combinarla con segnali di business (campagne di inizio trimestre, ticket aperti) per impostare allarmi di budget realistici. Per le decisioni operative:

Utilizzare soglie basate sulle previsioni per intercettare prima le tendenze di crescita.
Utilizzare soglie basate sui costi effettivi per evitare di superare il budget a fine mese.
Collegare gli allarmi a meccanismi di protezione automatizzati (guardrail) per arrestare o ridimensionare le risorse in account non critici.

Trasferimento dati e fattori di costo specifici del servizio

Rete e storage sono fattori di costo comuni e ad alta varianza. È importante comprendere queste specificità:

Trasferimento dati: il traffico in uscita (egress) tra regioni è fatturato per GB; il traffico tra AZ può essere gratuito o a pagamento a seconda del servizio (alcuni servizi addebitano costi per il traffico cross-AZ). I costi di NAT Gateway includono una tariffa oraria più i GB elaborati — le fatture di NAT Gateway possono dominare i costi di egress per carichi di lavoro ad alto throughput.
Load balancer: ALB/NLB comportano addebiti orari e per GB elaborato; il traffico con un intenso inoltro (forwarding) aumenta i costi.
S3/EBS: i prezzi dello storage S3 dipendono dalla classe (Standard, Intelligent-Tiering, Glacier) e dalle richieste; le policy di lifecycle spostano gli oggetti in classi di costo inferiore per ridurre la spesa di storage. Lo storage degli snapshot EBS è fatturato per GB-mese e per le operazioni di copia tra regioni.
Servizi gestiti: I/O di RDS, capacità di lettura/scrittura e backup on-demand di DynamoDB, e costi di storage e degli snapshot di ElasticSearch (OpenSearch Service).

Tattiche di ottimizzazione:

Utilizzare i VPC endpoint per S3 per ridurre il traffico in uscita (egress) verso Internet e usare S3 Transfer Acceleration o CloudFront per ridurre l’egress dall’origine quando si servono utenti a livello globale.
Consolidare il traffico tra regioni o collocare i servizi nella stessa regione per evitare l’egress tra regioni.
Sostituire i NAT Gateway con VPC endpoint, Gateway Load Balancer o istanze NAT quando appropriato e dopo aver testato i compromessi in termini di performance.

Errori Comuni e Criteri Decisionali

Lasciare risorse senza tag e non contabilizzate: imporre i tag obbligatori con AWS Config e usare la Resource Groups Tagging API per trovare e correggere automaticamente le risorse senza tag.
Fraintendere l’ambito di applicazione (scope) dei Savings Plan/RI: verificare se i Compute Savings Plans (cross-service) o gli EC2 Instance Savings Plans / RI (con scope di famiglia/zona) corrispondono ai propri carichi di lavoro prima di impegnarsi nell’acquisto.
Basarsi solo sulla CPU per il rightsizing: includere le metriche di memoria, rete e IOPS del disco (CloudWatch e Compute Optimizer) per evitare regressioni delle performance dopo il ridimensionamento (downsizing).
Ignorare i costi di trasferimento dati tra regioni/servizi: mappare i flussi di traffico, misurare l’egress tramite VPC Flow Logs/Athena e collocare nella stessa posizione i grandi produttori/consumatori di dati o usare CloudFront/VPC endpoint.
Configurazione errata del budget: scegliere appropriatamente tra Costi effettivi (Actual) e Previsti (Forecasted) e associare azioni programmatiche (SNS → Lambda) per limitare (throttle) o notificare in anticipo.
Lasciare storage/snapshot orfani e ELB inattivi: pianificare una pulizia automatizzata per volumi EBS non collegati, snapshot obsoleti e load balancer non utilizzati.

Problema Pratico: Scenario d’Uso

ApexAnalytics registra un picco di costi del 40% di mese in mese dopo una campagna di marketing; gli ingegneri hanno attivato numerosi stack di sviluppo in diverse regioni e si sono affidati a NAT Gateway per l’accesso a Internet. Il team finanziario necessita di visibilità e soluzioni immediate.

Attivare i report CUR orari con ID delle risorse e inviarli a un bucket S3 dedicato ai costi; creare una tabella Athena per interrogare i principali fattori di costo per linkedAccountId, regione e usageType.
Attivare e imporre i Cost Allocation Tag (CostCenter, Project, Owner) tramite Tag Policies e i tag obbligatori di AWS Config, e popolare retroattivamente i tag mancanti usando la Resource Groups Tagging API.
Eseguire i report di rightsizing di Cost Explorer e di Compute Optimizer, identificare un carico di calcolo di base stabile e acquistare un Savings Plan appropriato per le ore di base; pianificare il ridimensionamento (downsizing) per le istanze sottoutilizzate.
Verificare l’egress di rete con VPC Flow Logs → Athena; sostituire i NAT Gateway con VPC endpoint dove possibile e centralizzare i carichi di lavoro di test regionali per evitare trasferimenti tra regioni.
Creare AWS Budgets con soglie basate sulle previsioni (forecasted), collegare SNS per attivare una funzione Lambda che metta in quarantena gli account di sviluppo non critici o notifichi i proprietari, e abilitare Cost Anomaly Detection per i picchi improvvisi.

Logica: La consegna dei report CUR e l’imposizione dei tag consentono un chargeback preciso e un’analisi storica. Il rightsizing e gli impegni misurati (Savings Plans) riducono la spesa prevedibile, mentre le ottimizzazioni di rete e le azioni automatiche sui budget prevengono futuri costi di egress a sorpresa.

← Serverless e integrazione di applicazioni · Tutti i domini

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