La piattaforma usava un grande server EC2 sempre acceso, un database RDS più potente del necessario e rilasci manuali. Ho containerizzato l’applicazione e l’ho distribuita su ECS Fargate, il servizio AWS che esegue i container senza dover gestire server.
L'applicazione girava su un grande server EC2 sempre attivo. Anche il database RDS era dimensionato oltre il carico reale. La capacità era fissa, i costi pure, e non esisteva una vera strategia per crescere o ridursi in base al traffico.
Ridurre semplicemente la macchina avrebbe abbassato la fattura, ma tutto sarebbe rimasto legato a un solo server, con deploy manuali e nessuna capacità di reagire automaticamente ai cambi di carico.
Ho containerizzato l'applicazione e l'ho spostata su ECS Fargate. Le sue istanze (i task) girano in più zone del data center AWS, dietro un bilanciatore di carico che ne controlla la salute e sostituisce automaticamente quelle che non rispondono.
L'autoscaling aumenta o riduce il numero di task in base all'uso reale di CPU e memoria. Ho ridimensionato RDS sul carico effettivo, eliminando capacità che veniva pagata senza essere usata.
Ho spostato i file statici su S3 e li distribuisco con CloudFront, la rete che li consegna dal punto più vicino all'utente. Il load balancer resta responsabile del traffico dell'applicazione, mentre CDN e storage servono i contenuti statici e alleggeriscono i server.
GitHub Actions compila l'applicazione, costruisce e pubblica l'immagine container e aggiorna il servizio ECS. Il deploy non dipende più da operazioni manuali sulla macchina di produzione.
Il confronto tra fatture AWS comparabili ha mostrato una riduzione del 20%. L'applicazione non dipende più da una singola istanza e i deploy sono automatizzati.
Riduzione del 20% verificata confrontando le fatture.
Task distribuiti su più Availability Zone dietro ALB.
Numero di task regolato in base a CPU e memoria.
Build dell'immagine e aggiornamento ECS tramite GitHub Actions.
Posso analizzare spesa, carico, disponibilità e processo di deploy.