DEV Community: Bianca Szimanski

FinOps na AWS: guia para controlar custos em cloud

Bianca Szimanski — Wed, 30 Sep 2026 16:37:37 +0000

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:

Definir a região: os preços podem variar bastante entre regiões.
Escolher os serviços: adicionar os componentes necessários para representar a arquitetura.
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.
Comparar modelos de contratação: on-demand, savings plans, reserved instances e spot.
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.

FinOps na AWS: configurando o FinOps Agent e integrando com o Slack

Bianca Szimanski — Thu, 17 Sep 2026 23:18:39 +0000

1. Introdução

Este artigo tem como objetivo documentar a configuração do AWS FinOps Agent e sua integração com o Slack, desde a habilitação dos pré-requisitos até o recebimento das mensagens no canal. O FinOps Agent foi lançado em junho de 2026, com o objetivo de investigar os custos na conta da AWS, sendo possível integrá-lo às ferramentas de trabalho Slack e Jira.

Em ambientes corporativos, os dados de custo da AWS normalmente são consultados nas ferramentas nativas Cost Explorer, Compute Optimizer e Cost Optimization Hub. Esses ferramentas normalmente são acessadas apenas pelo time de FinOps ou de infraestrutura, enquanto os times de desenvolvimento que provisionam os recursos raramente as consultam. Sem monitoramento ativo, o time pode demorar para identificar quando um custo sobe. A integração do FinOps Agent com o Slack ou Jira atende esse ponto, pois o agente consolida as análises das 3 ferramentas e publica o resultado no canal ou em um ticket, onde o time trabalha diariamente. Isso aproxima a informação de custo de quem provisiona os recursos e reduz a chance de uma anomalia passar despercebida.

2. O AWS FinOps Agent

O agente é construído com base no Amazon Bedrock e oferece 4 recursos principais:

Consulta de custo em linguagem natural, utilizando os dados reais de custo e uso da conta.
Investigação de anomalia disparada por evento. Quando o AWS Cost Anomaly Detection identifica um desvio, o agente investiga a causa raiz e pode publicar um relatório consolidado em um canal do Slack, ou criar um ticket no Jira com o resultado.
Consolidação das recomendações do Cost Optimization Hub e do Compute Optimizer.
Relatórios recorrentes agendados, em periodicidade diária, semanal ou mensal, nos formatos HTML, PDF ou PPT.

Para isso, o agente lê 5 serviços da conta:

AWS Cost Explorer: dados de custo e uso, previsão e análise de Savings Plans e Reserved Instances.
AWS Cost Anomaly Detection: monitoramento e detecção de anomalias, que funciona como gatilho das investigações. Está disponível no console do Billing and Cost Management e depende do Cost Explorer habilitado. Em contas recentes, normalmente já existe um monitor padrão criado, mas vale conferir na aba "Cost monitors".
AWS Cost Optimization Hub: recomendações de otimização e estimativas de economia.
AWS Compute Optimizer: recomendações detalhadas de rightsizing por recurso.
AWS CloudTrail: logs de atividade de API, utilizados para identificar as alterações de infraestrutura ocorridas durante uma anomalia. Neste caso, o CloudTrail permite correlacionar o aumento de custo com a ação que o originou, identificando qual usuário ou role executou a alteração e em que momento.

Documentação: https://docs.aws.amazon.com/finops-agent/latest/userguide/what-is.html

3. Pré-requisitos

Para a implementação, alguns recursos precisam estar configurados:

Conta da AWS com acesso administrativo, ou permissão para criação de IAM roles.
Console na região us-east-1, única região disponível durante a fase de public preview.
AWS Cost Anomaly Detection disponível, que é o que dispara as investigações.
AWS Cost Optimization Hub e AWS Compute Optimizer habilitados.
Workspace do Slack com permissão para autorizar aplicativos.
Conta com volume de custos suficiente para gerar recomendações.

OBS: o Cost Optimization Hub e o Compute Optimizer precisam ser habilitados antes da criação do agente. Caso contrário, o agente é criado e responde as consultas normalmente, mas as recomendações de otimização podem retornar vazias.

4. Passo a passo

4.1. Habilitando o Cost Optimization Hub e o Compute Optimizer

Os dois serviços são gratuitos. Após a habilitação, a AWS pode levar algumas horas para gerar as recomendações, sendo assim, os dashboards podem aparecer vazios no primeiro acesso.

1.Acessar o Billing and Cost Management no console.

2.Localizar o Cost Optimization Hub e habilitar o serviço. No exemplo abaixo, o serviço já estava habilitado e apresentando as recomendações da conta:

3.Acessar o Compute Optimizer e habilitar o serviço. No exemplo abaixo, também já estava habilitado:

4.2. Criação do agente

1.Alterar a região do console para us-east-1, pois o serviço não é listado em outras regiões durante a public preview.

