> aws rds --training advanced

Amazon RDS
Relational Database Service — Percorso formativo avanzato

Per Database Administrator · Cloud Architect · DevOps Engineer

AGENDA

Agenda del percorso formativo

Modulo 1 · Slide 1-6 — Introduzione e fondamenti del Modulo 2 · Slide 7-14 — Architettura di base e provisioning
servizio gestito delle istanze

Modulo 3 · Slide 15-22 — Networking, connettività e Modulo 4 · Slide 23-30 — Alta disponibilità, Multi-AZ e
sicurezza end-to-end disaster recovery

Modulo 5 · Slide 31-36 — Backup, restore, PITR e Modulo 6 · Slide 37-43 — Amazon Aurora e architetture
manutenzione pianificata cloud-native

Modulo 7 · Slide 44-47 — Ottimizzazione dei costi, FinOps e Modulo 8 · Slide 48-50 — Monitoraggio, tuning e best
pricing practices finali

Amazon RDS 02 / 50
MODULO 1

Database nel cloud: gestiti vs self-hosted su EC2

Self-hosted su EC2 RDS gestito

Controllo totale su OS, kernel e binari del DB; accesso AWS gestisce OS, patching, backup e failover; nessun
root e file system. accesso al sistema operativo.

Costo operativo Quando restare su EC2

Su EC2 il TCO nasconde ore/uomo di DBA; RDS sposta Estensioni non supportate, versioni legacy, licenze
il costo su tariffa oraria. BYOL particolari, tuning a livello OS.

Amazon RDS 03 / 50
MODULO 1

Cos'è Amazon RDS: definizione e responsabilità

▪ Servizio gestito: provisioning, gestione e scalabilità di database relazionali senza amministrare

server o storage.
▪ Obiettivo: ridurre il lavoro operativo indifferenziato e rendere ripetibili patching, backup e alta
disponibilità.
▪ AWS è responsabile di: hardware, rete fisica, virtualizzazione, installazione e patch del motore,
backup automatici.
▪ Il cliente è responsabile di: schema, indici, query, utenti applicativi, security group, cifratura e
configurazione dei parametri.
▪ Confine chiave: nessun accesso SSH all'host: ogni intervento passa da API, parameter group e
option group.

Amazon RDS 04 / 50
MODULO 1

Vantaggi chiave di Amazon RDS

Automated patching Backup automatici

Minor version upgrade applicati nella maintenance Snapshot giornalieri e log delle transazioni per il
window definita dall'utente. recovery a un istante preciso.

Scalabilità Alta disponibilità

Modifica di classe di istanza e storage online, con Deployment Multi-AZ con failover automatico gestito
storage autoscaling opzionale. tramite DNS.

Sicurezza integrata Osservabilità

VPC, security group, KMS at rest, TLS in transito, IAM CloudWatch, Enhanced Monitoring, Performance
authentication. Insights e Event Notifications.

Amazon RDS 05 / 50
MODULO 1

I DB Engine supportati da RDS

MySQL PostgreSQL MariaDB

Community edition, ampia Ricchezza di estensioni (PostGIS, Fork di MySQL, storage engine
compatibilità applicativa, read pg_stat_statements), forte aggiuntivi e licenza pienamente
replica native. adozione enterprise. open source.

Oracle SQL Server Aurora

License Included o BYOL; option Edizioni Express, Web, Standard, Motore cloud-native compatibile
group per Data Guard, TDE e altre Enterprise; Multi-AZ basato su MySQL e PostgreSQL, storage
feature. Always On. distribuito su 6 AZ.

Amazon RDS 06 / 50
MODULO 2

Anatomia di un DB Instance

Compute Storage
Classe di istanza che definisce vCPU, memoria, banda Volume EBS gestito da AWS, allocato in GiB e con
di rete e banda EBS dedicata. profilo di IOPS e throughput.

Parameter group Option group

Insieme dei parametri del motore; static parameter Funzionalità aggiuntive engine-specific (es. TDE
richiedono un reboot per applicarsi. Oracle, SQLSERVER_AUDIT).

Endpoint Metadati
Nome DNS stabile che astrae l'host fisico sottostante e Subnet group, security group, KMS key, finestre di
sopravvive al failover. backup e manutenzione.

Amazon RDS 07 / 50
MODULO 2

Creazione di un'istanza: console, CLI e IaC

