VPC: Ponto de extremidade VPC inativo

Esta regra identifica VPC Endpoints do tipo:

  • Interface

  • GatewayLoadBalancer

que não apresentaram atividade de tráfego ou conexões durante o período configurado.

O objetivo é detectar endpoints que continuam provisionados e gerando custo recorrente, mas que não estão sendo utilizados.


Contexto da regra e impacto no negócio

VPC Endpoints permitem conexão privada a serviços AWS e serviços SaaS via AWS PrivateLink.

Para endpoints do tipo Interface e Gateway Load Balancer:

  • Existe cobrança por hora provisionada.

  • Existe cobrança por volume de dados processado.

Mesmo sem tráfego, o custo por hora permanece ativo.

Cenários comuns:

  • Integrações descontinuadas.

  • Migração de arquitetura.

  • Testes que não foram removidos.

  • Ambientes temporários esquecidos.

Impactos financeiros:

  • Custo recorrente por endpoint provisionado.

  • Multiplicação do custo em ambientes multi-região.

  • Complexidade arquitetural desnecessária.

Sem governança, endpoints inativos tornam-se custo estrutural oculto.


Detalhamento técnico da regra

A regra executa análise regional das VPC Endpoints.


Como a regra é executada

  1. Autentica na conta AWS por região.

  2. Lista todos os VPC Endpoints via describe_vpc_endpoints.

  3. Aplica filtros de tag (inclusão/exclusão).

  4. Filtra apenas endpoints dos tipos:

    • Interface

    • GatewayLoadBalancer

  5. Consulta métricas no CloudWatch para o período configurado:

    • BytesProcessed

    • ActiveConnections

    • NewConnections

  6. Para cada métrica:

    • Soma os valores diários (Statistics = Sum).

  7. Se todas as métricas forem iguais a zero no período analisado, o endpoint é sinalizado.


Lógica aplicada

Um endpoint será considerado inativo quando:

  • Tipo = Interface ou GatewayLoadBalancer

  • Durante o período configurado:

    • BytesProcessed = 0

    • ActiveConnections = 0

    • NewConnections = 0

Caso qualquer métrica seja maior que zero, o endpoint é considerado ativo.


Campos analisados

Endpoint:

  • VpcEndpointId

  • VpcEndpointType

  • ServiceName

  • VpcId

  • State

  • CreationTimestamp

  • Tags

CloudWatch Metrics (Namespace AWS/PrivateLinkEndpoints):

  • BytesProcessed

  • ActiveConnections

  • NewConnections

Dimensões utilizadas:

  • VPC Endpoint Id

  • Endpoint Type

  • Service Name

  • VPC Id


Parâmetros considerados na busca

APIs utilizadas:

  • ec2:DescribeVpcEndpoints

  • cloudwatch:GetMetricStatistics

Condições técnicas:

  • Período de análise baseado em self.checker.period.days

  • Período de agregação: 86400 segundos (1 dia)

  • Estatística utilizada: Sum


Período Avaliado (Filtro Temporal)

Período Avaliado (Filtro Temporal): A regra avalia as métricas de utilização do VPC Endpoint no intervalo correspondente aos dias definidos na configuração da regra (self.checker.period.days).

Padrão é configurado para 30 dias, a regra analisará as métricas dos últimos 30 dias. Caso todas as métricas estejam zeradas nesse período, o endpoint será considerado inativo.

Esse parâmetro pode ser ajustado conforme a política interna de tolerância a inatividade.


Intervalo de Análise

Execução padrão: a cada 8 horas.


Cálculo de Savings

O savings é baseado na eliminação do custo recorrente por hora do VPC Endpoint.


Fórmula Conceitual

Onde:

  • Custo por hora varia por região.

  • Pode haver custo adicional por AZ (Interface Endpoint).


Campo de custo utilizado

No Billing AWS:

  • Service: AmazonVPC

  • Usage Type:

    • VpcEndpoint-Hours

    • DataProcessing-Bytes (quando aplicável)

  • Line Item Type: Usage

  • Campo financeiro considerado:

    • Unblended Cost

    • Ou Amortized Cost


Elementos considerados

  • Tipo do endpoint.

  • Região.

  • Quantidade de AZs associadas.

  • Custo horário regional.

  • Não há projeção futura automática; trata-se de economia recorrente após exclusão.


Exemplo aplicado ao Billing

Cenário:

  • 1 Interface Endpoint

  • Custo médio: $0.01 por hora

  • Implantado em 2 AZs (cobrança por AZ)

Cálculo:

Savings anual:

Se houver 5 endpoints semelhantes:


Dicas de uso e boas práticas para o usuário

  • Confirmar com o time de arquitetura antes da exclusão.

  • Verificar integrações críticas com serviços SaaS.

  • Avaliar ambientes de DR antes de remover.

  • Priorizar endpoints com maior tempo de criação e zero uso histórico.

  • Implementar revisão periódica de endpoints provisionados.

Possíveis falsos positivos:

  • Endpoints utilizados de forma extremamente esporádica.

  • Ambientes sazonais.

  • Serviços com baixo tráfego, mas críticos.

Recomenda-se validação funcional antes da remoção definitiva.

Last updated