Pilastri dell'ottimizzazione dei costi e della sostenibilità

Il pilastro Ottimizzazione dei costi si concentra sull'eliminazione dei costi non necessari e sull'ottenimento del massimo valore dalla spesa AWS. Spesso è il pilastro con l'impatto più immediato, perché nel cloud è facile effettuare un provisioning eccessivo delle risorse. Principi di progettazione fondamentali: implementare la gestione finanziaria del cloud — trattare i costi come una metrica di primaria importanza. Adottare un modello basato sul consumo — pagare solo ciò che si utilizza. Misurare l'efficienza complessiva — monitorare il costo per unità di valore aziendale. Ridurre la spesa per attività operative indifferenziate e impegnative — utilizzare servizi gestiti invece di gestire l'infrastruttura.

Il dimensionamento corretto è l'azione di ottimizzazione dei costi più incisiva: consiste nell'identificare ed eliminare le risorse sovradimensionate. Un caso comune consiste nell'avviare istanze di grandi dimensioni durante il provisioning iniziale e non verificarle più in seguito. AWS Compute Optimizer analizza le metriche di utilizzo e consiglia il tipo di istanza ottimale. Un risultato tipico: un'istanza m5.4xlarge con un utilizzo della CPU del 5% dovrebbe essere sostituita da una t3.medium, con un risparmio dell'80% sui costi di calcolo. Il dimensionamento corretto si applica a EC2, Lambda (memoria), RDS e ai volumi EBS.

Per i carichi di lavoro stabili, i costi On-Demand sono l'opzione più costosa. È possibile ottenere risparmi significativi tramite: Reserved Instances (1 o 3 anni): fino al 72% di risparmio per i carichi di lavoro prevedibili. Savings Plans: impegno flessibile (fino al 66% di risparmio) applicabile a diverse famiglie di istanze e regioni. Spot Instances: fino al 90% di risparmio per i carichi di lavoro interrompibili (elaborazioni batch, CI/CD, applicazioni stateless). In genere, un parco risorse ottimizzato per i costi combina tutte e tre le opzioni: Savings Plans per il carico di base, Spot per i picchi e On-Demand per i casi particolari.

Le Spot Instances utilizzano la capacità AWS inutilizzata con uno sconto fino al 90%, ma possono essere interrotte con un preavviso di 2 minuti quando AWS deve recuperare tale capacità. Spot è adatto per: elaborazioni batch (con checkpoint e ripresa), agenti di build CI/CD, server web stateless (dietro un ALB; ELB instrada il traffico evitando le istanze interrotte) e nodi worker EMR ed EKS. Utilizzi Spot Fleet oppure un ASG con più tipi di istanza e AZ per distribuire le risorse tra più pool e ridurre il rischio di interruzione.

I costi dello storage S3 possono essere ridotti drasticamente utilizzando la classe di storage corretta e automatizzando le transizioni. S3 Intelligent-Tiering sposta automaticamente gli oggetti tra i livelli di accesso in base ai modelli di accesso, risultando ideale quando questi ultimi non sono noti. Le regole del ciclo di vita trasferiscono gli oggetti secondo una pianificazione: da Standard → Standard-IA dopo 30 giorni → Glacier dopo 90 giorni → Deep Archive dopo 180 giorni. Valuti anche S3 Select per recuperare solo il sottoinsieme necessario dei dati dell'oggetto, riducendo i costi di trasferimento ed elaborazione dei dati.

Senza un sistema di tag appropriato, è impossibile capire quanto spende ogni team o progetto. I Cost Allocation Tags consentono di suddividere i costi per team, progetto, ambiente o qualsiasi altra dimensione definita. Attivi i tag nella console Billing, quindi utilizzi AWS Cost Explorer per filtrare e raggruppare i costi in base ai tag. Imponga l'uso dei tag con le Tag Policies in AWS Organizations e utilizzi le regole AWS Config per rilevare le risorse prive di tag. In questo modo è possibile fornire showback (visibilità) e chargeback (attribuzione dei costi) ai singoli team.

