Guida ai costi di Data Transfer su AWS in pillole

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 è significativamente più alta del previsto. Scorri l'elenco e trovi il colpevole: una voce di costo dolorosamente alta per il Data Transfer.

Se questo scenario ti suona familiare, non sei solo. Il Data transfer è un costo che molti sottovalutano, spesso trattandolo come un errore di arrotondamento, finché non si trasforma in una spesa considerevole e ricorrente.

Il problema non è solo che spostare dati ha un costo. Capire quando si paga, quanto si paga e perché si paga è notoriamente complesso.

Spostare dati da un'istanza EC2 a un bucket S3 ha un costo?

E la replica di un database RDS tra Availability Zone per l’HA?

Cosa succede se del traffico passa attraverso un NAT Gateway?

Questa mancanza di chiarezza può portare a "punti ciechi" architetturali, dove una decisione progettuale apparentemente scontata per l'affidabilità o la scalabilità fa silenziosamente lievitare i costi operativi.

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 è davvero necessario conoscere.

Inizieremo con le regole fondamentali che governano il calcolo dei costi di data transfer, poi mostreremo come si applicano agli scenari reali.

Impareremo a prevedere, controllare e ottimizzare i costi di data transfer su AWS.

Le tre regole d'oro del trasferimento dei dati

La pagina dei prezzi di AWS per il trasferimento dati si estende su migliaia di righe e può sembrare intimidatoria. Il lato positivo è che non è necessario memorizzarla. Quasi ogni addebito per il trasferimento dati in fattura può essere compreso ricordando tre criteri fondamentali.

I dati in Ingresso sono (quasi) sempre GRATUITI

AWS ha bisogno dei tuoi dati. Rende il più semplice ed economico possibile spostare i tuoi carichi di lavoro, le tue applicazioni e i tuoi dati nel suo ecosistema.

Ciò significa che non ti verrà addebitato alcun costo per i dati trasferiti da Internet ai tuoi servizi AWS.

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.

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.

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.

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 è valida: l'ingresso da Internet è gratuito.

I dati in uscita verso Internet sono (quasi) sempre a PAGAMENTO

Si tratta del costo di cui tutti sono a conoscenza e che solitamente rappresenta la parte più consistente della voce "Trasferimento dati" nella bolletta.

Tutti i dati in uscita da un servizio AWS e in transito verso la rete Internet pubblica sono fatturabili. Il costo è calcolato per Gigabyte (GB) e varia in base alla regione AWS.

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.

Se ospiti un whitepaper PDF da 100 MB su S3, ogni volta che un cliente lo scarica direttamente da S3, ti verrà addebitato un costo di trasferimento dati in uscita di 100 MB.

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.

AWS è 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 è fantastico. Per qualsiasi applicazione di produzione su larga scala, questo piano gratuito viene in genere consumato entro i primi giorni del mese.

Trasferimento dati all'interno di AWS (o tra servizi AWS)... Dipende

Questa è la categoria con la complessità più nascosta.

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 è sempre "Dipende", e qui si nasconde la maggior parte dei costi che non ti aspetti.

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).

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).

Scenario A: stessa regione, stessa availability zone (intra-AZ)

Si riferisce al traffico tra servizi nella stessa posizione logica.

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 ​​è GRATUITO.

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").

In questo scenario, ti verrà addebitato il costo del data transfer in USCITA.

Si tratta di un errore di configurazione costoso e purtroppo comune.

Scenario B: stessa regione, diverse availability zones (Inter-AZ)

Questo è il "costo nascosto" più comune ed è direttamente collegato alla creazione di applicazioni ad alta disponibilità.

Tutto il traffico che attraversa un confine AZ è 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).

Il costo è in genere di $ 0,01 per GB in entrambe le direzioni. Ciò significa che inviare 1 GB di dati e ricevere una risposta di 1 GB costa in totale $ 0,02.

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 è il costo della replica dei dati.

Scenario C: Regioni diverse (inter region)

Si tratta di traffico destinato al disaster recovery (DR) o ad applicazioni globali.

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)).

Il costo è in genere più elevato rispetto al traffico Inter-AZ e varia a seconda delle regioni di origine e di destinazione.

Eccezioni e casi particolari

A volte il costo non dipende solo da dove si trovano i servizi, ma anche da come sono collegati.

1. Peering VPC: quando si collegano due VPC:

• Se le VPC si trovano nella stessa AZ, il traffico è GRATUITO.
• Se le VPC si trovano in AZ diverse (ma nella stessa regione), si paga la tariffa Inter-AZ.
• Se le VPC si trovano in regioni diverse, si paga la tariffa interregionale.

