Amazon SOA-C02: Monitoraggio, registrazione e ripristino — 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.

Monitoraggio, logging e remediation costituiscono il sistema nervoso operativo per gli ambienti AWS: rilevano i problemi, forniscono contesto e guidano le azioni correttive. Questo dominio copre la creazione di metriche e dashboard significative, la raccolta e la conservazione dei log in modo economicamente vantaggioso, la creazione di un’osservabilità delle applicazioni tracciabile e l’automazione di allarmi e remediation. Le buone implementazioni bilanciano il rapporto segnale/rumore, controllano i costi e garantiscono che i playbook e le automazioni siano testati e verificabili.

Metriche, dashboard e allarmi di CloudWatch

Progettare le metriche attorno agli SLI di business e operativi (latenza, tasso di errore, profondità della coda, CPU/memoria per l’infrastruttura). Utilizzare le metriche integrate (EC2, RDS, ELB) più le metriche personalizzate tramite PutMetricData per i contatori a livello di applicazione (aws cloudwatch put-metric-data –namespace MyApp –metric-name OrdersPerMinute –value 42). Preferire dimensioni che abilitano il filtraggio (InstanceId, ServiceName) ed evitare dimensioni ad alta cardinalità che fanno esplodere i costi delle metriche.

Utilizzare le dashboard di CloudWatch per combinare metriche, log e allarmi in viste operative. Creare widget nella console o tramite CloudFormation (AWS::CloudWatch::Dashboard) con la metric math per le metriche derivate: calcolare il tasso di errore usando la metric math (ERRORS/SUM(REQUESTS)) e visualizzare i percentili (p50, p90, p99). Per gli allarmi, scegliere i pattern di configurazione in base all’intento:

Allarmi su metrica singola per soglie semplici: aws cloudwatch put-metric-alarm –alarm-name HighCPU –metric-name CPUUtilization –namespace AWS/EC2 –statistic Average –period 300 –evaluation-periods 2 –threshold 80 –comparison-operator GreaterThanThreshold –alarm-actions arn:aws:sns:…
Allarmi compositi per ridurre il rumore combinando condizioni (AND/OR) tra più allarmi.
Rilevamento delle anomalie per regolare automaticamente le soglie: utilizzare il rilevamento delle anomalie di CloudWatch su una metrica con un comportamento stagionale previsto.

Criteri decisionali: utilizzare i periodi di valutazione e le impostazioni datapoint-to-alarm per evitare il flapping; attivare SNS, Auto Scaling o Systems Manager Automation come azioni di allarme. Preferire gli allarmi compositi e il rilevamento delle anomalie per ambienti con baseline variabili.

CloudWatch Logs, Logs Insights e conservazione

Aggregare i log con i gruppi di log di CloudWatch Logs e strutturarli per applicazione e ambiente. Creare gruppi di log tramite CLI: aws logs create-log-group –log-group-name /aws/myapp/frontend e imporre la conservazione con aws logs put-retention-policy –log-group-name /aws/myapp/frontend –retention-in-days 30. Utilizzare i filtri di sottoscrizione per trasmettere i log in streaming a Kinesis Data Firehose (per S3/Redshift), Lambda (elaborazione in tempo reale) o strumenti di partner; comprimere e partizionare in S3 per ridurre i costi di archiviazione.