▪ Console: adatta all'esplorazione e alla prima creazione; poco ripetibile e difficile da versionare.
▪ AWS CLI: create-db-instance con parametri espliciti: utile per script e automazioni puntuali.
▪ CloudFormation: risorsa AWS::RDS::DBInstance, drift detection e rollback nativo dello stack.
▪ Terraform: risorsa aws_db_instance, stato remoto e piano di modifica esplicito prima dell'apply.
▪ Raccomandazione: in produzione ogni database deve nascere da codice versionato, mai dalla
console.
▪ Attenzione: password e credenziali non vanno mai inserite in chiaro nel codice IaC.

Amazon RDS 08 / 50
MODULO 2

Scelta del motore e della versione

▪ Compatibilità applicativa: driver, dialetto SQL e ORM supportati determinano spesso la scelta
obbligata.
▪ Estensioni richieste: verificare che le estensioni o le feature enterprise necessarie siano supportate da
RDS.
▪ Ciclo di vita della versione: AWS pubblica date di fine supporto: pianificare l'upgrade prima della
deprecazione.
▪ Evitare le versioni estreme: l'ultima minor release è consigliata, la major appena rilasciata va prima
testata.
▪ Licenze: per Oracle e SQL Server valutare License Included rispetto a BYOL in termini di costo.
▪ Standardizzazione: limitare il numero di motori e versioni in flotta riduce il carico operativo.

Amazon RDS 09 / 50
MODULO 2

Dimensionamento di CPU e memoria

Classi Standard (m) Memory Optimized (r, x)

Rapporto bilanciato CPU/memoria, scelta di default Elevata memoria per vCPU: buffer pool ampio, ideale
per carichi OLTP generici. per working set grandi.

Burstable (t) Regola pratica

Basso costo con crediti CPU: solo per sviluppo, test e La memoria dovrebbe contenere il working set attivo
carichi molto discontinui. per minimizzare l'I/O su disco.

Banda EBS Verifica sul campo

Le classi maggiori offrono più throughput verso lo Dimensionare con le metriche reali di CPU,
storage: spesso è il vero collo di bottiglia. FreeableMemory e ReadIOPS, non a stima.

Amazon RDS 10 / 50
MODULO 2

Istanze AWS Graviton per RDS

▪ Processori ARM: sviluppati da AWS, disponibili nelle famiglie m6g/m7g, r6g/r7g e nelle classi Aurora.
▪ Rapporto prezzo/performance: miglioramento significativo rispetto alle equivalenti classi x86 a
parità di carico.
▪ Trasparenza applicativa: il client parla il protocollo del motore: nessuna ricompilazione lato
applicazione.
▪ Verifica delle estensioni: controllare la disponibilità di estensioni o plugin engine-specific su
architettura ARM.
▪ Migrazione: modifica della classe di istanza o failover Multi-AZ, con downtime ridotto a pochi minuti.
▪ Consiglio: candidato di default per nuovi workload MySQL, PostgreSQL e Aurora.

Amazon RDS 11 / 50
MODULO 2

Configurazione dello storage EBS

Fondamenta EBS gp2

Lo storage RDS è un volume EBS gestito: IOPS e IOPS proporzionali alla dimensione (3 IOPS/GiB) con
throughput sono risorse dimensionabili. meccanismo a crediti burst.

gp3 io1 / io2

IOPS e throughput configurabili indipendentemente Provisioned IOPS per carichi con requisiti di latenza
dalla capacità; scelta di default moderna. costante e I/O intensivo.

Magnetic Nota di capacità

Tipo legacy, sconsigliato per qualsiasi nuovo Sovradimensionare la capacità solo per ottenere IOPS
deployment. è tipico di gp2 e costoso: usare gp3.

Amazon RDS 12 / 50
MODULO 2

Storage Autoscaling

▪ Funzionamento: RDS espande automaticamente il volume quando lo spazio libero scende sotto la
soglia.
▪ Soglia di trigger: spazio libero inferiore al 10% della capacità allocata per almeno alcuni minuti.
▪ Maximum storage threshold: limite massimo configurabile che protegge da crescite incontrollate e
costi imprevisti.
▪ Nessun downtime: l'espansione avviene online, senza interruzione delle connessioni applicative.
▪ Vincolo temporale: tra due espansioni consecutive esiste un periodo di attesa di alcune ore.
▪ Best practice: abilitarlo sempre in produzione, affiancandolo a un allarme su FreeStorageSpace.

Amazon RDS 13 / 50
MODULO 2

