1 03/11/2026 11 min

Installare PostgreSQL 14 su Amazon Linux 2 in EC2

Su Amazon Linux 2 la strada più pulita è usare il repository ufficiale di PostgreSQL, non i pacchetti generici del sistema. Così eviti versioni vecchie, dipendenze sporche e differenze inutili tra ambiente di test e produzione. Se l’istanza EC2 è già online, l’obiettivo è semplice: installare PostgreSQL 14, avviarlo come servizio systemd, verificare che ascolti solo dove serve e lasciare una configurazione minima ma sensata per l’uso applicativo.

Prima di toccare il sistema, vale la pena chiarire il contesto: Amazon Linux 2 include un set di pacchetti stabile, ma PostgreSQL spesso va gestito dal repository PGDG per avere una major specifica. Questo è importante soprattutto se l’applicazione, un dump o un team operativo richiedono la 14.x e non una versione diversa. In più, su EC2 il vero confine di sicurezza non è solo PostgreSQL: conta anche il Security Group, eventuali NACL, la configurazione di rete interna e il fatto che il servizio non debba esporsi al mondo se non è strettamente necessario.

1. Verifica del sistema e scelta del repository

La prima cosa da controllare è che la macchina sia davvero Amazon Linux 2 e che abbia accesso in uscita ai repository. Sul piano operativo, il punto non è “se il comando funziona”, ma se la rete e i mirror consentono l’installazione senza sorprese.

cat /etc/system-release
uname -r
sudo yum repolist enabled | sed -n '1,20p'

Output atteso: una stringa che identifichi Amazon Linux 2 e una lista di repository abilitati. Se il sistema è isolato o dietro proxy, questa è la prima anomalia da risolvere prima di proseguire. Se il nodo non ha egress verso Internet, il repository PGDG va reso disponibile via mirror interno o tramite un percorso approvato dall’organizzazione.

Per PostgreSQL 14 su Amazon Linux 2, il pacchetto di repository ufficiale è in genere il punto di partenza corretto. L’installazione del repository è un’operazione reversibile: aggiunge file di configurazione yum, ma non modifica ancora il database né avvia servizi applicativi. Il blast radius è limitato al sistema locale; il rollback consiste nel rimuovere il file del repository e, se necessario, ripulire i pacchetti installati.

sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Nota pratica: Amazon Linux 2 è compatibile con i pacchetti EL7 della linea PGDG per molte installazioni standard. Se la tua immagine, il tuo hardening o il tuo supporto interno richiedono una variante specifica, verifica prima il repository approvato nel tuo contesto. Il dato importante è sempre lo stesso: repository coerente con la major 14, non il nome del pacchetto in sé.

2. Installazione dei pacchetti PostgreSQL 14

Una volta aggiunto il repository, installa client, server e utilità base. Qui conviene essere espliciti: il client serve per amministrazione e troubleshooting, il server contiene il demone, e gli strumenti di contrib possono tornare utili per estensioni o operazioni di supporto.

sudo yum install -y postgresql14 postgresql14-server postgresql14-contrib

Se l’installazione fallisce, le cause più probabili sono tre: repository non raggiungibile, conflitto con pacchetti già presenti, oppure problemi di dipendenze del sistema. In meno di cinque minuti puoi falsificarle così: controlla la reachability del repository con un semplice yum makecache, verifica i pacchetti già presenti con rpm -qa | grep -i postgres, e ispeziona l’errore completo senza tagliare il log a metà. Se c’è un conflitto, spesso la soluzione non è forzare: è rimuovere la versione sbagliata o allineare il repository corretto.

rpm -qa | grep -i postgres
sudo yum makecache fast

Se il nodo è in produzione o contiene già un database, fermati prima di qualsiasi rimozione. Il blast radius di un yum remove eseguito male è ovvio: puoi cancellare binari, librerie e potenzialmente rompere servizi dipendenti. Il rollback, in quel caso, è un backup o snapshot prima dell’intervento, non un semplice “reinstallo dopo”.

3. Inizializzazione del cluster dati

Dopo l’installazione, il servizio non è ancora pronto a partire finché non inizializzi il database cluster. Su PostgreSQL 14 questo passaggio crea la directory dati, i file di configurazione iniziali e la struttura base del cluster. È un’operazione locale, ma è anche quella che determina dove finiranno dati, WAL e configurazioni future.

sudo /usr/pgsql-14/bin/postgresql-14-setup initdb

Il risultato atteso è la creazione della directory dati, in genere sotto /var/lib/pgsql/14/data. Se il comando restituisce un errore, le verifiche immediate sono: spazio disco disponibile, permessi sulla directory, e presenza di un cluster già inizializzato. Una delle cause più banali è proprio questa: il cluster esiste già e l’operazione si rifiuta di sovrascriverlo.

