1. Introdução

FinOps é uma prática que ajuda as empresas a entender, controlar e otimizar seus custos em tecnologia. Para isso, aproxima os times de tecnologia, finanças e negócio, tornando mais fácil tomar decisões sobre custos e uso dos recursos. Este artigo é voltado para a aplicação do FinOps em ambientes de infraestrutura em cloud, com foco no controle e na otimização de custos.

Uma estratégia madura precisa responder perguntas como:

• O que está gerando o custo?
• Qual aplicação ou projeto está consumindo?
• Esse consumo está entregando valor para o negócio?
• O recurso está dimensionado corretamente?
• Existe capacidade ociosa?
• O modelo de contratação é adequado?
• O custo está crescendo mais rápido que o negócio?
• Quanto da economia identificada realmente foi capturada?

Por isso, FinOps deve ser tratado como um processo contínuo. O ciclo é dividido em 3 fases:

Informar

É a fase de entender e criar visibilidade sobre os custos, o uso e a eficiência da tecnologia. O objetivo é transformar os dados em informações que apoiem decisões de negócio.

• Coletar e organizar dados de custos e utilização
• Definir critérios de alocação de custos
• Definir padrões de tags ou outros mecanismos de identificação
• Criar relatórios e dashboards
• Acompanhar orçamento e previsões
• Definir e acompanhar KPIs
• Criar métricas de custo unitário
• Comparar custos e desempenho entre equipes ou ambientes
• Analisar variações de custos e utilização

Otimizar

É a fase de identificação de oportunidades para melhorar a relação entre custo, desempenho e valor.

• Avaliar rightsizing
• Identificar recursos ociosos ou subutilizados
• Automatizar a eliminação de desperdícios
• Otimizar armazenamento
• Avaliar transferência de dados
• Modernizar arquiteturas quando fizer sentido
• Avaliar modelos de preços, descontos e compromissos de consumo
• Considerar alternativas tecnológicas mais eficientes
• Documentar e priorizar oportunidades de otimização

Operar

É a fase de colocar em prática as oportunidades identificadas e promover melhorias contínuas no uso da tecnologia. Envolve transformar as decisões de FinOps em ações e acompanhar seus resultados.

• Implementar as oportunidades de otimização
• Acompanhar os resultados das ações
• Estabelecer responsáveis
• Acompanhar indicadores de custo, uso e eficiência
• Investigar anomalias
• Agir sobre desvios de orçamento e previsão
• Medir savings realizados e custo evitado
• Acompanhar recomendações e compromissos
• Melhorar processos e amadurecer a prática de FinOps na organização
• Promover colaboração entre tecnologia, finanças e negócio
• Revisar continuamente as estratégias de otimização

Documentação: https://www.finops.org/framework/phases/

2. Modelos de preço do Amazon EC2

O Amazon EC2 possui diferentes modelos de aquisição. A escolha deve considerar estabilidade da carga, previsibilidade, flexibilidade necessária e tolerância a interrupções.

Os principais modelos são:

• On-demand
• Savings plans
• Reserved instances (RIs)
• Spot instances

Além dos modelos de preço, a AWS oferece mecanismos específicos para capacidade e isolamento físico, como:

• On-demand capacity reservations: reservam capacidade de EC2 em uma zona de disponibilidade específica. Não oferecem desconto por si só, mas podem ser combinadas com savings plans ou RIs regionais para obter desconto.

• Dedicated hosts: disponibilizam um servidor físico dedicado ao cliente, sendo relevante para determinados requisitos de licenciamento e compliance.

• Dedicated instances: executam instâncias em hardware fisicamente isolado de outras contas AWS, sem visibilidade ou controle sobre o servidor físico.

• Capacity blocks for ML: permitem reservar instâncias de computação acelerada para uma data futura, por um período definido, para workloads de machine learning.

2.1 On-demand

No modelo on-demand não existe compromisso de longo prazo. Paga-se por segundo apenas enquanto a instância está em execução, com mínimo de 60 segundos.

É indicado principalmente para workloads de curto prazo, irregulares e que não podem ser interrompidas, como:

• Workloads novas
• Ambientes ainda imprevisíveis
• Projetos temporários
• Picos de demanda
• Cargas que ainda precisam ser avaliadas antes de um compromisso

