Hai calcolato meticolosamente il costo delle istanze EC2, ottimizzato i tier di storage S3 e messo a punto gli IOPS di RDS. Sembra tutto sotto controllo. Poi, arriva la fattura mensile ed \u00e8 significativamente pi\u00f9 alta del previsto. Scorri l’elenco e trovi il colpevole: una voce di costo dolorosamente alta per il Data Transfer.<\/p>\n\n\n\n
Se questo scenario ti suona familiare, non sei solo. Il Data transfer \u00e8 un costo che molti sottovalutano, spesso trattandolo come un errore di arrotondamento, finch\u00e9 non si trasforma in una spesa considerevole e ricorrente.<\/p>\n\n\n\n
Il problema non \u00e8 solo che spostare dati ha un costo. Capire quando si paga, quanto si paga e perch\u00e9 si paga \u00e8 notoriamente complesso.<\/p>\n\n\n\n
Spostare dati da un’istanza EC2 a un bucket S3 ha un costo?<\/p>\n\n\n\n
E la replica di un database RDS tra Availability Zone per l\u2019HA?<\/p>\n\n\n\n
Cosa succede se del traffico passa attraverso un NAT Gateway?<\/p>\n\n\n\n
Questa mancanza di chiarezza pu\u00f2 portare a “punti ciechi” architetturali, dove una decisione progettuale apparentemente scontata per l’affidabilit\u00e0 o la scalabilit\u00e0 fa silenziosamente lievitare i costi operativi.<\/p>\n\n\n\n
In questo articolo, il primo di una serie dedicata a questo argomento, vogliamo demistificare il data transfer su AWS. Distilleremo la fitta documentazione per mettere in luce i principi fondamentali che \u00e8 davvero necessario conoscere.<\/p>\n\n\n\n
Inizieremo con le regole fondamentali che governano il calcolo dei costi di data transfer, poi mostreremo come si applicano agli scenari reali.<\/p>\n\n\n\n
Impareremo a prevedere, controllare e ottimizzare i costi di data transfer su AWS.<\/p>\n\n\n\n
La pagina dei prezzi di AWS per il trasferimento dati si estende su migliaia di righe e pu\u00f2 sembrare intimidatoria. Il lato positivo \u00e8 che non \u00e8 necessario memorizzarla. Quasi ogni addebito per il trasferimento dati in fattura pu\u00f2 essere compreso ricordando tre criteri fondamentali.<\/p>\n\n\n\n
AWS ha bisogno dei tuoi dati. Rende il pi\u00f9 semplice ed economico possibile spostare i tuoi carichi di lavoro, le tue applicazioni e i tuoi dati nel suo ecosistema.<\/p>\n\n\n\n
Ci\u00f2 significa che non ti verr\u00e0 addebitato alcun costo per i dati trasferiti da Internet ai tuoi servizi AWS.<\/p>\n\n\n\n
Ad esempio, un utente carica un video da 50 MB sulla tua applicazione web in esecuzione su EC2. I dati viaggiano dal suo laptop, tramite Internet, al tuo Application Load Balancer (ALB). Paghi $ 0,00 per quel trasferimento di 50 MB.<\/p>\n\n\n\n
Se stai migrando un database da 2 TB dal tuo data center locale a un’istanza Amazon RDS, pagherai $ 0,00 per quel traffico in ingresso da 2 TB.<\/p>\n\n\n\n
Se i tuoi clienti o dispositivi IoT caricano milioni di piccoli file (registri, foto, ecc.) in un bucket S3, pagherai 0,00 $ per tutti quei dati in arrivo.<\/p>\n\n\n\n
Come ogni buona regola, ci sono alcune eccezioni di nicchia (ad esempio, i dati trasferiti in un Global Accelerator). Ma per il 99% delle architetture standard, questa regola \u00e8 valida: l’ingresso da Internet \u00e8 gratuito.<\/p>\n\n\n\n
Si tratta del costo di cui tutti sono a conoscenza e che solitamente rappresenta la parte pi\u00f9 consistente della voce “Trasferimento dati” nella bolletta.<\/p>\n\n\n\n
Tutti i dati in uscita da un servizio AWS e in transito verso la rete Internet pubblica sono fatturabili. Il costo \u00e8 calcolato per Gigabyte (GB) e varia in base alla regione AWS.<\/p>\n\n\n\n
Ad esempio, se un utente visita il tuo sito web e il tuo server (su EC2 o Fargate) invia una pagina web da 3 MB (HTML, CSS, JS, immagini), pagherai per quei 3 MB di trasferimento dati in uscita. Non dimenticare di moltiplicare questo costo per ogni visitatore o, peggio ancora, per ogni aggiornamento della pagina.<\/p>\n\n\n\n
Se ospiti un whitepaper PDF da 100 MB su S3, ogni volta che un cliente lo scarica direttamente da S3, ti verr\u00e0 addebitato un costo di trasferimento dati in uscita di 100 MB.<\/p>\n\n\n\n
La tua app mobile richiama la tua API backend (su API Gateway + Lambda). L’API restituisce una risposta JSON di 50 KB. Paghi per quel trasferimento di 50 KB.<\/p>\n\n\n\n
AWS \u00e8 generosa e offre un piano gratuito che include 100 GB al mese di trasferimento dati gratuito verso Internet. Questi 100 GB sono aggregati per tutti i servizi e tutte le regioni (ad eccezione di GovCloud e Cina). Per i progetti di piccole dimensioni, questo \u00e8 fantastico. Per qualsiasi applicazione di produzione su larga scala, questo piano gratuito viene in genere consumato entro i primi giorni del mese.<\/p>\n\n\n\n
Questa \u00e8 la categoria con la complessit\u00e0 pi\u00f9 nascosta.<\/p>\n\n\n\n
Per quanto riguarda i dati che non escono mai dalla rete, del traffico tra i vari servizi e le componenti della tua infrastruttura, la risposta \u00e8 sempre “Dipende”, e qui si nasconde la maggior parte dei costi che non ti aspetti.<\/p>\n\n\n\n
Il costo in questi casi dipende interamente dal percorso seguito dai dati. Rimangono nello stesso “data center”? Passano da un data center all’altro? Arrivano in un altro Paese? In termini AWS, ci riferiamo allo spostamento all’interno di un’availability zone (AZ), tra availability zones (inter-AZ) o tra regioni (inter-regione).<\/p>\n\n\n\n
Quasi ogni decisione sui costi del traffico interno si riduce a tre concetti: Availability Zone (AZ), region e routing specifico del servizio (come gli endpoint VPC).<\/p>\n\n\n\n
Si riferisce al traffico tra servizi nella stessa posizione logica.<\/p>\n\n\n\n
Il trasferimento dati tra servizi all’interno della stessa AZ (ad esempio, da un’istanza EC2 in us-east-1a a un’istanza RDS in us-east-1a) utilizzando i loro indirizzi IP privati<\/strong> \u200b\u200b\u00e8 GRATUITO<\/strong>.<\/p>\n\n\n\n Questa regola si applica solo quando si utilizzano IP privati. Se la tua istanza EC2 in us-east-1a comunica con un altro servizio in us-east-1a utilizzando il suo indirizzo IP pubblico o un elastic IP, il traffico deve lasciare la VPC, raggiungere il confine della rete AWS e rientrare (un processo chiamato “hairpinning”).<\/p>\n\n\n\n In questo scenario, ti verr\u00e0 addebitato il costo del data transfer in USCITA.<\/p>\n\n\n\n Si tratta di un errore di configurazione costoso e purtroppo comune.<\/p>\n\n\n\n Questo \u00e8 il “costo nascosto” pi\u00f9 comune ed \u00e8 direttamente collegato alla creazione di applicazioni ad alta disponibilit\u00e0.<\/p>\n\n\n\n Tutto il traffico che attraversa un confine AZ \u00e8 a pagamento. Questo vale anche se i servizi si trovano nella stessa VPC (ad esempio, da una subnet in us-east-1a a una subnet in us-east-1b).<\/p>\n\n\n\n Il costo \u00e8 in genere di $ 0,01 per GB in entrambe le direzioni. Ci\u00f2 significa che inviare 1 GB di dati e ricevere una risposta di 1 GB costa in totale $ 0,02.<\/p>\n\n\n\n Si tratta della tariffa per l’utilizzo della fibra ridondata a banda larga e a bassa latenza di AWS. Quando si gestisce un database Multi-AZ, questo \u00e8 il costo della replica dei dati.<\/p>\n\n\n\n Si tratta di traffico destinato al disaster recovery (DR) o ad applicazioni globali.<\/p>\n\n\n\n Tutti i dati trasferiti da una regione AWS a un’altra sono a pagamento (ad esempio, da eu-west-1 (Irlanda) a eu-central-1 (Francoforte)).<\/p>\n\n\n\n Il costo \u00e8 in genere pi\u00f9 elevato rispetto al traffico Inter-AZ e varia a seconda delle regioni di origine e di destinazione.<\/p>\n\n\n\n A volte il costo non dipende solo da dove si trovano i servizi, ma anche da come sono collegati.<\/p>\n\n\n\n 1. Peering VPC: quando si collegano due VPC:<\/p>\n\n\n\n 2. NAT Gateway: questa \u00e8 una trappola di costi importante.<\/p>\n\n\n\n Il problema: un’istanza EC2 in una subnet privata deve accedere a S3 (che \u00e8 un servizio regionale, ma il cui punto di accesso \u00e8 pubblico). Senza un endpoint VPC, il traffico viene instradato verso il gateway NAT.<\/p>\n\n\n\n Si pagano due commissioni:<\/p>\n\n\n\n La tariffa Inter-AZ se il tuo NAT Gateway si trova in un AZ diverso (come dovrebbe essere per HA!).<\/p>\n\n\n\n Commissione per l’elaborazione dei dati del gateway NAT.<\/p>\n\n\n\n Questo traffico non \u00e8 “Dati in uscita verso Internet” perch\u00e9 S3 si trova sulla rete AWS, ma spesso \u00e8 pi\u00f9 costoso!<\/p>\n\n\n\n 3. VPC Gateway endpoints (S3 e DynamoDB)<\/p>\n\n\n\n Puoi creare un Gateway Endpoint per S3 nella tua VPC; In questo modo si crea un percorso diretto e privato dalla VPC a S3.<\/p>\n\n\n\n Tutto il traffico dalle tue istanze (in qualsiasi AZ in quella regione) a S3 tramite questo endpoint \u00e8 GRATUITO.<\/p>\n\n\n\n Si tratta di una buona pratica non negoziabile per l’ottimizzazione dei costi.<\/p>\n\n\n\n Bene, ora che abbiamo capito le regole e abbiamo visto perch\u00e9 ci viene addebitato un costo, passiamo alla parte interessante: come ottimizzare la bolletta.<\/p>\n\n\n\n 1. Adotta Amazon CloudFront (il tuo CDN Shield)<\/strong><\/p>\n\n\n\n Questa \u00e8 la prima e migliore difesa contro un costo esagerato per il traffico verso internet.<\/p>\n\n\n\n Pensaci. Ogni volta che un utente, da qualche parte nel mondo, scarica un’immagine, un video, un PDF o anche solo il bundle JavaScript principale per la tua app web, stai pagando un prezzo premium per i dati che escono dalla tua istanza EC2, ALB o bucket S3.<\/p>\n\n\n\n La soluzione? Smetti di servire direttamente gli asset statici. Usa Amazon CloudFront, la CDN di AWS, come cache per la tua applicazione.<\/p>\n\n\n\n Ottieni 3 principali vantaggi:<\/p>\n\n\n\n Tariffe pi\u00f9 convenienti: il prezzo per GB dei dati serviti da CloudFront \u00e8 semplicemente… pi\u00f9 economico. Spesso \u00e8 fino al 40% pi\u00f9 economico rispetto al servizio dello stesso file direttamente da EC2.<\/p>\n\n\n\n Un free tier pi\u00f9 che generoso: CloudFront offre un free tier separato e incredibilmente generoso: 1 TB di dati in uscita al mese, completamente separato dai 100 GB del livello gratuito generico. Per molte applicazioni, rappresenta sicuramente una svolta.<\/p>\n\n\n\n Inoltre, il traffico dalla tua “origine” (il tuo bucket S3 o ALB) alla rete CloudFront per memorizzare nella cache quel file \u00e8 completamente gratuito.<\/p>\n\n\n\n 2. Gestisci gli endpoint VPC (evita il NAT Gateway per raggiungere i servizi AWS)<\/strong><\/p>\n\n\n\n Ricordate la nostra istanza EC2 in una subnet privata? Non ha un percorso diretto verso Internet, ma deve comunque comunicare con servizi AWS come S3 per scaricare un file o DynamoDB per scrivere dati. Di default, come fa? Instrada il traffico verso il NAT Gateway (che si trova in una subnet pubblica), che a sua volta lo invia a S3.<\/p>\n\n\n\n Ma in questo scenario si cade in trappola e si finisce per pagare un prezzo premium per quel traffico.<\/p>\n\n\n\n La soluzione \u00e8 creare un VPC Gateway Endpoint per S3 e DynamoDB.<\/p>\n\n\n\n L’endpoint in s\u00e9 \u00e8 gratuito. E tutti i dati che lo attraversano sono gratuiti. In questo modo si bypassa completamente il NAT Gateway e tutti i costi associati a quel traffico.<\/p>\n\n\n\n Nota<\/strong>: Stiamo parlando di endpoint Gateway. Il traffico che attraversa gli endpoint interface \u00e8 a pagamento<\/strong>; tuttavia \u00e8 comunque meno costoso del traffico che transita nel NAT Gateway.<\/p>\n\n\n\n 3. Progettare con “Consapevolezza delle AZ”<\/strong><\/p>\n\n\n\n Ogni gigabyte che attraversa i confini di un’AZ (Inter-AZ) costa 0,01 $ in ciascuna direzione.<\/p>\n\n\n\n Questo \u00e8 il “costo della resilienza” e, per cose come l\u2019alta affidabilit\u00e0 dei DB, \u00e8 un costo che dovremmo essere felici di pagare.<\/p>\n\n\n\n Il problema \u00e8 il traffico cross-AZ non necessario, spesso proveniente da applicazioni molto “chiacchierone” che comunicano costantemente tra loro.<\/p>\n\n\n\n Anche se la pagina dei prezzi di AWS potrebbe sembrare un codice indecifrabile, la realt\u00e0 \u00e8 che quasi ogni addebito sulla tua fattura si riduce ad alcuni semplici principi.<\/p>\n\n\n\n Riassumiamo ancora una volta le tre regole d’oro:<\/p>\n\n\n\n Semplicemente ricordando queste regole, puoi iniziare a “vedere” i costi di trasferimento dati prima ancora di scrivere una riga di codice. Puoi capire che un’istanza RDS Multi-AZ non costa solo per la CPU e lo storage, ma anche per la replica (e in caso di grandi volumi di dati, il costo della replica non \u00e8 trascurabile). Puoi riconoscere che servire un’immagine da 1 MB da EC2 costa, mentre servirla da CloudFront \u00e8 praticamente gratuito.<\/p>\n\n\n\n Ottimizzare la fattura AWS non significa solo disattivare alcune funzionalit\u00e0. Si tratta di creare architetture pi\u00f9 intelligenti ed efficienti. Utilizzare strumenti come CloudFront e i VPC Endpoints non \u00e8 solo una best practice per migliorare le prestazioni o la sicurezza; \u00e8 una delle leve pi\u00f9 efficaci per il controllo dei costi.<\/p>\n\n\n\n Abbiamo trattato i fondamenti e le nozioni fondamentali del trasferimento dati AWS. Ora hai le conoscenze necessarie per analizzare il 90% dei costi di data transfer, e per ottimizzarli.<\/p>\n\n\n\n Ma che dire di quell’ultimo 10%? E di scenari ibridi pi\u00f9 complessi?<\/p>\n\n\n\n Nel nostro prossimo articolo approfondiremo gli argomenti avanzati.<\/p>\n\n\n\n Rimani sintonizzato!<\/p>\n\n\n\nScenario B: stessa regione, diverse availability zones (Inter-AZ)<\/h5>\n\n\n\n
Scenario C: Regioni diverse (inter region)<\/h5>\n\n\n\n
Eccezioni e casi particolari<\/h4>\n\n\n\n
\n
Le soluzioni rapide per ridurre i costi di trasferimento dati<\/h2>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n
\n
\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n