df -h
ls -ld /var/lib/pgsql/14/data
sudo ls -la /var/lib/pgsql/14/data | sed -n '1,20p'

Se la directory dati è già presente e non è vuota, non forzare l’inizializzazione a occhi chiusi. Prima fai un backup o verifica se quel path appartiene a una precedente installazione. In produzione il rischio non è teorico: un init su una directory sbagliata può sovrascrivere dati o rendere ingestibile il recupero. Il rollback corretto, in questo caso, è ripristinare la directory dati dal backup o ripuntare il servizio al path originale, non improvvisare una ricostruzione.

4. Avvio e abilitazione del servizio systemd

Una volta creato il cluster, avvia il servizio e abilitalo all’avvio. Qui il controllo non è solo “si avvia”, ma “resta su, ascolta e registra correttamente”. PostgreSQL su Amazon Linux 2 usa systemd, quindi l’unità di servizio è il riferimento principale per stato, restart e log di base.

sudo systemctl enable --now postgresql-14
sudo systemctl status postgresql-14 --no-pager

Lo stato atteso è active (running). Se il servizio va in failed, le prime verifiche utili sono nel journal e nel file di log del database. Su un sistema standard, il log può finire nel journal systemd o in un file sotto la directory dati, a seconda della configurazione. Il punto è leggere il messaggio esatto, non dedurlo.

sudo journalctl -u postgresql-14 -n 100 --no-pager
sudo tail -n 100 /var/lib/pgsql/14/data/log/postgresql*.log 2>/dev/null

Se il demone non parte perché la porta è occupata, il falsificatore più veloce è ss -ltnp | grep 5432. Se invece il problema è nei permessi, il log lo dirà chiaramente. Se il database si avvia ma non risponde dall’esterno, il problema spesso non è PostgreSQL ma il Security Group di EC2 o il binding su localhost. In altre parole: il servizio può essere sano e comunque invisibile dal client.

ss -ltnp | grep 5432

5. Configurazione minima di ascolto e accesso

La configurazione più comune su una EC2 è lasciare PostgreSQL in ascolto solo sull’interfaccia privata o sul localhost, a seconda dell’architettura. Esporre la porta 5432 pubblicamente è quasi sempre una cattiva idea. Se l’applicazione gira sulla stessa istanza, localhost basta e avanza. Se l’applicazione è su un’altra macchina nella VPC, conviene usare l’IP privato o, meglio ancora, un gruppo di sicurezza ben definito e una rete segmentata.

Le impostazioni chiave stanno in /var/lib/pgsql/14/data/postgresql.conf e /var/lib/pgsql/14/data/pg_hba.conf. Prima di modificare, fai sempre una copia di sicurezza o almeno un diff chiaro. Il blast radius qui è medio: un errore su listen_addresses o pg_hba.conf può bloccare l’accesso al database o, peggio, aprirlo troppo.

sudo cp /var/lib/pgsql/14/data/postgresql.conf /var/lib/pgsql/14/data/postgresql.conf.bak
sudo cp /var/lib/pgsql/14/data/pg_hba.conf /var/lib/pgsql/14/data/pg_hba.conf.bak

Un esempio minimo per ascoltare solo su un indirizzo privato o su localhost può essere questo:

listen_addresses = 'localhost'
port = 5432

Se invece devi accettare connessioni da una subnet interna, usa un indirizzo specifico o una lista molto stretta, non un wildcard inutile. Dopo la modifica riavvia o ricarica il servizio secondo la natura del cambiamento; per listen_addresses in genere serve un restart completo.

Per pg_hba.conf, un esempio prudente per accesso dalla rete privata potrebbe essere:

host all all 10.0.0.0/16 scram-sha-256

Non usare range ampi se non hai un motivo preciso. La verifica immediata è semplice: dopo il reload o il restart, prova la connessione dal client previsto e controlla che il server risponda solo dagli host autorizzati. Se l’accesso fallisce, i colpevoli più comuni sono ordine delle regole in pg_hba.conf, password errata, o Security Group AWS troppo restrittivo.

6. Creazione utente e database applicativo

Per evitare di usare l’account amministrativo nelle applicazioni, crea un ruolo dedicato e un database separato. È una misura semplice ma decisiva: limita i danni se una credenziale viene compromessa e rende più chiaro il perimetro di accesso dell’applicazione.

sudo -u postgres psql

Dentro psql, crea ruolo e database in modo coerente con la tua policy di password e naming. Non mettere password in chiaro in script o cron: se serve automazione, usa secret manager, file protetto o variabili passate in modo controllato dal tuo orchestratore.

