Guida ai costi di Data Transfer su AWS in pillole<\/a>” abbiamo esplorato in dettaglio i costi di network su AWS: data transfer in ingresso e uscita, tra\ufb03co tra Region e Availability Zone, VPC peering, NAT Gateway e VPC Endpoints. La teoria \u00e8 chiara. <\/p>\n\n\n\nMa come si traduce nella pratica?<\/p>\n\n\n\n
\u00c8 il momento di passare dall’astrazione alla realt\u00e0. In questo articolo analizzeremo tre scenari reali di complessit\u00e0 crescente<\/strong>, dimostrando come una corretta analisi dei costi di network possa portare a risparmi signi\ufb01cativi e decisioni architetturali pi\u00f9 consapevoli.<\/p>\n\n\n\nPreparate i vostri Jupyter Notebook: \u00e8 tempo di fare i conti.<\/p>\n\n\n\n
Caso 1: MongoDB Atlas – Public Endpoint vs VPC Peering<\/h2>\n\n\n\nIl contesto<\/h4>\n\n\n\n Un’applicazione ospitata su AWS utilizza MongoDB Atlas come database. Attualmente l’accesso avviene tramite endpoint pubblici, ma ci viene chiesto di valutare se convenga investire tempo per con\ufb01gurare un VPC Peering verso la VPC messa a disposizione da MongoDB.<\/p>\n\n\n\n
La di\ufb00erenza sostanziale tra le due soluzioni risiede nel percorso di rete:<\/p>\n\n\n\n
\nPublic Endpoint<\/strong>: il tra\ufb03co esce dalla VPC attraverso un NAT Gateway, raggiunge MongoDB Atlas su internet, e incorre nei relativi costi<\/li>\n\n\n\nVPC Peering<\/strong>: il tra\ufb03co rimane privato, viaggia sul peering connection di AWS, ed evita i costi di NAT Gateway<\/li>\n<\/ul>\n\n\n\nAnalisi dei costi<\/h4>\n\n\n\n Consideriamo un’istanza MongoDB M10 (57$\/mese) e analizziamo i costi di network per entrambe le soluzioni.<\/p>\n\n\n\n
Soluzione A – Public Endpoint<\/h4>\n\n\n\n I costi includono:<\/p>\n\n\n\n
\nCluster M10: $57\/mese<\/li>\n\n\n\n NAT Gateway: $0.048\/h<\/li>\n\n\n\n NAT Gateway data processing: $0.048\/GB<\/li>\n\n\n\n Data transfer OUT: $0.09\/GB<\/li>\n<\/ul>\n\n\n\nLa formula del costo totale \u00e8:<\/p>\n\n\n\n
\nCostSaaS-M10<\/sub> = ClusterM10<\/sub> + NAThourly<\/sub> \u00d7 730 + V \u00d7 (NATprocessing<\/sub> + Internetout<\/sub>)\n<\/p>\n\n\n\ndove V rappresenta il volume di traffico mensile (V assumer\u00e0 lo stesso significato anche per le successive formule).<\/p>\n\n\n\n
Soluzione B – VPC Peering<\/h4>\n\n\n\n MongoDB Atlas non applica costi per il VPC peering. I costi sono limitati al tra\ufb03co AWS:<\/p>\n\n\n\n
\nCluster M10: $57\/mese<\/li>\n<\/ul>\n\n\n\n\nVPC Peering same-AZ: gratuito<\/li>\n\n\n\n VPC Peering cross-AZ: $0.01\/GB (in entrambe le direzioni)<\/li>\n<\/ul>\n\n\n\nQui sorge una complicazione: le Availability Zone non sono allineate tra account AWS diversi. L’identi\ufb01catore eu-west-1a<\/em> nel nostro account non corrisponde necessariamente a eu-west-1a<\/em> nell’account MongoDB. Senza poter garantire il posizionamento same-AZ, dobbiamo assumere tra\ufb03co cross-AZ.<\/p>\n\n\n\nLa formula diventa:<\/p>\n\n\n\n
\nCostPeering-M10<\/sub> = ClusterM10<\/sub> + V \u00d7 (CrossAZin<\/sub> + CrossAZout<\/sub>)\n<\/p>\n\n\n\nNota<\/strong>: il tra\ufb03co cross-AZ costa $0.01\/GB in entrambe le direzioni (ingresso e uscita dall’AZ), per un totale di $0.02\/GB sul peering.<\/p>\n\n\n\nConfronto e Risultati<\/h4>\n\n\n\n Calcoliamo la di\ufb00erenza di costo:<\/p>\n\n\n\n
\n\u0394CostM10<\/sub>(V) = CostSaaS-M10<\/sub> \u2212 CostPeering-M10<\/sub> \n\u0394CostM10<\/sub>(V) = [ClusterM10<\/sub> + NAThourly<\/sub> \u00d7 730 + V \u00d7 (NATprocessing<\/sub> + Internetout<\/sub>)] \u2212 [ClusterM10<\/sub> + V \u00d7 (CrossAZin<\/sub> + CrossAZout<\/sub>)] \n\u0394CostM10<\/sub>(V) = NAThourly<\/sub> \u00d7 730 + V \u00d7 [(NATprocessing<\/sub> + Internetout<\/sub>) \u2212 (CrossAZin<\/sub> + CrossAZout<\/sub>)] \n\u0394CostM10<\/sub>(V) = $35.04 + V \u00d7 0.118<\/b>\n<\/p>\n\n\n\nIl risultato \u00e8 sempre positivo<\/strong>: il VPC peering genera un risparmio in ogni scenario di tra\ufb03co.<\/p>\n\n\n\n
<\/figure><\/div>\n\n\nIl gra\ufb01co evidenzia due aspetti fondamentali:<\/p>\n\n\n\n
\nRisparmio base \ufb01sso<\/strong>: il solo costo del NAT Gateway ($32.85\/mese) rappresenta un risparmio immediato, indipendentemente dal volume di tra\ufb03co<\/li>\n\n\n\nRisparmio marginale<\/strong>: ogni GB trasferito costa $0.118 in meno con il peering<\/li>\n<\/ol>\n\n\n\nAnche con volumi di tra\ufb03co molto elevati (oltre 10TB\/mese), il costo del data transfer cross-AZ sul peering non raggiunge nemmeno il costo del solo NAT Gateway della soluzione pubblica.<\/p>\n\n\n\n
Conclusioni<\/h4>\n\n\n\n Il VPC peering verso MongoDB Atlas \u00e8 conveniente dal punto di vista economico in qualsiasi scenario di tra\ufb03co. Ai bene\ufb01ci economici si aggiungono:<\/p>\n\n\n\n
\nSicurezza<\/strong>: il tra\ufb03co rimane nella rete privata AWS<\/li>\n\n\n\nPerformance<\/strong>: latenza inferiore e throughput pi\u00f9 stabile rispetto alla rete pubblica<\/li>\n\n\n\nSemplicit\u00e0<\/strong>: eliminazione di un NAT Gateway e relativa gestione<\/li>\n<\/ul>\n\n\n\nVale la pena notare che, pur assumendo tra\ufb03co cross-AZ (scenario peggiore), esiste una probabilit\u00e0 statistica di ottenere un matching same-AZ, che renderebbe il risparmio ancora maggiore grazie all’assenza di costi sul peering.<\/p>\n\n\n\n
Caso 2: AWS S3 Backup – Private vs Public Connectivity<\/h2>\n\n\n\nIl contesto<\/h4>\n\n\n\n Un cliente ci commissiona un’architettura per e\ufb00ettuare backup di server on-premise su S3. I requisiti forniti sono:<\/p>\n\n\n\n
\n“Mantenere il tra\ufb03co privato passando dal Direct Connect”<\/li>\n\n\n\n “Contenere i costi”<\/li>\n<\/ol>\n\n\n\nIl cliente dispone gi\u00e0 di una connessione Direct Connect verso AWS con un Transit Gateway con\ufb01gurato.<\/p>\n\n\n\n
Mettere in discussione i requisiti<\/h4>\n\n\n\n Come sempre in architettura, \u00e8 fondamentale validare i requisiti prima di accettarli acriticamente.<\/p>\n\n\n\n
Comprendiamo il ragionamento: avendo gi\u00e0 investito in un Direct Connect, sembra logico utilizzarlo per ogni caso d’uso. Tuttavia, per il tra\ufb03co verso S3, AWS fornisce connettivit\u00e0 pubblica ottimizzata e, soprattutto, il data transfer IN verso AWS \u00e8 gratuito<\/strong>.<\/p>\n\n\n\nLa domanda diventa: quanto costa realmente questa “privatezza” del tra\ufb03co?<\/p>\n\n\n\n
Analisi dei costi<\/h4>\n\n\n\n In questo caso la nostra variabile sar\u00e0 il volume in GB di cui effettuare mensilmente il backup su S3 Standard.<\/p>\n\n\n\n
Soluzione A – Tra\ufb03co Privato via Direct Connect<\/h4>\n\n\n\n Il percorso del tra\ufb03co \u00e8: <\/p>\n\n\n\n
On-premise \u2192 Direct Connect \u2192 Transit Gateway \u2192 VPC \u2192 VPC Endpoint (S3) \u2192 S3<\/p>\n\n\n\n
<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
I costi includono:<\/p>\n\n\n\n
\nDirect Connect: $0.30\/h (gi\u00e0 esistente)<\/li>\n\n\n\n Transit Gateway attachment: $0.05\/h<\/li>\n\n\n\n Transit Gateway data processing: $0.02\/GB<\/li>\n\n\n\n VPC Endpoint per S3: gratuito<\/li>\n\n\n\n S3 storage: $0.023\/GB-mese<\/li>\n\n\n\n S3 API calls: costo trascurabile ai fini del confronto in quanto identico in entrambe le soluzioni<\/li>\n<\/ul>\n\n\n\nDi conseguenza il costo totale dell\u2019opzione A \u00e8:<\/p>\n\n\n\n
\nCostPrivate<\/sub> = DCPortHours + TGAttachmenthourly<\/sub> \u00d7 730 + (V \u00d7 TGprocessing<\/sub>) + S3Storage + S3API \nCostPrivate<\/sub> = $219 + $36.50 + (V \u00d7 $0.02) + S3Storage + API Costs \nCostPrivate<\/sub> = $255.50 + (V \u00d7 $0.02) + S3Storage + API Costs\n<\/p>\n\n\n\nIn realt\u00e0, se il Direct Connect \u00e8 gi\u00e0 presente, \u00e8 possibile escluderlo dal costo totale:<\/p>\n\n\n\n
\nCostPrivate<\/sub> = $36.50 + (V \u00d7 $0.02) + S3Storage + API Costs\n<\/p>\n\n\n\nSoluzione B – Tra\ufb03co Pubblico<\/h4>\n\n\n\n Il percorso \u00e8 semplicemente: <\/p>\n\n\n\n
On-premise \u2192 Internet \u2192 S3<\/p>\n\n\n\n
<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
I costi sono:<\/p>\n\n\n\n
\nData IN verso AWS: gratuito<\/li>\n\n\n\n S3 storage: $0.023\/GB-mese<\/li>\n\n\n\n S3 API calls: costo trascurabile ai fini del confronto in quanto identico in entrambe le soluzioni<\/li>\n<\/ul>\n\n\n\n\nCostPublic<\/sub> = S3Storage + S3API\n<\/p>\n\n\n\nConfronto e Risultati<\/h3>\n\n\n\n A questo punto risulta molto semplice fare la differenza tra i due costi:<\/p>\n\n\n\n
\n\u0394Cost(V) = CostPrivate<\/sub> \u2212 CostPublic<\/sub> \n\u0394Cost(V) = $36.50 + (V \u00d7 $0.02)<\/b>\n<\/p>\n\n\n\n <\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
L’analisi gra\ufb01ca rivela un quadro inequivocabile:<\/p>\n\n\n\n
\nPer volumi ridotti<\/strong> (centinaia di GB): la soluzione privata costa diverse volte in pi\u00f9 rispetto alla soluzione pubblica. Il costo \ufb01sso del Transit Gateway attachment ($35\/mese) domina la spesa totale.<\/li>\n\n\n\nPer volumi elevati<\/strong> (decine di TB): il costo della soluzione privata si stabilizza a circa il doppio della soluzione pubblica. La componente variabile ($0.02\/GB del Transit Gateway processing) rappresenta un overhead costante.<\/li>\n\n\n\nNon esiste un break-even point<\/strong>: la soluzione pubblica \u00e8 sempre pi\u00f9 conveniente, indipendentemente dal volume di dati.<\/li>\n<\/ol>\n\n\n\nConsiderazioni aggiuntive<\/h4>\n\n\n\n– Alternative non analizzate in dettaglio:<\/h4>\n\n\n\n Per completezza, menzioniamo che esiste una terza opzione: utilizzare un AWS Direct Connect Public VIF invece del Private VIF con Transit Gateway. Questa soluzione mantiene il tra\ufb03co sulla connessione Direct Connect dedicata (evitando il transito su internet pubblico) ma elimina la necessit\u00e0 del Transit Gateway, riducendo signi\ufb01cativamente i costi. L’analisi dettagliata di questa opzione esula dagli obiettivi di questo articolo, ma rappresenta un’alternativa interessante per contesti speci\ufb01ci.<\/p>\n\n\n\n
– Quando la soluzione privata ha senso:<\/h4>\n\n\n\n L’analisi economica non \u00e8 l’unico fattore decisionale. La soluzione privata pu\u00f2 essere giusti\ufb01cata in presenza di:<\/p>\n\n\n\n
\nRequisiti di compliance che impongono tra\ufb03co privato<\/li>\n\n\n\n Politiche di sicurezza aziendali stringenti<\/li>\n\n\n\n Limitazioni della banda internet disponibile on-premise<\/li>\n\n\n\n Necessit\u00e0 di QoS garantite<\/li>\n<\/ul>\n\n\n\nConclusioni<\/h4>\n\n\n\n Dal punto di vista puramente economico, la soluzione pubblica \u00e8 superiore in ogni scenario. Il risparmio varia da un fattore 5-10x per piccoli volumi a un fattore 2x per grandi volumi.<\/p>\n\n\n\n
Caso 3: NAT Gateway – Centralizzati o Distribuiti?<\/h2>\n\n\n\nIl contesto<\/h4>\n\n\n\n Un’organizzazione AWS con decine di account si trova a gestire un elevato numero di NAT Gateway distribuiti. Ogni account ha una VPC con tre NAT Gateway (uno per Availability Zone), generando costi mensili signi\ufb01cativi anche in assenza di tra\ufb03co.<\/p>\n\n\n\n
La domanda sorge spontanea: ha senso mantenere NAT Gateway in ogni account, o conviene centralizzare l’egress internet in un account dedicato, raggiungibile dagli altri account tramite Transit Gateway?<\/p>\n\n\n\n
Premessa importante<\/h4>\n\n\n\n Questa decisione architetturale ha implicazioni che vanno oltre il puro aspetto economico:<\/p>\n\n\n\n
\nTra\ufb03c inspection<\/strong>: centralizzare permette di implementare controlli di sicurezza centralizzati<\/li>\n\n\n\nIP addressing<\/strong>: consente di utilizzare IP pubblici di propriet\u00e0 aziendale per tutto il tra\ufb03co in uscita<\/li>\n\n\n\nGovernance<\/strong>: facilita audit e compliance centralizzando il punto di egress<\/li>\n\n\n\nBlast radius<\/strong>: un problema al NAT Gateway centralizzato impatta tutti gli account<\/li>\n<\/ul>\n\n\n\nIn questo articolo ci concentreremo esclusivamente sull’analisi economica, ma \u00e8 fondamentale considerare questi aspetti in una valutazione reale.<\/p>\n\n\n\n
Analisi dei costi<\/h4>\n\n\n\n Consideriamo un’organizzazione con N account AWS, ognuno con una VPC e tre NAT Gateway (uno per AZ).<\/p>\n\n\n\n
Soluzione A – NAT Gateway Distribuiti<\/h4>\n\n\n\n Ogni account ha:<\/p>\n\n\n\n
\n3 NAT Gateway: 3 \u00d7 $0.048\/h<\/li>\n\n\n\n NAT Gateway data processing: $0.048\/GB<\/li>\n\n\n\n Data transfer OUT: $0.09\/GB<\/li>\n<\/ul>\n\n\n\n\nCostDistributed<\/sub> = N \u00d7 (NATper_AZ<\/sub> \u00d7 AZCount \u00d7 NAThourly<\/sub> \u00d7 730 + Vper_account<\/sub> \u00d7 NATprocessing<\/sub>) + V \u00d7 Internetout<\/sub>\n<\/p>\n\n\n\nSostituendo alcune variabili arriviamo a:<\/p>\n\n\n\n
\nCostDistributed<\/sub> = N \u00d7 (3 \u00d7 $0.048 \u00d7 730 + Vper_account<\/sub> \u00d7 $0.048) + V \u00d7 Internetout<\/sub> \nCostDistributed<\/sub> = N \u00d7 ($105.12 + Vper_account<\/sub> \u00d7 $0.048) + InternetEgressCost<\/b>\n<\/p>\n\n\n\nLasciamo il costo del traffico in uscita espresso come variabile, in quanto sar\u00e0 presente anche nel secondo caso, di conseguenza non \u00e8 necessario calcolarlo ai fini del confronto.<\/p>\n\n\n\n
Soluzione B – NAT Gateway Centralizzati<\/h4>\n\n\n\n Architettura: <\/p>\n\n\n\n
VPC spoke \u2192 Transit Gateway \u2192 VPC egress \u2192 NAT Gateway \u2192 Internet<\/p>\n\n\n\n
Costi coinvolti:<\/p>\n\n\n\n
\nTransit Gateway attachments: $0.05\/h \u00d7 (N spoke + 1 egress) account<\/li>\n\n\n\n NAT Gateway centralizzati: 3 \u00d7 $0.048\/h<\/li>\n\n\n\n Transit Gateway data processing: $0.02\/GB<\/li>\n\n\n\n NAT Gateway data processing: $0.048\/GB<\/li>\n\n\n\n Data transfer OUT: $0.09\/GB<\/li>\n<\/ul>\n\n\n\n\nCostCentralized<\/sub> = (N + 1) \u00d7 TGAttachmenthourly<\/sub> \u00d7 730 + NATcount<\/sub> \u00d7 NAThourly<\/sub> \u00d7 730 + V \u00d7 (TGprocessing<\/sub> + NATprocessing<\/sub> + Internetout<\/sub>)\n<\/p>\n\n\n\nSostituendo alcune variabili arriviamo a:<\/p>\n\n\n\n
\nCostCentralized<\/sub> = (N + 1) \u00d7 $0.05 \u00d7 730 + 3 \u00d7 $0.048 \u00d7 730 + V \u00d7 ($0.02 + $0.048) + InternetEgressCost \nCostCentralized<\/sub> = (N + 1) \u00d7 $36.50 + $105.12 + V \u00d7 $0.068 + InternetEgressCost \nCostCentralized<\/sub> = ($36.50 + $105.12) + N \u00d7 $36.50 + V \u00d7 $0.068 + InternetEgressCost \nCostCentralized<\/sub> = $141.62 + N \u00d7 $36.50 + V \u00d7 $0.068 + InternetEgressCost<\/b>\n<\/p>\n\n\n\nAnalisi Bidimensionale<\/h4>\n\n\n\n Ci troviamo di fronte a una funzione con due variabili: tra\ufb03co e numero di account. Dobbiamo analizzare entrambe.<\/p>\n\n\n\n
<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Fissando il volume di tra\ufb03co a diversi livelli (1TB, 5TB, 10TB, 50TB, 100TB), osserviamo che:<\/p>\n\n\n\n
\nPer bassi volumi di tra\ufb03co<\/strong>: il break-even si raggiunge con pochissimi account. Da quel punto in poi, la centralizzazione genera risparmi crescenti.<\/li>\n\n\n\nPer volumi elevati<\/strong>: il break-even si sposta leggermente pi\u00f9 avanti a causa del costo aggiuntivo di $0.02\/GB del Transit Gateway processing.<\/li>\n\n\n\nRisparmio massimo<\/strong>: si ottiene con molti account e poco tra\ufb03co per account.<\/li>\n<\/ol>\n\n\n\nGra\ufb01co 2 – Visualizzazione Tridimensionale<\/h4>\n\n\n\n Se vogliamo invece evitare di fissare la variabile del traffico, un grafico in due dimensioni non basta pi\u00f9, dobbiamo quindi passare da una retta ad un piano. Il gra\ufb01co tridimensionale o\ufb00re una visione completa dell’andamento dei costi al variare di entrambe le variabili simultaneamente.<\/p>\n\n\n\n
<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Dal grafico tridimensionale si delinea lo stesso andamento evidenziato in precedenza. Il risparmio massimo si ottiene con un elevato numero di account e basse quantit\u00e0 di traffico. Questo grafico rende pi\u00f9 evidente un\u2019altra informazione interessante: sebbene altissime quantit\u00e0 di traffico possano rendere la centralizzazione dei NAT Gateway poco vantaggiosa in termini economici, a partire dalla decina di account \u00e8 quasi impossibile trovarsi in questa situazione.<\/p>\n\n\n\n
Gra\ufb01co 3 – Sempli\ufb01cazione per Leggibilit\u00e0<\/h4>\n\n\n\n Il gra\ufb01co tridimensionale, pur completo, pu\u00f2 risultare di di\ufb03cile lettura. Per sempli\ufb01care la visualizzazione, abbiamo creato un gra\ufb01co bidimensionale che mostra la di\ufb00erenza di costo (zona verde = risparmio, zona rossa = costo aggiuntivo) in funzione di account e tra\ufb03co.<\/p>\n\n\n\n
<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Conclusioni<\/h4>\n\n\n\n L’analisi economica indica chiaramente che la centralizzazione dei NAT Gateway \u00e8 conveniente nella maggioranza degli scenari reali, in particolare:<\/p>\n\n\n\n
Centralizzare \u00e8 conveniente quando:<\/p>\n\n\n\n