A principal vantagem é a flexibilidade. Para cargas estáveis e contínuas, ou tolerantes a interrupções, savings plans, RIs e spot podem oferecer um custo menor.

--

2.2 Savings plans

Os savings plans oferecem preços reduzidos em troca de um compromisso de utilização consistente, medido em US$/hora, por um período de 1 ou 3 anos. Os percentuais máximos de economia dependem do tipo de plano e do serviço.

Atualmente existem 4 tipos:

• Compute savings plans: são os savings plans mais flexíveis para computação. Podem oferecer até 66% de economia sobre on-demand, dependendo da configuração. Eles podem ser aplicados a EC2, AWS Fargate e AWS Lambda. A principal vantagem é a flexibilidade, por exemplo, uma organização pode alterar família de instância, tamanho, região ou até migrar uma carga de EC2 para Fargate e continuar utilizando o benefício, desde que o uso seja elegível. É interessante considerar o uso quando existe uma base de computação relativamente previsível, mas a arquitetura ainda pode mudar.

• EC2 instance savings plans: os EC2 instance savings plans podem oferecer até 72% de economia sobre on-demand. Em troca de uma economia potencialmente maior, existe um compromisso mais específico, que é a família de instância e região. Dentro dessa família e região, existe flexibilidade de tamanho, sistema operacional e tenancy. Por exemplo, uma empresa possui utilização constante da família M em uma determinada região, então se existe alta confiança de que essa base continuará nessa família e região, um EC2 instance savings plans pode ser considerado. Por outro lado, se existe possibilidade de migração de arquitetura ou região, o compute savings plans pode oferecer maior flexibilidade.

• Database savings plans: podem oferecer até 35% de economia sobre on-demand, dependendo do serviço e da configuração. Ao contrário dos outros tipos, possuem prazo de 1 ano e são oferecidos na modalidade “no upfront”. Cobrem serviços como Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS e OpenSearch Service. O compromisso é medido em US$/hora e se aplica de forma flexível ao uso elegível, permitindo mudanças entre serviços suportados, engines, famílias e tamanhos de instância, tipo de implantação (provisionado ou serverless) e regiões AWS. No uso provisionado, o plano se aplica às gerações mais recentes de instâncias.

• SageMaker AI savings plans: podem oferecer até 64% de economia sobre on-demand e são aplicados ao uso de instâncias de ML no Amazon SageMaker AI, com prazo de 1 ou 3 anos. Eles cobrem diversos componentes da plataforma, como notebooks do SageMaker Studio, jobs de treinamento, processamento, Data Wrangler e inferência em tempo real e em lote. A principal vantagem é a flexibilidade, pois o desconto se aplica independentemente da família de instância, tamanho, região ou componente do SageMaker utilizado. Por exemplo, uma organização pode mover um endpoint de inferência para outra família de instância ou para outra região e continuar se beneficiando do plano.

--

2.3 Reserved instances

São compromissos de 1 ou 3 anos em que a empresa paga menos do que no on-demand. Apesar do nome, as RIs não são máquinas reservadas. Elas funcionam como um desconto na fatura, aplicado automaticamente sempre que o uso bate com a configuração contratada, sendo o tipo de instância, região, tenancy e sistema operacional. Nas RIs, o desconto fica preso a essa configuração. Se a empresa compra RIs de m5.xlarge Linux em us-east-1, só esse uso recebe o desconto. No compute savings plans, o compromisso é um valor em US$/hora, e o desconto continua valendo, até esse valor, mesmo que a carga mude de família, de região ou vá para o Fargate. Na prática, a escolha depende de quão estável é o ambiente e de quanta flexibilidade a arquitetura ainda precisa.

--

2.4 Spot instances

São instâncias que usam a capacidade ociosa do EC2, com preço abaixo do on-demand. O preço spot é definido pela AWS e varia aos poucos, conforme a oferta e a demanda de longo prazo. Quando a AWS precisa dessa capacidade de volta, a instância pode ser interrompida com um aviso de 2 minutos, por isso o spot faz sentido para cargas que toleram interrupções e têm flexibilidade de horário, como:

• Análise de dados
• Processamento em lote
• Tarefas opcionais ou não críticas

--