2. NAT Gateway: questa è una trappola di costi importante.

Il problema: un'istanza EC2 in una subnet privata deve accedere a S3 (che è un servizio regionale, ma il cui punto di accesso è pubblico). Senza un endpoint VPC, il traffico viene instradato verso il gateway NAT.

Si pagano due commissioni:

La tariffa Inter-AZ se il tuo NAT Gateway si trova in un AZ diverso (come dovrebbe essere per HA!).

Commissione per l'elaborazione dei dati del gateway NAT.

Questo traffico non è "Dati in uscita verso Internet" perché S3 si trova sulla rete AWS, ma spesso è più costoso!

3. VPC Gateway endpoints (S3 e DynamoDB)

Puoi creare un Gateway Endpoint per S3 nella tua VPC; In questo modo si crea un percorso diretto e privato dalla VPC a S3.

Tutto il traffico dalle tue istanze (in qualsiasi AZ in quella regione) a S3 tramite questo endpoint è GRATUITO.

Si tratta di una buona pratica non negoziabile per l'ottimizzazione dei costi.

Le soluzioni rapide per ridurre i costi di trasferimento dati

Bene, ora che abbiamo capito le regole e abbiamo visto perché ci viene addebitato un costo, passiamo alla parte interessante: come ottimizzare la bolletta.

1. Adotta Amazon CloudFront (il tuo CDN Shield)

Questa è la prima e migliore difesa contro un costo esagerato per il traffico verso internet.

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.

La soluzione? Smetti di servire direttamente gli asset statici. Usa Amazon CloudFront, la CDN di AWS, come cache per la tua applicazione.

Ottieni 3 principali vantaggi:

Tariffe più convenienti: il prezzo per GB dei dati serviti da CloudFront è semplicemente... più economico. Spesso è fino al 40% più economico rispetto al servizio dello stesso file direttamente da EC2.

Un free tier più 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.

Inoltre, il traffico dalla tua "origine" (il tuo bucket S3 o ALB) alla rete CloudFront per memorizzare nella cache quel file è completamente gratuito.

2. Gestisci gli endpoint VPC (evita il NAT Gateway per raggiungere i servizi AWS)

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.

Ma in questo scenario si cade in trappola e si finisce per pagare un prezzo premium per quel traffico.

La soluzione è creare un  VPC Gateway Endpoint per S3 e DynamoDB.

L'endpoint in sé è 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.

Nota: Stiamo parlando di endpoint Gateway. Il traffico che attraversa gli endpoint interface è a pagamento; tuttavia è comunque meno costoso del traffico che transita nel NAT Gateway.

3. Progettare con "Consapevolezza delle AZ"

Ogni gigabyte che attraversa i confini di un'AZ (Inter-AZ) costa 0,01 $ in ciascuna direzione.

Questo è il "costo della resilienza" e, per cose come l’alta affidabilità dei DB, è un costo che dovremmo essere felici di pagare.

Il problema è il traffico cross-AZ non necessario, spesso proveniente da applicazioni molto "chiacchierone" che comunicano costantemente tra loro.

Conclusioni

Anche se la pagina dei prezzi di AWS potrebbe sembrare un codice indecifrabile, la realtà è che quasi ogni addebito sulla tua fattura si riduce ad alcuni semplici principi.

Riassumiamo ancora una volta le tre regole d'oro:

• I dati IN INGRESSO da Internet sono (quasi sempre) GRATUITI.
• I dati in USCITA verso Internet sono (quasi sempre) A PAGAMENTO.
• Per il traffico interno alla rete AWS:
  • Intra-AZ (utilizzando IP privati) è GRATUITO.
  • Inter-AZ (per alta disponibilità) è a PAGAMENTO.
  • Inter-Region (per il ripristino in caso di disastro) è a PAGAMENTO (e costa di più).

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 è trascurabile). Puoi riconoscere che servire un'immagine da 1 MB da EC2 costa, mentre servirla da CloudFront è praticamente gratuito.

Ottimizzare la fattura AWS non significa solo disattivare alcune funzionalità. Si tratta di creare architetture più intelligenti ed efficienti. Utilizzare strumenti come CloudFront e i VPC Endpoints non è solo una best practice per migliorare le prestazioni o la sicurezza; è una delle leve più efficaci per il controllo dei costi.

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.

Ma che dire di quell'ultimo 10%? E di scenari ibridi più complessi?

Nel nostro prossimo articolo approfondiremo gli argomenti avanzati.

Rimani sintonizzato!

About Proud2beCloud

Proud2beCloud è il blog di beSharp, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione più all'avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!