Ecco un quiz divertente sul cloud: cosa c'è di invisibile, silenzioso e che sottrae di nascosto decine (o centinaia) di migliaia di dollari alla sua fattura AWS ogni mese?
No, non sono i volumi EBS inutilizzati (anche se sì, conviene ripulire anche quelli).
È il trasferimento dati tra AZ, ed è più subdolo di quanto sembri.
Il costoso chiacchiericcio tra AZ
In AWS, quando i dati si spostano tra Availability Zone (AZ) della stessa region, l'addebito arriva due volte: una per i dati in uscita dall'AZ di origine e una per quelli in ingresso all'AZ di destinazione. Parliamo di 2¢ per GB in ciascuna direzione, una cifra che nelle architetture su larga scala lievita in fretta.
Certo, ha senso se gestisce database multi-AZ o architetture ad alta disponibilità. Ma il punto è un altro: una fetta enorme del traffico dati inter-AZ è accidentale, superflua o semplicemente frutto di malintesi.
I motivi ricorrenti per cui il traffico tra AZ esplode:
- Microservizi che comunicano tra AZ senza che nessuno se ne accorga.
- Nodi EKS in AZ diverse usati in modo intercambiabile.
- Load balancer che instradano il traffico tra zone in modo imprevedibile.
- Servizi stateful che non rispettano l'affinity di AZ.
- Un file YAML del 2019 ereditato e lasciato lì sperando che funzionasse ancora.
In questo ottimo articolo, un team ha scoperto che oltre l'80% del proprio traffico dati tra AZ era evitabile: mancava semplicemente la visibilità, arrivata solo dopo un'analisi approfondita.
Ma perché è così difficile ridurre questi costi?
Questi costi sono visibili nell'AWS Cost and Usage Report (CUR), sotto usage type come:
- AWS:DataTransfer-Regional-Bytes
- AWS:DataTransfer-Regional-Bytes-Out
- BoxUsage:
:DataTransfer-Out-Bytes
Per esempio:
Ma ecco il problema: anche fissando queste voci in un foglio di calcolo, non ha la minima idea di cosa le abbia effettivamente generate.
Può ottenere qualche insight a livello di macchina tramite gli ID delle istanze EC2, ma se esegue workloads moderni su Kubernetes, buona fortuna nel ricondurre quel costo a un pod, un namespace o un workload specifico.
Alcuni team provano a colmare il divario con i VPC Flow Logs, che catturano i metadati della comunicazione IP-to-IP. Utili, senza dubbio, ma tenerli attivi in continuo su tutta l'infrastruttura è incredibilmente costoso e, paradossalmente, potrebbe costare più dei trasferimenti tra AZ che sta cercando di analizzare.
E anche ammesso di digerire il costo dei VPC Flow Log, c'è un altro problema:
I Flow Log forniscono dati di rete grezzi, non contesto. Ecco un esempio di log:
Ora si ritrova con una montagna di dati di traffico IP-to-IP. E indovini un po'? È come ricevere una scatola di pezzi di puzzle senza l'immagine sul coperchio. Il lavoro pesante resta tutto sulle sue spalle: arricchire i log, mappare gli IP alle istanze, incrociare i dati con l'inventario cloud, capire a quale workload o container appartiene ciascun IP e, solo a quel punto, provare a decodificare la logica di business dietro quel pattern di traffico.
E in un mondo Kubernetes va anche peggio. Ha a che fare con IP dinamici, pod effimeri, autoscaling group, service mesh… è il caos. Servono ore (o giorni) di lavoro degli Engineers, disciplina di tagging condivisa tra i team e uno stack niente male di strumenti di correlazione dei log, solo per capire se è un singolo microservizio a chiacchierare tra le AZ.
Quando finalmente arrivano le risposte, la sua fattura cloud è già esplosa.
Come si combatte, allora, un costo che non si riesce nemmeno a tracciare?
La soluzione di Attribute™: fare luce sui costi nascosti
In Attribute™ abbiamo sviluppato una soluzione unica per rendere visibile l'invisibile.
Il nostro sensore eBPF traccia ogni byte in uscita dai suoi workloads-dall'IP di origine a quello di destinazione-così possiamo ricostruire la storia dietro ogni trasferimento dati. E non ci fermiamo qui:
Smart AZ Detection Engine
Non ci limitiamo a osservare il traffico: lo interpretiamo. Il nostro engine correla ogni IP con le tabelle di routing del cloud per stabilire se la comunicazione avviene:
- All'interno della stessa AZ
- Tra due AZ nella stessa region
- Tra region diverse
- Oppure direttamente verso internet (ciao, egress fee!)
E se i suoi dati sgusciano fuori attraverso NAT gateway, ELB o altri intermediari di rete, ce ne accorgiamo anche lì.
In sintesi, combinando i dati esclusivi del nostro sensore eBPF con le voci di costo del CUR, otteniamo un costo AZ-AZ preciso a livello di workload, per ogni connessione e ogni IP.
Dall'insight all'azione
Individuato il problema, l'aiutiamo a risolverlo. La affianchiamo nel valutare le alternative: co-locare i servizi nella stessa AZ, rivedere le regole di affinity di k8s o riprogettare i flussi.
Con Attribute™ ottiene la visibilità, la chiarezza e il controllo per tagliare i costi inter-AZ superflui, spesso del 50-80%.
Il primo passo
Non si può sistemare ciò che non si vede.
Cominci scoprendo dove sta davvero andando il suo traffico inter-AZ e perché, poi passi all'azione per ridurne il costo. Attribute™ è qui per accompagnarla dalla A alla Z.
Prenoti una demo con noi e inizi a parlare la lingua dei costi di rete.