Amazon DOP-C02: Systems Manager, Patching e Automazione Operativa — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’automazione operativa su AWS si basa su AWS Systems Manager, che unifica il controllo degli accessi, la configurazione, l’applicazione di patch e la remediation su istanze EC2, server on-premise e dispositivi edge. I servizi correlati forniscono pipeline per “golden image” (EC2 Image Builder), governance delle licenze (AWS License Manager), ottimizzazione continua (AWS Trusted Advisor e AWS Compute Optimizer) e controlli dei costi (Savings Plans). L’obiettivo è avere operazioni standardizzate e verificabili, guidate da eventi e applicabili trasversalmente su più account e Regioni.

Accesso, Parametri, Inventario e Conformità di Systems Manager

Systems Manager Session Manager fornisce un accesso shell interattivo e verificabile alle istanze gestite senza aprire porte in entrata o gestire chiavi SSH. La connessione avviene tramite il control plane di AWS, opzionalmente attraverso endpoint di interfaccia VPC per una connettività privata. Il port forwarding consente l’accesso sicuro a servizi locali o remoti dietro l’istanza:

Le sessioni di local port forwarding instradano una porta della workstation locale a una porta sull’istanza di destinazione (ad esempio, inoltrare localhost:8080 a instance:8080).
Il remote host port forwarding instrada una porta locale, tramite l’istanza, a un altro host privato raggiungibile da quell’istanza. Session Manager supporta la registrazione centralizzata e verificabile delle trascrizioni e dell’I/O delle sessioni sia su Amazon S3 che su Amazon CloudWatch Logs, con crittografia KMS opzionale. L’attività delle API (StartSession, TerminateSession) viene catturata in AWS CloudTrail. È possibile imporre controlli tramite le preferenze di Session Manager: richiedere la crittografia, limitare il port forwarding o gli appunti e registrare i log in entrambe le destinazioni.

Systems Manager Parameter Store centralizza la configurazione e i segreti. Utilizzare parametri di tipo SecureString crittografati con una chiave KMS gestita dal cliente per i segreti delle applicazioni. Organizzare i valori in percorsi gerarchici (ad esempio, /prod/payments/db/password) per abilitare lo scoping per ambiente e applicazione, lo scoping delle policy e le operazioni massive. Il versioning dei parametri mantiene una cronologia immutabile; le etichette (come current) consentono di puntare le applicazioni a un target mobile senza modificare il codice. I riferimenti dinamici in CloudFormation, CodeBuild e altri servizi risolvono i parametri al momento del deploy o del runtime, prevenendo la proliferazione dei segreti. Il livello Standard offre un throughput di base e una dimensione massima del valore di 4 KB; il livello Advanced supporta policy per i parametri (scadenza, notifiche di rotazione), valori più grandi (8 KB) e un throughput più elevato. Le regole di EventBridge possono notificare le modifiche ai parametri e le policy delle risorse abilitano la condivisione di parametri tra account diversi, dove necessario.

Systems Manager Inventory e Compliance forniscono visibilità a livello di flotta. Inventory (abilitato tramite un’associazione di State Manager) raccoglie metadati come pacchetti software installati, ruoli di Windows, schede di rete e item di inventario personalizzati. Utilizzare Resource Data Sync per esportare i dati su S3 per analisi con Athena/Glue e per visualizzare lo stato dell’intera flotta in Systems Manager Explorer. Compliance aggrega gli stati di patching e delle associazioni: è possibile vedere quali istanze mancano di patch o hanno baseline di configurazione fallite. Questo crea la base di dati operativi necessaria per la remediation automatizzata, gli audit e il rilevamento delle licenze.

Patch Manager e Orchestrazione Operativa

Patch Manager standardizza l’applicazione di patch al sistema operativo e alle applicazioni utilizzando patch baseline, patch group e finestre di manutenzione.

Le patch baseline definiscono cosa approvare e quando. Per ogni famiglia di sistemi operativi, è possibile partire da una baseline predefinita fornita da AWS o crearne una personalizzata con:

