Un ambiente AWS ereditato, rimesso in ordine.
Lo stesso portale di bandi che abbiamo reso leggibile dagli assistenti AI aveva un ambiente AWS ereditato da un fornitore precedente. Ne abbiamo preso in carico la gestione sistemistica.
Abbiamo preso in carico la gestione sistemistica dell'ambiente AWS di un portale di bandi e finanziamenti: più istanze EC2 tra Irlanda e Milano e un database Amazon RDS MySQL. Abbiamo tolto gli accessi del fornitore precedente, reso i server Debian gestibili dalla console senza esporre SSH, recuperato un server di staging che non si avviava e analizzato la bolletta, individuando risparmi per circa il 30%. Il sito pubblico è passato su un server Laravel Forge a Milano, dietro Cloudflare.
Contesto
Il portale raccoglie bandi e opportunità di finanziamento per le imprese. Il sito era già stato semplificato e reso leggibile dagli agenti AI; l'infrastruttura sotto era invece quella lasciata dal fornitore precedente: istanze EC2 in due regioni, Irlanda e Milano, un database Amazon RDS MySQL e regole di accesso da rivedere.
Il problema
Un ambiente ereditato si conosce un pezzo alla volta. Nei Security Group c'erano ancora le regole di accesso del fornitore precedente. Un server di staging è rimasto irraggiungibile per circa tre giorni, con i certificati dei suoi siti scaduti. E la bolletta conteneva voci che nessuno guardava più, a partire dall'Extended Support di MySQL 5.7.
Cosa abbiamo fatto
- 01
Accessi da zero
Rimosse dai Security Group le regole del fornitore precedente. Agente SSM e ruoli IAM installati sui server Debian, che ora si gestiscono dalla console AWS senza esporre SSH.
- 02
Il server che non si avviava
Con il supporto AWS abbiamo trovato la causa nel log di avvio: una voce errata in fstab bloccava il boot. Il disco è stato montato su un'istanza di soccorso, corretto e rimesso al suo posto.
- 03
La bolletta, voce per voce
Risparmi individuati per circa il 30% della spesa mensile: soprattutto l'Extended Support di MySQL 5.7, che si elimina con l'aggiornamento a 8.0, e lo storage RDS da io1 a gp3. Poi IPv4 pubblici inutilizzati, EBS da gp2 a gp3, ciclo di vita degli snapshot.
- 04
Il database alla sua taglia
L'istanza RDS di Milano, su MySQL 8.0, aveva una CPU media intorno all'1,5%: l'abbiamo ridotta di una taglia, da m5.xlarge a m5.large, e abbiamo tolto il Multi-AZ.
- 05
phpMyAdmin chiuso
phpMyAdmin collegato a RDS con autenticazione a cookie, raggiungibile solo dall'IP della VPN aziendale, con HTTP Basic Auth come protezione di riserva.
- 06
Il sito pubblico su Forge
Il sito pubblico è passato su un server Laravel Forge a Milano, dietro il proxy di Cloudflare, con certificato Let's Encrypt sull'origine.
Com'è andata
L'ambiente ha un solo gestore, accessi che si possono spiegare uno per uno e un database dimensionato sul carico reale. Le altre voci di risparmio sono individuate e si affrontano una alla volta, a partire dall'aggiornamento di MySQL.
Strumenti
Domande frequenti
Perché SSM invece di SSH?
Con Session Manager si entra nei server dalla console AWS, con permessi IAM e sessioni registrate, senza tenere aperta la porta SSH verso internet.
Togliere il Multi-AZ non è rischioso?
Il Multi-AZ tiene una copia pronta in un'altra zona e fa pagare un'istanza in più. Con un carico medio dell'1,5%, per questo database il costo non era giustificato; i backup di RDS restano attivi.
Cos'è l'Extended Support di MySQL 5.7?
Quando una versione di MySQL esce dal supporto standard, AWS continua a farla girare su RDS ma la fa pagare a parte. Aggiornare a 8.0 toglie quel costo e riporta il database su una versione supportata.