Para entender os Custos na Nuvem e como otimizá-los, o que chamamos de Cloud Economics, é importante entender alguns conceitos importantes como OPEX, CAPEX e TCO, assim como as boas práticas para reduzir custos na nuvem.
CAPEX e OPEX
CAPEX (ou capital expenditure) refere-se às despesas ou investimentos em bens de capital (ativos). Quando uma empresa compra um servidor físico para instalar em data center próprio, trata-se de CAPEX.
Já OPEX (operational expenditure) refere-se às despesas operacionais. Quando uma empresa utiliza Cloud Computing pagando por hora de utilização de um servidor em nuvem, trata-se de OPEX.
No caso de CAPEX as despesas são utilizadas para comprar bens físicos como um hardware.
No caso de OPEX paga-se pelo uso e não pela propriedade do bem.
Um dos grandes problemas de CAPEX atualmente, especialmente, quando se fala em utilizar on premisses em vez de nuvem é a falta de elasticidade, que faz com que você sempre tenha capacidade demais ou insuficiente para atender as demandas de negócio.
Pense num varejo, por exemplo, que na época de Natal ou BlackFriday pode precisar de até 5x a capacidade de uma semana normal.
Talvez não faça sentido adquirir todas essa capacidade necessária no pico de uso com CAPEX, deixando-a ociosa o resto do ano.
Pior ainda, seria dimensionar mal o pico de demanda, e não suportar os alto níveis de acessos, perdendo clientes e vendas no momento de maior oportunidade de faturamento da companhia.
A capacidade elástica na Nuvem resolve muito bem esse problema, e permite que você transforme o que seria custo fixo em variável.
Custo Total de Propriedade (TCO)
Para comparar os custos na nuvem (cloud computing) a aquisição de servidores para instalação on premisses, é importante considerar outro conceito muito importante que é o Custo Total de Propriedade (em inglês TCO – Total Cost of Ownership) que representa o custo total envolvido, tanto direto como indireto.
Ao utilizar um servidor EC2 na AWS, nos valores que paga por hora para usar o servidor, estão embutidos todos os custos necessários para que esse servidor esteja disponível para você utilizá-lo com segurança.
Em se tratando de um data center próprio você deve considerar os demais custos envolvidos como o de cotação e aquisição do equipamento, equipe para instalação e atualização desses equipamentos, custo de manutenção, segurança do data-center, custos com energia elétrica, equipamentos de ar condicionado, prevenção de incêndios, etc.
Mesmo com tudo isso, vale ressaltar que seja comum que num primeiro momento de migração de on premisses para a nuvem os custos se tornem mais altos do que eram antes, até porque possivelmente haverá custos de treinar os novos colaboradores, mudar processos e criar novos processos de gestão, migração de dados, etc.
Contudo, passado o período inicial e ao se utilizar melhor os recursos disponíveis na nuvem e utilizar as boas práticas que veremos a seguir, é possível, em muitos casos, arrisco até dizer que na maioria, reduzir significativamente os custos de infraestrutura.
Boas Práticas para Otimização de Custos na Nuvem
Provisionamento Adequado na Nuvem
Certifique-se de manter apenas os recursos que você realmente precisa com o tamanho que precisa (CPU, Memória, Storage, etc.).
Monitore os recursos com o Cloud Watch para certificar-se de que não há recursos ociosos em sua conta da AWS.
Certifique-se de utilizar a elasticidade da nuvem aumentando a capacidade dos momentos de pico e reduzindo a capacidade nos momentos de menor demanda, fazendo uso de aplicações stateless, e escalabilidade horizontal.
Reserve Recursos e use instâncias SPOT
A AWS tem diferentes modalidades de preço para instâncias sob demanda (on demand), reservadas e spot.
Para aqueles recursos que você sabe que vai utilizar por 1 ano ou mais, vale bastante a pena fazer uma reserva anual, nesse caso você se compromete a utilizar e pagar por aquele recurso (por exemplo, uma instância EC2) por um ano, mas em troca consegue um desconto interessante algumas vezes superior a 50%.
Além de pagar menos pelas instâncias reservadas do que pelas sob demanda você tem a garantia que aquela instância estará disponível para você quando você precisar dela (se você associar uma AZ a reserva).
No mundo AWS, uma AZ (ou Zona de Disponibilidade) representa um Data Center numa determinada Região.
Esta garantia pode ser interessante especialmente num cenário de falha de uma AZ quando as outras AZs vão ser mais requisitadas e disputadas por outros clientes da AWS.
Para recursos temporários em que não se tem grande prejuízo caso forem interrompidos repentinamente recomenda-se o uso de instâncias spot que podem chegar a descontos muito altos em alguns casos próximos a 90%.
O preço das instâncias spot é dinâmico e varia de acordo com a demanda, por isso, se alguém ofertou mais do que você ofertou pelas instâncias elas podem ser derrubadas para que sejam então usadas por quem está disposto a pagar mais por elas.
As instâncias spot permitem que você aproveite a capacidade não utilizada na Nuvem AWS, os casos mais comuns são aplicativos stateless, tolerantes a falhas e flexíveis como big data, CI/CD, servidores web, computação de alta performance (HPC) e workloads de teste e desenvolvimento.
Você também tem a opção de hibernar, parar ou encerrar as instâncias spot quando o EC2 solicitar a devolução da capacidade, com 2 horas de aviso prévio.
No caso de EC2 é possível utilizar um recurso chamado EC2 Fleets em que você definir um mix de instâncias reservadas, sob demanda e spot para melhor utilização dos recursos. O importante aqui é certificar que se as instâncias spot não estiverem mais disponíveis os serviços essenciais não deixem de funcionar.
Fique atento as Regiões
Os preços dos recursos em nuvem na AWS podem variar de acordo com a Região, por exemplo, recentemente numa pesquisa que fiz, EC2 estava cerca de 40% mais caro em São Paulo no Brasil, do que em Virgina nos Estados Unidos, por exemplo.
É importante considerar qual a melhor região para cada aplicação que você está executando, e também os pontos positivos e negativos de estar numa ou outra.
Por exemplo, se a maioria dos usuários da sua aplicação acessa de São Paulo, talvez faça sentido pagar mais caro para usar essa região e ter uma latência menor, ou talvez utilizar uma região mais em conta como Virgínia em conjunto com um CDN como Cloud Front já seja suficiente.
Use Serviços Gerenciados
Serviços gerenciados como, por exemplo, usar RDS MySQL em vez de instalar e manter o MySQL manualmente em uma instância EC2 pode deixar sua fatura da AWS efetivamente um pouco mais cara, mas por outro, muito provavelmente vai liberar mais tempo da sua equipe (e geralmente o tempo das pessoas é muito mais caro do que a AWS cobra de adicional pelo serviço gerenciado).
O ganho vem da redução da complexidade e de se evitar intervenções manuais, que são mais propensas a erros humanos que consequentemente aumentam os custos.
Para saber mais leia meu artigo Serviços Gerenciados em vez de Servidores na Nuvem.
Custos com Transferência de Dados
Fique atento também a transferência de dados entre regiões da AWS, especialmente quando você tem aplicações sendo executadas em diferentes regiões que trocam informações entre si.
Em alguns casos, pode ser interessante concentrar as aplicações na mesma região para reduzir os custos de transferência.
Política de Ciclo de Vida (Lifecyle)
Alguns serviços na AWS permite que você crie política de ciclo de vida para evitar que recursos que não precisam mais ser usados continuem existindo ou que tenham um nível de acesso mais alto e caro do que deveriam.
Por exemplo, é possível determinar no Backup de Volumes do EBS uma política de Lifecycle para apagar backups antigos que não precisarão mais ser utilizados.
Já no S3, por exemplo, há níveis de acesso diferentes que podem ser configurados sem afetar a durabilidade dos arquivos, dados que são acessados com menos frequência podem ser movidos para um Storage Class mais barato gerando redução de custos.
Use etiquetas (tags)
Praticamente todos os recursos da AWS podem associados com tags, e posteriormente é possível analisar os custos de recursos que utilizam uma determinada tag.
Com isso você, por exemplo, identificar o custo por aplicação, por departamento, ou qualquer outra dimensão que faça sentido no seu contexto.
Crie e Consolide Diferentes Contas
Além do uso de tags, é possível criar diferentes contas na AWS e consolidar o Billing (cobrança) numa única conta, isso pode ser particularmente interessante para separar ambiente de produção e desenvolvimento em diferentes contas, por exemplo, aumentando assim o grau de isolamento entre esses ambientes.
Outro ponto positivo de usar diferentes contas, é conseguir separar a análise de custos especialmente de custos mais difíceis de se rastrear apenas com uso de tags, como é o caso dos custos de transferência de dados, por exemplo.
Finalmente, alguns recursos na AWS, tem redução de custo em alta escala, como, por exemplo, o S3 que tem um custo por TB que é menor ao se ultrapassar o marco de 50 TB, nesse caso, se o billing for consolidado, considera-se a soma de todas as contas para se aplicar o desconto, de forma que o custo das contas consolidadas será menor que o custo individual de cada conta separadamente.
Defina e acompanhe o orçamento (Budget)
Há uma ferramenta gratuita na AWS chamada AWS Budgets que permite que você defina limites orçamentários e receba notificações caso esses limites sejam ultrapassados.
Há uma série de métricas interessantes como custo, percentual de utilização das instâncias reservadas, e cobertura de instâncias reservadas (ou seja, o percentual de instâncias existentes que estão reservadas).
Atenção aos avisos do Trusted Advisor
O AWS Trusted Advisor funciona como uma espécie de checklist na sua conta da AWS que identifica potenciais oportunidade de melhorias e redução de custo como ajustes de tamanho de recursos, ou reservas de instâncias que podem ser feitas.
Palestras sobre Custos na Nuvem
Para você que pretende se aprofundar em Cloud Economics recomendo também ver as seguintes apresentações:
Conclusão
A Computação em Nuvem pode trazer muita economia e permitir que você pague apenas pelo usa, transformando custos fixos em custos variáveis e substituindo CAPEX por OPEX.
Se mal gerenciado um mesmo ambiente em nuvem pode custar muitas vezes, fazer o bom uso de reservas e spots, além de dimensionar bem, e evitar capacidade ociosa pode representar uma economia significativa, por isso esteja sempre atento as boas práticas de redução de custos em nuvem e Cloud Econimics.
Para aprender mais leia o White Paper da AWS sobre Otimização de Custos, o White Paper sobre Maximização de Valor na AWS, o White Paper AWS Economics,
