Como membro do time de segurança, parte do meu trabalho é criar e manter regras de conformidade na nuvem, que garantem um padrão mínimo de qualidade e segurança para os diversos serviços que uma nuvem oferece. Obviamente as regras não saem de graça e são um custo que os times de segurança acabam arcando com – entretanto essa é a forma mais fácil de escalar boas práticas de segurança no ambiente. Uma das formas de implementar essas regras é utilizando o serviço AWS Config, um serviço da AWS capaz de verificar, auditar e avaliar configurações e relacionamentos entre recursos na nuvem. Com o AWS Config pagamos por evento de configuração gerado e também pela execução das regras.
Outro dia, enquanto olhava os custos das contas, notei que o AWS Config era o segundo maior gasto de uma conta, logo abaixo dos custos de EC2 – o normal é encontrar custos de rede, EBS, S3, RDS nessa posição. Algo não estava certo e fui investigar o que estava causando esse comportamento, afinal uma conta de testes não deveria gastar mais em AWS Config do que uma conta de produção.
Depois de encontrar alguns textos sobre o assunto e alguns exemplos de query para utilizar no AWS Athena, comecei a investigação. O primeiro achado foi que gerávamos entre 28 e 36 mil itens de configuração por dia, em um ambiente muito pequeno e com baixo nível de mudanças – as maiores mudanças vêm da utilização de um agendador para ligar e desligar o sistema durante as horas de trabalho, que gera uma ótima economia de EC2 e RDS.
Escolhi um dia qualquer e olhei o agregado de eventos agrupados por tipo de evento que foi gerado. Outro espanto: o primeiro colocado eram alterações de subnet! O que estava alterando a rede tantas vezes em um dia? Na sequência tinham alterações em interfaces de rede e grupos de segurança, o que faz sentido se o primeiro colocado for alterações de subnet. Mais algumas conversas com colegas, outras queries rodadas e identificamos que a maioria das alterações vinham de uma subnet só. Para nossa sorte, essa subnet só tinha 12 EC2s rodando, o que permitiria até uma exploração manual olhando cada uma das 12 máquinas, mas não foi necessário. Uma das EC2s tinha o mesmo nome de um dos grupos de segurança que aparecia no topo da lista de eventos gerados por dia – uma ótima correlação!
Investigando a EC2 logo chegamos a conclusão que ela fazia parte de um grupo de autoscale, e olhando os eventos deste grupo vimos que havia uma falha sistemática na verificação da saúde da instância criada. Resumindo, o grupo de autoscale estava criando uma instância, tentava verificar a saúde, falhava, destruía a instância, criava uma nova… eternamente preso num ciclo de falhas. Em um ambiente sem AWS Config habilitado isso teria um custo mínimo associado ao valor da EC2, de um balanceador de carga ocioso e de armazenamento não utilizado. Mas, quando habilitamos o Config passou a gerar diversos itens de configuração, quase um ataque de amplificação de custos. Cada ligar / desligar de uma máquina, criar / destruir interfaces de rede, vincular / desvincular grupos de segurança, etc. geraram novos itens de configuração.
Com esse achado, resolvemos investigar os outros grupos de autoscale para ver se existia o mesmo comportamento errôneo e encontramos mais alguns. Fazendo os ajustes necessários, seja desligando o sistema que claramente não estava em uso pois falhava sempre ou resolvendo a saúde do sistema, o custo da conta caiu rapidamente.
Se os custos estão altos, ou fora de um padrão esperado, invista um tempo na investigação da causa, converse com os times que utilizam a conta, proponha novas arquiteturas e veja quais trocas são possíveis em cada sistema. Gerir custos na nuvem não é simples, requer um trabalho constante de todos – e não somente do time de FinOps. Não deixe os custos da nuvem ficarem nas nuvens.
Top comments (0)