Endpoint di connessione

Formato Writer endpoint

[Link]- Punta sempre all'istanza primaria; segue
[Link], con porta automaticamente il failover Multi-AZ.
specifica del motore.

Reader endpoint Instance endpoint

Su Aurora e Multi-AZ cluster distribuisce le Indirizza un singolo nodo: utile per diagnostica,
connessioni sulle repliche di lettura. rischioso se cablato nell'app.

Regola d'oro Cache DNS

L'applicazione deve usare l'endpoint DNS, mai Configurare TTL brevi lato client per non restare
l'indirizzo IP risolto. agganciati al nodo precedente.

Amazon RDS 14 / 50
MODULO 3

Integrazione tra RDS e Amazon VPC

▪ Isolamento di rete: ogni istanza RDS risiede in una VPC e riceve indirizzi IP privati dalle subnet scelte.
▪ Elastic Network Interface: l'endpoint è servito da ENI gestite da AWS all'interno delle subnet del
cliente.
▪ Routing: route table e NACL della VPC governano il traffico verso e dal database.
▪ Connettività ibrida: accesso da on-premise tramite VPN Site-to-Site o AWS Direct Connect.
▪ Cross-VPC: VPC peering, Transit Gateway o PrivateLink per esporre il database ad altri account.
▪ Principio guida: il database non deve mai essere raggiungibile da Internet.

Amazon RDS 15 / 50
MODULO 3

DB Subnet Groups

▪ Definizione: insieme di subnet nelle quali RDS può collocare le istanze del database.
▪ Requisito minimo: almeno due subnet in due Availability Zone distinte, anche per istanze Single-AZ.
▪ Perché è obbligatorio: senza subnet in più AZ non è possibile attivare Multi-AZ o eseguire il failover.
▪ Dimensionamento: prevedere IP liberi sufficienti per repliche, failover e operazioni di modifica.
▪ Coerenza: usare subnet dedicate al layer dati, separate da quelle applicative e pubbliche.
▪ Nota operativa: il subnet group va progettato prima della creazione: modificarlo dopo è oneroso.

Amazon RDS 16 / 50
MODULO 3

Private subnet vs public subnet

Private subnet Public subnet

Nessuna route verso Internet Gateway: scelta corretta Espone l'endpoint a Internet: ammissibile solo in
per il 99% dei casi. laboratori temporanei.

Publicly accessible Accesso amministrativo

Flag da mantenere disabilitato; se attivo, RDS assegna Bastion host, AWS Systems Manager Session Manager
un indirizzo IP pubblico. o VPN, mai esposizione diretta.

Difesa in profondità Verifica continua

Subnet privata, security group restrittivo, TLS AWS Config e Security Hub segnalano le istanze RDS
obbligatorio e autenticazione forte. pubblicamente accessibili.

Amazon RDS 17 / 50
MODULO 3

Security Group per RDS

▪ Firewall stateful: controlla il traffico in ingresso verso la porta del motore a livello di ENI.
▪ Porte tipiche: 3306 per MySQL e MariaDB, 5432 per PostgreSQL, 1521 per Oracle, 1433 per SQL
Server.
▪ Sorgente per riferimento: consentire l'accesso indicando il security group dell'applicazione, non un
CIDR.
▪ Anti-pattern: regole di ingresso da [Link]/0 sulla porta del database: mai in nessun ambiente.
▪ Segmentazione: security group distinti per applicazione, batch, strumenti di analisi e amministrazione.
▪ Audit: revisione periodica delle regole e alert automatico sulle modifiche inattese.

Amazon RDS 18 / 50
MODULO 3

Encryption at Rest con AWS KMS

▪ Cosa viene cifrato: volumi di storage, backup automatici, snapshot, read replica e log.
▪ Chiavi: AWS managed key oppure customer managed key (CMK) con policy e rotazione controllate.
▪ Momento della decisione: la cifratura si abilita alla creazione: un'istanza non cifrata va migrata via
snapshot.
▪ Procedura di migrazione: snapshot, copia dello snapshot con cifratura abilitata, restore della nuova
istanza.
▪ Cross-region: la copia in un'altra regione richiede una chiave KMS della regione di destinazione.
▪ Compliance: la cifratura at rest è requisito comune per PCI-DSS, GDPR e standard interni.

Amazon RDS 19 / 50
MODULO 3

Encryption in Transit con SSL/TLS

