Amazon SAA-C03: Gestione, Operazioni, Osservabilità e Costi — Guida allo studio

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

CloudWatch: Metriche, Namespace, Dashboard e Allarmi

CloudWatch è il piano di telemetria predefinito per i servizi AWS, ma la sua utilità dipende interamente dal sapere in quale namespace un servizio pubblica le proprie metriche. Un namespace è un contenitore per le metriche che previene collisioni tra i servizi: AWS/Lambda contiene Invocations, Errors e Throttles per le funzioni, mentre AWS/Events contiene Invocations, FailedInvocations, TriggeredRules e MatchedEvents per le regole di EventBridge. Questa distinzione è importante quando si diagnosticano pipeline basate su eventi. Se una regola di EventBridge invoca un’API di terze parti tramite una destinazione API e nessun traffico arriva a valle, la risposta non si trova in AWS/Lambda, ma in AWS/Events. Controllare TriggeredRules indica se il pattern della regola ha effettivamente trovato una corrispondenza, e Invocations/FailedInvocations indicano se il target stesso è stato chiamato e se la chiamata ha avuto successo. Cercare le metriche di Lambda solo perché è il servizio più familiare ignora il fatto che la regola potrebbe non aver mai corrisposto a un evento in arrivo.

La risoluzione delle metriche è un’impostazione per singola risorsa con implicazioni sui costi. Il monitoraggio di base emette metriche ogni cinque minuti senza costi aggiuntivi, il che è sufficiente per carichi di lavoro stabili e di lunga durata, ma è troppo grossolano per reazioni di autoscaling, rilevamento di picchi o calcoli di SLO che richiedono una risoluzione al minuto. Il monitoraggio dettagliato riduce l’intervallo a un minuto (e a un secondo per le metriche personalizzate ad alta risoluzione), ed è ciò che si abilita quando i gruppi di scaling devono reagire rapidamente. È una funzionalità a pagamento, motivo per cui non è attiva di default.

Ogni servizio emette nativamente un set predefinito di metriche, ma l’hypervisor non può vedere all’interno del sistema operativo guest. CPUUtilization, NetworkIn e DiskReadOps sono visibili per EC2 senza alcuno sforzo; l’utilizzo della memoria e le percentuali di utilizzo del filesystem richiedono l’agente CloudWatch, che è l’unico modo per ottenerle. Anche le metriche personalizzate delle applicazioni arrivano tramite l’agente o tramite PutMetricData.

Gli allarmi dovrebbero distinguere il segnale dal rumore. Un singolo allarme su CPU > 50% si attiva costantemente durante i normali picchi di attività, abituando gli operatori a ignorarlo. Gli allarmi compositi combinano gli stati degli allarmi figli con un’espressione booleana, in modo che gli operatori vengano avvisati solo quando si verifica una condizione realmente problematica e che richiede un intervento. Per un carico di lavoro in cui i picchi transitori di CPU sono benigni ma una pressione prolungata sulla CPU combinata con IOPS di lettura su disco elevati indica un problema reale:

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

Gli allarmi figli possono comunque passare internamente allo stato ALARM, ma solo l’allarme composito attiva SNS. Due allarmi indipendenti che avvisano entrambi il personale di turno ricreano il problema del rumore; un singolo allarme con una soglia più alta non coglierebbe la correlazione.

Le dashboard aggregano widget di metriche, widget di log e testo. Esistono due modelli di condivisione e confonderli è un errore comune. Se un utente ha già un account AWS, concedigli un’identità IAM (o un ruolo tramite l’osservabilità cross-account) con le autorizzazioni cloudwatch:GetDashboard e cloudwatch:GetMetricData. Se l’utente non ha un account AWS — un product manager, uno stakeholder del cliente — si utilizza la funzionalità di condivisione integrata della dashboard, che produce un link condivisibile protetto da una singola coppia email/password, da un user pool di Cognito o da un URL pubblico (raramente appropriato). Inviare screenshot via email non è osservabilità, e creare un utente IAM con accesso alla console per un utente non-AWS non rispetta il principio del privilegio minimo.

Osservabilità Cross-Account con OAM