2.Em seguida, pesquisar o serviço AWS FinOps Agent, acessar e clicar em “Get started”:

3.Definir o nome e descrição:

4.Na etapa seguinte, configurar as permissões. A opção recomendada, “Auto-create a new FinOps Agent role”, cria automaticamente a role que o agente usa para ler os dados de custo da conta:

5.Em seguida, será necessário configurar a permissão de acesso da aplicação web ao agente. Trata-se de uma segunda permissão, diferente da anterior, que define o que a aplicação pode executar, como criar tarefas, visualizar o histórico de execução e gerenciar os arquivos de contexto. Neste caso, é possível selecionar a opção “Auto-create a new FinOps Operator role” para criar a role automaticamente:

4.3. Integração com o Slack

1.Nesta etapa, será necessário selecionar a opção “Connect with Slack” e clicar em “Add integration” para abrir a tela de configuração da integração:

2.Na próxima tela, clicar em “Next”:

3.Em seguida, será necessário permitir que o FinOps Agent acesse o workspace do Slack, clicando em “Authorize with Slack”:

4.Em seguida, adicionar a URL do workspace e clicar em “Continue” para efetuar o login:

5.Após efetuar o login na conta do Slack, clicar em “Allow” para permitir o acesso:

6.O Slack foi conectado com sucesso. Em seguida, clicar em “Close” para fechar a aba e retornar à tela de início da integração:

7.Em seguida, criar um canal no Slack (por exemplo, “aws-finops”), abri-lo, clicar na aba Agents & apps e selecionar “Add Agent or App” para adicionar o AWS FinOps Agent.

OBS: o agente só publica em canais dos quais o app é membro. Se o app não for adicionado ao canal, a entrega falha.

8.Clicar no nome do canal com o botão esquerdo, acessar a aba About e copiar o “Channel ID” exibido ao final:

OBS: o Channel ID começa com a letra C. IDs iniciados com D pertencem a conversas diretas e não funcionam na integração

9.Voltar à tela de integração, colar o Channel ID, selecionar a integração “BS” na etapa Third-party integrations e clicar em “Next” para continuar:

10.Por fim, revisar e clicar em “Create agent”:

4.4. Testando o agente e a integração com o Slack

Nesta etapa será realizado o teste de funcionamento do agente e a validação da entrega das mensagens no canal do Slack.

1.Após configurar o canal do Slack, acessar o serviço AWS FinOps Agent e selecionar a aba “Agents” para abrir a interface e realizar as consultas:

Primeira consulta:

Os testes foram realizados em uma conta com baixo volume de custo, o que limita o alcance das recomendações.

O arquivo HTML foi gerado, conforme a solicitação:

Segunda consulta:

O arquivo HTML foi gerado, conforme a solicitação:

Terceira consulta:

O VPC aparece com $3.58 em uma mensagem e $2.58 em outra. O primeiro valor é gasto realizado nos últimos 30 dias, de 8 de agosto a 6 de setembro. O segundo é a previsão para setembro fechado. Antes de comparar valores entre consultas, é necessário verificar o período e se o dado é realizado ou previsto.

O valor atual de $0.63 retornado pelo agente para o custo de VPC em setembro, foi validado no Cost Explorer:

5. Lições aprendidas

