Installare Apache2 su AWS EC2 con Ubuntu 22.04 e 20.04

Su AWS EC2, installare Apache2 su Ubuntu 22.04 o 20.04 è una procedura semplice solo in apparenza: il punto vero non è far partire il demone, ma farlo esporre in modo corretto sulla rete di AWS, mantenere una configurazione pulita e avere un rollback rapido se qualcosa non torna. La differenza tra “Apache installato” e “sito raggiungibile” sta quasi sempre in tre punti: security group, firewall locale e stato del servizio.

Qui sotto trovi una procedura pratica, pensata per un’istanza nuova o appena preparata, con comandi verificabili e una sequenza che riduce gli errori. Le istruzioni valgono per entrambe le versioni di Ubuntu; dove cambia qualcosa, lo segnalo esplicitamente.

Prerequisiti minimi sull’istanza EC2

Prima di toccare Apache, verifica che l’istanza sia in stato running, abbia un IP pubblico o un Elastic IP associato e che il gruppo di sicurezza consenta almeno SSH dalla tua rete e HTTP dal traffico che deve raggiungere il sito. Se stai usando un load balancer o CloudFront, il discorso cambia: Apache potrebbe non essere esposto direttamente all’esterno, ma deve comunque ascoltare correttamente sulla porta 80.

Se non hai ancora accesso alla macchina, chiudi prima questo punto: senza SSH non puoi distinguere un problema di installazione da un problema di rete. In AWS console controlla EC2 > Instances > Networking e Security groups. Il caso tipico è banale: Apache funziona, ma la porta 80 è chiusa nel security group.

Accesso alla macchina e verifica del sistema

Collegati via SSH usando la chiave associata all’istanza. Su Ubuntu l’utente iniziale è di solito ubuntu.

ssh -i /percorso/chiave.pem ubuntu@IP_PUBBLICO

Una volta dentro, verifica release e stato base del sistema. Non serve fare supposizioni: meglio leggere i dati reali dell’host.

lsb_release -a

uname -a

Su Ubuntu 20.04 e 22.04, Apache2 arriva dai repository ufficiali e si installa senza repository esterni. Questo riduce il rischio di pacchetti incoerenti e semplifica gli aggiornamenti di sicurezza.

Installazione di Apache2

Aggiorna l’indice dei pacchetti e installa Apache2. È un’operazione reversibile e non distruttiva.

sudo apt update
sudo apt install -y apache2

Al termine, controlla che il servizio sia attivo e abilitato all’avvio automatico.

systemctl status apache2 --no-pager

Stato atteso: active (running). Se è inactive o failed, il problema va letto subito nei log di systemd.

journalctl -u apache2 -b --no-pager

Abilita il servizio all’avvio, se non è già stato fatto dal pacchetto:

sudo systemctl enable apache2

Verifica locale del web server

Prima di testare dalla rete, verifica in locale sulla macchina. In questo modo separi i problemi del demone dai problemi di AWS o del firewall. Il test più rapido è una richiesta HTTP verso loopback.

curl -I http://127.0.0.1/

Risposta attesa: HTTP/1.1 200 OK o comunque una risposta valida del server Apache. Se ottieni connessione rifiutata, il servizio non è in ascolto. Se ottieni errore 500, il demone vive ma la configurazione o il contenuto servito non è sano.

Controlla anche quali porte sono in ascolto.

sudo ss -ltnp | grep ':80'

Atteso: un processo apache2 in ascolto su 0.0.0.0:80 o equivalente. Se ascolta solo su 127.0.0.1, c’è una configurazione anomala o un proxy locale davanti.

Configurazione di rete AWS: security group e accesso pubblico

Se Apache risponde in locale ma non dall’esterno, il problema è quasi sempre fuori da Ubuntu. Nel security group devi consentire almeno:

• SSH su 22/tcp dal tuo IP amministrativo
• HTTP su 80/tcp dalla rete che deve accedere al sito
• HTTPS su 443/tcp se prevedi TLS subito o a breve

Per un setup iniziale, puoi lasciare 80 aperta verso 0.0.0.0/0 se il sito deve essere pubblico, ma il controllo corretto dipende dal contesto. Se l’istanza è dietro bilanciatore, l’apertura va limitata ai soli source previsti.

Un controllo rapido lato client è questo:

curl -I http://IP_PUBBLICO/

Se il comando va in timeout ma localmente funziona, guarda nell’ordine: security group, NACL, IP pubblico associato, firewall host. Non saltare direttamente alla configurazione Apache.

Firewall locale su Ubuntu: UFW

Su Ubuntu spesso UFW non è attivo di default, ma va verificato. Se è abilitato e non consenti HTTP, il sito resta irraggiungibile anche con Apache perfetto.

sudo ufw status verbose

Se risulta attivo, consenti il profilo Apache appropriato. Su Ubuntu il pacchetto espone profili già pronti.

sudo ufw app list
sudo ufw allow 'Apache Full'

Se non vuoi aprire subito HTTPS, puoi usare:

sudo ufw allow 'Apache'

Verifica finale:

sudo ufw status numbered

Atteso: regola esplicita per il traffico web. Se non vuoi usare UFW, disabilitalo solo dopo aver confermato che il security group copre già l’esposizione necessaria.

Pagina di test e struttura dei file su Ubuntu 20.04 e 22.04