Il pilastro della Sustainability (aggiunto nel 2021) si concentra sulla riduzione al minimo dell'impatto ambientale dei carichi di lavoro cloud, diminuendo il consumo energetico e aumentando l'efficienza. Principi di progettazione: Comprendere il proprio impatto: misurare l'impronta di carbonio dei carichi di lavoro. Stabilire obiettivi di sostenibilità. Massimizzare l'utilizzo: eseguire il dimensionamento corretto per evitare risorse inattive. Prevedere e adottare hardware più efficiente: utilizzare le generazioni più recenti di istanze. Utilizzare servizi gestiti: AWS gestisce i data center in modo più efficiente rispetto alla maggior parte delle organizzazioni.

I processori AWS Graviton (basati su ARM) offrono un'efficienza energetica superiore del 60% e un rapporto prezzo/prestazioni superiore del 20-40% rispetto alle istanze x86. Le istanze Graviton3/4 (famiglie c7g, m7g, r7g, t4g) sono disponibili per la maggior parte dei carichi di lavoro EC2, Lambda e Fargate. Il passaggio da x86 a Graviton migliora simultaneamente i pilastri Sustainability e Cost Optimisation: sono necessari meno watt per ogni calcolo e i prezzi delle istanze sono inferiori. La maggior parte dei carichi di lavoro (Linux, applicazioni containerizzate, JVM) può essere migrata con modifiche minime.

Una delle principali fonti di costi ed energia sprecati sono le risorse inattive: istanze EC2 con un utilizzo della CPU dell'1%, volumi EBS non collegati, indirizzi IP elastici inutilizzati e ambienti di sviluppo/test dimenticati e in esecuzione 24 ore su 24, 7 giorni su 7. Implementi una pianificazione di arresto/avvio per gli ambienti non di produzione utilizzando le regole EventBridge e Systems Manager Automation: arresti le istanze di sviluppo alle 18:00 e le avvii alle 8:00. Utilizzi AWS Trusted Advisor e Cost Explorer per identificare istanze inattive, volumi EBS inutilizzati e Reserved Instances sottoutilizzate.

Conservare i dati indefinitamente comporta uno spreco di energia. Il pilastro della Sustainability consiglia di implementare policy del ciclo di vita dei dati per eliminare o archiviare automaticamente i dati non più necessari. Utilizzi le regole S3 Lifecycle con date di scadenza per eliminare gli oggetti dopo un determinato periodo di conservazione. Utilizzi DynamoDB TTL per far scadere automaticamente i record obsoleti. Utilizzi le policy di conservazione di CloudWatch Logs per eliminare i gruppi di log dopo un periodo definito. L'eliminazione dei dati non necessari riduce sia i costi di storage sia l'energia necessaria per conservarli e raffreddarli.

L'ottimizzazione dei costi a volte entra in conflitto con altri pilastri. Multi-AZ RDS raddoppia i costi del database, ma è necessario per il pilastro Reliability. La replica tra regioni migliora l'affidabilità, ma aumenta i costi di storage e trasferimento. Un'architettura active-active multi-region riduce la latenza (Performance Efficiency), ma costa da 2 a 3 volte di più. Il Well-Architected Framework non afferma che si debba sempre scegliere l'opzione più economica: richiede di valutare consapevolmente i compromessi tra i pilastri e documentare le motivazioni. L'esame verifica la capacità di selezionare la soluzione più conveniente che soddisfi comunque i requisiti indicati.

In questa lezione ha appreso che: Cost Optimisation combina il dimensionamento corretto, i modelli di acquisto (Reserved/Savings Plans/Spot) e la gestione del ciclo di vita di S3; Sustainability si concentra sulla massimizzazione dell'utilizzo, sull'uso delle istanze Graviton e sull'implementazione di policy del ciclo di vita dei dati; inoltre, i compromessi sui costi con gli altri pilastri devono essere valutati consapevolmente in base ai requisiti aziendali. I tag dei costi consentono di fornire showback e chargeback tra i team. Ora esamineremo il Well-Architected Tool e il processo di revisione.