▪ Obiettivo: proteggere le credenziali e i dati tra client e database da intercettazione e manomissione.

▪ Certificate authority: AWS pubblica bundle di CA regionali e globali da distribuire ai client.
▪ Verifica del certificato: usare la modalità verify-full per validare anche il nome host dell'endpoint.
▪ Imposizione lato server: parametro rds.force_ssl per PostgreSQL, require_secure_transport per
MySQL.
▪ Rotazione delle CA: le CA hanno scadenza: pianificare l'aggiornamento del trust store prima
dell'expiry.
▪ Impatto: l'overhead di TLS è marginale rispetto al rischio di traffico in chiaro.

Amazon RDS 20 / 50
MODULO 3

Autenticazione IAM per RDS

▪ Principio: il client ottiene un token temporaneo da IAM al posto di una password statica.
▪ Durata del token: validità di 15 minuti; la connessione già stabilita non viene interrotta alla scadenza.
▪ Motori supportati: MySQL, MariaDB, PostgreSQL e i corrispondenti motori Aurora.
▪ Vantaggi: nessuna password nel codice, revoca centralizzata e audit trail su CloudTrail.
▪ Configurazione: abilitare IAM database authentication e mappare l'utente DB al ruolo IAM.
▪ Limiti: vincoli sul numero di nuove connessioni al secondo: adatto ad app con connection pooling.

Amazon RDS 21 / 50
MODULO 3

AWS Secrets Manager e RDS

▪ Archiviazione sicura: le credenziali sono cifrate con KMS e recuperate a runtime tramite API.
▪ Rotazione automatica: funzione Lambda gestita che cambia la password nel database e aggiorna il
segreto.
▪ Strategia alternating users: due utenti alternati per evitare finestre di indisponibilità durante la
rotazione.
▪ Integrazione nativa: RDS può gestire la master password direttamente in Secrets Manager.
▪ Controllo degli accessi: resource policy sul segreto per limitare quali ruoli possono leggerlo.
▪ Alternativa: Parameter Store per casi semplici, ma senza rotazione automatica integrata.

Amazon RDS 22 / 50
MODULO 4

Alta disponibilità applicata ai database

▪ Definizione: capacità del sistema di restare disponibile nonostante il guasto di un componente.

▪ Domini di guasto: l'Availability Zone è l'unità di isolamento su cui costruire la ridondanza.
▪ HA non è DR: l'alta disponibilità copre guasti locali, il disaster recovery eventi regionali.
▪ HA non è backup: la replica propaga anche gli errori logici: serve comunque il backup.
▪ Metriche: l'obiettivo si esprime in RTO e RPO concordati con il business, non in percentuali generiche.
▪ Il collo di bottiglia: spesso è l'applicazione: senza retry e timeout corretti il failover resta visibile.

Amazon RDS 23 / 50
MODULO 4

RDS Multi-AZ Deployment (Active-Standby)

▪ Architettura: istanza primaria in una AZ e standby in una seconda AZ della stessa regione.
▪ Replica sincrona: ogni commit viene confermato solo dopo la scrittura anche sullo standby.
▪ Standby non leggibile: nel modello classico lo standby non serve traffico applicativo.
▪ Trigger di failover: guasto dell'istanza o dell'AZ, perdita di rete, patching o modifica della classe.
▪ Tempo di failover: tipicamente entro uno o due minuti, senza intervento manuale.
▪ Costo: raddoppio della componente compute e storage: è il prezzo della continuità.

Amazon RDS 24 / 50
MODULO 4

Standby replica e DNS failover

▪ Promozione automatica: in caso di guasto lo standby diventa primario e assume il ruolo di writer.
▪ Riscrittura del DNS: AWS aggiorna il record dell'endpoint verso il nuovo nodo primario.
▪ Endpoint invariato: l'applicazione continua a usare lo stesso nome host, senza modifiche di
configurazione.
▪ Cache DNS lato client: JVM e librerie con TTL infinito continuano a puntare al vecchio IP: va corretto.
▪ Ricostruzione dello standby: al termine del failover AWS ricrea uno standby nell'altra AZ.
▪ Test: il failover può essere forzato con reboot with failover per validare il comportamento dell'app.

Amazon RDS 25 / 50
MODULO 4

Multi-AZ DB Cluster con due repliche

▪ Topologia: un writer e due reader distribuiti su tre Availability Zone distinte.