CREATE ROLE appuser WITH LOGIN PASSWORD 'password-forte-da-gestire-correttamente';
CREATE DATABASE appdb OWNER appuser;

Qui il punto non è il comando in sé, ma la gestione del segreto. In un contesto serio, la password va subito ruotata o redatta dal materiale operativo, e l’accesso va centralizzato dove possibile. Se devi testare la connessione, fallo con un client esterno e con credenziali dedicate, non con l’utente postgres.

7. Verifiche finali: porta, versione, autenticazione

A installazione completata, la verifica non si limita a “il servizio è attivo”. Devi controllare tre cose: versione effettiva, ascolto sulla porta giusta, e autenticazione funzionante dal punto previsto dall’architettura.

psql --version
sudo -u postgres psql -c 'SELECT version();'
ss -ltnp | grep 5432

Output atteso: psql e il server devono riportare la major 14, la porta deve risultare in ascolto, e la query SQL deve rispondere senza errori. Se il client mostra una versione e il server un’altra, vuol dire che hai più installazioni o path non allineati. In quel caso è meglio fermarsi e fare pulizia: un ambiente con binari misti è il modo più veloce per creare problemi di manutenzione.

Se la connessione remota fallisce ma il servizio locale funziona, controlla in quest’ordine: listen_addresses, pg_hba.conf, Security Group EC2, e solo dopo eventuali firewall host-based. Questo ordine evita di perdere tempo su livelli sbagliati. Il layer che decide davvero se un client remoto entra non è uno solo: è la somma di configurazione PostgreSQL e rete AWS.

8. Hardening minimo consigliato

Una installazione funzionante non è automaticamente una installazione sana. Anche su una singola EC2 conviene applicare alcuni interventi minimi: accesso ristretto, password robuste, backup pianificato e log leggibili. Se il database contiene dati importanti, la priorità successiva è la strategia di backup, non l’ottimizzazione fine.

Primo: limita l’esposizione di rete. Lascia aperta la 5432 solo agli host che devono parlarci davvero. Secondo: usa autenticazione moderna, come scram-sha-256, invece di vecchie modalità meno robuste. Terzo: imposta una retention dei log che ti consenta di capire cosa è successo senza saturare il disco. Quarto: monitora spazio, memoria e connessioni attive, perché PostgreSQL soffre più di quanto sembri quando la macchina è stretta di risorse.

Se vuoi una verifica rapida della salute del nodo, osserva almeno questi segnali: spazio libero su /var, numero di connessioni, e messaggi di OOM nel kernel log. Su EC2, un database che sembra “lento” può in realtà essere solo sotto pressione di memoria o I/O. Prima di cambiare parametri a caso, misura.

free -h
sudo dmesg | grep -i oom
sudo du -sh /var/lib/pgsql/14/data

Se il disco si avvicina alla saturazione, il rischio è concreto: PostgreSQL può degradare rapidamente o fermarsi. Il rollback qui non è “tornare indietro”, ma liberare spazio in modo controllato, spostare i log, aumentare il volume EBS e verificare che il filesystem sia stato esteso correttamente. Ogni azione va fatta con consapevolezza del blast radius, perché toccare lo storage di un database è sempre un’operazione sensibile.

9. Rimozione pulita o rollback dell’installazione

Se qualcosa va storto e devi tornare indietro, la sequenza corretta dipende dallo stato del cluster. Se il database non contiene dati utili, puoi fermare il servizio, rimuovere i pacchetti e cancellare il cluster inizializzato. Se invece il cluster contiene dati reali, il rollback non è una disinstallazione: è un ripristino da backup o snapshot.

sudo systemctl stop postgresql-14
sudo yum remove -y postgresql14 postgresql14-server postgresql14-contrib

Prima di cancellare la directory dati, verifica sempre che non ci siano informazioni da conservare. Il path tipico è /var/lib/pgsql/14/data, ma può cambiare se hai personalizzato l’installazione. La rimozione del pacchetto non elimina automaticamente tutti i dati, quindi la pulizia completa va fatta con attenzione e solo se il contesto lo consente.

Se devi preservare l’ambiente, la strategia corretta è: backup del cluster, snapshot del volume EBS, documentazione della configurazione e solo dopo eventuale reinstallazione. In caso di rollback vero, la priorità è riportare il servizio in uno stato coerente, non inseguire il pacchetto singolo. Un database si recupera bene quando hai già pensato al ripristino prima del guasto.

Assunzioni: istanza EC2 con Amazon Linux 2, accesso sudo, nessun PostgreSQL preesistente da preservare, repository esterno raggiungibile o sostituibile con mirror interno.