Regole di approvazione automatica per prodotto/versione, classificazione (ad esempio, Security, Bugfix), gravità e architettura
Un ritardo nell’approvazione (ad esempio, approvare automaticamente le patch di sicurezza sette giorni dopo il rilascio)
Liste esplicite di patch consentite (allow list) e bloccate (block list)
Sorgenti/repository di patch (ad esempio, aggiungere un repository yum o apt personalizzato per software interno) Associare una baseline a un patch group. Un patch group è un insieme di istanze identificate dal tag Patch Group con un valore specifico (ad esempio, Patch Group=linux-prod); l’associazione garantisce che la baseline corretta sia applicata ai server giusti. Ogni istanza dovrebbe appartenere a un solo patch group per evitare ambiguità. Le operazioni di patching utilizzano il documento AWS-RunPatchBaseline con Operation=Scan per calcolare la conformità e Operation=Install per applicare le patch approvate. Controllare la concorrenza, le soglie di errore e il comportamento di riavvio. Utilizzare InstallOverrideList per il “pinning” di emergenza di pacchetti specifici. I risultati di conformità confluiscono in Systems Manager Compliance, da cui è possibile generare allarmi ed eseguire la remediation.

Le finestre di manutenzione (maintenance windows) confinano le operazioni potenzialmente disruptive in intervalli di tempo sicuri. Definire una pianificazione (rate/cron), una durata e un tempo limite (cutoff) per impedire l’avvio di nuovi task in prossimità della fine della finestra. Registrare i target tramite tag o gruppi di risorse, quindi registrare i task con una priorità. Patch Manager si integra nativamente: registrare un task AWS-RunPatchBaseline per i propri patch group e baseline. Le impostazioni di concorrenza e soglia di errore sui task prevengono un “blast radius” (raggio d’impatto) esteso in caso di fallimenti.

Systems Manager Automation rende operative le attività di remediation ripetibili e verificabili. Utilizzare runbook predefiniti e personalizzati per orchestrare le attività pre e post-patch (ad esempio, rimuovere dal load balancer, fermare i servizi applicativi, applicare patch, eseguire smoke test, registrare nuovamente) e per imporre controlli tramite la remediation di AWS Config. Automation supporta approvazioni (Change Manager), calendari delle modifiche (per impedire l’esecuzione durante periodi di blocco) e l’esecuzione cross-account/Regione tramite assume-role. Collegare il tutto con regole di Amazon EventBridge che reagiscono a eventi di stato, deviazioni di configurazione (config drift) o allarmi per attivare esecuzioni mirate di Automation per l’auto-riparazione (self-healing).

Immagini Golden con EC2 Image Builder

Le immagini immutabili riducono il drift e accorciano le finestre di patching. EC2 Image Builder codifica la creazione e la distribuzione delle AMI utilizzando pipeline, ricette (recipe) e impostazioni di distribuzione.

Le ricette delle immagini (image recipe) specificano l’immagine di base (ad esempio, l’ultima versione di Amazon Linux 2023), i componenti (passaggi di build/test definiti in YAML, come l’installazione dell’agente SSM, i runtime dei linguaggi e l’hardening della sicurezza) e il versioning semantico. I componenti possono essere riutilizzati in più ricette per imporre controlli di base.
Le pipeline definiscono il flusso di lavoro end-to-end: configurazione dell’infrastruttura (VPC/subnet/profilo dell’istanza/gruppi di sicurezza), passaggi di build, passaggi di test e pianificazione (ad esempio, settimanale). Image Builder applica automaticamente le patch del sistema operativo al momento della build, esegue i test e fa fallire le build che non li superano.
Le impostazioni di distribuzione replicano e condividono le immagini: pubblicare le AMI in Regioni selezionate, aggiungere permessi di avvio (launch permission) per account o OU di AWS Organizations, imporre la crittografia EBS (con una chiave KMS) e taggare gli output. Image Builder può pubblicare l’ARN dell’AMI più recente in Systems Manager Parameter Store (ad esempio, /prod/images/web/latest) in modo che i gruppi di Auto Scaling, CodePipeline e CloudFormation utilizzino l’immagine approvata (“blessed”) corrente senza aggiornamenti manuali.

Questo approccio a pipeline si abbina a Patch Manager: eseguire il patching dell’AMI frequentemente per ridurre al minimo i delta delle patch sulle istanze, e poi utilizzare le finestre di manutenzione per patch delta più piccole su server a lunga esecuzione (long-lived).

Governance, licenze e ottimizzazione dei costi

AWS License Manager gestisce le licenze proprie (BYOL) e i diritti del Marketplace. È possibile definire configurazioni di licenza che modellano le regole del fornitore (core, socket, vCPU, affinità con l’host e vincoli di virtualizzazione), scegliere un’applicazione rigida (hard) o flessibile (soft) e associare le configurazioni ad AMI, launch template o istanze. License Manager rileva il software tramite Systems Manager Inventory per tracciare il consumo e prevenire avvii non conformi. Per i prodotti del Marketplace che utilizzano i diritti di License Manager, è possibile condividere le concessioni tra account e tracciare l’utilizzo dei diritti centralmente con un amministratore delegato.