▪ Failover più rapido: tempi tipicamente inferiori ai 35 secondi grazie alla promozione di una replica
esistente.
▪ Repliche leggibili: a differenza dello standby classico, i due reader servono traffico di sola lettura.
▪ Commit semi-sincrono: il writer conferma quando almeno una replica ha acquisito il log delle
transazioni.
▪ Motori supportati: disponibile per MySQL e PostgreSQL con versioni recenti.
▪ Caso d'uso: workload enterprise con requisiti stringenti di RTO e necessità di scalare le letture.

Amazon RDS 26 / 50
MODULO 4

Read Replicas asincrone

▪ Scopo: scaricare dal primario le query di sola lettura, report e analitiche.

▪ Replica asincrona: esiste un ritardo di replica misurabile con la metrica ReplicaLag.
▪ Consistenza eventuale: l'applicazione deve tollerare la lettura di dati leggermente non aggiornati.
▪ Numero e collocazione: più repliche per istanza, nella stessa AZ, in altre AZ o in altre regioni.
▪ Configurazione indipendente: classe di istanza, storage e indici possono differire dal primario.
▪ Attenzione: una replica sovraccarica o sotto-dimensionata accumula lag e diventa inaffidabile.

Amazon RDS 27 / 50
MODULO 4

Promozione di una Read Replica

▪ Effetto: la replica diventa un'istanza standalone indipendente, con propri backup e repliche.
▪ Irreversibilità: dopo la promozione non è possibile ricollegarla al primario originale.
▪ Casi d'uso: creazione di ambienti di test, sharding funzionale, upgrade con downtime ridotto.
▪ Disaster recovery: promozione di una replica cross-region per attivare la regione secondaria.
▪ Cautele: verificare che il lag di replica sia azzerato prima di promuovere.
▪ Procedura: interrompere le scritture, attendere il catch-up, promuovere e ripuntare l'applicazione.

Amazon RDS 28 / 50
MODULO 4

Cross-Region Read Replicas

▪ Replica geografica: copia asincrona dei dati in una regione AWS diversa da quella primaria.
▪ Disaster recovery: consente il ripristino del servizio anche in caso di evento su scala regionale.
▪ Latenza di lettura: avvicina i dati agli utenti di aree geografiche distanti.
▪ Migrazione: strumento efficace per spostare un carico da una regione all'altra con downtime minimo.
▪ Prerequisiti: cifratura con chiave KMS della regione di destinazione e backup automatici attivi.
▪ Costi: va considerato il traffico di replica inter-regione oltre al costo dell'istanza replica.

Amazon RDS 29 / 50
MODULO 4

RTO e RPO negli scenari RDS

RTO RPO
Tempo massimo accettabile per ripristinare il servizio Quantità massima di dati che l'organizzazione può
dopo un incidente. permettersi di perdere.

Multi-AZ classico Multi-AZ DB Cluster

RTO di uno o due minuti, RPO prossimo a zero grazie RTO tipicamente sotto i 35 secondi, RPO molto
alla replica sincrona. ridotto.

PITR da backup Cross-region replica

RTO da decine di minuti a ore secondo la dimensione, RTO legato ai tempi di promozione, RPO pari al lag di
RPO di circa 5 minuti. replica corrente.

Amazon RDS 30 / 50
MODULO 5

Automated Backups vs Manual Snapshots

Automated backup Ciclo di vita

Gestito da RDS, giornaliero, con log delle transazioni Vengono eliminati alla cancellazione dell'istanza, salvo
per il point-in-time recovery. backup retention conservati.

Manual snapshot Condivisione

Creato su richiesta, persiste finché non viene Solo lo snapshot manuale può essere condiviso o
esplicitamente cancellato. copiato tra account e regioni.

Restore Strategia
Entrambi generano sempre una nuova istanza: non Backup automatici per l'operatività quotidiana,
esiste il restore in-place. snapshot per milestone e conformità.

Amazon RDS 31 / 50
MODULO 5

Automated Backups: retention e log

▪ Retention period: da 1 a 35 giorni; il valore 0 disattiva i backup e con essi il PITR.

▪ Backup window: finestra giornaliera configurabile in cui viene eseguito lo snapshot di sistema.
▪ Log delle transazioni: caricati su S3 con frequenza tipica di 5 minuti, abilitando il recovery granulare.
▪ Impatto sulle performance: su istanze Single-AZ può verificarsi una breve latenza di I/O durante il
backup.
▪ Multi-AZ: il backup viene eseguito dallo standby, riducendo l'impatto sul primario.
▪ Governance: AWS Backup consente policy centralizzate, vault immutabili e retention di lungo periodo.