Saltare tra decine di account per visualizzare le metriche è insostenibile. L’osservabilità cross-account di CloudWatch designa un account di monitoraggio come sink centrale e un numero qualsiasi di account di origine che condividono metriche, log e tracce con esso tramite risorse sink e link. Il modo più rapido per implementarlo su larga scala è aprire la console di CloudWatch nell’account di monitoraggio, creare un sink e distribuire il template CloudFormation StackSet generato in tutta l’organizzazione per creare risorse AWS::Oam::Link in ogni account di origine:

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

Risolvere questo problema con ruoli IAM cross-account e query manuali è tecnicamente possibile, ma non fornisce dashboard unificate, query Metrics Insights cross-account o l’arricchimento automatico con le etichette dei nomi degli account che i link OAM offrono.

Container Insights e Tracciamento Distribuito

Per i carichi di lavoro containerizzati, Container Insights è la funzionalità canonica di CloudWatch. Su EKS, distribuisce l’agente CloudWatch (o il collettore ADOT) come DaemonSet più Fluent Bit per l’inoltro dei log. L’agente estrae (scrape) le metriche da cAdvisor e kubelet e le emette nei namespace ECS/ContainerInsights e ContainerInsights (CPU/memoria per pod, nodo, namespace e cluster), mentre Fluent Bit invia stdout/stderr a gruppi di log come /aws/containerinsights/<cluster>/application, /dataplane e /host. È possibile implementare il proprio stack Prometheus/Grafana, ma il modello gestito è Container Insights più Logs Insights:

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

Le metriche ti dicono che qualcosa è lento; le tracce ti dicono dove. X-Ray strumenta ogni servizio nel percorso di una richiesta, propagando un ID di traccia tramite l’header X-Amzn-Trace-Id ed emettendo segmenti e sottosegmenti al demone X-Ray o al collettore ADOT. La mappa dei servizi visualizza nodi e archi con percentuali di latenza, errore e fault. Senza X-Ray, un picco p99 emerge come una metrica CloudWatch senza alcuna attribuzione.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights, X-Ray e CloudWatch Logs sono i tre pilastri dell’osservabilità dei microservizi.

I tre flussi di log: CloudTrail, VPC Flow Logs, CloudWatch Logs

Qualsiasi strategia di osservabilità su AWS distingue tre flussi di log separati: attività delle API sul piano di gestione (CloudTrail), attività di rete sul piano dati (VPC Flow Logs) e output di applicazioni/sistemi operativi (CloudWatch Logs). Ciascuno risponde a un diverso quesito forense, e confonderli è un errore di progettazione comune.

CloudTrail registra ogni chiamata API AWS: chi l’ha invocata (userIdentity), da quale IP, su quale risorsa, con quali parametri e se ha avuto successo. È l’unico servizio che collega in modo affidabile una modifica a uno specifico principal IAM. Un malinteso comune è che CloudWatch Logs sia il posto giusto per cercare l’attività delle API; CloudWatch Logs acquisisce l’output di applicazioni/sistemi, non dati di audit a livello di principal. CloudTrail può inviare i suoi eventi a CloudWatch Logs per il filtraggio di metriche in tempo reale, ma il record di audit sottostante ha origine in CloudTrail.

In un ambiente AWS Organizations, il pattern corretto è un trail di organizzazione (organization trail) creato dall’account di gestione (o da un account amministratore delegato), che registra automaticamente i nuovi account membri e invia gli eventi in streaming a un singolo bucket S3 in un account di archiviazione dei log dedicato:

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

Il bucket di destinazione necessita di versioning, una bucket policy che limiti s3:PutObject al service principal di CloudTrail, crittografia SSE-KMS, accesso in lettura cross-account per gli auditor e, idealmente, S3 Object Lock in modalità conformità (compliance mode) per garanzie WORM (Write Once, Read Many). La convalida dei file di log produce file di digest firmati, in modo che le manomissioni siano rilevabili. Gli eventi di gestione sono attivi di default per 90 giorni; per conservarli oltre questo periodo è necessario un trail. Gli eventi dati (a livello di oggetto S3, invocazione di Lambda, a livello di item DynamoDB) sono da attivare esplicitamente a causa del volume e del costo. Per query storiche ad-hoc, CloudTrail Lake o Athena sul bucket del trail permettono di eseguire SQL:

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

