Aqui vai uma curiosidade divertida sobre nuvem: o que é invisível, silencioso e drena discretamente dezenas (ou centenas) de milhares de dólares da sua fatura da AWS todo mês?
Não, não são volumes EBS ociosos (embora, sim, você também deva limpá-los).
É a transferência de dados AZ-a-AZ — e ela é bem mais sorrateira do que parece.
O papo caro entre AZs
Na AWS, quando os dados trafegam entre Availability Zones (AZs) da mesma região, você é cobrado duas vezes: uma pelos dados que saem da AZ de origem e outra pelos que entram na AZ de destino. São 2¢ por GB em cada direção, e a conta cresce rápido em arquiteturas de larga escala.
Até aí, pode fazer sentido se você roda bancos de dados multi-AZ ou arquiteturas de alta disponibilidade. Mas eis o pulo do gato: uma parcela enorme da transferência de dados entre AZs é acidental, desnecessária ou simplesmente mal compreendida.
Motivos comuns para o tráfego AZ-a-AZ disparar:
- Você tem microsserviços conversando entre AZs sem que ninguém se dê conta.
- Seus nós EKS estão em AZs diferentes e sendo usados de forma intercambiável.
- Load balancers roteiam o tráfego entre zonas de maneira imprevisível.
- Serviços stateful não respeitam a afinidade de AZ.
- Você herdou um YAML de 2019 e ficou rezando para ele continuar funcionando.
Neste excelente artigo, uma equipe descobriu que mais de 80% da transferência de dados AZ-a-AZ dela era evitável — só faltava visibilidade, até mergulharem fundo no problema.
Mas por que é tão difícil reduzir esses custos?
Dá para ver esses custos no AWS Cost and Usage Report (CUR), em tipos de uso como:
- AWS:DataTransfer-Regional-Bytes
- AWS:DataTransfer-Regional-Bytes-Out
- BoxUsage:
:DataTransfer-Out-Bytes
Por exemplo:
Só que o problema é o seguinte: mesmo encarando esses itens na planilha, você não faz ideia do que realmente os causou.
Você até consegue insights em nível de máquina, como IDs de instâncias EC2, mas se estiver rodando workloads modernos no Kubernetes, boa sorte para rastrear esse custo até um pod, namespace ou workload específico.
Alguns times tentam preencher essa lacuna com VPC Flow Logs, que capturam metadados de comunicação IP a IP. Ajudam, sim, mas manter Flow Logs ligados o tempo todo em toda a infraestrutura é absurdamente caro e, paradoxalmente, pode sair mais caro do que as próprias transferências AZ-a-AZ que você está tentando depurar.
E, mesmo que você engula o custo dos VPC Flow Logs, tem outro problema:
Flow Logs entregam dados brutos de rede, não contexto. Veja um exemplo dos logs:
Agora você tem uma montanha de dados de tráfego IP a IP. Mas adivinha? É como receber uma caixa de quebra-cabeça sem a imagem na tampa. Você ainda tem todo o trabalho pesado pela frente: enriquecer os logs, mapear IPs para instâncias, cruzar referências com o inventário da nuvem, descobrir a que workload ou container cada IP pertence e, só então, tentar decodificar a lógica de negócio por trás do padrão de tráfego.
E no mundo Kubernetes, a coisa fica ainda pior. Você lida com IPs dinâmicos, pods efêmeros, autoscaling groups, service meshes… é o caos. Vai precisar de horas (ou dias) de engenharia, disciplina de tagging entre os times e uma pilha considerável de ferramentas de correlação de logs — só para descobrir se é um microsserviço específico que fica papeando entre AZs.
Quando as respostas chegam, sua fatura de nuvem já explodiu.
Então, como combater um custo que você nem consegue rastrear?
A solução do Attribute™: iluminar os custos ocultos
No Attribute™, criamos uma solução única para tornar visível o invisível.
Nosso sensor eBPF rastreia cada byte que sai dos seus workloads — do IP de origem ao IP de destino — para reconstruir a história por trás das suas transferências de dados. E não para por aí:
Smart AZ Detection Engine
Não olhamos só para o tráfego — nós o entendemos. Nosso motor correlaciona cada IP com as tabelas de roteamento da nuvem para determinar se a comunicação está:
- Dentro da mesma AZ
- Entre duas AZs da mesma região
- Entre regiões diferentes
- Ou saindo direto para a internet (olá, taxas de egress!)
Se seus dados estão vazando por NAT gateways, ELBs ou outros intermediários de rede, a gente também identifica.
Resumindo: ao combinar os dados exclusivos do nosso sensor eBPF com os itens de custo do CUR, obtemos o custo AZ-AZ preciso em nível de workload, por conexão e por IP.
Do insight à ação
Depois que você enxerga o problema, ajudamos a resolvê-lo. Avaliamos alternativas junto com você — seja colocar serviços na mesma AZ, ajustar as regras de afinidade do k8s ou repensar a arquitetura dos seus fluxos.
Com o Attribute™, você ganha a visibilidade, a clareza e o controle para cortar custos desnecessários entre AZs — em geral, de 50% a 80%.
Dê o primeiro passo
Não dá para consertar o que você não consegue enxergar.
Comece descobrindo para onde seu tráfego entre AZs está indo de verdade e por quê, e depois parta para as ações que reduzem esse custo. O Attribute™ está aqui para ajudar você de A a Z.
Agende uma demo com a gente e comece a falar a linguagem dos custos de rede.