Amazon RDS 32 / 50
MODULO 5

Point-in-Time Recovery (PITR)

▪ Cosa consente: ripristinare il database a un secondo preciso all'interno del periodo di retention.
▪ Latest restorable time: istante più recente ripristinabile, generalmente a circa 5 minuti dal presente.
▪ Meccanismo: restore dello snapshot più vicino e riapplicazione dei log delle transazioni fino al target.
▪ Nuova istanza: il ripristino crea sempre una nuova istanza con un nuovo endpoint.
▪ Configurazione da ricreare: security group, parameter group e opzioni vanno riapplicati
esplicitamente.
▪ Caso d'uso tipico: recupero da errore logico, come una DELETE senza clausola WHERE.

Amazon RDS 33 / 50
MODULO 5

DB Snapshots manuali

▪ Natura: backup completo e persistente dello storage dell'istanza in un momento preciso.

▪ Momenti chiave: prima di un upgrade, di un rilascio applicativo o di una migrazione dello schema.
▪ Copia cross-region: copy-db-snapshot per replicare il backup in una regione di disaster recovery.
▪ Condivisione cross-account: utile per ambienti di test o forensics; snapshot cifrati richiedono una
CMK condivisa.
▪ Snapshot pubblici: mai per snapshot contenenti dati reali: rischio grave di data leak.
▪ Costo: storage incrementale sui blocchi modificati: gli snapshot dimenticati generano spesa silenziosa.

Amazon RDS 34 / 50
MODULO 5

Maintenance Window e minor upgrade

▪ Finestra settimanale: intervallo di 30 minuti scelto dal cliente per le operazioni di manutenzione.
▪ Contenuto: patch di sicurezza del sistema operativo e minor version upgrade del motore.
▪ Auto minor version upgrade: flag che applica automaticamente le minor release durante la finestra.
▪ Impatto: possibile riavvio; con Multi-AZ la manutenzione avviene prima sullo standby con failover.
▪ Pianificazione: collocare la finestra nella fascia di traffico più bassa dell'applicazione.
▪ Pending modifications: verificare le modifiche in attesa per sapere cosa verrà applicato.

Amazon RDS 35 / 50
MODULO 5

Major version upgrade

▪ Non automatico: richiede sempre un'azione esplicita e comporta downtime dell'istanza.

▪ Rischio di compatibilità: cambi di piano di esecuzione, funzioni deprecate, comportamenti SQL
diversi.
▪ Test preventivo: clonare l'ambiente da snapshot e ripetere il carico applicativo reale sulla nuova
versione.
▪ Blue/Green Deployment: ambiente parallelo sincronizzato con switchover rapido e rollback
semplificato.
▪ Snapshot prima dell'upgrade: punto di ripristino obbligatorio in caso di esito negativo.
▪ Post-upgrade: aggiornare le statistiche, rivedere i parametri e monitorare le query più critiche.

Amazon RDS 36 / 50
MODULO 6

Introduzione ad Amazon Aurora

▪ Il limite tradizionale: i motori classici legano compute e storage sullo stesso nodo, limitando la
scalabilità.
▪ Approccio Aurora: separazione tra livello di calcolo e livello di storage distribuito e condiviso.
▪ Log-structured storage: il nodo scrive solo record di log, non pagine complete: meno I/O di rete.
▪ Performance: throughput significativamente superiore rispetto ai motori community equivalenti.
▪ Compatibilità: protocollo e strumenti MySQL e PostgreSQL restano invariati per l'applicazione.
▪ Modello di servizio: resta un servizio RDS: stessi concetti di snapshot, parameter group e
monitoraggio.

Amazon RDS 37 / 50
MODULO 6

Architettura di storage di Aurora

▪ Volume condiviso: un unico volume logico auto-espandibile condiviso da tutte le istanze del cluster.
▪ Sei copie su tre AZ: ogni blocco è replicato sei volte, con due copie per Availability Zone.
▪ Quorum di scrittura: quattro copie su sei devono confermare per considerare la scrittura durevole.
▪ Quorum di lettura: tre copie su sei sono sufficienti a servire una lettura coerente.
▪ Tolleranza ai guasti: il cluster tollera la perdita di un'intera AZ più una copia aggiuntiva senza perdita
dati.
▪ Self-healing: i segmenti danneggiati vengono rilevati e ricostruiti automaticamente in background.