I VPC Flow Logs acquisiscono metadati sul traffico IP (la 5-tupla, byte, pacchetti, azione (ACCEPT/REJECT) e stato del log) per un VPC, una sottorete o un’ENI. Non acquisiscono i payload dei pacchetti. Le destinazioni di consegna sono CloudWatch Logs, S3 o Kinesis Data Firehose. Scegliere S3 per l’archiviazione; scegliere CloudWatch Logs quando si necessita di filtri di metrica per attivare allarmi su pattern di traffico sospetti; scegliere Firehose quando il requisito è l’analisi quasi in tempo reale. La pipeline canonica quasi in tempo reale per un VPC con NLB, ASG e database:

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

Il percorso alternativo CloudWatch Logs → filtro di sottoscrizione → Firehose → OpenSearch funziona, ma aggiunge un passaggio e costi. S3 è la scelta sbagliata quando il requisito è “quasi in tempo reale”. Non abilitare affatto i Flow Logs è la trappola più dannosa: quando si verifica un incidente di sicurezza, non esiste alcuna registrazione di sorgente/destinazione/porta e nessuna visibilità su ACCEPT vs REJECT. Lo stesso ragionamento si applica ai log di accesso degli ALB: sono da attivare esplicitamente, vengono consegnati a S3 e senza di essi non c’è alcuna registrazione a livello di richiesta degli IP dei client, dei codici di risposta, delle latenze dei target o degli user agent. Insieme, i Flow Logs (L3/L4) e i log di accesso degli ALB (L7) costituiscono la baseline per l’analisi forense del traffico.

CloudWatch Logs riceve i log di applicazioni, Lambda e sistemi operativi tramite l’agente CloudWatch. La sua potenza deriva dai filtri di metrica: espressioni di pattern che analizzano gli eventi in entrata e, in caso di corrispondenza, incrementano una metrica personalizzata, che a sua volta attiva un allarme:

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

Un filtro parallelo sulla porta 3389 copre l’RDP. L’ingestione di log senza allarmi produce analisi forense post-incidente, non prevenzione.

Per flotte di grandi dimensioni, lo standard è instradare i log a una pipeline di elaborazione tramite un filtro di sottoscrizione su un gruppo di log, inviando in streaming gli eventi corrispondenti a un Kinesis Data Stream, Firehose o Lambda quasi in tempo reale:

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

La trappola è inviare log grezzi all’archiviazione senza una pipeline di elaborazione: scaricarli su S3 senza un catalogo Glue, un indice OpenSearch o un workgroup Athena significa che i log esistono ma non possono essere utilizzati per agire durante un incidente. L’osservabilità richiede una superficie di interrogazione, non solo byte durevoli. I gruppi di log necessitano anche di policy di conservazione esplicite (l’impostazione predefinita è “non scadere mai”, che consuma denaro silenziosamente) e possono essere esportati su S3 per l’archiviazione a lungo termine tramite regole di lifecycle.

Rilevamento di Eventi a Livello API con il Minimo Overhead

Per eventi di alto valore sul piano di controllo (control plane) — CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin senza MFA — il pattern con il minor overhead è CloudTrail → regola EventBridge → SNS. EventBridge riceve nativamente ogni evento di gestione di CloudTrail, e una regola con un event pattern non necessita di codice “collante” (glue code) Lambda:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

Inviare CloudTrail a CloudWatch Logs e applicare un filtro di metrica funziona ugualmente, ma aggiunge un gruppo di log, un filtro, un allarme e dei costi, risultando quindi svantaggioso in termini di overhead operativo quando il requisito è semplicemente “avvisare in caso di API X”.

AWS Config: Configurazione Continua e Drift

Config e CloudTrail vengono spesso confusi, ma rispondono a domande fondamentalmente diverse. CloudTrail registra chi ha chiamato cosa; Config registra come appare la risorsa ora e come è cambiata nel tempo. Aspettarsi che Config registri le chiamate API è un classico errore: Config non sa che un utente ha invocato PutBucketAcl; sa che alle 14:03:22 l’ACL del bucket è cambiata dallo stato A allo stato B. Per identificare il principal, è necessario correlare la registrazione della modifica di Config con l’evento CloudTrail allo stesso timestamp (Config fornisce un deep-link a quest’ultimo nella console).