2.5 Savings plans x Spot x On-demand

A escolha deve considerar custo, flexibilidade, risco e arquitetura, e não apenas o maior percentual de desconto. Uma forma prática de analisar:

3. FinOps para bancos de dados

Os bancos de dados exigem uma análise diferente de uma simples instância EC2.

Dependendo do serviço e da configuração, o custo pode envolver:

• Computação
• Armazenamento
• I/O
• Requisições
• Backup e snapshots
• Transferência de dados
• Licenciamento
• Capacidade provisionada (leitura/escrita ou IOPS)
• Capacidade serverless
• Réplicas e alta disponibilidade (Multi-AZ)
• Suporte estendido para versões antigas de engine

Por isso, reduzir o tamanho da instância não necessariamente representa a maior oportunidade.

3.1 Amazon RDS

O Amazon RDS possui diferentes mecanismos e modelos de contratação. Dependendo da configuração, os custos podem envolver:

• Instância
• Armazenamento
• I/O
• Backup
• Transferência de dados
• Multi-AZ
• Licenciamento
• RDS Extended Support para versões que ultrapassaram o período de suporte padrão

Para otimização de custos de longo prazo em workloads estáveis, a análise deve priorizar database savings plans ou RIs, avaliando a estabilidade da carga e a compatibilidade de gerações de instâncias antes de assumir o compromisso financeiro. Os dois modelos não podem ser combinados na mesma carga, então a escolha deve ser feita por workload.

--

3.2 Amazon Aurora

No Aurora, é importante analisar não apenas a capacidade computacional, mas também o padrão de I/O. O serviço oferece duas configurações de armazenamento:

• Aurora Standard: além do uso das instâncias e do armazenamento, cobra por milhão de requisições de I/O. É a melhor escolha quando o gasto com I/O fica abaixo de 25% do gasto total com Aurora.

• Aurora I/O-Optimized: não cobra pelas operações de leitura e escrita, e o custo fica concentrado no uso das instâncias e no armazenamento. É a melhor escolha quando o gasto com I/O chega a 25% ou mais do gasto total com Aurora.

A mudança de Standard para I/O-Optimized pode ser feita uma vez a cada 30 dias, e o caminho inverso pode ser feito a qualquer momento. Por isso, a decisão deve ser baseada no comportamento real da workload e revisada periodicamente.

--

3.3 Database savings plans

Os database savings plans ampliam as possibilidades de otimização para workloads de banco de dados. Atualmente, eles podem oferecer até 35% de economia e possuem cobertura para diversos serviços, incluindo:

• Amazon RDS
• Amazon Aurora
• Amazon DynamoDB
• Amazon ElastiCache
• Amazon DocumentDB
• Amazon Neptune
• Amazon Keyspaces
• Amazon Timestream
• AWS DMS
• Amazon OpenSearch Service

Eles também podem se aplicar a determinados usos provisionados e serverless elegíveis. Uma característica importante é a flexibilidade entre determinados serviços, regiões, famílias e gerações elegíveis.

--

3.4 Database savings plans x Reserved instances

A escolha deve considerar a estabilidade e a estratégia tecnológica.

As RIs podem fazer sentido quando:

• A carga é estável
• A arquitetura é previsível
• A organização conhece bem o padrão de utilização
• Existe pouca expectativa de mudança

Os database savings plans podem fazer sentido quando:

• Existe necessidade de maior flexibilidade
• Existe possibilidade de modernização
• Diferentes serviços de banco podem ser utilizados
• Existe possibilidade de mudança de família ou região
• Existe utilização elegível consistente

Antes de adquirir qualquer compromisso, o histórico de utilização deve ser analisado. Como os dois modelos não podem ser combinados na mesma carga, a decisão deve ser feita por workload.

4. Sistemas operacionais e o impacto em FinOps

O sistema operacional pode alterar bastante o custo de uma workload. Os sistemas Linux, Windows e macOS possuem características diferentes de licenciamento, cobrança e disponibilidade.

4.1 Linux

Distribuições sem licença comercial adicional podem evitar custos de licença associados ao sistema operacional. Também existe a possibilidade de utilizar arquiteturas ARM, como AWS Graviton, quando a aplicação for compatível. Porém, não é correto afirmar que o Graviton será automaticamente mais barato para qualquer workload. Embora instâncias baseadas em Graviton ofereçam nativamente um custo por hora cerca de 20% menor e prometam até 40% mais eficiência em preço/desempenho frente às opções x86 equivalentes, o ganho real varia.