Amazon RDS 38 / 50
MODULO 6

Aurora Serverless v2

▪ Capacità elastica: la capacità di calcolo si misura in Aurora Capacity Unit e varia in modo continuo.
▪ Scalabilità istantanea: adattamento in frazioni di secondo, senza interruzione delle connessioni attive.
▪ Intervallo configurabile: si definiscono ACU minima e massima per governare performance e spesa.
▪ Cluster misto: istanze provisioned e serverless possono coesistere nello stesso cluster.
▪ Casi d'uso: carichi variabili o imprevedibili, ambienti di sviluppo, SaaS multi-tenant.
▪ Attenzione al costo: un limite massimo troppo alto su un carico costante può risultare più caro del
provisioned.

Amazon RDS 39 / 50
MODULO 6

Aurora Global Database

▪ Struttura: una regione primaria in scrittura e fino a cinque regioni secondarie in sola lettura.
▪ Replica a livello di storage: la propagazione avviene sotto il motore, con latenza tipica sotto il
secondo.
▪ Nessun impatto sul primario: la replica non consuma capacità di calcolo dell'istanza writer.
▪ Failover regionale: promozione di una regione secondaria con RTO tipicamente nell'ordine del
minuto.
▪ Letture locali: gli utenti di ogni area geografica leggono dalla regione più vicina.
▪ Write forwarding: le scritture emesse in una regione secondaria possono essere inoltrate alla
primaria.

Amazon RDS 40 / 50
MODULO 6

Fast Database Cloning e Backtrack

Fast cloning Copy-on-write

Crea un nuovo cluster da uno esistente in pochi Il clone condivide i blocchi dell'originale e diverge solo
minuti, indipendentemente dalla dimensione. sulle pagine modificate.

Uso del clone Backtrack

Test di upgrade, analisi di performance e ambienti di Riporta il cluster indietro nel tempo senza ripristinare
QA su dati realistici. un backup.

Finestra di backtrack Valore operativo

Configurabile in ore; disponibile per Aurora MySQL- Recupero in minuti da un errore logico, contro le ore
compatible. di un restore completo.

Amazon RDS 41 / 50
MODULO 6

Aurora MySQL vs Aurora PostgreSQL

Aurora MySQL Aurora PostgreSQL

Compatibile con il protocollo MySQL: driver, dump e Compatibile con PostgreSQL, con supporto a un
strumenti esistenti restano validi. ampio insieme di estensioni.

Feature esclusive MySQL Punti di forza PostgreSQL

Backtrack e alcune ottimizzazioni specifiche del Tipi di dato avanzati, indici specializzati e query
motore. planner sofisticato.

Comune a entrambi Criterio di scelta

Storage distribuito, cloning, Global Database, Guidata dallo stack applicativo e dalle competenze del
Serverless v2 e repliche a bassa latenza. team, non dal motore in sé.

Amazon RDS 42 / 50
MODULO 6

RDS standard o Aurora?

Scegli RDS quando Scegli RDS quando

Serve un motore non coperto da Aurora, come Oracle, Il carico è modesto e prevedibile: il costo di ingresso è
SQL Server o MariaDB. inferiore.

Scegli Aurora quando Scegli Aurora quando

Servono throughput elevato, molte repliche di lettura Il requisito è la distribuzione globale o la scalabilità
e failover rapidissimo. serverless.

Fattore costo Percorso di migrazione

Aurora fattura anche l'I/O nel modello standard: Da RDS MySQL o PostgreSQL si migra ad Aurora
valutare la configurazione I/O-Optimized. tramite replica o snapshot.

Amazon RDS 43 / 50
MODULO 7

Modelli di prezzo: On-Demand e Reserved

On-Demand Reserved Instance

Tariffa oraria senza impegno: massima flessibilità, Impegno di 1 o 3 anni su una classe di istanza in
costo unitario più alto. cambio di uno sconto rilevante.

Componenti di costo Multi-AZ

Compute, storage allocato, IOPS, backup oltre la soglia Raddoppia sostanzialmente il costo di compute e
e traffico di rete. storage dell'istanza.

Backup Strategia mista

Lo storage di backup pari alla dimensione del Reserved per la baseline stabile, On-Demand per i
database è tipicamente incluso. picchi e i progetti temporanei.

Amazon RDS 44 / 50
MODULO 7

RDS Reserved Instances in dettaglio