O Cost Optimization Hub e o Compute Optimizer devem ser habilitados antes da criação do agente. Sem isso, as recomendações retornam vazias, mesmo que o agente esteja configurado corretamente.
A configuração envolve duas permissões diferentes, sendo a IAM role utilizada pelo agente para leitura dos dados da conta e a permissão de acesso da aplicação web ao agente.
O CloudTrail é o componente que permite a correlação entre variação de custo e alteração de infraestrutura, identificando o usuário ou role responsável.
A integração com o Slack ou Jira é o que viabiliza o uso pelo time de engenharia.
As respostas devem ser validadas no Cost Explorer durante as primeiras semanas de uso, para verificar se o agente está retornando os dados corretos.
O arquivo de contexto é opcional no fluxo, mas determina a qualidade prática das respostas, por incorporar informações que não estão disponíveis nas APIs de custo. (https://docs.aws.amazon.com/finops-agent/latest/userguide/getting-started.html).

6. Conclusão

Neste artigo foi possível validar a configuração do AWS FinOps Agent e sua integração com o Slack. O processo não exigiu provisionamento de infraestrutura adicional. O agente ainda está em public preview, com restrição de região, resposta em inglês e resultado que depende de conferência na conta. Por esses motivos, ainda não é indicado como fonte oficial de dados para basear o fechamento de custo, pois se trata de uma ferramenta recente que está passando por uma fase de testes.

VPC Peering: conectando redes privadas entre contas e regiões na AWS

Bianca Szimanski — Sun, 13 Sep 2026 02:44:25 +0000

1. Cenário de negócio

Neste projeto, será implementado um VPC peering entre duas VPCs que estão em contas e regiões distintas, sendo uma conta de infraestrutura e outra de segurança. Em ambientes corporativos, é comum que empresas adotem uma estratégia multi-account para isolar recursos e dividir responsabilidades por área. Por exemplo, o gerenciamento de DNS via Route 53, processos de backup e pipelines de CI/CD, podem ser centralizados na conta de infraestrutura, enquanto a conta de segurança pode ser utilizada para centralizar scanners de vulnerabilidade, soluções de VPN, SIEM e outros serviços voltados à proteção e auditoria do ambiente.

Quando um recurso hospedado na VPC de infraestrutura precisa se comunicar com os serviços da VPC de segurança, é necessário estabelecer uma integração de rede privada entre as contas. Para esse tipo de comunicação direta, o VPC peering é uma solução adequada em ambientes menores ou de arquitetura simples. Em empresas de maior porte ou com requisitos de escalabilidade, o Transit Gateway atende melhor.

2. Arquitetura do ambiente

Foram criadas duas contas, sendo a BS-Infra responsável pela infraestrutura, onde estão hospedados, por exemplo, um servidor de aplicação e um banco de dados em subnets privadas, além de um servidor de testes em subnet pública. Já a conta BS-Security possui uma subnet pública, também utilizada por um servidor de testes e duas subnets privadas, sendo uma destinada ao servidor de VPN e outra voltada à servidores que hospedam ferramentas de segurança, como Wazuh e Vault, por exemplo. Em ambas as contas, o servidor de testes foi provisionado apenas para validar a conectividade do VPC peering.

Os workloads das duas contas estão distribuídos em 3 zonas de disponibilidade, em duas regiões diferentes. Em cenários reais, o ideal é distribuir os workloads estrategicamente entre diferentes AZs para garantir alta disponibilidade. Já a escolha por múltiplas regiões, normalmente é pensada em disaster recovery, custo, latência ou normas de compliance que não permitem que determinados dados sejam hospedados fora do país de origem.

As subnets privadas possuem tabelas de rotas configuradas para direcionar o tráfego de saída para um NAT gateway, permitindo o acesso à internet (por exemplo, para atualização de pacotes e instalação de dependências) sem expor diretamente os recursos internos. O NAT gateway, por padrão, é provisionado em uma subnet pública, mesmo que o roteamento seja originado das subnets privadas, pois é necessário realizar a tradução de endereços de origem (SNAT), substituindo os IPs privados das instâncias por um endereço IP público associado ao NAT gateway. Já a subnet pública é associada a uma tabela de rotas que possui um caminho para um internet gateway anexado à VPC, permitindo o tráfego bidirecional, ou seja, a comunicação de entrada e saída com a internet. Em situações reais, jamais se deve colocar um banco de dados ou servidor de aplicação em subnets públicas, por questões de segurança.

Será realizado um peering entre as duas VPCs, com o objetivo de estabelecer uma comunicação privada e direta entre elas, sem que o tráfego precise passar pela internet pública.

O ambiente também conta com o VPC Flow Logs, que realiza a captura do tráfego das VPCs (como IPs de origem/destino, portas e protocolo, e se o tráfego foi aceito ou rejeitado). Esses logs serão centralizados no CloudWatch, facilitando análise e troubleshooting de conectividade. Vale mencionar que, em cenários corporativos com alto volume de tráfego, outra alternativa comum é enviar os flow logs diretamente para um bucket S3 e utilizar o Amazon Athena para realizar consultas SQL sob demanda.

3. Elementos Chave

Esta seção descreve os principais componentes utilizados na implementação. Cada um deles tem um papel específico para garantir que a comunicação entre as VPCs funcione corretamente.

3.1. VPC Peering

Estabelece uma comunicação privada e direta entre duas VPCs, podendo ser na mesma conta, entre contas diferentes ou até entre regiões diferentes. O tráfego entre as VPCs não passa pela internet pública, ele é roteado diretamente pela infraestrutura da AWS, o que garante menor latência e maior segurança. Para funcionar, além de criar a conexão de peering, é necessário configurar as tabelas de rotas de ambas as VPCs e ajustar os security groups para permitir o tráfego entre os CIDRs envolvidos. Vale destacar que o VPC peering não é transitivo, ou seja, se a VPC A tem peering com a VPC B, e a VPC B tem peering com a VPC C, a VPC A não consegue se comunicar com a VPC C automaticamente. Cada conexão precisa ser estabelecida de forma independente. Trata-se de uma conexão ponto a ponto.

Documentação: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html

3.2. NAT Gateway (NGW)

Permite que recursos (neste caso, as duas instâncias) em subnets privadas enviem tráfego para a internet, sem que a internet estabeleça conexões diretas com esses recursos. Isso é possível graças ao processo de SNAT (Source Network Address Translation), que substitui o IP privado da origem pelo IP público do NAT gateway antes de encaminhar o pacote para a internet. Quando a resposta retorna, o NAT gateway realiza o processo inverso, entregando o tráfego ao recurso correto dentro da subnet privada. Por esse motivo, o NAT gateway deve ser provisionado em uma subnet pública, pois é necessário ter um IP público para executar essa tradução.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html

3.3. Internet Gateway (IGW)

Permite o tráfego bidirecional entre recursos em subnets públicas e a internet. Para isso, o recurso precisa de um IP público associado e uma rota configurada apontando para o internet gateway. Diferentemente do NAT gateway, a comunicação por meio do internet gateway ocorre nos dois sentidos, então, a instância pode iniciar conexões com a internet, e a internet também pode iniciar conexões com a instância. Na prática, um bom exemplo é um servidor web em subnet pública, onde ele recebe requisições HTTPS de usuários na internet e responde a elas (pode ser um site institucional, um portal acessível externamente ou uma API consumida por um aplicativo, por exemplo). Outro exemplo comum é um bastion host, que pode ficar em uma subnet pública para permitir que administradores acessem os recursos internos, seja via SSH (em ambientes Linux) ou RDP (em ambientes Windows), funcionando como um ponto de entrada controlado.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html

3.4. Route Tables

As tabelas de rotas definem como o tráfego de rede é roteado dentro da VPC, direcionando os pacotes para destinos como NAT gateway, internet gateway, conexões de VPC peering, entre outros.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html

3.5. Security Groups

Atuam como um firewall a nível de instância, controlando o tráfego de entrada e saída. Por exemplo, para acesso via SSH, é necessário permitir a porta 22 no security group e restringir o IP de origem. No entanto, em ambientes mais seguros, é comum utilizar bastion host ou acesso via AWS SSM, eliminando a necessidade de exposição dessa porta. Um ponto importante é que os security groups são stateful, ou seja, ao permitir o tráfego de entrada em uma porta, a resposta desse tráfego é automaticamente permitida na saída, sem precisar criar uma regra explícita para isso, diferente das NACLs (Network Access Control List), que atuam a nível de subnet e são stateless, exigindo regras explícitas para entrada e saída. Em ambientes corporativos, o ideal é utilizar os dois em conjunto, para garantir uma melhor proteção dos recursos.

Documentação SG: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html
Documentação NACL: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html

3.6. VPC Flow Logs

Permite capturar informações sobre o tráfego de IP de entrada e saída das interfaces de rede da VPC. Os dados coletados incluem IPs de origem e destino, portas, protocolo e se o tráfego foi aceito ou rejeitado, o que o torna uma ferramenta muito útil para troubleshooting de conectividade (por exemplo, como identificar problemas de comunicação entre duas instâncias, detectar tráfego de rede suspeito, etc). Os logs podem ser publicados no CloudWatch Logs, S3 ou Data Firehose, dependendo da necessidade da empresa e do volume de dados.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

4. Implementação

Durante a implementação, os seguintes recursos serão configurados:

Contas AWS: duas contas ativas (BS-Infra e BS-Security), com permissão para criar os recursos.
VPCs: será criada uma em cada conta, com blocos CIDR privados que não se sobrepõem e seguem as diretrizes da RFC 1918. As subnets públicas e privadas foram criadas dentro do intervalo de endereçamento de cada VPC e associadas às suas respectivas tabelas de rotas.
NAT Gateway e Internet Gateway: serão configurados e associados às subnets corretas.
Security Groups: serão configurados para permitir apenas o tráfego entre as VPCs envolvidas no peering.
VPC Flow Logs: serão configurados em ambas as VPCs, com os logs publicados no CloudWatch.
Instâncias EC2: será criada uma em cada conta para realizar um teste (srv-infra-test e srv-sec-test).

5. Passo a passo

5.1. Criação das VPCs, subnets e tabelas de rotas

Nesta etapa, serão criadas as VPCs em cada conta, seguidas de duas subnets privadas e uma pública, distribuídas entre diferentes zonas de disponibilidade.
Conta: BS-Infra | Região: us-east-1 | VPC: VPC-BS-INFRA

1.Acessar o serviço de VPC e clicar em “Create VPC”:

A opção “VPC only” foi selecionada, permitindo que as subnets e demais recursos sejam configurados manualmente posteriormente. No campo “IPv4 CIDR”, será utilizado o bloco 172.31.0.0/16, que está contido dentro da faixa privada 172.16.0.0/12 definida pela RFC 1918. Essa norma estabelece 3 blocos de endereços IP reservados para redes privadas, sendo 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16.

A VPC foi criada com sucesso:

OBS: Quando há mais de uma VPC na conta, é possível filtrar a que está sendo utilizada no momento, para facilitar a visualização e organização:

2.Agora, será necessário criar as 3 subnets da VPC-BS-INFRA, conforme o diagrama:

Subnet INFRA-PRIVATE-APP

Selecionar a aba “Subnets” e clicar em “Create subnet”:

Em seguida, selecionar a VPC-BS-INFRA, definir o nome da subnet, IP e zona de disponibilidade.

OBS: no momento de definir o bloco CIDR da subnet, deve-se prestar atenção para que o bloco CIDR da subnet esteja contido dentro do bloco CIDR da VPC, pois a subnet é uma subdivisão da rede principal. Neste caso, vamos trabalhar com a máscara /16 para a rede, o que nos dá 65.536 endereços IP disponíveis, e /24 para as subnets, cada uma com 256 endereços, garantindo que cada subnet caiba perfeitamente dentro da VPC:

OBS: caso não seja necessário definir uma zona de disponibilidade, é possível selecionar a opção “No preference”. Neste caso específico, vamos trabalhar com a AZ A (us-east-1a), na subnet 1.

Já que serão criadas 3 subnets na mesma VPC, podemos criar as outras duas clicando em “Add new subnet” e por fim, “Create subnet” para concluir:

As 3 subnets foram criadas com sucesso:

OBS: a tabela abaixo explica o que significa cada coluna da aba “Subnets”:

3.Agora, será necessário criar as tabelas de rotas da VPC-BS-INFRA, para definir o roteamento das subnets privadas e da pública.

Ao criar uma VPC, a AWS provisiona automaticamente uma tabela de rotas principal, contendo uma única rota local (neste caso,a nossa VPC 172.31.0.0/16), que permite a comunicação interna entre todas as subnets da VPC. Subnets sem associação explícita herdam essa tabela por padrão:

Podemos renomeá-la como RTB-BS-INFRA-PRIVATE e torná-la a tabela de rotas para as duas subnets privadas:

Para editar, basta clicar em “Edit subnet associations”, na aba “Subnet associations” e selecionar as subnets privadas:

No final, as subnets ficarão associadas dessa forma:

Agora, será necessário clicar em “Create route table” para criar a tabela de rotas para a subnet pública:

OBS: o ideal, por boas práticas de arquitetura na AWS, é que sejam criadas route tables separadas para subnets públicas e privadas, mantendo cada camada com apenas as rotas necessárias para sua função.

Subnets públicas: route table com rota 0.0.0.0/0 apontando para um internet gateway.

Subnets privadas: route table com rota 0.0.0.0/0 apontando para um NAT gateway (ou sem rota de saída, se não precisar sair para a internet).

Por que separar?

Controle granular de tráfego por camada (aplicação, banco de dados, ferramentas, etc).
Subnets privadas não ficam expostas diretamente à internet.
Facilita aplicar regras diferentes por ambiente ou serviço.
Segurança por princípio do menor privilégio.

Após clicar em “Create route table”, será necessário inserir um nome (neste caso, será RTB-BS-INFRA-PUBLIC para a subnet pública) e selecionar a VPC:

Para editar, basta clicar em “Edit subnet associations”, na aba “Subnet associations” e selecionar a subnet pública:

Ficará dessa forma:

Ao finalizar, teremos duas tabelas de rotas:

No entanto, ainda não existe conectividade de rede para nenhuma das subnets. Por isso, agora será necessário configurar o internet gateway para a subnet pública e o NAT gateway para as subnets privadas.

OBS: lembrando que o uso do NAT gateway não é obrigatório. Ele só é necessário quando os recursos em subnets privadas precisam sair para a internet de forma segura (por exemplo, para atualizar pacotes de software ou instalar dependências). No geral, o que torna uma subnet privada é simplesmente não possuir uma rota para o internet gateway na tabela de rotas. Isso por si só já a define como privada.

Em seguida, será necessário criar um internet gateway. Para isso, será necessário acessar a aba “Internet gateway” e clicar em “Create internet gateway”:

Definir o nome, neste caso, será IGW-BS-INFRA-PUBLIC:

Após a criação do IGW, será necessário vinculá-lo à VPC-BS-INFRA, clicando em “Actions” e “Attach to VPC”:

Em seguida, podemos voltar na aba “Route tables” e apontar a rota da subnet pública para o IGW que foi criado, clicando em “Routes” e “Edit routes”:

Devemos definir o destino 0.0.0.0/0, selecionar a opção “Internet Gateway” e escolher o IGW que foi criado anteriormente:

Por fim, a tabela de rotas ficará com duas rotas configuradas, sendo uma rota local para comunicação interna da VPC (172.31.0.0/16) e uma rota padrão apontando para o internet gateway, permitindo tráfego de entrada e saída com a internet (0.0.0.0/0):

Em seguida, podemos criar o NAT gateway, vinculá-lo à VPC-BS-INFRA e prosseguir com a configuração na tabela de rotas da mesma forma.

OBS: o NAT gateway necessita estar em uma subnet pública e com um Elastic IP alocado para funcionar corretamente. Ao selecionar a opção “Allocate Elastic IP”, é criada uma interface de rede com dois IPs: um público, utilizado para realizar o SNAT e se comunicar com a internet, e um privado, utilizado para a comunicação interna dentro da VPC.

Sendo assim, podemos criar o NAT gateway. Para isso, será necessário acessar a aba “NAT gateways” e clicar em “Create NAT gateway”:

Abaixo, alguns detalhes importantes na página de criação do NGW:

Availability mode:

Zonal: o NAT gateway fica em uma única AZ. Se essa AZ cair, as subnets privadas daquela AZ perdem saída para internet. É mais barato.
Regional: o NAT gateway é distribuído entre AZs automaticamente, com alta disponibilidade. É mais caro.

Na prática, muitas empresas ainda usam o modo zonal e criam um NAT gateway por AZ (um em cada AZ onde há subnet privada), associando cada subnet privada ao NAT da sua própria AZ. Isso evita o tráfego cross-AZ (que tem custo) e mantém resiliência sem depender do modo regional.

Zonal ou regional em cenários corporativos?

O padrão corporativo geralmente é zonal com um NAT gateway por AZ. O modo regional é um recurso novo e tem custo mais alto. A abordagem consolidada do mercado é:

1 NAT gateway na subnet pública da AZ-a sendo usado pelas subnets privadas da AZ-a.
1 NAT gateway na subnet pública da AZ-b sendo usado pelas subnets privadas da AZ-b.

Connectivity type:

Público: permite que instâncias privadas acessem a internet. Requer Elastic IP. É o caso mais comum.
Privado: usado para rotear tráfego entre VPCs ou on-premises via VPN/Direct Connect, sem sair para internet.

Devemos deixar “público” se o objetivo é dar saída à internet para as subnets privadas. Devemos selecionar a subnet pública e clicar em “Allocate Elastic IP”:

Após criar o NAT gateway, é possível observar que uma ENI (Elastic Network Interface) foi criada automaticamente, ela possui um IP privado (172.31.3.123) para receber o tráfego dos recursos das subnets privadas, e um Elastic IP público (100.50.71.167) para se comunicar com a internet, realizando o SNAT, que substitui o IP privado de origem pelo IP público, mantendo os recursos privados invisíveis para a internet:

O IP elástico que foi alocado na criação do NGW, está localizado no serviço de EC2, na aba “Elastic IPs”.

OBS: um Elastic IP sem associação à algum recurso, gera custo (em dólar) na AWS. O custo atual é de $0,005 por hora por IP público não associado (ou associado a uma instância parada). Isso dá aproximadamente $3,60/mês por IP ocioso. Quando alocamos um Elastic IP sem usá-lo, está reservando um endereço do pool da AWS que poderia ser usado por outro cliente. A cobrança serve como incentivo para que os usuários não acumulem e liberem IPs ociosos, evitando desperdício desse recurso, uma vez que os endereços IPv4 públicos são recursos limitados.

Para evitar custos, o ideal é liberar os Elastic IPs que não estiverem em uso. Neste caso, o EIP será utilizado para o NAT, mas em outro cenário de teste, após realizá-lo, será importante liberar o IP, clicando em “Release Elastic IP addresses”:

Como boa prática para manter a organização dos recursos, podemos renomeá-lo com o nome do NGW, para facilitar as auditorias futuras:

Em seguida, podemos voltar na aba “Route tables” e configurar a tabela de rotas da subnet privada, apontando o destino 0.0.0.0/0 para o NAT gateway recém-criado, permitindo que os recursos privados acessem a internet através dele:

Por fim, as subnets privadas deverão ser associadas dessa forma:

E o “Resource map” da VPC ficará assim:

Agora, podemos criar a VPC na conta BS-Security e prosseguir da mesma forma, criando as subnets, tabela de rotas, Internet e NAT gateway:

Conta: BS-Security | Região: sa-east-1 | VPC: VPC-BS-SECURITY

1.Criação da VPC:

A VPC foi criada com sucesso:

2.Agora, será necessário criar as 3 subnets da VPC-BS-SECURITY, conforme o diagrama:

3.Após a criação das subnets, será necessário criar o Internet e o NAT gateway:

4.Em seguida, será necessário criar e configurar as tabelas de rotas:

Tabela RTB-BS-SEC-PRIVATE:

Tabela RTB-BS-SEC-PUBLIC:

5.2.Configuração do peering entre as VPCs

Após a criação das VPCs e subnets nas contas BS-Infra e BS-Security, o próximo passo será criar o peering entre as duas contas.

Conta: BS-Infra | Região: us-east-1 | Peering connection: VPC-BS-INFRA

1.Acessar o serviço de VPC, aba “Peering connections” e criar:

Será necessário definir um nome, por padrão, iremos adotar o prefixo “PCX”, que é uma convenção comum para peering connection, adotada pela própria AWS para nomenclaturas. Neste caso, será criada uma conexão do requester VPC-BS-INFRA para o accepter VPC-BS-SECURITY:

Alguns detalhes:

A requisição de conexão foi enviada:

Em seguida, será necessário acessar a conta BS-Security e aceitar:

Agora, será necessário configurar as rotas. Dependendo do caso de uso da empresa, podemos permitir a comunicação entre tabelas de rotas privadas, públicas ou ambas. Em cenários reais, o mais recomendado é conectar tabelas de rotas privadas entre si, mantendo os recursos sensíveis isolados da internet. Neste caso de teste, faremos com que a tabela pública da conta BS-Infra tenha comunicação com a tabela da conta BS-Security, e vice-versa. Em produção, é necessário analisar cada cenário para configurar o roteamento de acordo com os requisitos de conectividade e segurança.

Em seguida, podemos ir na route table da conta BS-Security e editar as duas tabelas:

Tabela RTB-BS-SEC-PRIVATE

Adicionar o IP de destino 172.31.0.0/16 da VPC-BS-INFRA e selecionar o peering connection criado:

Em seguida, podemos repetir o mesmo procedimento na route table pública:

Tabela RTB-BS-SEC-PUBLIC

Agora será necessário fazer o mesmo procedimento nas route tables da conta BS-Infra, com o IP de destino 10.0.0.0/16, referente à VPC-BS-SECURITY.

Tabela RTB-BS-INFRA-PRIVATE

Tabela RTB-BS-INFRA-PUBLIC

Agora teremos duas route tables vinculadas neste peering connection:

5.3. Criação de instâncias EC2 para testar a conexão entre as redes

Agora, será necessário criar duas instâncias, sendo uma em cada conta.

Conta: BS-Infra

1.Acessar o serviço EC2 e clicar em “Launch instance”:

2.Definir as opções abaixo:

Nome da instância: SRV-INFRA-TEST
AMI: neste caso, pode ser Amazon Linux 2023.
Tipo de instância: neste caso, pode ser t2.micro (é barata).
Key pair: não será criado o par de chaves. Caso a instância fosse acessada via SSH, por exemplo, seria necessário criar o par, pois a chave pública ficaria dentro da instância e a privada seria baixada no formato .pem ou .ppk para acesso via SSH.
Rede: VPC-BS-INFRA
Subnet: Pode ser a subnet pública para teste (INFRA-PUBLIC-SRV)
Auto-assign public IP: deixar habilitado para ser atribuído um IP público para a instância.
Firewall (Security Groups): como o acesso à instância será via SSM, não será necessário configurar regras de entrada (como SSH, por exemplo). Dessa forma, o security group pode ser definido apenas com regras de saída.

Para o teste, não será necessário alterar o tipo e tamanho do storage:

Podemos clicar em “Advanced details” para criar a IAM role que permitirá o acesso à incia via SSM. Para isso, será necessário anexar a política “AmazonSSMManagedInstanceCore” à role, que fornece as permissões usadas pelo AWS Systems Manager para gerenciar a instância:

Após isso, podemos clicar em “Launch instance” para criar a instância:

No security group, para acesso via SSM, por padrão é liberada apenas a saída para a internet (outbound), pois o SSM agent é quem inicia a comunicação com os endpoints da AWS na porta 443. Nenhuma regra de entrada (inbound) é necessária, o que elimina a exposição de portas como SSH (22) ou RDP (3389).

Neste caso, como será realizado um teste de ping, será necessário liberar tráfego ICMP no inbound do security group, restrito ao bloco de IP da VPC-BS-SECURITY (10.0.0.0/16):

Em seguida, podemos repetir o mesmo processo na conta BS-Security, para criar a instância:

E configurar o security group, liberando o ICMP no inbound, restrito ao bloco de IP da VPC-BS-INFRA (172.31.0.0/16):

5.4. Acesso às instâncias e teste de conectividade

Agora, vamos acessar as duas máquinas e testar um ping e telnet entre elas:

Instância: SRV-INFRA-TEST

Com o comando ip a, é possível visualizar o IP privado dessa máquina:

E também, diretamente no console:

Foi realizado um teste de conectividade via ping da instância SRV-INFRA-TEST (172.31.3.215) para a SRV-SEC-TEST (10.0.3.67).

O retorno foi bem-sucedido, confirmando a comunicação entre as máquinas.

Também é possível validar a conectividade TCP entre as instâncias utilizando o Telnet. Para isso, basta instalar a ferramenta nas duas máquinas e executar o teste informando o IP e a porta desejada.

sudo yum install telnet -y

Para isso, será necessário acessar os security groups das duas instâncias e liberar, por exemplo, a porta 22 (SSH) nas regras de entrada, permitindo testar a conectividade.

BS-Infra:

BS-Security:

Por fim, executar telnet <IP> <porta> em ambas as máquinas. O teste confirmou que a conectividade TCP entre as instâncias funcionou corretamente na porta 22. O retorno “Connected to” e a identificação do serviço OpenSSH demonstram que a comunicação entre as VPCs foi estabelecida com sucesso:

OBS: foi utilizada a porta 22, pois as instâncias Linux utilizadas já possuíam o serviço SSH disponível por padrão, não sendo necessária a instalação de serviços adicionais para a realização dos testes básicos.

5.5. Configuração do VPC Flow Logs

Para configurar, será necessário selecionar a VPC, neste caso a VPC-BS-INFRA e na aba de Flow Logs, clicar em “Create flow log”:

Podemos selecionar as opções “Accept”, “Reject” ou “All”, que definem o tipo de tráfego que será capturado. Neste caso, vamos utilizar a opção “All”, para registrar toda a comunicação, independentemente de o tráfego ter sido aceito ou rejeitado.

Na opção de agregação, podemos manter 1 minuto, para que um novo arquivo de log seja gerado a cada minuto:

Em seguida, podemos definir um destino para os logs. O S3 dificulta um pouco a leitura dos logs diretamente, então, caso optemos por armazená-los nele, podemos baixar os arquivos para análise local ou utilizar o Athena para filtrar e consultar os dados utilizando SQL. Já o CloudWatch Logs centraliza a visualização de logs, então, neste caso, vamos optar por ele. Para isso, será necessário criar um grupo de logs no CloudWatch.

Será necessário acessar o CloudWatch, e na aba “Log Management”, clicar em “Create log group”:

Podemos selecionar o tempo de retenção dos logs (neste exemplo, serão apenas 3 dias), também o log class (classes de armazenamento) e proteger os logs contra deleção acidental. Em cenários corporativos reais, o ideal seria também criptografar os logs, para manter a segurança em ambientes de produção.

Após criar o grupo de logs, podemos retornar à página de criação do Flow Logs e selecioná-lo para dar continuidade. Também podemos criar uma IAM role diretamente nesta tela, concedendo as permissões necessárias para que o Flow Logs possa enviar os registros ao CloudWatch Logs.

Em seguida, podemos customizar os registros dos logs, clicando em “Custom format” e selecionando as opções abaixo:

A criação foi feita com sucesso:

Em seguida, podemos repetir o mesmo procedimento com a VPC-BS-SECURITY:

5.6. Análise de tráfego das VPCs com o Flow Logs

Após criar os Flow Logs nas duas VPCs, podemos validar o monitoramento realizando, por exemplo, um telnet da VPC-BS-INFRA para a VPC-BS-SECURITY e, posteriormente, verificando no CloudWatch Logs se o tráfego foi registrado corretamente:

O log apresentou os IPs de origem e destino, a porta 22 e a ação “ACCEPT OK ”, confirmando que a comunicação entre as VPCs ocorreu com sucesso e foi devidamente monitorada pelo Flow Logs:

6.Conclusão

O recurso de VPC peering funciona sobre o backbone da rede privada da AWS e o tráfego entre as VPCs é roteado internamente pela infraestrutura global, sem nunca passar pela internet pública. Em conexões entre regiões diferentes, o tráfego é criptografado antes de sair das instalações da AWS, permanecendo sempre na rede global privada, o que reduz riscos de exposição externa e ataques como DDoS.

Foi possível validar na prática que o VPC peering funciona entre contas e regiões geográficas diferentes, conectando uma VPC em Norte da Virgínia (us-east-1) com uma VPC em São Paulo (sa-east-1). A conectividade foi comprovada através de testes com ping e telnet, onde a instância de origem conseguiu alcançar a instância de destino utilizando exclusivamente o IP privado, confirmando que o tráfego não passou pela internet pública.

O monitoramento foi realizado através do VPC Flow Logs, configurado nas duas contas, que registrou de forma detalhada todo o tráfego gerado durante os testes, incluindo IPs de origem e destino, portas, protocolo, quantidade de pacotes, bytes transferidos e a ação tomada pelo security group. Esse recurso é muito útil para troubleshooting, pois pode ajudar a descobrir onde o pacote morreu. Neste caso, por exemplo:

Se a conta de infraestrutura mostrasse ACCEPT no envio, mas a conta de segurança não registrasse nenhuma entrada correspondente, o problema poderia estar na configuração das tabelas de rotas ou no caminho até a VPC de destino.
Caso a conta de segurança registrasse o pacote chegando com o status REJECT, isso indicaria que a conectividade do VPC peering estaria funcionando, mas o tráfego poderia estar sendo bloqueado pelo security group ou pela NACL da instância de destino.