É necessário avaliar:

• Compatibilidade (arquitetura ARM x x86)
• Desempenho (ganho real de throughput ou latência)
• Custo (comparativo de precificação direta das famílias)
• Dependências (bibliotecas compiladas e pacotes do ecossistema)
• Esforço de migração (homologação, pipeline de CI/CD e suporte a multi-arch)
• Comportamento da aplicação (perfil de uso de memória, CPU, etc)

--

4.2 Windows

O Windows possui custos relacionados ao licenciamento. Em ambientes Windows, FinOps deve considerar não apenas o tamanho da instância, mas também:

• Licença Windows Server / SQL Server
• Modelo de licenciamento
• Quantidade de CPUs
• Possibilidade de BYOL
• Requisitos de hardware
• Arquitetura da aplicação

Em workloads com licenciamento por núcleo, reduzir a quantidade de CPUs pode também reduzir o custo de licenciamento. Por isso, no Windows, o rightsizing pode gerar economia tanto na infraestrutura quanto nas licenças. A redução, porém, deve ser feita somente quando o desempenho da aplicação continuar adequado e o modelo de licenciamento permitir.

--

4.3 macOS

O Amazon EC2 permite executar macOS em hosts físicos dedicados Apple, principalmente para desenvolvimento, testes e builds de aplicações para o ecossistema Apple. Há características específicas, então os pontos abaixo devem ser considerados:

• Utilização de dedicated hosts
• Cobrança mínima de 24 horas para o host
• Disponibilidade regional
• Capacidade limitada
• Ausência de spot
• Possibilidade de utilizar savings plans

Por isso, uma estratégia FinOps para macOS deve considerar a utilização real dos hosts e o perfil diário de builds. É necessário prestar atenção, pois um host subutilizado pode gerar custos desnecessários.

5. AWS Pricing Calculator

A AWS pricing calculator é uma ferramenta importante para estimar custos antes da implementação de uma arquitetura.

Ela pode ser utilizada para simular:

• EC2
• RDS
• Lambda
• S3
• Transferência de dados
• Entre outros serviços da AWS

Um processo simples:

1. Definir a região: os preços podem variar bastante entre regiões.

2. Escolher os serviços: adicionar os componentes necessários para representar a arquitetura.

3. Definir a capacidade: para isso, podemos considerar quantidade, tipo de instância, memória, CPU, armazenamento, horas de utilização, requisições e tráfego.

4. Comparar modelos de contratação: on-demand, savings plans, reserved instances e spot.

5. Considerar custos indiretos: EBS, snapshots, transferência de dados, NAT gateway, load balancers, IP público, logs e backups.

Uma estimativa de EC2 isolada não representa o custo total da arquitetura.

Link: https://calculator.aws/#/

6. Ferramentas de FinOps na AWS

A AWS oferece diversas ferramentas que podem ser utilizadas em conjunto. O Cost Optimization Hub consolida recomendações como rightsizing, recursos ociosos, savings plans, reserved instances e também apresenta estimativas de economia.

6.1 Cost Explorer

O AWS Cost Explorer ajuda a responder:

• Quanto gastamos?
• Onde gastamos?
• Qual serviço cresceu?
• Qual conta está consumindo?
• Qual região aumentou?
• Como o custo evoluiu?
• Qual tendência podemos observar?

É possível analisar os gastos por diferentes dimensões e períodos.

Documentação: https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html

--

6.2 AWS Budgets

O AWS Budgets permite definir orçamentos e acompanhar o consumo em relação a eles, enviando alertas quando os valores reais ou previstos ultrapassam os limites definidos.

Uma empresa pode criar budgets utilizando filtros como:

• Conta
• Serviço
• Região
• Tag
• Cost category
• Tipo de uso
• Outros filtros disponíveis conforme o tipo de budget

O ideal é criar uma cadeia de controle: budget, alerta, investigação, ação e acompanhamento.

Documentação: https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html

--

6.3 Cost Anomaly Detection

