Scenari di alte prestazioni e ottimizzazione dei costi

Scenario: Il database RDS MySQL di un sito di notizie gestisce il 90% di traffico in lettura per contenuti degli articoli che cambiano al massimo una volta all'ora. La CPU del database ha un utilizzo medio dell'80%, i costi stanno aumentando e la latenza per query è di 200ms. Soluzione: Aggiungere un cluster ElastiCache Redis davanti a RDS utilizzando il pattern lazy loading (cache-aside). L'applicazione controlla prima la cache: in caso di cache hit, restituisce l'articolo memorizzato in meno di 1ms. In caso di cache miss, interroga RDS, restituisce il risultato e lo scrive nella cache con un TTL di 1 ora. Risultato previsto: cache hit rate del 90%, CPU di RDS inferiore al 20% e latenza inferiore a 5ms per le risposte memorizzate nella cache.

Scenario: Gli utenti dell'area Asia-Pacifico attendono 2-4 secondi per il caricamento di un'applicazione web ospitata su EC2 in us-east-1. L'applicazione distribuisce risorse statiche di grandi dimensioni, come immagini, JS e CSS. Soluzione: Posizionare una distribuzione CloudFront davanti all'ALB. Configurare un comportamento di caching per il percorso /static/* con un TTL lungo, ad esempio 1 settimana, in modo che i file statici vengano memorizzati nelle edge location CloudFront vicine agli utenti asiatici. Le richieste API dinamiche ignorano la cache con TTL=0. Gli utenti asiatici caricano le risorse statiche da un'edge location di Singapore o Tokyo in meno di 100ms, invece di attendere i round trip verso us-east-1.

Scenario: Un'azienda dispone di 500 istanze EC2, molte delle quali sono state configurate 3 anni fa con tipi di istanza sovradimensionati. La fattura AWS è elevata, ma l'azienda non sa quali istanze siano sovradimensionate. Soluzione: Abilitare AWS Compute Optimizer, che è gratuito e utilizza 14 giorni di metriche CloudWatch. Compute Optimizer analizza l'utilizzo effettivo di CPU, memoria, rete e disco di ogni istanza e fornisce consigli per il dimensionamento corretto. Per una t3.xlarge con un utilizzo medio della CPU dell'8% verrebbe consigliato il ridimensionamento a t3.small. Applicando i consigli a tutte le 500 istanze, in genere i costi EC2 si riducono del 20–40%.

Scenario: Un'azienda di genomica esegue processi batch notturni che durano 8 ore e possono essere ripetuti se interrotti. Il costo EC2 On-Demand per questi processi è di 10.000 $ al mese. Soluzione: Utilizzare EC2 Spot Instances per il parco dedicato all'elaborazione batch. Le Spot Instances utilizzano capacità EC2 inutilizzata disponibile con uno sconto fino al 90%. Per i processi batch tolleranti alle interruzioni, utilizzare AWS Batch, che accoda nuovamente automaticamente i processi Spot non riusciti e utilizza un parco misto, composto da Spot e da un fallback On-Demand minimo. Risparmio previsto: riduzione del 70–90% dei costi di calcolo, da 10.000 $ a 1.000–3.000 $ al mese.

Scenario: Una classifica di gioco utilizza DynamoDB con throughput assegnato. Durante il lancio dei giochi, il traffico aumenta di 50 volte e la tabella limita le richieste. Al di fuori dei lanci, il throughput è quasi nullo e la capacità assegnata viene sprecata. Soluzione: Passare DynamoDB alla modalità di capacità On-Demand. On-Demand si adatta istantaneamente a qualsiasi throughput senza pianificazione manuale della capacità e addebita i costi per richiesta anziché per unità assegnata. Si paga solo per le richieste effettuate, senza costi per capacità inutilizzata tra un lancio e l'altro. On-Demand comporta un costo per richiesta leggermente superiore, ma garantisce l'assenza di throttling e nessuna gestione della capacità.

Scenario: Un'azienda archivia milioni di immagini generate dagli utenti in S3 Standard. I modelli di accesso sono imprevedibili: alcune immagini vengono consultate ogni giorno, altre non vengono consultate per mesi. L'azienda vuole ridurre i costi di archiviazione senza gestire manualmente le policy del ciclo di vita. Soluzione: utilizzare S3 Intelligent-Tiering. Il servizio sposta automaticamente gli oggetti tra i diversi tier in base ai modelli di accesso: Frequent Access (Standard), Infrequent Access (nessun accesso da almeno 30 giorni), Archive Instant Access (90+ giorni) e Archive Access (90+ giorni, con attivazione esplicita). Intelligent-Tiering non applica costi di recupero. Il costo di monitoraggio è di 0,0025 $ per 1.000 oggetti al mese, trascurabile per dataset di grandi dimensioni.

Scenario: Una startup vuole eseguire query sulle tabelle di un data lake S3. Esegue circa 10 query ad hoc alla settimana. Un fornitore propone Amazon Redshift con un cluster dc2.large. Soluzione per una startup: iniziare con Amazon Athena: nessun costo per l'infrastruttura e pagamento solo dei dati analizzati (circa 5 $/TB). 10 query alla settimana su dati Parquet ben partizionati potrebbero costare meno di 5 $ al mese. Redshift dc2.large costa circa 180 $ al mese in modo continuativo. Redshift diventa conveniente solo quando la concorrenza delle query è elevata (50+ query al giorno) oppure è richiesta una risposta in meno di un secondo. La parola chiave «ad hoc, infrequenti» indica chiaramente Athena.

Scenario: Un server di database relazionale richiede 64.000 IOPS con latenza ridotta e costante. Il volume EBS gp3 attuale sta raggiungendo il proprio limite di IOPS. Soluzione: eseguire l'upgrade a io2 Block Express (tipo di volume EBS progettato per database con carichi I/O intensivi). io2 Block Express supporta fino a 256.000 IOPS per volume e una latenza inferiore al millisecondo. È più costoso di gp3 (0,125 $/GB + 0,065 $/IOPS provisioned al mese), ma è l'unica opzione EBS che soddisfa requisiti di almeno 64.000 IOPS. Per i carichi di lavoro dei database in cui la latenza è critica e il limite di 16.000 IOPS di gp3 non è sufficiente, io2 è l'unica scelta EBS praticabile.

Scenario: Un'azienda esegue continuamente 20 istanze EC2 r6i.4xlarge per un'applicazione di produzione e prevede che i requisiti rimangano invariati per 3 anni. Il costo attuale On-Demand per queste istanze è di 80.000 $ all'anno. Soluzione: acquistare Standard Reserved Instances di 3 anni (oppure Compute Savings Plans) con pagamento All Upfront per ottenere lo sconto massimo. Le Standard Reserved Instances offrono uno sconto fino al 72% rispetto a On-Demand. Le istanze sono in esecuzione 24 ore su 24, 7 giorni su 7, con un carico di lavoro prevedibile: il profilo tipico per le Reserved Instances. Riduzione dei costi prevista: 80.000 $ × 0,72 = 22.400 $ all'anno rispetto agli 80.000 $ all'anno di On-Demand, con un risparmio di 57.600 $ all'anno.

Scenario: Un'azienda esegue una REST API su un'istanza EC2 t3.micro che costa 8 $ al mese. L'API riceve 1 milione di richieste al mese, ognuna con un tempo di elaborazione di 100 ms. Il team chiede se Lambda sarebbe più economico. Analisi: costo di Lambda: 1.000.000 di richieste × 0,0000002 $ = 0,20 $ (costo delle richieste) + 1.000.000 × 0,1 s × 128 MB di memoria × tariffa = circa 1,67 $ (costo di calcolo) = circa 1,87 $ al mese. Lambda è più economico di EC2 per questa API a basso traffico. Quando il traffico supera circa 40 milioni di richieste al mese, EC2 diventa più conveniente. Utilizzare il Lambda Cost Calculator per trovare il punto di pareggio per ogni carico di lavoro.

Scenario: Un'API globale che serve utenti in Europa, negli Stati Uniti e in Asia presenta una latenza incoerente perché il traffico attraversa percorsi Internet imprevedibili. È stato preso in considerazione CloudFront, ma le risposte dell'API sono dinamiche e non possono essere memorizzate nella cache. Soluzione: utilizzare AWS Global Accelerator. Il servizio fornisce globalmente due anycast IP addresses statici. Il traffico degli utenti entra nel backbone globale AWS dalla AWS edge location più vicina e viaggia sulla rete privata AWS fino all'origine nella Regione di destinazione, evitando il tratto centrale congestionato della rete Internet pubblica. Global Accelerator migliora del 20-60% i tempi di risposta delle API dinamiche e fornisce un failover immediato quando un endpoint regionale non è integro.

Verifichi la Sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha affrontato scenari riguardanti: il lazy loading di ElastiCache per ridurre l'utilizzo della CPU di RDS dall'80% al 20%, Spot Instances e AWS Batch per risparmiare il 70-90% sui costi dei job batch, Athena per query ad hoc poco frequenti rispetto a Redshift per analisi ad alta concorrenza e S3 Intelligent-Tiering per modelli di accesso imprevedibili senza costi di recupero. Il prossimo argomento è il capstone finale: un mini esame a tempo con domande miste per valutare la Sua preparazione.