AWS Backup: centralizzare backup plan e retention

AWS Backup è il servizio di riferimento quando devi proteggere in modo centralizzato risorse eterogenee: EBS, EC2, RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway. Il modello ruota attorno a tre concetti: il backup plan (uno o più schedule con frequenza e finestra di esecuzione), la retention (per quanto tempo i recovery point restano nel backup vault) e la resource assignment. In un contesto operativo l’assegnazione delle risorse per tag è quasi sempre la risposta corretta: definisci un tag come backup=daily, lo applichi alle risorse e AWS Backup include automaticamente ogni nuova risorsa che lo espone, senza toccare il plan. È il pattern che scala e che riduce il rischio di dimenticare workload nuovi.

Per il lato compliance ricorda AWS Backup Vault Lock: applica una protezione WORM ai recovery point, impedendo cancellazioni anche agli utenti con permessi amministrativi entro il periodo di retention. È il controllo giusto quando lo scenario cita ransomware, requisiti normativi o “impedire la cancellazione dei backup”.

Snapshot EBS/RDS e Amazon Data Lifecycle Manager

Per i soli volumi EBS, Amazon Data Lifecycle Manager (DLM) automatizza creazione, retention e cancellazione degli snapshot (e delle AMI EBS-backed) sulla base di tag e schedule, senza costi aggiuntivi oltre agli snapshot stessi. Gli snapshot EBS sono incrementali: solo i blocchi modificati vengono salvati, ma ogni snapshot è comunque un ripristino completo. Il criterio di scelta d’esame: se il requisito riguarda esclusivamente EBS, DLM basta; se serve coprire più tipi di risorsa con policy e reportistica unificate, si sceglie AWS Backup.

Su RDS distingui i backup automatici (abilitano il point-in-time recovery, retention fino a 35 giorni, eliminati alla cancellazione dell’istanza) dagli snapshot manuali (restano finché non li cancelli tu, ideali per conservazione a lungo termine o prima di un upgrade). Il restore di RDS crea sempre una nuova istanza: non sovrascrive quella esistente.

Amazon S3: versioning e lifecycle per la protezione degli oggetti

Su S3 la prima linea di difesa contro cancellazioni e sovrascritture accidentali è il versioning. Con il versioning attivo, una DELETE non rimuove l’oggetto ma inserisce un delete marker: recuperi il dato eliminando il marker o richiamando la versione precedente. Per protezione più forte esistono MFA Delete e S3 Object Lock (modalità governance o compliance) per requisiti WORM sugli oggetti.

Le lifecycle policy governano il costo e il ciclo di vita: transizione automatica verso classi più economiche (Standard-IA, Glacier Flexible Retrieval, Glacier Deep Archive), scadenza degli oggetti e — punto spesso trascurato — expiration delle noncurrent version e cleanup dei multipart upload incompleti. Su un bucket con versioning, senza una regola sulle versioni non correnti i costi crescono indefinitamente.

Copia cross-region e resilienza

La multi-region è la leva per DR e resilienza. AWS Backup supporta la cross-region copy (e cross-account) dei recovery point: la copia in una seconda region ti protegge dalla perdita dell’intera region primaria. Analogamente puoi copiare snapshot EBS e RDS in un’altra region. Per S3 la Cross-Region Replication (CRR) replica gli oggetti in un bucket di destinazione e richiede il versioning attivo su entrambi i bucket; replica solo gli oggetti scritti dopo l’attivazione, salvo usare S3 Batch Replication per il backlog esistente.

Trappole tipiche d’esame

  • Coprire automaticamente ogni nuova risorsa → tag-based resource assignment: assegna le risorse al backup plan per tag, non per ID, così i workload nuovi rientrano senza modifiche.
  • Impedire la cancellazione dei backup (ransomware/compliance) → AWS Backup Vault Lock: applica WORM ai recovery point; non basta una IAM policy, che un admin può alterare.
  • Sopravvivere alla perdita di un’intera region → cross-region copy: i backup nella sola region primaria non proteggono da un guasto regionale; serve la copia cross-region.
  • Attivare la CRR su S3 → versioning obbligatorio su origine e destinazione: senza versioning la replica non parte, e gli oggetti preesistenti non vengono replicati senza Batch Replication.
  • Costi S3 che crescono nel tempo con versioning → lifecycle sulle noncurrent version: aggiungi expiration delle versioni non correnti e cleanup dei multipart incompleti.
  • Solo volumi EBS da gestire → Data Lifecycle Manager, non AWS Backup: per snapshot EBS schedulati DLM è la scelta mirata e senza costi extra; AWS Backup serve quando le risorse sono eterogenee.