▪ Durata: impegno di 1 anno oppure di 3 anni, con sconto crescente sulla durata più lunga.
▪ No Upfront: nessun pagamento iniziale, sconto minore, rata mensile costante.
▪ Partial Upfront: pagamento parziale all'acquisto e canone ridotto: compromesso più diffuso.
▪ All Upfront: pagamento integrale anticipato e sconto massimo sull'intero periodo.
▪ Attributi vincolanti: regione, famiglia e classe di istanza, motore e configurazione Multi-AZ.
▪ Prima di acquistare: consolidare l'architettura: una reservation su una classe poi dismessa è denaro
sprecato.

Amazon RDS 45 / 50
MODULO 7

Ottimizzazione dei costi di storage

▪ Capacità allocata: si paga lo spazio allocato, non quello effettivamente utilizzato dai dati.
▪ Riduzione non supportata: lo storage può solo crescere: ridurlo richiede una migrazione dei dati.
▪ Migrazione a gp3: consente di disaccoppiare IOPS e capacità, riducendo il sovradimensionamento
tipico di gp2.
▪ IOPS provisioned: monitorare l'utilizzo reale prima di confermare valori elevati di io1 o io2.
▪ Igiene dei dati: archiviare o eliminare tabelle storiche e log applicativi mantenuti nel database.
▪ Snapshot dimenticati: definire una policy di retention automatica per evitare accumuli silenziosi.

Amazon RDS 46 / 50
MODULO 7

Ambienti dev/test: stop e start pianificati

▪ Stop temporaneo: un'istanza RDS può restare ferma fino a 7 giorni consecutivi, poi riparte
automaticamente.
▪ Cosa si risparmia: cessa il costo di compute; storage e snapshot continuano a essere fatturati.
▪ Automazione: EventBridge Scheduler con Lambda o Systems Manager per spegnere la sera e
riaccendere la mattina.
▪ Tagging: tag come Environment e Schedule per applicare le policy in modo selettivo e sicuro.
▪ Limiti: le istanze in un cluster Multi-AZ e alcune configurazioni hanno regole di stop diverse.
▪ Alternativa: Aurora Serverless v2 per ambienti non produttivi con capacità minima molto bassa.

Amazon RDS 47 / 50
MODULO 8

Metriche chiave in Amazon CloudWatch

CPUUtilization FreeableMemory
Saturazione del calcolo; valori costantemente alti Memoria disponibile: un calo continuo anticipa
indicano query o dimensionamento errati. swapping e degrado delle performance.

DatabaseConnections FreeStorageSpace
Numero di sessioni attive; utile per dimensionare il Spazio libero residuo: allarme obbligatorio prima della
connection pool applicativo. soglia critica.

Read/WriteIOPS e Latency ReplicaLag

Profilo di I/O e tempi di risposta dello storage Ritardo delle repliche di lettura: soglia di allarme per la
sottostante. coerenza dei dati letti.

Amazon RDS 48 / 50
MODULO 8

RDS Performance Insights

▪ Metrica centrale: Average Active Sessions, che misura il carico reale sul database nel tempo.
▪ Wait events: identifica se il collo di bottiglia è CPU, I/O, lock o attesa di rete.
▪ Top SQL: classifica le query per contributo al carico, non per semplice tempo di esecuzione.
▪ Dimensioni di analisi: scomposizione per utente, host, applicazione e statement.
▪ Retention: 7 giorni gratuiti, con estensione a lungo termine a pagamento.
▪ Metodo: partire dal picco di AAS, isolare il wait event dominante e poi la query responsabile.

Amazon RDS 49 / 50
MODULO 8

Checklist finale delle best practices

Rete — Istanze in subnet private, mai publicly accessible, Cifratura — KMS abilitato alla creazione e TLS imposto lato
security group per riferimento. server per tutte le connessioni.

Credenziali — Secrets Manager con rotazione automatica o Disponibilità — Multi-AZ in produzione e test periodici di
autenticazione IAM; nessuna password nel codice. failover documentati.

Backup — Retention adeguata, snapshot prima di ogni Manutenzione — Finestre pianificate, minor upgrade
cambiamento e prove di restore reali. automatici, major upgrade testati in staging.

Osservabilità — Allarmi su CPU, memoria, spazio libero, Costi — Reserved per la baseline, gp3, stop programmato in
connessioni e lag; Performance Insights attivo. dev/test e pulizia degli snapshot.

Amazon RDS 50 / 50