Hai un'applicazione che cresce, il database in self-managed su un VPS inizia a dare segni di cedimento: query lente, backup manuali che non ricordi di aver fatto, un'impennata di traffico trasforma il sito in un fermacarte. È lo scenario classico che vediamo ogni giorno da chi arriva da noi con un progetto già in produzione. La soluzione non è un server più grosso: è un database gestito AWS come RDS o Aurora. Qui non parliamo di teoria — partiamo dal problema concreto e ti mostriamo come configurare, dimensionare e ottimizzare un database su AWS, con esempi reali, costi alla mano e senza orpelli.
Perché un database gestito AWS (RDS o Aurora) conviene al tuo progetto?
Noi, di Meteora Web, gestiamo decine di database per clienti in produzione. La differenza tra un database self-managed e uno gestito AWS la vedi la prima notte in cui scatta un failover automatico e la tua app continua a funzionare. RDS (Relational Database Service) ti toglie dalle spalle la manutenzione del sistema operativo, gli aggiornamenti di sicurezza, il provisioning dello storage. Aurora va oltre: è un motore MySQL/PostgreSQL compatibile ma riscritto per il cloud, con prestazioni fino a 5x superiori e un sistema di storage distribuito che replica i dati su 6 copie in 3 AZ (Availability Zone).
Niente più notti insonni per un disco pieno: con RDS imposti un limite di storage e il provisioning è automatico (se usi storage Auto Scaling). Con Aurora lo storage scala da solo fino a 128 TB senza interventi. E se pensi al costo: non paghi un server fermo, paghi quello che usi. Per un cliente e-commerce con traffico stagionale siamo passati da un VPS dedicato (80 €/mese) a Aurora Serverless v2 (circa 40 €/mese a regime) con picchi gestiti automaticamente.
Come configurare RDS per un'applicazione in produzione?
Scelta del motore e versione
Parti dal tuo stack: MySQL e PostgreSQL sono i più diffusi. Noi consigliamo PostgreSQL per applicazioni che richiedono integrità referenziale e funzioni avanzate (JSONB, full-text search). MySQL (o MariaDB) per progetti WordPress, WooCommerce o Laravel legacy. Evita versioni non più supportate (guarda le date di EOL su docs.aws.amazon.com).
Sponsored Protocol
# Esempio: creare un'istanza RDS PostgreSQL 16 via AWS CLI
aws rds create-db-instance \
--db-instance-identifier mia-app-prod \
--db-instance-class db.t4g.medium \
--engine postgres \
--engine-version 16.3 \
--master-username admin \
--master-user-password 'S3cur3P@ss!' \
--allocated-storage 100 \
--storage-type gp3 \
--vpc-security-group-ids sg-0123456789abcdef0 \
--db-subnet-group-name mio-subnet-group \
--backup-retention-period 7 \
--multi-az \
--auto-minor-version-upgrade \
--enable-performance-insights \
--monitoring-interval 60Spiegazione operativa: db.t4g.medium (2 vCPU, 4 GB RAM) è un buon punto di partenza per app fino a qualche migliaio di utenti. gp3 è storage SSD con IOPS base e burst. multi-az abilita il failover automatico (fondamentale per produzione). backup-retention-period 7 conserva 7 giorni di snapshot automatici. performance-insights ti dà visibilità sulle query lente.
Parametri critici: max_connections e timeouts
Il valore predefinito di max_connections su RDS è legato alla RAM (es. 4 GB → 100 connessioni). Per app con pool di connessioni (Laravel, Django) può bastare, ma se usi code o WebSocket devi aumentarlo. Modifica il DB Parameter Group:
-- Verifica il valore corrente
SHOW max_connections;
-- Imposta a 200 (dopo aver creato un parameter group custom)
aws rds modify-db-parameter-group \
--db-parameter-group-name mio-custom-pg \
--parameters "ParameterName=max_connections,ParameterValue=200,ApplyMethod=immediate"Errore comune: non settare idle_in_transaction_session_timeout (PostgreSQL) o wait_timeout (MySQL). Le connessioni aperte indefinite consumano risorse. Noi lo impostiamo a 30 secondi per applicazioni web.
Sponsored Protocol
Security Group e accesso
Mai aprire il database su 0.0.0.0/0. Usa security group riferito agli IP privati dei tuoi server EC2 o Lambda. Se devi accedere da remoto, usa un bastion host o AWS SSM Port Forwarding.
Quanto costa un database gestito AWS rispetto a un VPS?
Facciamo due conti concreti. Un VPS con 4 GB RAM, 2 CPU e 100 GB SSD costa in media 40-60 €/mese su provider italiani. Devi pagare anche backup manuali (o aggiuntivi), aggiornamenti, e il tuo tempo. Un'istanza RDS db.t4g.medium (4 GB RAM, 2 vCPU) on-demand: ~60 €/mese solo di compute + storage gp3 (100 GB ~10 €/mese) + backup (gratis fino a 100% dello storage) = circa 70 €/mese. Sembra di più, ma include:
- Backup automatici e PITR (point-in-time recovery)
- Failover automatico con Multi-AZ
- Patch e manutenzione gestita
- Performance Insights e monitoraggio
Se usi Aurora Serverless v2 paghi solo le ACU (Aurora Capacity Unit) usate. Per carichi variabili (e-commerce, SaaS) il costo medio scende. Un nostro cliente (negozio di abbigliamento) ha ridotto la spesa del 35% passando da RDS provisioned ad Aurora Serverless, mantenendo la stessa latenza di risposta.
Come gestire backup, restore e alta disponibilità su RDS e Aurora?
Backup automatici e snapshot manuali
RDS esegue snapshot automatici ogni giorno nel tuo window di backup. Puoi conservarli fino a 35 giorni. Per archiviazione a lungo termine, fai snapshot manuali e copiali in un'altra regione (utile per disaster recovery).
Sponsored Protocol
# Creare uno snapshot manuale
aws rds create-db-snapshot \
--db-instance-identifier mia-app-prod \
--db-snapshot-identifier mia-snapshot-$(date +%Y%m%d)
# Copiarlo in un'altra regione
aws rds copy-db-snapshot \
--source-db-snapshot-identifier arn:aws:rds:eu-west-1:123456789012:snapshot:mia-snapshot-20260420 \
--target-db-snapshot-identifier mia-snapshot-backup \
--source-region eu-west-1 \
--region eu-central-1PITR (Point-in-Time Recovery)
Con RDS puoi ripristinare il database a qualsiasi secondo negli ultimi giorni. È un'ancora di salvezza se un deploy sbagliato o un errore umano cancella dati. Il ripristino crea una nuova istanza: puoi testare e poi promuoverla.
Alta disponibilità con Multi-AZ
RDS Multi-AZ crea una replica sincrona in un'altra zona. Se l'istanza primaria fallisce, AWS fa failover automatico in circa 60 secondi. La tua app deve riconnettersi (usa un endpoint o un proxy). Aurora fa di meglio: ha sei copie dello storage su tre AZ e il failover di una replica è sub-secondo. Non serve nemmeno riavviare l'app se usi endpoint letto/scrittura separati.
Quali differenze tecniche tra RDS e Aurora e quando preferire l'uno all'altro?
RDS è un servizio maturo, affidabile, con supporto multi-engine (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server). Aurora è AWS-native: storage distribuito, caching a livello di buffer pool, repliche per il read scaling fino a 15 nodi. La scelta dipende da:
- Volume di dati: oltre 500 GB Aurora scala meglio perché lo storage è disaccoppiato dal compute.
- Picchi di carico: Aurora Serverless scala in secondi senza pre-provisioning.
- Costi fissi: RDS è più prevedibile. Aurora Serverless può essere più economico sotto 20-30 ACU.
- Compatibilità: se hai codice legacy MySQL o tool di terze parti (WordPress, Magento), RDS è più sicuro. Aurora è compatibile ma ha qualche differenza in stored procedures e gestione di alcune funzioni.
Noi di Meteora Web preferiamo Aurora per progetti cloud-native, SaaS e app con traffico variabile. Per clienti con carichi stabili e budget limitato, consigliamo RDS Multi-AZ.
Sponsored Protocol
Monitoraggio e ottimizzazione delle performance
Performance Insights e Enhanced Monitoring
Abilita Performance Insights: ti mostra le query che consumano più risorse, ordinate per wait event. Noi lo abbiamo usato per ottimizzare un gestionale che faceva 500 query al minuto: abbiamo ridotto il carico del 40% indicizzando due tabelle.
Autoscaling dello storage
RDS può aumentare automaticamente lo storage quando raggiungi il 90% di occupazione. Imposta MaxAllocatedStorage a un limite superiore (es. 1000 GB) per evitare interruzioni.
Query cache e parametri di tuning
Per MySQL, abilita query_cache_type = 1 (solo per workload read-heavy). Per PostgreSQL, lavora su shared_buffers (25% della RAM) e effective_cache_size. Esempio di parameter group per PostgreSQL:
{
"Parameters": [
{"ParameterName": "shared_buffers", "ParameterValue": "{DBInstanceClassMemory*1/4}", "ApplyMethod": "pending-reboot"},
{"ParameterName": "effective_cache_size", "ParameterValue": "{DBInstanceClassMemory*3/4}", "ApplyMethod": "immediate"},
{"ParameterName": "random_page_cost", "ParameterValue": "1.1", "ApplyMethod": "immediate"}
]
}Errori comuni che vediamo nei progetti che arrivano da noi
1. Porta del database esposta pubblicamente — clienti che copiano le regole di security group da tutorial e lasciano 0.0.0.0/0. Lo risolviamo in due minuti e spieghiamo perché non si fa.
2. Backup dimenticati — RDS li fa automatici, ma molti non settano il retention period. Un cliente ha perso 3 giorni di ordini per una cancellazione accidentale e non aveva uno snapshot. Ora usiamo retention a 14 giorni + snapshot giornaliero automatico.
Sponsored Protocol
3. Istanza sovradimensionata — pagano una db.r5.large (16 GB RAM) per un blog WordPress. Con RDS puoi scalare down senza downtime (a meno di database molto grandi). Analizza i CloudWatch metrics prima di scegliere la classe.
Migliori pratiche di sicurezza per un database gestito AWS
- Usa encryption at rest (KMS) — abilitalo al momento della creazione (non puoi dopo).
- Abilita SSL/TLS per le connessioni — in PostgreSQL forza
sslmode=requirenella stringa di connessione. - Limita l'accesso con IAM Database Authentication (solo per RDS MySQL/PostgreSQL) — elimina le password statiche.
- Abilita Audit Logging — per compliance e indagini in caso di incidente.
Cosa fare adesso
- Fai un check del tuo database attuale: quanto storage usi? Quante connessioni? Quale motore? Se è auto-gestito, programma la migrazione.
- Prendi un account AWS (se non ce l'hai) e crea un'istanza RDS di prova con
db.t4g.micro. Costo irrisorio e impari in sicurezza. - Configura backup e retention: anche se il progetto è piccolo, imposta almeno 7 giorni.
- Abilita Performance Insights: dopo una settimana guardi le query più lente e ottimizzi.
- Valuta se Aurora è adatto al tuo carico: traffico variabile? Spendi meno con Serverless. Carico stabile? RDS Multi-AZ.
Noi, di Meteora Web, accompagniamo team e aziende in questa transizione da anni. Se hai un progetto in produzione e vuoi un parere sulla scelta del database gestito AWS, contattaci. Intanto, leggi la nostra guida pillar su AWS per sviluppatori per inquadrare RDS e Aurora nell'ecosistema complessivo.