O Cost Anomaly Detection utiliza machine learning para identificar padrões de custo que podem indicar comportamento fora do esperado.

Pode ser utilizado para detectar situações como:

• Aumento repentino de consumo
• Criação inesperada de recursos
• Crescimento anormal de um serviço
• Alterações de utilização

Documentação: https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html

--

6.4 Cost Optimization Hub

O Cost Optimization Hub consolida recomendações de otimização em um único ambiente.

Entre as recomendações estão:

• Rightsizing
• Recursos ociosos
• Savings plans
• Reserved instances
• Determinadas oportunidades de otimização de recursos

A ferramenta também considera informações comerciais específicas da conta ao estimar economias.

Documentação: https://docs.aws.amazon.com/cost-management/latest/userguide/coh-getting-started.html

--

6.5 Compute Optimizer

O Compute Optimizer analisa o histórico de utilização dos recursos, recomenda ajustes de tamanho (rightsizing) e aponta recursos ociosos. As recomendações também aparecem no Cost Optimization Hub, onde podem ser priorizadas junto com as demais oportunidades de economia.

Pode fornecer recomendações relacionadas a recursos como:

• Instâncias EC2 e Auto Scaling groups
• Volumes EBS
• Funções Lambda
• Instâncias RDS
• Entre outros serviços da AWS

Antes de aplicar alguma recomendação, é necessário avaliar:

• CPU
• Memória
• Throughput
• I/O
• Latência
• Picos de uso
• Criticidade da aplicação
• Comportamento da aplicação

Documentação: https://docs.aws.amazon.com/compute-optimizer/latest/ug/supported-resources.html

--

6.6 AWS Organizations

Em ambientes maiores, centralizar tudo em uma única conta pode dificultar a governança e a alocação de custos. O AWS Organizations permite estruturar múltiplas contas.

Uma organização pode, por exemplo, separar:

• Produção
• Desenvolvimento
• Homologação
• Segurança
• Dados
• Workloads específicas

A estrutura correta depende do modelo operacional da empresa. O objetivo não é criar várias contas, mas criar uma estrutura que facilite:

• Governança
• Segurança
• Responsabilidade financeira
• Isolamento
• Auditoria
• Controle de custos

O AWS Organizations também oferece faturamento consolidado, que centraliza a cobrança de todas as contas-membro em uma única fatura, permitindo combinar o uso entre as contas e compartilhar os benefícios de descontos por volume, reserved instances e savings plans dentro da organização.

Documentação: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html

--

6.7 CUR e Data Exports

Quando a empresa precisa de mais detalhe do que o Cost Explorer oferece, os dados de billing podem ser exportados para o S3 e analisados depois.

Um fluxo comum é:

Billing - Data Exports - S3 - Athena - Dashboard (por exemplo, Amazon Quick Sight).

Com essa estrutura, é possível montar análises personalizadas, como:

• Custo por serviço
• Custo por região
• Custo por conta
• Custo por ambiente
• Custo por aplicação
• Custo por cliente
• Custo por centro de custo

Documentação: https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html

--

6.8 Tags e alocação de custos

Um dos pilares de FinOps é responder “Quem é responsável por este custo?” Para isso, uma organização pode utilizar tags como:

Environment    = prod
Project        = ecommerce-platform
Application    = checkout-api
Department     = it
BusinessUnit   = ecommerce
CostCenter     = it-042
TechnicalOwner = cloud-team

Para manter uma política de tags, é necessário:

• Definir um padrão de nomes e valores
• Aplicar as tags
• Ativar as tags relevantes como cost allocation tags no console de Billing
• Monitorar a conformidade, por exemplo com tag policies do AWS Organizations
• Tratar os recursos sem identificação

Tags bem estruturadas permitem análises mais precisas e facilitam o processo de showback e chargeback.

7. O que otimizar primeiro?

Não existe uma ordem universal para todas as empresas, mas uma análise prática pode começar pelos pontos de menor risco e retorno mais rápido.

7.1 Recursos claramente ociosos

É o ponto de partida mais simples, pois são recursos que geram custo sem entregar valor e a remoção deles raramente afeta o ambiente. Por exemplo:

• Instâncias EC2 sem utilização
• Volumes EBS não associados a nenhuma instância
• Elastic IPs não associados
• Snapshots antigos ou desnecessários
• Load balancers sem destinos ativos
• NAT gateways sem tráfego
• Recursos criados para testes e esquecidos

--

7.2 Recursos superdimensionados

Depois de eliminar o que está ocioso, o próximo passo é o rightsizing, que consiste em ajustar o tamanho dos recursos que estão em uso, mas com mais capacidade do que precisam. Para isso, podem ser analisados:

• CPU
• Memória
• I/O
• Rede
• Utilização histórica, incluindo picos e sazonalidade

Olhar só a média não é o correto, pois uma instância com uso médio baixo pode ter picos que justificam o tamanho atual. Por isso, vale analisar um período representativo, no mínimo os últimos 30 dias e o ideal, 3 meses, incluindo fechamento de mês ou datas sazonais. Também é importante testar a mudança antes de aplicá-la em produção.

--

7.3 Ambientes que podem ser desligados

Nem todo ambiente precisa ficar ligado 24 horas por dia. Os principais candidatos são:

• Desenvolvimento
• Homologação
• Laboratórios
• POCs

--

7.4 Armazenamento

O custo de armazenamento costuma crescer aos poucos, então vale revisar:

• Classe: dados pouco acessados podem ir para classes mais baratas do S3.

• Retenção e lifecycle: regras de lifecycle movem ou apagam dados antigos automaticamente.

• Snapshots: é comum acumular snapshots antigos que ninguém usa mais.

• Volumes: os volumes EBS gp2 podem em muitos casos, ser migrados para gp3, que costuma sair mais barato.

• Dados sem acesso: o S3 Storage Lens ajuda a identificar buckets e padrões de armazenamento pouco acessados ou inativos, permitindo encontrar oportunidades de otimização e aplicação de políticas de ciclo de vida.

Documentação: https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.html

--

7.5 Rede

Custos de rede podem passar despercebidos. Vale revisar:

• NAT Gateway: cobra por hora e pelo volume de dados processados.

• Endpoints: Gateway VPC Endpoints para S3 e DynamoDB permitem evitar o tráfego pelo NAT gateway e não possuem cobrança adicional.

• Transferência entre zonas de disponibilidade: tráfego entre AZs pode gerar cobranças de transferência de dados.

• Transferência para a internet: o tráfego de saída pode gerar cobranças e crescer rapidamente em workloads com grande volume de dados.

• Arquitetura de VPC: o desenho da rede influencia o caminho do tráfego e pode impactar os custos de NAT, endpoints e transferência de dados.

--

7.6 Arquitetura

Algumas mudanças de arquitetura reduzem custo de forma mais duradoura. Vale avaliar:

• Graviton: instâncias com processadores da AWS, que costumam ter melhor custo-benefício.

• Serverless: paga-se pelo uso real, sem manter servidores ligados o tempo todo.

• Auto Scaling: a capacidade acompanha a demanda, em vez de ficar dimensionada pelo pico.

• Serviços gerenciados: reduzem o esforço de operação e manutenção.

• Modernização: revisar aplicações antigas pode abrir espaço para as opções acima.

--

7.7 Compromissos

Compromissos devem vir por último, depois de eliminar desperdícios e ajustar os recursos. Assim, o compromisso é feito sobre uma base estável e já otimizada, e não sobre um consumo que ainda vai diminuir.

• Savings plans
• Reserved instances
• Outros modelos de compromisso

8. Ambiente de desenvolvimento e homologação

Ambientes não produtivos normalmente apresentam oportunidades de otimização. Uma estratégia simples pode ser ligar, utilizar e depois desligar. Por exemplo, um ambiente utilizado somente durante o horário comercial pode não precisar permanecer ativo 24 horas por dia.

O desligamento pode ser automatizado de diferentes formas, conforme a arquitetura. As mais comuns são:

• Resource Scheduler (Systems Manager Quick Setup): liga e desliga instâncias EC2 em horários definidos, a partir de uma tag, inclusive em várias contas e regiões. O Quick Setup em si não tem custo.

• EventBridge Scheduler: agenda ações em horários definidos e pode chamar diretamente APIs da AWS, como as de parar e iniciar instâncias, sem precisar de uma função Lambda.