AWS Trusted Advisor valuta continuamente il vostro ambiente rispetto alle best practice. Le categorie includono ottimizzazione dei costi, sicurezza, tolleranza ai guasti, limiti di servizio, prestazioni ed eccellenza operativa. Con il supporto Business o Enterprise, è possibile accedere al set completo di controlli e all’API di AWS Support per aggiornare e recuperare i risultati programmaticamente. Si può utilizzare l’integrazione con EventBridge per instradare le modifiche dello stato dei controlli verso flussi di lavoro di remediation (ad esempio, attivare un runbook di Automation per abilitare la crittografia predefinita di S3 o rimuovere l’accesso pubblico su un bucket) e abilitare la Organizational View per aggregare i dati tra gli account con accesso IAM mirato e notifiche ai team corretti.

L’ottimizzazione dei costi è un processo continuo e basato sui dati:

Right-sizing: Combinare le raccomandazioni di right-sizing di Cost Explorer con gli insight di AWS Compute Optimizer. Compute Optimizer analizza le metriche di istanze, gruppi di Auto Scaling, volumi EBS, funzioni Lambda ed ECS su Fargate per raccomandare configurazioni ottimali con risparmi previsti e rischio per le prestazioni. Può anche segnalare volumi gp2 che dovrebbero migrare a gp3 con throughput/IOPS ottimizzati. Abbinare le raccomandazioni a finestre di manutenzione e runbook di Automation per eseguire modifiche in sicurezza.
Savings Plans: Utilizzare i Compute Savings Plans per una copertura ampia su EC2, Fargate e Lambda, o gli EC2 Instance Savings Plans per gli sconti maggiori su famiglie/Regioni specifiche. Impegnarsi a una spesa di $/ora per uno o tre anni con opzioni di pagamento (Nessun/Parziale/Totale anticipato), aggregare tra account tramite la fatturazione consolidata e dimensionare gli impegni utilizzando la spesa storica On-Demand. Monitorare l’utilizzo e la copertura e adeguarsi all’evoluzione dei carichi di lavoro. Continuare a utilizzare le Reserved Instances per i servizi non coperti dai Savings Plans (ad esempio, RDS, OpenSearch, Redshift, DynamoDB).
Fattori abilitanti operativi: Utilizzare Systems Manager Automation e Change Manager per pianificare l’arresto/avvio degli ambienti non di produzione, applicare pianificazioni per le istanze ed eseguire transizioni di right-sizing e da gp2 a gp3 con approvazioni e guardrail. Rafforzare con i controlli dei costi di Trusted Advisor e con budget/allarmi.

Scenario pratico

Azienda: Airbnb

Sfida: Airbnb gestisce carichi di lavoro EC2 multi-account e multi-Regione per l’elaborazione dati e servizi web. La sicurezza richiede un accesso auditabile e senza SSH; la conformità impone l’applicazione tempestiva di patch di sicurezza sia dai repository predefiniti che da quelli personalizzati; il team della piattaforma deve standardizzare le AMI e ridurre i costi senza rischi per le prestazioni. I fornitori di software impongono licenze basate sui core per alcuni nodi di analisi. Il team operativo desidera una remediation guidata dagli eventi e una visibilità a livello direzionale su tutti gli account.

Approccio passo-passo:

Imporre l’accesso sicuro con Systems Manager Session Manager

Configurare endpoint VPC per SSM/EC2Messages e abilitare il logging di Session Manager su CloudWatch Logs e S3 con crittografia KMS. Disabilitare SSH e richiedere l’uso di Session Manager per l’accesso alla shell. Abilitare il port forwarding per consentire agli ingegneri di raggiungere i servizi interni in modo sicuro durante il troubleshooting.
Perché: Rimuove la superficie di attacco in entrata, centralizza le tracce di audit e permette un port forwarding controllato senza VPN o bastion host.

Standardizzare la configurazione e la visibilità con Inventory e Compliance

Creare un’associazione di State Manager per abilitare Inventory su tutte le istanze. Configurare Resource Data Sync verso S3 e interrogare i dati con Athena. Abilitare Compliance per lo stato delle patch e delle associazioni e visualizzare lo stato di salute della flotta in Systems Manager Explorer.
Perché: Inventory consente di avere una visione accurata dello stato del software e delle patch e alimenta i processi a valle di rilevamento delle licenze e di audit.

Definire baseline di patch e gruppi di patch con repository personalizzati