Dopo l’installazione, Apache serve la pagina predefinita da /var/www/html. Il file classico è /var/www/html/index.html. Su una macchina pulita puoi sostituirlo con una pagina minima per confermare che stai davvero raggiungendo questa istanza e non una cache o un altro origin server.

echo 'Apache su EC2: OK' | sudo tee /var/www/html/index.html

Poi prova di nuovo da browser o con curl:

curl http://IP_PUBBLICO/

Se il contenuto non cambia, stai probabilmente passando da un layer diverso: CDN, load balancer, cache reverse proxy o DNS che punta altrove. In quel caso il problema non è Apache ma il percorso di pubblicazione.

Apache: moduli utili e controllo della configurazione

Su Ubuntu, Apache è gestito con una struttura abbastanza lineare: moduli in /etc/apache2/mods-available, siti in /etc/apache2/sites-available, siti attivi in /etc/apache2/sites-enabled. Questa separazione aiuta a non mischiare test e produzione.

Controlla la configurazione prima di riavviare:

sudo apache2ctl configtest

Atteso: Syntax OK. Se non lo ottieni, non riavviare a tentativi: correggi prima il file indicato dall’errore. Un riavvio con configurazione rotta ti lascia in mano un servizio fermo e nessun guadagno diagnostico.

Per un sito semplice puoi lasciare il virtual host di default. Se invece vuoi un sito dedicato, crea un file separato.

sudo nano /etc/apache2/sites-available/example.conf

Esempio minimo:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example

    <Directory /var/www/example>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Poi abilita il sito e, se serve, disabilita il default.

sudo mkdir -p /var/www/example
sudo a2ensite example.conf
sudo a2dissite 000-default.conf
sudo systemctl reload apache2

Preferisci reload quando fai modifiche compatibili; usa restart solo se necessario. Il reload riduce l’impatto e ti permette un rollback più pulito.

Hardening base subito dopo l’installazione

Un’istanza EC2 pubblica non va lasciata con la configurazione minima e basta. Il primo hardening non è “enterprise”, è buon senso operativo.

• Apri solo le porte necessarie nel security group
• Abilita HTTPS appena il sito esce dal test interno
• Evita directory listing se non serve
• Tieni il sistema aggiornato con patch di sicurezza
• Non mettere segreti in chiaro nei file di configurazione

Se vuoi ridurre la superficie d’attacco, inizia disabilitando le directory listing e controllando i permessi della web root. Un esempio utile è verificare che il contenuto sia leggibile dal servizio ma non scrivibile da utenti non necessari.

sudo find /var/www -maxdepth 2 -ls

Per aggiornare il sistema senza toccare ancora la configurazione applicativa:

sudo apt update
sudo apt upgrade -y

Se la macchina è già in produzione, pianifica questi update con finestra e rollback, non come gesto automatico a caldo.

Abilitare HTTPS dopo l’installazione base

Apache su EC2 spesso è solo il primo passo. Appena il sito serve traffico reale, HTTPS passa da “opzione” a requisito. Su Ubuntu puoi usare Certbot con il plugin Apache, ma solo dopo che il DNS punta correttamente all’istanza o al bilanciatore.

sudo apt install -y certbot python3-certbot-apache

Prima di emettere il certificato, controlla che il nome host risolva verso l’IP giusto:

dig +short example.com

Se il DNS non è allineato, Certbot può fallire o validare il dominio sbagliato. In quel caso il fix non è nel server web, ma nel record DNS.

Troubleshooting rapido: i casi più frequenti

Se qualcosa non funziona, conviene seguire la catena dei layer. È il modo più veloce per evitare interventi inutili.

1. DNS: il dominio punta all’IP corretto? Verifica con dig +short dominio.tld.
2. Rete AWS: il security group consente 80/443? Controlla regole in ingresso.
3. Firewall host: UFW blocca la porta? Usa sudo ufw status verbose.
4. Apache: il servizio è attivo? Usa systemctl status apache2.
5. Contenuto: il virtual host e la DocumentRoot sono corretti?

Tre sintomi tipici e lettura rapida:

• Timeout: spesso rete o firewall
• Connection refused: servizio non in ascolto o porta sbagliata
• 403/404: configurazione Apache o path errato

Per leggere i log di Apache su Ubuntu:

sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /var/log/apache2/access.log

Se il log è vuoto ma il servizio risponde male, il problema può stare prima di Apache: proxy, ELB, CDN o regole di rete.

Riassunto operativo per Ubuntu 22.04 e 20.04

La procedura corretta è questa: accesso SSH, aggiornamento pacchetti, installazione di apache2, verifica del servizio, test in locale, apertura della porta nel security group, eventuale UFW, poi personalizzazione del virtual host. Se fai ordine in questo modo, separi nettamente i problemi di sistema da quelli di rete e limiti il tempo perso in diagnosi.

Su 20.04 e 22.04 non cambia il cuore della procedura; cambia soprattutto il contorno operativo: versioni dei pacchetti, eventuali policy interne di hardening e il modo in cui vuoi gestire TLS e reverse proxy. Per un’istanza EC2 nuova, Apache2 è una base solida proprio perché resta prevedibile e facile da verificare con pochi comandi.

Se vuoi un controllo finale asciutto, questi tre comandi ti dicono quasi tutto quello che serve sapere: systemctl status apache2, curl -I http://127.0.0.1/, curl -I http://IP_PUBBLICO/. Se il primo è verde, il secondo risponde e il terzo no, il colpevole è quasi sempre fuori da Apache.