• AWS Step Functions: indicado quando o desligamento envolve várias etapas ou dependências, como parar a aplicação antes do banco.

• Entre outros métodos.

Antes de automatizar, avalie:

• Banco de dados: no RDS, uma instância pode ficar parada por no máximo 7 dias seguidos. Depois disso, ela é religada automaticamente. Enquanto está parada, continuam sendo cobrados o armazenamento, os backups e o IP público, se houver. Instâncias que possuem uma réplica de leitura ou que são réplicas de leitura não podem ser paradas.

• Aplicações: verificar se dependem do banco durante o período de parada.

• Integrações: verificar integrações que possam tentar acessar o banco.

• Jobs: validar jobs, ETLs, scripts e processos agendados.

• Backups: verificar políticas de backup e retenção.

• Dependências externas: identificar sistemas externos que dependam da disponibilidade do banco.

• Requisitos de disponibilidade: confirmar se o ambiente permite indisponibilidade temporária.

Documentação: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_StopInstance.html

Documentação: https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-scheduler.html

9. Amazon S3

No S3, FinOps pode atuar em:

• Classe de armazenamento
• Lifecycle policies
• Dados sem acesso
• Versões antigas de objetos, em buckets com versionamento
• Uploads multipart incompletos
• Retenção
• Requisições
• Transferência

O S3 Intelligent-Tiering é uma boa opção quando o padrão de acesso aos dados é desconhecido ou muda com o tempo. Ele move os objetos automaticamente entre as camadas de acesso conforme o uso. Não há cobrança pela recuperação dos dados, mas existe uma pequena taxa de monitoramento por objeto. Objetos menores que 128 KB não são monitorados e permanecem na camada de acesso frequente.

Para dados armazenados por mais tempo e acessados com pouca frequência, classes como Standard-IA e Glacier podem reduzir o custo de armazenamento. Porém, elas possuem cobrança pela recuperação dos dados e períodos mínimos de armazenamento, sendo 30 dias na Standard-IA, 90 dias no Glacier Instant Retrieval e Glacier Flexible Retrieval e 180 dias no Glacier Deep Archive. Se o objeto for excluído ou movido antes desse período, pode haver cobrança pelo tempo restante.

A escolha deve considerar o custo, a frequência de acesso e o tempo necessário para recuperar os dados.

Documentação: https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html

10. Framework prático de FinOps para AWS

Uma implementação inicial pode seguir 6 etapas. Elas seguem as fases do ciclo de FinOps, ou seja, as duas primeiras ficam em “Informar”, as duas seguintes em “Otimizar” e as duas últimas em “Operar”.

Etapa 1: visibilidade

Saber quanto se gasta e onde.

• AWS Organizations
• Cost Explorer
• Tags
• Data Exports
• Dashboards

Etapa 2: alocação

Saber quem é responsável por cada custo.

• Contas
• Projetos
• Centros de custo
• Owners
• Ambientes

Etapa 3: otimização

Reduzir desperdício e ajustar o que está em uso.

• Recursos ociosos
• Rightsizing
• Armazenamento
• Rede
• Arquitetura

Etapa 4: compromissos

Garantir desconto sobre a base que já foi otimizada.

• Savings plans
• Reserved instances
• Outros modelos específicos

Etapa 5: governança

Evitar que o desperdício volte.

• Budgets
• Cost Anomaly Detection
• Políticas
• Responsabilidades
• Processos

Etapa 6: valor

Mostrar o que o gasto em cloud entrega para o negócio.

• Custo unitário
• Eficiência
• Produtividade
• Margem
• Relação entre gasto cloud e resultado do negócio

11. Conclusão

FinOps não é apenas reduzir custos, é entender como os recursos estão sendo utilizados e escolher a melhor estratégia para cada recurso. Cada cenário exige um modelo de contratação diferente, seja buscando flexibilidade, descontos de longo prazo ou oportunidades pontuais, enquanto práticas de dimensionamento, automação e melhorias na arquitetura eliminam os desperdícios do dia a dia. O mais importante é acompanhar o custo, entender sua origem, identificar oportunidades e medir o resultado das otimizações. No fim das contas, a prática de FinOps transforma a gestão da cloud em uma estratégia guiada por dados reais, garantindo que cada centavo investido traga retorno para o negócio.