Utilizzare CloudWatch Logs Insights per query ad-hoc e dashboard; creare query salvate che estraggono ID di traccia e contesti di errore (es., fields @timestamp, @message | filter @message like /ERROR/ | parse “traceId=* " as traceId). Pratiche di controllo dei costi di conservazione e ingestione:

Impostare una conservazione appropriata per ogni gruppo di log (7/30/90/365 giorni) in base alle esigenze di conformità e troubleshooting.
Esportare i log più vecchi su S3 tramite il ciclo di vita della conservazione o Firehose con compressione e regole del ciclo di vita verso Glacier/Archive.
Utilizzare il campionamento o log strutturati (JSON) e l’Embedded Metric Format (EMF) per ridurre i costosi log ad alta cardinalità, derivando comunque le metriche.

Criteri decisionali: conservazione breve per i log di debug prolissi, conservazione più lunga per i log di audit/sicurezza; instradare i log ad alto volume verso S3 invece della conservazione a tempo indeterminato in CloudWatch.

CloudTrail, tracce di audit e cronologia degli eventi

Abilitare CloudTrail in tutte le regioni e account; creare un trail dell’organizzazione per il logging di audit centralizzato in un bucket S3 protetto, con convalida dei file di log e crittografia SSE-KMS. Configurare gli eventi di gestione (Read/Write) e abilitare selettivamente gli eventi dati (a livello di oggetto S3, invocazione di funzioni Lambda) dove è richiesto un audit dettagliato, poiché gli eventi dati hanno volume e costo più elevati.

Utilizzare la cronologia degli eventi di CloudTrail nella console per ricerche rapide su 90 giorni e CloudTrail Lake o Athena sui log esportati in S3 per analisi e indagini a lungo termine. Proteggere il trail:

Imponendo trail multi-regione per catturare gli eventi dei servizi globali.
Integrando CloudTrail con CloudWatch Logs per il rilevamento quasi in tempo reale, o con EventBridge per instradare eventi specifici a Lambda/Systems Manager per la remediation automatizzata.
Applicando policy del bucket S3 e S3 Object Lock (se necessario) per prevenire la manomissione.

Criteri decisionali: abilitare gli eventi dati solo per i bucket/funzioni dove è necessaria una visibilità forense; utilizzare trail centralizzati e pattern di accesso cross-account per semplificare la conformità.

Tracciamento delle applicazioni e osservabilità (X-Ray)

Strumentare le applicazioni con gli SDK di AWS X-Ray per emettere segmenti e sottosegmenti. Per i runtime non strumentati, eseguire il demone/agente X-Ray come sidecar o servizio (task ECS, demone EC2 o tracciamento integrato di Lambda). Configurare regole di campionamento per controllare il volume delle tracce e impostare le mappe di servizio in ServiceLens per visualizzare le dipendenze tra i servizi. Annotare le tracce con chiavi di business (userId, orderId) e registrare eccezioni/metadati per facilitare il triage.

Correlare le tracce con i log includendo l’ID di traccia X-Ray nei log dell’applicazione (usare l’header di traccia o l’SDK per ottenere l’ID di traccia corrente) in modo che le query di CloudWatch Logs Insights possano unire log e tracce. Per Lambda, abilitare il tracciamento attivo (Console o aws lambda update-function-configuration –function-name fn –tracing-config Mode=Active) per inviare automaticamente le tracce a X-Ray. Utilizzare l’analisi delle tracce per rilevare le latenze di coda (tail latency), gli hotspot e il dettaglio delle chiamate al database.

Criteri decisionali: abilitare il tracciamento per i servizi critici e utilizzare il campionamento adattivo per limitare i costi; preferire tracce strutturate (annotazioni/metadati) per rendere deterministica la correlazione Log+Tracce.

Remediation e alerting automatizzati (EventBridge/Lambda)

Utilizzare le regole di EventBridge per intercettare i cambiamenti di stato degli allarmi CloudWatch, gli eventi CloudTrail o eventi personalizzati e instradarli verso target come Lambda, documenti di Systems Manager Automation, Step Functions o SNS. Creare regole con trasformatori di input per passare un contesto minimo all’azione di remediation (

undefined

). Implementare funzioni Lambda per remediation leggere (riavviare un servizio, revocare credenziali) ma usare SSM Automation o Step Functions per playbook a lunga esecuzione, auditabili e con checkpoint.

Progettare le remediation tenendo conto della sicurezza: includere modalità di dry-run, idempotenza, passaggi di validazione, principio del privilegio minimo (least-privilege) di IAM, logging e un kill-switch. Utilizzare code di messaggi non recapitabili (dead-letter queue) e policy di tentativi nelle integrazioni EventBridge/Lambda e pubblicare i tentativi di remediation in un log di audit o in un security trail. Testare le automazioni in un account di staging ed eseguire test canary dopo il deployment.

Criteri decisionali: preferire SSM Automation o Step Functions per ripristini multi-step e approvazione umana; usare Lambda per correzioni semplici e veloci. Includere sempre un rollback manuale o un punto di interruzione con intervento umano per le azioni rischiose.

Errori comuni e criteri decisionali

Affidarsi a una singola metrica per le decisioni sullo stato di salute: combinare metriche (es. tasso di errore + latenza + throttle) o usare allarmi compositi/metric math per evitare falsi positivi.
Non tenere conto dei costi di conservazione e ingestione dei log: impostare la retention per ogni gruppo di log, instradare i log massivi su S3 tramite Firehose con compressione e usare policy di lifecycle per spostare i dati più vecchi su tier di archiviazione più economici.
Strumentazione eccessiva con dimensioni ad alta cardinalità o campionamento delle tracce disabilitato: limitare le dimensioni e abilitare il campionamento adattivo per controllare i costi preservando il segnale.
Eseguire il deployment di remediation automatizzate senza test: validare in staging, usare flag di dry-run e assicurare l’idempotenza e rollback sicuri prima dell’attivazione in produzione.
Affaticamento da alert a causa di allarmi rumorosi: usare il rilevamento delle anomalie, allarmi compositi, finestre di soppressione e inoltrare al personale di turno (on-call) solo gli eventi significativi.
Mancata correlazione tra log, metriche e tracce: propagare i trace ID nei log e nelle metriche EMF, e creare query salvate in Logs Insights e viste in ServiceLens per collegare i dati tra loro.

Problema pratico: scenario d’uso

Acme Payments riscontra fallimenti intermittenti nell’elaborazione dei pagamenti durante i picchi di traffico; gli ingegneri notano un aumento della latenza e sporadici errori 5xx, ma i riavvii automatici hanno talvolta mascherato la causa principale (root cause).

Strumentare il servizio di pagamento con l’SDK di X-Ray e le metriche EMF; aggiungere i trace ID ai log dell’applicazione e inviare le metriche strutturate OrdersFailed e OrdersProcessed tramite PutMetricData/EMF.
Creare una CloudWatch metric math per calcolare il tasso di errore (OrdersFailed / OrdersProcessed) e un allarme composito che combini tasso di errore > soglia E latenza p99 > soglia.
Indirizzare le azioni dell’allarme a una regola EventBridge che avvia un workflow di Step Functions per i passaggi diagnostici (raccogliere tracce/log recenti, eseguire controlli di integrità) e, se sicuro, un riavvio automatico tramite SSM Automation.
Configurare la sottoscrizione di CloudTrail e CloudWatch Logs per archiviare i log completi su S3 (compressi) con una policy di lifecycle verso Glacier, e impostare una retention breve in CloudWatch per i log di debug verbosi.
Eseguire test end-to-end e transazioni sintetiche canary (CloudWatch Synthetics) per validare l’osservabilità e il flusso di remediation prima di abilitare la auto-remediation in produzione.

Motivazione: correlare metriche, log e tracce per individuare la causa principale invece di trattare ripetutamente i sintomi; combinare gli allarmi per ridurre il rumore e utilizzare un’automazione auditabile e testata (Step Functions/SSM) per una remediation sicura, controllando al contempo i costi di archiviazione dei log.

Tutti i domini · Alta disponibilità →

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