Creare baseline personalizzate in Patch Manager per ogni sistema operativo, che approvino automaticamente gli aggiornamenti di sicurezza dopo sette giorni e aggiungano repository yum/apt personalizzati per gli agenti interni. Taggare le istanze con Patch Group=linux-web, linux-data e windows-app. Associare le baseline a ciascun gruppo di patch.
Perché: Assicura che sia i pacchetti predefiniti che quelli personalizzati vengano aggiornati in modo coerente, con approvazioni scaglionate tra i vari carichi di lavoro.

Pianificare il patching tramite Maintenance Windows con passaggi di pre/post-esecuzione di Automation

Per ogni gruppo di patch, registrare una finestra di manutenzione che coincida con le ore non lavorative. Registrare un task di Automation ad alta priorità che rimuove le istanze dai target group, esegue AWS-RunPatchBaseline (Install) con concorrenza e soglie di errore controllate, riavvia se necessario, esegue test di base (smoke test) e registra nuovamente le istanze con il load balancer.
Perché: Minimizza l’impatto sui clienti, impone un’orchestrazione sicura e produce una cronologia di esecuzione auditabile.

Creare golden image con EC2 Image Builder e pubblicarle su Parameter Store

Creare delle “recipe” che includano l’Agente SSM, componenti di hardening della sicurezza e prerequisiti applicativi. Le pipeline eseguono build settimanali, effettuano test e pubblicano le AMI in us-east-1 e eu-west-1, condividendole con account selezionati tramite Organizations. Salvare gli ARN delle AMI più recenti in /prod/images/web/latest e /prod/images/data/latest in Parameter Store.
Perché: Riduce la deviazione di configurazione (drift) e il tempo necessario per applicare le patch sulle istanze; gli sviluppatori e le pipeline di deployment recuperano le immagini approvate tramite i parametri, senza la distribuzione manuale degli ID.

Gestire le licenze dei fornitori con AWS License Manager

Definire configurazioni di licenza per il software di analisi utilizzando il conteggio delle vCPU con applicazione rigida (hard enforcement). Associarle alle AMI e ai launch template corrispondenti. Abilitare un amministratore delegato per tracciare il consumo tra gli account utilizzando i dati di rilevamento di Inventory.
Perché: Previene avvii non conformi e fornisce una prova dell’utilizzo delle licenze ai fornitori e al reparto finanziario.

Implementare remediation e guardrail guidati dagli eventi

Utilizzare le regole gestite di AWS Config (ad esempio, tag obbligatori, crittografia S3) con azioni di remediation automatica che invocano runbook di Systems Manager Automation. Aggiungere regole di EventBridge per gli eventi di manutenzione di AWS Health per attivare riavvii sicuri tramite runbook.
Perché: Chiude il ciclo dal rilevamento alla correzione senza lavoro manuale ripetitivo, mantenendo le risorse conformi alle policy.

Ottimizzare i costi con Compute Optimizer e Savings Plans, governati dal controllo delle modifiche

Abilitare Compute Optimizer su tutti gli account; settimanalmente, esportare le raccomandazioni di right-sizing e di migrazione da gp2 a gp3. Utilizzare le approvazioni di Change Manager e le finestre di manutenzione per applicare le modifiche alla famiglia di istanze e ai volumi EBS. Acquistare un Compute Savings Plan combinato nell’account pagatore per coprire il carico di calcolo stazionario tra le Regioni; monitorare l’utilizzo e adeguare trimestralmente. Utilizzare Session Manager Automation per imporre pianificazioni di avvio/arresto negli ambienti di sviluppo/test.
Perché: L’ottimizzazione basata sui dati con un rollout controllato permette di ottenere risparmi proteggendo al contempo le prestazioni e la disponibilità.

Monitorare a livello di organizzazione con Trusted Advisor

Abilitare la Organizational View di Trusted Advisor e l’integrazione con EventBridge per notificare i team della piattaforma e della sicurezza riguardo a rilievi ad alto rischio (ad esempio, limiti di servizio, risorse inattive, security group aperti). Per controlli selezionati, attivare runbook di Systems Manager Automation per la remediation o l’apertura di ticket.
Perché: La supervisione centralizzata e la risposta automatizzata mantengono l’igiene operativa e prevengono costi o rischi fuori controllo.

Questo design integrato offre accesso sicuro, patching standardizzato, AMI immutabili, conformità delle licenze, remediation automatizzata e un’ottimizzazione dei costi misurabile, il tutto con controlli auditabili sull’intero footprint AWS di Airbnb.

← Networking e Distribuzione di Contenuti · Tutti i domini

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