Le regole di Config (Config rules) valutano le risorse rispetto a uno stato desiderato. Le regole gestite (Managed rules) coprono controlli comuni (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), mentre le regole personalizzate (custom rules) vengono eseguite come funzioni Lambda o utilizzano CloudFormation Guard. Le regole eseguono la valutazione al momento di una modifica della configurazione e secondo una pianificazione, contrassegnano le risorse come COMPLIANT o NON_COMPLIANT e possono attivare una remediation automatica tramite i documenti di SSM Automation. Questa è la risposta a basso carico operativo per “rilevare SSH aperto” o “rilevare tipi di istanza sovradimensionati”: le regole esistono già e si integrano nativamente con SNS e Security Hub. Proporre audit manuali periodici, scansioni pianificate o scanner personalizzati richiede di creare e manutenere codice che Config fornisce già di serie.

Config pubblica i risultati della valutazione su SNS. Per automatizzare la remediation, si collega una regola di EventBridge all’evento di cambio di conformità (compliance-change) e si invoca un documento di SSM Automation o una Lambda:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Gli aggregatori (Aggregators) consolidano la conformità (compliance) all’interno di un’organizzazione; i pacchetti di conformità (conformance packs) raggruppano regole per framework come PCI-DSS o HIPAA. Workload Discovery on AWS (precedentemente AWS Perspective) è una soluzione basata su Config che visualizza le relazioni tra le risorse e genera diagrammi dell’architettura: è la risposta canonica quando una domanda richiede uno strumento di inventario in grado di creare un diagramma di un ambiente esistente. Config è un prerequisito.

Security Hub, GuardDuty e Control Tower

Security Hub è il piano di aggregazione per i risultati di sicurezza (findings). Acquisisce dati da GuardDuty (rilevamento delle minacce basato su VPC Flow Logs, DNS e CloudTrail), Inspector (risultati di vulnerabilità), Macie, IAM Access Analyzer e Config, per poi normalizzare tutto nel formato AWS Security Finding Format (ASFF). L’abilitazione di Security Hub abilita anche gli standard di sicurezza, in particolare lo standard AWS Foundational Security Best Practices (FSBP): decine di controlli automatici (MFA per l’utente root, S3 pubblici, EBS non crittografati, CloudTrail multi-regione) mappati internamente a regole di Config.

Su scala di organizzazione, si designa un account amministratore delegato per Security Hub (e per GuardDuty e Config), si abilita il servizio e lo standard FSBP per l’intera organizzazione con l’opzione “auto-enable new accounts” e si instradano i risultati tramite EventBridge a SNS, filtrando per Security Hub Findings - Imported sull’ARN dello standard FSBP con Compliance.Status = FAILED. Creare una propria Lambda per il parsing di CloudTrail o dashboard per ogni account aggiunge un carico operativo che Security Hub gestisce già.

Una distinzione concettuale cruciale: Security Hub è di tipo detective e aggregativo, non preventivo. Prevenire il drift è compito di AWS Control Tower, che orchestra una landing zone multi-account ben architettata. Account Factory esegue il provisioning di nuovi account con una configurazione di base per networking, logging e IAM. La governance è espressa tramite guardrail di tre tipi:

I controlli proattivi valutano i template di CloudFormation prima che uno stack venga distribuito e impediscono la creazione, ad esempio, di un’istanza RDS non crittografata. Security Hub si limiterebbe a segnalare l’esistenza dell’istanza non crittografata solo dopo che è in esecuzione. Se un requisito dice “prevenire”, la risposta è Control Tower. Se dice “rilevare, notificare o aggregare”, la risposta è Security Hub o Config.

Macie: Scoperta di Dati Sensibili

Macie utilizza ML e pattern matching per identificare dati sensibili (PII, dati finanziari, credenziali) all’interno degli oggetti S3. L’errore critico è presumere che Macie protegga i dati. Non lo fa. Macie scopre e segnala. Utilizzo corretto:

1. Abilitare Macie nell’account/regione di destinazione.
2. Configurare un processo di scoperta di dati sensibili (sensitive data discovery job), specificando bucket/prefissi/tag secondo una pianificazione.
3. Instradare i risultati (findings) tramite EventBridge (source: aws.macie) a SNS per le notifiche, a Lambda per la remediation (messa in quarantena, restrizione della bucket policy) o a Security Hub.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Senza il processo di scoperta, Macie non produce alcun risultato. Senza il collegamento EventBridge → SNS, i risultati rimangono inosservati all’interno della console di Macie.

Organizations, SCP e Tag Policy

AWS Organizations espone tre tipi di policy rilevanti in questo contesto. Le Tag policy definiscono le chiavi dei tag, l’uso di maiuscole/minuscole e i valori consentiti; esse segnalano la non conformità e, se combinate con le condizioni aws:ResourceTag/aws:RequestTag, possono essere applicate in modo restrittivo. Le Service Control Policy (SCP) definiscono i permessi massimi disponibili per le entità principali (principal) degli account membri. Le Backup policy e le AI opt-out policy completano l’insieme.

Un modello mentale cruciale: le SCP non concedono mai permessi. Sono un filtro su ciò che IAM (policy di identità, policy di risorsa, permissions boundary) potrebbe altrimenti consentire. Un’entità principale (principal) deve avere un Allow in IAM e la SCP non deve contenere un Deny (oppure deve includere l’azione nella sua lista di Allow). “Basta allegare una SCP” non è mai una risposta completa a una domanda sui permessi: senza un Allow in IAM, all’entità principale viene negato l’accesso per impostazione predefinita, indipendentemente dal contenuto della SCP.

Per richiedere i tag al momento della creazione, si combinano le tag policy con una SCP come la seguente:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

La tag policy dichiara lo schema; la SCP nega la creazione senza il tag; la policy IAM concede l’azione di creazione. Sono necessari tutti e tre. La regola required-tags di AWS Config rileva e corregge le risorse esistenti non conformi.

Systems Manager Automation e Patching

Systems Manager (SSM) è la spina dorsale operativa per le attività del ciclo di vita su flotte di istanze EC2 e nodi ibridi. Due costrutti sono particolarmente importanti per il patching: gli Automation document (runbook dichiarativi in YAML/JSON che richiamano API AWS o script) e le Maintenance Window (che pianificano l’esecuzione di tali runbook su target basati su tag o gruppi di risorse, all’interno di una finestra di modifica con soglie di concorrenza ed errore).

Il flusso di patching canonico prevede l’esecuzione di AWS-RunPatchBaseline (un Command document) su istanze selezionate tramite un tag di Patch Group, utilizzando una Patch Baseline che definisce le regole di approvazione per ogni sistema operativo. Per le istanze dietro un load balancer, l’esecuzione diretta di AWS-RunPatchBaseline interrompe le connessioni a metà del processo di patching, poiché le istanze rimangono nello stato InService nel target group. Il pattern corretto è AWSEC2-PatchLoadBalancerInstance, che esegue le seguenti operazioni:

1. Annulla la registrazione (deregister) dell’istanza dal suo target group di un CLB o ALB.
2. Attende il completamento del connection draining / il ritardo di annullamento della registrazione.
3. Avvia i passaggi di scansione e installazione della patch baseline.
4. Riavvia l’istanza se la baseline lo richiede.
5. Registra nuovamente l’istanza e attende che il controllo di integrità del target restituisca lo stato healthy.

Due prerequisiti causano la modalità di fallimento “produce errori”. Primo, il ruolo IAM passato come AutomationAssumeRole deve includere elasticloadbalancing:DeregisterTargets, RegisterTargets e DescribeTargetHealth oltre ai permessi standard di patching di SSM. Secondo, l’istanza deve essere un managed node, ovvero con l’SSM Agent in esecuzione e il profilo dell’istanza che include la policy AmazonSSMManagedInstanceCore. Senza questi prerequisiti, le chiamate di annullamento della registrazione falliscono o SSM non è in grado di “vedere” l’istanza.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← Sicurezza · Tutti i domini · Alta Disponibilità →

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

Sfoglia Amazon →