AWS Systems Manager come piano di controllo della flotta

AWS Systems Manager (SSM) è il servizio che, nel mondo DOP-C02, risponde alla domanda “come governo configurazione e stato di centinaia di istanze senza SSH e senza bastion host”. Il prerequisito trasversale è il SSM Agent attivo sull’istanza più un instance profile con i permessi corretti; senza questi due elementi nessuna capability funziona, ed è un dettaglio che l’esame ama nascondere negli scenari di troubleshooting.

Le capability da distinguere per compito:

  • Run Command: esecuzione imperativa e una tantum di comandi o script su un target set (per tag, per resource group, per instance ID). Serve quando devi fare un intervento puntuale — riavviare un servizio, raccogliere un log, applicare una hotfix — su molte istanze in parallelo con rate control e error threshold.
  • State Manager: esecuzione dichiarativa e ricorrente. Definisci uno stato desiderato tramite un’association e SSM lo riapplica su schedule, correggendo il drift. È l’analogo AWS-native di un configuration manager tipo Ansible/Puppet quando non vuoi un server dedicato.
  • Automation runbook: orchestrazione multi-step di operazioni sull’infrastruttura (creare una AMI, fare patch + reboot ordinato, ruotare istanze, rispondere a un evento). I runbook AWS-owned (prefisso AWS-*) coprono i casi comuni; puoi comporne di custom con branching, approvazioni manuali e integrazione con EventBridge per remediation automatica.
  • Patch Manager: definisce patch baseline (regole di auto-approvazione per classificazione/severità e liste di approvazione/rifiuto esplicite) e maintenance window per applicare le patch in finestre controllate, con report di compliance. È la risposta corretta ogni volta che lo scenario chiede patching su scala con audit, non Run Command manuale.
  • Session Manager: shell interattiva verso l’istanza senza porta 22 aperta, senza bastion e senza key pair, con log centralizzati su S3/CloudWatch Logs. È la scelta “sicura e auditabile” per accesso amministrativo.
  • Parameter Store: storage gerarchico di configurazione (String, StringList, SecureString cifrato con KMS) con versioning e integrazione IAM. Standard tier gratuito; per rotazione automatica dei segreti serve Secrets Manager.

Fleet management è il termine ombrello: combinare Inventory, tag e resource group per targetizzare azioni su gruppi logici invece che su singoli host.

Golden AMI, immutabile vs mutabile

La golden AMI è un’immagine base “cotta” con OS hardenizzato, agent e dipendenze già installate. La si costruisce tipicamente con EC2 Image Builder (pipeline versionata, test automatici, distribuzione multi-region e multi-account) o con un Automation runbook che avvia un’istanza, applica configurazione e ne cattura la AMI.

Il trade-off centrale:

  • Immutabile: ogni cambiamento produce una nuova AMI; le istanze non si modificano mai in place, si sostituiscono ruotando la Launch Template dell’Auto Scaling Group. Vantaggi: rollback banale (torni alla versione precedente), zero drift, coerenza fra ambienti, deploy blue/green e canary puliti. È l’approccio preferito in scenari di deployment ripetibile e disaster recovery.
  • Mutabile: le istanze longeve vengono aggiornate sul posto con State Manager/Patch Manager. Vantaggi: aggiornamenti rapidi e leggeri senza rebake; svantaggi: drift progressivo, rollback difficile, “snowflake server”.

In pratica un’architettura matura usa golden AMI immutabili per il base layer e SSM (State/Patch Manager) per lo hardening continuo e le patch di sicurezza fra un rebake e l’altro.

Trappole tipiche d’esame

  • Accesso shell senza aprire la porta 22 → Session Manager: niente bastion, niente key pair, niente inbound SG; l’accesso è auditabile via CloudTrail e i log vanno su S3/CloudWatch. Scartare risposte con bastion o SSH.
  • Patching su scala con report di compliance → Patch Manager + maintenance window: Run Command “manuale” con yum update è la trappola; non dà baseline né compliance.
  • Correggere il drift di configurazione in modo ricorrente → State Manager association: Run Command è una tantum e non riapplica lo stato; scegliere State Manager quando serve idempotenza schedulata.
  • Segreti con rotazione automatica → Secrets Manager, non Parameter Store: SecureString cifra ma non ruota; se lo scenario cita rotazione o credenziali RDS, la risposta è Secrets Manager.
  • Rollback immediato dopo un deploy fallito → infrastruttura immutabile + AMI versionata: aggiornare in place rende il rollback complesso; ruotare la Launch Template alla AMI precedente è pulito.
  • Agent presente ma il nodo non appare in SSM → instance profile/IAM role mancante o endpoint di rete: la causa quasi sempre è il permesso AmazonSSMManagedInstanceCore assente o la mancanza di route/endpoint verso SSM, non l’agent.