DEV Community: Kauê Matos

Amazon EKS na prática: arquitetura, funcionamento e boas práticas

Kauê Matos — Tue, 13 Oct 2026 10:07:54 +0000

Introdução: o que é o EKS e por que usar

Rodar Kubernetes por conta própria exige manter etcd, API server, scheduler e controllers em alta disponibilidade, aplicar patches e fazer upgrades sem derrubar nada. O EKS tira esse peso das suas costas: o control plane é gerenciado, distribuído em várias Zonas de Disponibilidade e atualizado pela AWS.

O EKS roda Kubernetes upstream e é certificado como conforme, então manifests, Helm charts e ferramentas do ecossistema funcionam sem adaptação. A diferença está na integração com a AWS: IAM, VPC, ELB, EBS/EFS, CloudWatch, ECR e Secrets Manager.

Por que adotar o EKS:

Alta disponibilidade do control plane, com SLA de 99,95% da AWS.
Integração nativa com IAM, VPC, Load Balancers e observabilidade.
Ecossistema Kubernetes: Helm, ArgoCD, Prometheus, Istio e operadores.
Flexibilidade de compute: EC2, Fargate, Spot e Karpenter.
Portabilidade: o mesmo manifest roda em outro Kubernetes, com menos lock-in.

O ponto de atenção é a complexidade. Para uma aplicação simples em containers, ECS pode ser suficiente. O EKS compensa quando há muitos serviços, necessidade de portabilidade, um ecossistema Kubernetes já adotado ou requisitos avançados de rede e escalabilidade.

Arquitetura do cluster: control plane e data plane

Um cluster EKS se divide em duas partes: o control plane, que a AWS gerencia, e o data plane, onde seus pods rodam.

Control plane (gerenciado pela AWS). Roda em uma VPC da própria AWS, separada da sua conta, e inclui:

API server: ponto de entrada de todo kubectl e de todos os componentes. Pode ter endpoint público, privado ou ambos.
etcd: banco chave-valor com o estado do cluster, replicado em três Zonas de Disponibilidade.
Scheduler: decide em qual nó cada pod vai rodar.
Controller manager: reconcilia o estado desejado com o estado real.

A AWS provisiona ao menos duas instâncias de API server e três de etcd em AZs diferentes e substitui automaticamente as que falharem. A comunicação com seus nós passa por ENIs (Elastic Network Interfaces) criadas nas suas subnets.

Data plane (sob sua responsabilidade). São os nós dentro da sua VPC. Em cada nó rodam:

kubelet: agente que mantém os pods no estado desejado.
kube-proxy: mantém as regras de rede que implementam os Services.
containerd: o container runtime.
VPC CNI: plugin que dá a cada pod um IP real da VPC.

Add-ons gerenciados. O EKS instala e atualiza componentes essenciais como add-ons: VPC CNI, CoreDNS, kube-proxy, EBS CSI Driver e o Pod Identity Agent.

O caminho de um deploy:

O usuário ou o pipeline executa kubectl apply ou um deploy via Helm.
A requisição chega ao API server, autenticada via IAM e autorizada via RBAC.
O manifest é gravado no etcd.
O scheduler escolhe um nó para o pod.
O kubelet do nó puxa a imagem do ECR e inicia o container.
O VPC CNI atribui um IP da VPC ao pod, e o kube-proxy atualiza as regras do Service.

Modelos de compute: managed node groups, Fargate e Karpenter

O EKS oferece formas diferentes de prover capacidade, e é comum combiná-las no mesmo cluster.

Managed node groups são a escolha padrão. A AWS cria as instâncias EC2 num Auto Scaling Group, usa AMIs otimizadas (Amazon Linux 2023 ou Bottlerocket) e faz upgrades com drenagem controlada dos nós. Indicado para cargas gerais, quando você quer controle sobre o tipo de instância. Em contrapartida, você dimensiona os grupos e escolhe as instâncias.

AWS Fargate roda cada pod em seu próprio ambiente isolado, sem nós para administrar. Você define quais pods usam Fargate por meio de Fargate profiles (namespace + labels). Indicado para cargas esporádicas ou com isolamento por pod. Limitações: não suporta DaemonSets nem GPU, e o custo por vCPU costuma ser maior.

Karpenter observa pods em estado Pending, escolhe a instância mais adequada ao pedido de CPU e memória e a cria em segundos. Também consolida nós subutilizados e remove os ociosos. Indicado para eficiência de custo, uso de Spot e diversidade de instâncias. Exige configurar NodePools e EC2NodeClasses.

Self-managed nodes deixam toda a operação com você: indicados só para casos especiais, como AMI customizada.

O EKS Auto Mode vai além e automatiza o gerenciamento de compute, rede e armazenamento para você.

Rede: VPC CNI, subnets, Services e Ingress

No EKS, cada pod recebe um IP real da VPC, sem overlay nem encapsulamento. Isso é feito pelo plugin Amazon VPC CNI e é o que torna a rede do EKS diferente da maioria dos clusters Kubernetes. O diagrama mostra um cluster em duas AZs (sa-east-1a e sa-east-1b), com um worker node por AZ.

Topologia da VPC

Subnets públicas (10.0.0.0/24 e 10.0.1.0/24): abrigam o Application Load Balancer e os NAT Gateways, com saída pelo Internet Gateway.
Subnets privadas (10.0.32.0/19 e 10.0.64.0/19): abrigam os worker nodes e os pods. Os /19 oferecem milhares de IPs, o que importa porque cada pod consome um.
Route tables privadas: tráfego local para 10.0.0.0/16 e 0.0.0.0/0 pelo NAT Gateway da mesma AZ.
ENIs do control plane: o EKS cria interfaces cross-account nas suas subnets para que o API server converse com o kubelet (porta 10250) e os nós com a API (443).

Como o VPC CNI funciona. Cada worker node tem uma ENI primária (eth0) e ENIs secundárias (eth1…) com IPs reservados para pods, o warm pool. Quando um pod é agendado, o plugin aws-node entrega um desses IPs, cria o par veth e adiciona uma rota /32 no namespace de rede do host. O número máximo de pods por nó depende do tipo da instância: ENIs × IPs por ENI. Quando isso limita, a prefix delegation atribui blocos /28 por ENI e aumenta bastante a densidade.

Os sete fluxos de comunicação do diagrama:

Entrada: Internet → IGW → ALB nas subnets públicas → direto no IP do pod. Isso é possível porque o AWS Load Balancer Controller usa target-type: ip, sem passar por NodePort.
Pod ↔ pod no mesmo nó: via veth e rotas /32 no host. O tráfego não sai do nó.
Pod ↔ pod entre nós ou AZs: sai pela ENI e é roteado nativamente pela VPC, sem encapsulamento.
Saída para a internet: pod → NAT Gateway → IGW, com SNAT para o Elastic IP.
Serviços AWS: ECR, S3, STS e CloudWatch Logs via VPC Endpoints, com credenciais por IRSA ou Pod Identity.
Control plane: o kubelet fala com a API pelas ENIs cross-account, e o kubectl de dev ou CI/CD usa o endpoint público ou privado na porta 443.
Services e DNS: o pod acessa o ClusterIP (172.20.0.0/16), o kube-proxy faz DNAT para os IPs reais dos pods, e o CoreDNS resolve *.svc.cluster.local.

Services, Ingress e segurança de rede. Os Services são IPs virtuais: o ClusterIP não existe na VPC, só nas regras de iptables ou IPVS gravadas pelo kube-proxy. Para expor ao mundo, o AWS Load Balancer Controller transforma um Ingress em ALB (HTTP/HTTPS) e um Service do tipo LoadBalancer em NLB (TCP/UDP). A segurança de rede opera em três camadas:

Security Groups do nó e do cluster, no nível da VPC.
Security Groups for Pods (opcional), que aplicam SGs diretamente a pods específicos.
Network Policies, via VPC CNI ou Calico, para regras entre pods dentro do cluster.

Segurança e identidade: IAM, IRSA, Pod Identity e RBAC

O EKS usa duas camadas de controle: o IAM decide quem é você na AWS, e o RBAC do Kubernetes decide o que você pode fazer dentro do cluster.

Acesso ao cluster. As pessoas e pipelines se autenticam com IAM e são mapeados a permissões do Kubernetes. O mecanismo moderno são as EKS Access Entries, que substituem o antigo ConfigMap aws-auth: você associa um principal IAM a uma access policy ou a grupos RBAC, tudo pela API da AWS e versionável em Terraform.

Acesso dos pods à AWS. Pods não devem usar as credenciais do nó, porque todos os pods do nó herdariam as mesmas permissões. Há dois mecanismos para dar a cada workload um papel IAM próprio:

IRSA (IAM Roles for Service Accounts): usa o provedor OIDC do cluster e uma ServiceAccount anotada com o ARN da role. Boa escolha para clusters existentes e ampla compatibilidade.
EKS Pod Identity: add-on com agente no nó, associação feita pela API do EKS, sem OIDC por cluster. Indicado para novos clusters, com gestão mais simples e roles reutilizáveis entre clusters.

Em ambos os casos vale o princípio do menor privilégio: uma role por aplicação, com apenas as ações que ela precisa.

Boas práticas de segurança:

Endpoint privado do API server, ou público restrito por CIDR.
Nós em subnets privadas, com acesso à AWS por VPC Endpoints.
Secrets no AWS Secrets Manager, montados via Secrets Store CSI Driver, e criptografia de envelope com KMS.
Pod Security Standards para impedir containers privilegiados.
Network Policies para restringir comunicação entre namespaces.
Imagens do ECR com scan habilitado.
Audit logs do control plane enviados ao CloudWatch.

Integrando o EKS ao banco: exemplo com RDS

Bancos de dados raramente rodam dentro do cluster: o padrão é usar um serviço gerenciado como o Amazon RDS numa subnet de banco separada e deixar os pods se conectarem a ele pela rede da VPC.

Security Groups: o SG do banco libera a porta (5432 no PostgreSQL) apenas para o SG dos nós ou, com Security Groups for Pods, apenas para o SG dos pods da aplicação.
Endpoint estável: a aplicação usa o endpoint DNS do RDS, guardado num ConfigMap ou num Service do tipo ExternalName. Assim o nome interno fica independente do endpoint real.
Credenciais: usuário e senha no Secrets Manager, lidos pelo pod com IRSA ou Pod Identity, sem senha em manifest.

Observabilidade, escalabilidade e custos

Observabilidade. Um cluster em produção precisa de logs, métricas e traces:

Logs do control plane (api, audit, authenticator, controllerManager, scheduler): habilitados por cluster e enviados ao CloudWatch Logs.
Container Insights: métricas de CPU, memória e rede por nó, pod e namespace.
Prometheus e Grafana: o Amazon Managed Service for Prometheus e o Amazon Managed Grafana evitam operar essa stack.
Traces: OpenTelemetry com AWS X-Ray ou outro backend compatível.
Alarmes: pods em CrashLoopBackOff, nós NotReady e falhas de agendamento.

Escalabilidade. Há três níveis de escala, e eles trabalham juntos:

HPA (Horizontal Pod Autoscaler): ajusta o número de réplicas por CPU, memória ou métricas customizadas.
Karpenter ou Cluster Autoscaler: adiciona ou remove nós conforme pods pendentes ou capacidade ociosa.
KEDA: escala por eventos externos, como o tamanho de uma fila SQS.

Defina sempre requests e limits de recursos: sem eles o scheduler decide às cegas, e o HPA por utilização não funciona.

Custos. O custo do EKS tem três componentes: a taxa fixa por hora do cluster, as instâncias EC2 ou o Fargate, e itens associados como NAT Gateway, load balancers, transferência entre AZs e volumes EBS. Para reduzir:

Spot para cargas tolerantes a interrupção.
Karpenter com consolidação de nós.
Graviton para muitas cargas, com bom custo-benefício.
VPC Endpoints para reduzir o tráfego pelo NAT Gateway.
Right-sizing de requests, com VPA ou Goldilocks.
Manter o cluster em versão suportada: versões antigas entram em suporte estendido, cobrado a mais.

Provisionando com Terraform e fazendo deploy com GitHub Actions

Em produção o cluster deve ser código: versionado, revisado e reproduzível.

Terraform. O caminho mais comum é o módulo terraform-aws-modules/eks/aws junto com o módulo de VPC. O exemplo é um esqueleto: confira versões e parâmetros na documentação dos módulos.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  name    = "eks-vpc"
  cidr    = "10.0.0.0/16"
  azs     = ["sa-east-1a", "sa-east-1b"]

  public_subnets  = ["10.0.0.0/24", "10.0.1.0/24"]
  private_subnets = ["10.0.32.0/19", "10.0.64.0/19"]

  enable_nat_gateway = true
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  name    = "meu-cluster"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  endpoint_public_access = true

  eks_managed_node_groups = {
    default = {
      instance_types = ["m6i.large"]
      min_size       = 2
      max_size       = 6
      desired_size   = 2
    }
  }
}

Boas práticas: state remoto em S3 com lock, módulos com versão fixa e plano revisado em pull request antes do apply.

GitHub Actions. O pipeline típico faz build da imagem, publica no ECR e atualiza o Deployment. Use OIDC entre o GitHub e a AWS, sem chaves de longa duração guardadas como secret.

name: deploy
on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::<conta>:role/github-deploy
          aws-region: sa-east-1
      - uses: aws-actions/amazon-ecr-login@v2
        id: ecr
      - name: Build e push
        run: |
          IMAGE=${{ steps.ecr.outputs.registry }}/api:${{ github.sha }}
          docker build -t $IMAGE .
          docker push $IMAGE
      - name: Deploy
        run: |
          aws eks update-kubeconfig --name meu-cluster
          kubectl set image deployment/api api=$IMAGE
          kubectl rollout status deployment/api

A role do pipeline recebe acesso ao cluster por uma Access Entry. Em ambientes maiores, vale considerar GitOps com ArgoCD ou Flux, em que o cluster puxa o estado desejado do Git.

Boas práticas e conclusão

O EKS entrega um control plane confiável e deixa para você as decisões que definem a qualidade da operação: rede, identidade, compute e observabilidade. Checklist de produção:

Cluster em pelo menos duas AZs, com nós em subnets privadas.
Subnets com IPs suficientes para os pods (CIDR /19 ou maior, ou prefix delegation).
Add-ons gerenciados (VPC CNI, CoreDNS, kube-proxy, EBS CSI) atualizados.
Access Entries para pessoas e pipelines, e IRSA ou Pod Identity para pods, sempre com menor privilégio.
Endpoint do API server restrito, secrets fora do etcd e criptografia com KMS.
Requests e limits em todos os workloads, com HPA e Karpenter ou Cluster Autoscaler.
PodDisruptionBudgets e topologySpreadConstraints para sobreviver a upgrades e falhas de AZ.
Logs do control plane, Container Insights e alarmes configurados.
Infraestrutura em Terraform e deploys por pipeline com OIDC ou GitOps.
Upgrades de versão planejados, um minor por vez, testados antes em ambiente não produtivo.

O EKS não é o caminho mais simples para rodar containers, mas é um dos mais completos quando o objetivo é um ambiente padronizado, seguro e escalável. Entender a arquitetura, em especial a rede baseada em ENIs e IPs reais da VPC, é o que separa um cluster que apenas funciona de um que se opera com previsibilidade.

Backstage o portal de desenvolvedores da CNCF, como funciona por dentro

Kauê Matos — Thu, 08 Oct 2026 00:59:33 +0000

O Backstage é um framework open source para construir portais de desenvolvedores: uma interface única onde times encontram seus serviços, criam novos projetos a partir de modelos padronizados, leem a documentação e acessam as ferramentas de infraestrutura que usam no dia a dia. Ele não é um produto pronto para instalar e usar; é uma base que você monta, estende com plugins e hospeda por conta própria.

O projeto nasceu dentro do Spotify, para domar a quantidade crescente de serviços e ferramentas internas. Foi aberto ao público em março de 2020, doado à CNCF (Cloud Native Computing Foundation) como projeto Sandbox em setembro de 2020 e promovido ao nível Incubating em março de 2022. Hoje é uma das bases mais usadas para o que o mercado chama de Internal Developer Portal (IDP).

Tecnicamente, o Backstage é uma aplicação TypeScript: um frontend em React e um backend em Node.js, ligados por um sistema de plugins. Este artigo percorre o problema que ele resolve, sua arquitetura, os três pilares (Catalog, Templates e TechDocs), o modelo de plugins, autenticação, deploy e o que esperar da adoção.

O problema que o Backstage resolve

O Backstage ataca a carga cognitiva de quem desenvolve software em uma organização com muitos times, serviços e ferramentas. Em empresas que adotam microsserviços e nuvem, as mesmas perguntas se repetem o tempo todo, e a resposta fica espalhada em wikis, planilhas, chats e na cabeça de poucas pessoas.

Quem é dono deste serviço? E onde está o repositório, o pipeline, o dashboard e o canal de plantão?
Como crio um novo serviço seguindo o padrão da empresa? Cada time acaba montando o seu, com variações de pipeline, segurança e observabilidade.
Onde está a documentação, e ela está atualizada? Wikis desconectadas do código envelhecem rápido.
Quais serviços dependem de qual API? Sem esse mapa, avaliar o impacto de uma mudança vira investigação manual.

A resposta do Backstage é centralizar esses metadados em um catálogo vivo, alimentado pelos próprios repositórios, e expor sobre ele ações e visões: criar, documentar, observar e operar.

Onde entra o platform engineering

O Backstage é a camada de interface de uma plataforma interna de desenvolvedores. Um time de plataforma oferece capacidades prontas (pipelines, ambientes, templates, observabilidade) e o portal é a vitrine de autoatendimento delas. A ideia central são os golden paths: caminhos recomendados e já configurados que tornam o jeito certo de fazer também o jeito mais fácil. Quem quiser sair do caminho pode, mas quem seguir ganha velocidade e segurança por padrão.

Arquitetura

O Backstage tem uma arquitetura em camadas: um frontend React que roda no navegador, um backend Node.js que concentra a lógica, as credenciais e o acesso a dados, e as fontes externas que o backend consulta em nome do usuário.

[embedded content: arquitetura do Backstage · 3 camadas]

O navegador conversa apenas com o backend, e é o backend que acessa o PostgreSQL, o armazenamento do TechDocs e os sistemas externos, o que mantém tokens e segredos fora do alcance do usuário.

As peças

Frontend: uma aplicação de página única em React. Cada plugin registra suas páginas e seus componentes, e o app os compõe em rotas, abas de entidade e cartões.
Backend: um processo Node.js (TypeScript) que hospeda os plugins de servidor. Cada plugin é isolado: tem seus endpoints, seu esquema de banco e seus serviços injetados (logger, banco, configuração, autenticação).
Banco de dados: guarda o estado do catálogo, o histórico das tarefas do Scaffolder e dados de outros plugins. PostgreSQL em produção.
Armazenamento de objetos: opcional, usado pelo TechDocs para servir a documentação já gerada.
Sistemas externos: repositórios Git, clusters Kubernetes, ferramentas de CI/CD, provedores de identidade e nuvens, acessados por plugins e integrações configuradas no app-config.yaml.

Os dois processos costumam ser publicados juntos: o backend serve também os arquivos estáticos do frontend, e todo o conjunto vira uma única imagem de contêiner. Em instalações maiores, é possível separar frontend e backend ou dividir o backend em vários serviços por plugin.

Software Catalog

O Software Catalog é o coração do Backstage: um inventário central de tudo o que a organização constrói e opera, com donos, relações e links para as ferramentas de cada item. Os outros pilares dependem dele para saber de qual serviço se está falando.

O modelo de entidades

Cada item do catálogo é uma entidade, descrita por um arquivo YAML com apiVersion, kind, metadata e spec. Os tipos (kind) padrão são:

Kind	Representa	Exemplo
Component	Uma unidade de software	Serviço, website, biblioteca
API	Uma interface exposta por um componente	OpenAPI, gRPC, GraphQL, AsyncAPI
Resource	Infraestrutura da qual componentes dependem	Banco, fila, bucket S3
System	Conjunto de componentes, APIs e recursos que formam um produto	Sistema de pagamentos
Domain	Agrupamento de sistemas de uma área de negócio	Financeiro
Group	Time ou unidade organizacional	Time de plataforma
User	Pessoa	Desenvolvedor
Location	Ponteiro para outros arquivos de descritor	Repositório com vários YAMLs

As entidades se ligam por relações como ownedBy, dependsOn, providesApi, consumesApi e partOf. É isso que permite responder, por exemplo, quais componentes consomem uma API que será descontinuada.

O descritor catalog-info.yaml

Por convenção, cada repositório guarda na raiz um catalog-info.yaml que descreve seu componente. O metadado vive junto do código, versionado e revisado como qualquer outra mudança.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: servico-pagamentos
  description: API de processamento de pagamentos
  annotations:
    github.com/project-slug: minha-org/servico-pagamentos
    backstage.io/techdocs-ref: dir:.
  tags:
    - java
    - spring-boot
spec:
  type: service
  lifecycle: production
  owner: group:time-pagamentos
  system: plataforma-financeira
  providesApis:
    - api-pagamentos
  dependsOn:
    - resource:default/postgres-pagamentos

As annotations são o mecanismo de ligação com plugins: a de github.com/project-slug faz o plugin do GitHub saber qual repositório mostrar na página da entidade, e a de backstage.io/techdocs-ref indica onde está a documentação.

Como o catálogo é alimentado

O backend do catálogo roda um processo contínuo de ingestão em três etapas:

Entity providers descobrem descritores. Há providers para GitHub, GitLab, Bitbucket, Azure DevOps, AWS S3 e outros, e eles podem varrer uma organização inteira procurando catalog-info.yaml. Também é possível registrar uma URL manualmente na interface.
Processors validam cada entidade, resolvem referências, emitem relações e podem enriquecê-la com dados externos.
Stitching consolida o resultado final de cada entidade e o grava no banco, de onde o frontend lê.

O catálogo atualiza em ciclos periódicos, então uma mudança no YAML aparece no portal após alguns minutos, sem ação manual. Dados de organização (grupos e usuários) costumam vir de um provedor de identidade, como Microsoft Entra ID, Okta, LDAP ou GitHub, para manter os donos sincronizados com a realidade.

Software Templates

Os Software Templates (o plugin Scaffolder) transformam um formulário em um repositório novo, já configurado, e registrado no catálogo. O desenvolvedor escolhe um modelo, preenche alguns campos e, minutos depois, tem código, pipeline, documentação e dono definidos, sem abrir chamado para o time de plataforma.

Como um template é definido

Um template é uma entidade do catálogo com kind: Template. Ele declara os parâmetros (que viram um formulário gerado a partir de JSON Schema) e os passos (ações executadas em sequência).

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: servico-spring-boot
  title: Novo serviço Spring Boot
  description: Cria um serviço Java com pipeline e docs prontos
spec:
  owner: group:time-plataforma
  type: service

  parameters:
    - title: Informações do serviço
      required: [nome, dono]
      properties:
        nome:
          type: string
          description: Nome do serviço
        dono:
          type: string
          title: Time responsável
          ui:field: OwnerPicker
          ui:options:
            allowedKinds: [Group]
    - title: Destino
      required: [repoUrl]
      properties:
        repoUrl:
          type: string
          ui:field: RepoUrlPicker
          ui:options:
            allowedHosts: [github.com]

  steps:
    - id: fetch
      name: Gerar código a partir do esqueleto
      action: fetch:template
      input:
        url: ./skeleton
        values:
          nome: ${{ parameters.nome }}
          dono: ${{ parameters.dono }}

    - id: publish
      name: Criar repositório
      action: publish:github
      input:
        repoUrl: ${{ parameters.repoUrl }}
        description: ${{ parameters.nome }}

    - id: register
      name: Registrar no catálogo
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

  output:
    links:
      - title: Repositório
        url: ${{ steps['publish'].output.remoteUrl }}
      - title: Abrir no catálogo
        icon: catalog
        entityRef: ${{ steps['register'].output.entityRef }}

Peças do mecanismo

Esqueleto (skeleton): uma pasta de arquivos com marcadores ${{ values.nome }}, renderizada pela ação fetch:template (engine Nunjucks). É nele que ficam o Dockerfile, o workflow de CI, o catalog-info.yaml e a estrutura de documentação.
Ações: funções que o backend executa, como fetch:template, publish:github, publish:gitlab e catalog:register. É possível escrever ações customizadas, por exemplo para criar um recurso em nuvem ou abrir um ticket.
Campos de formulário: componentes como OwnerPicker e RepoUrlPicker dão uma experiência guiada, e há suporte a campos customizados.
Execução e log: cada execução vira uma tarefa com log em tempo real na interface, o que facilita diagnosticar falhas.

O valor para a organização está no que o esqueleto embute: padrões de segurança, observabilidade, estrutura de pipeline e metadados de catálogo nascem corretos em todo serviço novo. Atualizar o template melhora os próximos projetos, mas não altera os já criados, ponto que costuma exigir uma estratégia à parte de manutenção.

TechDocs

O TechDocs aplica a ideia de docs-like-code: a documentação técnica fica em Markdown dentro do mesmo repositório do código e aparece no portal, na página do componente. Quem muda o código muda a documentação no mesmo pull request, o que reduz o envelhecimento.

Como funciona

O TechDocs usa o MkDocs como gerador de site estático, com o plugin techdocs-core. A configuração fica em um mkdocs.yml na raiz do repositório, e a entidade aponta para ele pela annotation backstage.io/techdocs-ref.

# mkdocs.yml
site_name: servico-pagamentos
nav:
  - Início: index.md
  - Arquitetura: arquitetura.md
  - Runbooks: runbooks.md
plugins:
  - techdocs-core

Duas estratégias de build

Estratégia	Quem gera o site	Quando usar
Basic (`techdocs.builder: local`)	O próprio backend do Backstage, sob demanda	Testes e instalações pequenas
Recommended (`techdocs.builder: external`)	Um pipeline de CI, a cada mudança, publicando em um armazenamento	Produção

Na estratégia recomendada, o CI roda a CLI techdocs-cli generate e techdocs-cli publish, enviando o site gerado para um armazenamento de objetos (AWS S3, Google Cloud Storage, Azure Blob Storage ou OpenStack Swift). O Backstage apenas lê dali. Isso tira a carga de build do backend e permite escalar a leitura de forma independente.

Benefícios e cuidados

O resultado é uma documentação com busca integrada ao portal, navegação lateral e a mesma autenticação do restante da plataforma. O cuidado é cultural: o plugin entrega a infraestrutura, mas a qualidade do conteúdo continua dependendo de cada time. Um bom começo é incluir no template um docs/ mínimo, com seções para visão geral, arquitetura e runbook de operação.

Plugins e ecossistema

Tudo no Backstage é plugin, inclusive o Catalog, o Scaffolder e o TechDocs. Essa é a decisão de design que o torna extensível: o portal é uma casca que carrega plugins, e cada plugin traz sua interface, sua lógica de servidor ou os dois.

Como um plugin é composto

Um plugin típico tem duas metades. O plugin de frontend é um pacote React que registra páginas, abas e cartões na interface. O plugin de backend é um serviço Node.js que expõe endpoints, acessa o banco, chama APIs externas e guarda credenciais, para que o navegador nunca as veja. Um plugin de frontend costuma consultar o seu backend, e esse backend consulta a ferramenta externa, por exemplo o GitHub, o Kubernetes ou o PagerDuty.

O backend atual é montado com o novo sistema de backend, em que o plugin é registrado com backend.add(...) e dependências como logger, banco, cache e configuração são injetadas como serviços. O Backstage também evolui um novo sistema de frontend baseado em extensões, mas parte dos plugins da comunidade ainda usa o modelo anterior, então vale conferir a compatibilidade antes de adotar.

Plugins populares

Categoria	Exemplos
Código e CI/CD	GitHub Actions, GitLab, Jenkins, CircleCI, Argo CD
Infraestrutura	Kubernetes, Terraform, AWS, Azure, Google Cloud
Observabilidade e incidentes	Grafana, Datadog, Prometheus, PagerDuty, Sentry
Segurança	SonarQube, Snyk, relatórios de vulnerabilidades
Qualidade e maturidade	Tech Insights, scorecards
Custos	Cost Insights
Busca	Pesquisa unificada sobre catálogo e docs (Lunr, PostgreSQL ou Elasticsearch)

O diretório de plugins no site do projeto lista centenas de opções, mantidas pelo Spotify, por fornecedores e pela comunidade. A qualidade varia: antes de depender de um plugin, verifique a data do último commit, a compatibilidade com a versão do Backstage em uso e se ele já migrou para o novo sistema de backend.

Criando o seu

O CLI do Backstage gera o esqueleto de um plugin com yarn new. O caminho comum em empresas é escrever plugins internos para exibir dados proprietários, como o status de uma plataforma interna ou o painel de custos do time, e ligar a página à entidade do catálogo por uma annotation.

Autenticação e permissões

O Backstage separa duas perguntas: quem é você (autenticação) e o que você pode fazer (autorização). A primeira vem pronta com vários provedores; a segunda é um framework que você configura.

Autenticação

O plugin de autenticação oferece provedores como GitHub, GitLab, Google, Microsoft Entra ID, Okta, Auth0, AWS ALB, OneLogin, além de OIDC e SAML genéricos. Ao concluir o login, um sign-in resolver associa a identidade externa a uma entidade User do catálogo, e é essa ligação que dá ao usuário seus grupos e, portanto, seus donos e permissões. Um resolver mal escrito, que associe a pessoa errada, é uma das falhas de configuração mais sérias, e vale revisá-lo com cuidado.

Por padrão, um projeto novo permite acesso como convidado, útil só em desenvolvimento. Em produção, desative esse acesso e configure o provedor corporativo.

Autorização com o Permission Framework

Sem configuração extra, qualquer usuário autenticado pode fazer quase tudo. O framework de permissões muda isso: os plugins declaram permissões (ler uma entidade, executar um template, remover do catálogo), e uma política em código decide, para cada requisição, se o usuário recebe ALLOW, DENY ou uma decisão condicional.

Um exemplo comum é restringir quem pode apagar entidades ao time de plataforma, ou limitar que templates aparecem para cada time. As condicionais permitem regras como "o usuário só edita entidades de que é dono", avaliadas no banco com eficiência.

Segurança do portal como um todo

O Backstage guarda tokens de integração (GitHub, nuvem, Kubernetes) e enxerga metadados sensíveis de toda a empresa, o que o torna um alvo valioso. Mantenha o portal atrás do SSO corporativo, guarde credenciais em um gerenciador de segredos, use permissões mínimas nos tokens de integração e acompanhe as atualizações de segurança do projeto, que lança versões com frequência mensal.

Instalação e deploy

Uma instância do Backstage é um projeto seu, gerado por um CLI, e não um pacote que você instala. Você cria o app, o versiona em um repositório próprio e o atualiza para acompanhar as versões do projeto.

Criando e rodando localmente

O pré-requisito é uma versão LTS do Node.js e o Yarn. O comando abaixo gera a estrutura do monorepo.

npx @backstage/create-app@latest
cd meu-portal
yarn start

O projeto gerado tem dois pacotes principais: packages/app (frontend) e packages/backend (backend). No modo de desenvolvimento, o frontend responde em localhost:3000 e o backend em localhost:7007. A configuração fica em app-config.yaml, com variantes como app-config.production.yaml e app-config.local.yaml sobrepondo valores por ambiente.

Banco de dados

O desenvolvimento usa SQLite em memória, e produção exige PostgreSQL. Cada plugin de backend usa seu próprio banco lógico, e o Backstage cria o que for preciso. Em nuvem, um banco gerenciado (como Amazon RDS ou Aurora PostgreSQL) resolve backup, alta disponibilidade e atualização.

# app-config.production.yaml
app:
  baseUrl: https://backstage.minha-empresa.com
backend:
  baseUrl: https://backstage.minha-empresa.com
  database:
    client: pg
    connection:
      host: ${POSTGRES_HOST}
      port: ${POSTGRES_PORT}
      user: ${POSTGRES_USER}
      password: ${POSTGRES_PASSWORD}

Empacotando e publicando

O caminho usual é gerar uma imagem de contêiner. O projeto traz um Dockerfile de exemplo em packages/backend, e o build típico compila o TypeScript, empacota o backend e embute o frontend estático para ser servido por ele.

yarn install --immutable
yarn tsc
yarn build:backend
docker build . -f packages/backend/Dockerfile --tag meu-portal:1.0.0

A imagem roda em qualquer orquestrador: Kubernetes (com Helm chart, que a comunidade mantém), Amazon ECS ou EKS, Cloud Run e similares. Em um deploy típico, um balanceador termina o TLS, o serviço roda em duas ou mais réplicas, o PostgreSQL é gerenciado, os segredos vêm de um gerenciador (e não do app-config.yaml) e os arquivos do TechDocs ficam em um bucket de objetos.

Atualizações

O Backstage publica uma versão a cada mês, e o comando yarn backstage-cli versions:bump atualiza todos os pacotes @backstage/* de uma vez. Atualizar com regularidade custa menos que acumular meses de mudanças, e o site do projeto traz um upgrade helper que mostra o diff entre duas versões do projeto gerado.

Adoção na prática

O maior risco do Backstage não é técnico: é tratá-lo como um projeto de instalação em vez de um produto interno. O código é aberto e gratuito, mas o custo real está em manter, evoluir e convencer pessoas a usá-lo.

O custo de ser dono do portal

Um portal útil costuma exigir uma equipe dedicada, com conhecimento de TypeScript, React e Node.js. Cabe a ela atualizar versões todo mês, manter plugins internos, resolver quebras de compatibilidade e atender os times usuários. Organizações pequenas, sem um time de plataforma, costumam subestimar esse esforço.

Armadilhas frequentes

Catálogo desatualizado. Um catálogo com donos errados e serviços mortos perde a confiança em semanas. Automatize a descoberta, valide os descritores no CI e exija um dono para cada entidade.
Começar largo demais. Instalar dezenas de plugins antes de resolver uma dor concreta gera um portal cheio e sem uso. Comece com o catálogo e um template para o caso mais frequente.
Ausência de incentivo. Se a documentação e os templates do portal não são o caminho mais fácil, as pessoas continuam usando wikis e planilhas. O portal precisa economizar tempo desde o primeiro uso.
Template sem manutenção. Serviços criados a partir de um template não recebem suas atualizações; planeje como propagar correções (por exemplo, com ferramentas de atualização automática de dependências e pipelines reutilizáveis).
Confundir portal com plataforma. O Backstage é a interface. As capacidades por trás dele, como pipelines, ambientes e observabilidade, ainda precisam existir.

Como medir o sucesso

Indicadores úteis incluem a porcentagem de serviços no catálogo com dono definido, o tempo para criar um serviço novo e colocá-lo em produção, o uso ativo semanal do portal e a satisfação dos desenvolvedores em pesquisas curtas. Esses números sustentam a continuidade do investimento.

Alternativas e opções gerenciadas

Quem quer o resultado sem montar o portal pode olhar soluções que oferecem o Backstage hospedado ou alternativas de mercado. As principais opções são:

Opção	Perfil
Red Hat Developer Hub	Distribuição corporativa baseada no Backstage, com suporte
Roadie	Backstage gerenciado como serviço
Port, Cortex, OpsLevel	Portais de mercado (não baseados em Backstage), com configuração mais guiada e menos código

A escolha entre montar ou comprar depende de equipe disponível, necessidade de customização e orçamento. Verifique recursos e preços atuais direto com cada fornecedor, pois mudam com frequência.

Conclusão

O Backstage entrega um portal de desenvolvedores montado sobre três ideias simples: um catálogo alimentado pelo código, templates que codificam os caminhos recomendados e documentação que mora junto do código. O resto é plugin. Sua força é a extensibilidade e o respaldo da CNCF; seu custo é a necessidade de tratá-lo como um produto interno, com equipe, roadmap e métricas.

Um caminho prático para começar:

Gere um app com npx @backstage/create-app e rode localmente.
Registre dois ou três serviços reais com catalog-info.yaml e conecte o provider do seu repositório de código.
Crie um template para o tipo de serviço mais comum na empresa.
Ative o TechDocs com build externo em um bucket de objetos.
Troque o acesso de convidado pelo SSO corporativo e defina uma política de permissões básica.
Meça o uso e expanda os plugins só onde houver dor concreta.

Referências

Comandos, nomes de pacotes e recursos mudam entre versões; confirme sempre na documentação oficial.

Docker Scout e Trivy segurança de imagens de contêiner na prática

Kauê Matos — Wed, 07 Oct 2026 22:49:56 +0000

Trivy e Docker Scout resolvem o mesmo problema central: descobrir, antes da produção, quais vulnerabilidades, licenças e dependências estão dentro das suas imagens de contêiner. Eles chegam a esse objetivo por caminhos diferentes, e entender essa diferença define qual usar, ou se usar os dois.

Uma imagem Docker raramente contém apenas o seu código. Ela carrega um sistema operacional base, bibliotecas do sistema, o runtime da linguagem (JRE, Node.js, Python) e dezenas ou centenas de dependências transitivas. Cada camada é uma superfície de ataque herdada, e a maior parte dessas vulnerabilidades não está no código que você escreveu.

Este artigo explica como cada ferramenta funciona, mostra os comandos do dia a dia, compara os dois lado a lado e apresenta um pipeline de CI/CD com GitHub Actions que aplica ambos. Os exemplos usam Java/Spring Boot e Node.js apenas como cenário; os comandos valem para qualquer stack.

Conceitos fundamentais

Sete conceitos aparecem em toda conversa sobre scan de imagens, e confundi-los é a origem da maioria dos relatórios mal interpretados.

Conceito	O que é	Por que importa no scan
CVE	Identificador público de uma vulnerabilidade (ex.: CVE-2024-XXXX)	É a unidade que os scanners reportam
CVSS	Nota de severidade de 0 a 10 (Low, Medium, High, Critical)	Base para filtros como `--severity HIGH,CRITICAL`
EPSS	Probabilidade estimada de exploração real nos próximos 30 dias	Ajuda a priorizar: CVSS alto com EPSS baixo pode esperar
KEV	Catálogo da CISA de vulnerabilidades já exploradas ativamente	Tratar como prioridade máxima, independentemente do CVSS
SBOM	Inventário de componentes da imagem (formatos SPDX e CycloneDX)	Permite reavaliar vulnerabilidades sem reescanear a imagem
VEX	Declaração de que uma CVE existe no componente, mas não é explorável no seu contexto	Forma auditável de suprimir falsos positivos
Provenance	Atestado de como, onde e por quem a imagem foi construída (SLSA)	Prova a origem da imagem na cadeia de suprimentos

Duas ideias completam o quadro. A base image é a imagem do FROM: ela costuma responder pela maior parte das CVEs de um relatório, e trocá-la tende a render mais que corrigir dependências uma a uma. Já a SCA (Software Composition Analysis) é a técnica por trás dos dois scanners: identificar pacotes instalados (via dpkg, apk, rpm) e dependências de aplicação (pom.xml, package-lock.json, go.mod) e cruzá-los com bases de vulnerabilidades.

Um ponto sutil: um scanner só encontra o que consegue inventariar. Binários copiados à mão ou compilados estaticamente sem metadados passam despercebidos, o que justifica gerar SBOM no build e não apenas escanear a imagem pronta.

Trivy em detalhe

O Trivy é um scanner de segurança open source (licença Apache 2.0), mantido pela Aqua Security, distribuído como um único binário Go. Seu diferencial é a amplitude: o mesmo comando cobre imagens, sistemas de arquivos, repositórios Git, manifestos Kubernetes e arquivos de infraestrutura como código.

Como ele funciona

O Trivy extrai o conteúdo da imagem, identifica os pacotes do SO e das linguagens e consulta um banco local de vulnerabilidades (o trivy-db), baixado do registry no primeiro uso e atualizado periodicamente. Como a comparação acontece na sua máquina ou no runner de CI, ele funciona sem enviar a imagem para nenhum serviço externo, e pode operar offline com o banco em cache.

Tipos de scan

Scanner	O que detecta	Flag
Vulnerabilidades	CVEs em pacotes do SO e de linguagens	`--scanners vuln`
Misconfiguration	Erros em Dockerfile, Terraform, Kubernetes, Helm, CloudFormation	`--scanners misconfig`
Secrets	Chaves de API, tokens e senhas embutidos	`--scanners secret`
Licenças	Licenças de dependências (ex.: GPL, AGPL)	`--scanners license`

Alvos

O primeiro argumento define o alvo: image, fs (diretório local), repo (repositório remoto), rootfs, config (IaC), k8s (cluster) e sbom (reescanear um SBOM existente).

Comandos do dia a dia

# Scan básico de uma imagem
trivy image minha-app:1.0.0

# Somente HIGH e CRITICAL, ignorando CVEs sem correção disponível
trivy image --severity HIGH,CRITICAL --ignore-unfixed minha-app:1.0.0

# Falhar o comando (exit code 1) quando houver achados: ideal para CI
trivy image --exit-code 1 --severity CRITICAL minha-app:1.0.0

# Saída em JSON, SARIF ou template próprio
trivy image --format json --output relatorio.json minha-app:1.0.0
trivy image --format sarif --output trivy.sarif minha-app:1.0.0

# Gerar SBOM em CycloneDX e reescanear depois, sem a imagem
trivy image --format cyclonedx --output sbom.cdx.json minha-app:1.0.0
trivy sbom sbom.cdx.json

# Escanear o código-fonte e dependências do projeto
trivy fs --scanners vuln,secret,misconfig .

# Validar IaC (Terraform, Kubernetes, Dockerfile)
trivy config ./infra

# Resumo de um cluster Kubernetes
trivy k8s --report summary cluster

Suprimindo achados com critério

O arquivo .trivyignore lista CVEs a ignorar, e as versões recentes aceitam data de expiração e comentário por entrada, o que evita exceções eternas. Para um registro mais formal, o Trivy também consome documentos VEX (OpenVEX, CSAF, CycloneDX VEX) via --vex. Para configuração persistente, use um trivy.yaml em vez de repetir flags.

# .trivyignore
# Não explorável: a função vulnerável não é chamada pela aplicação
CVE-2024-00000

Banco de dados e desempenho em CI

O download do banco a cada execução é o principal gargalo e a causa mais comum de falhas por limite de requisições em runners compartilhados. Três práticas ajudam: cachear o diretório de cache do Trivy entre execuções, usar --skip-db-update quando o banco já estiver presente e espelhar o banco em um registry interno, apontando com --db-repository.

Trivy Operator

No Kubernetes, o Trivy Operator roda dentro do cluster e gera relatórios como recursos customizados (VulnerabilityReport, ConfigAuditReport, ExposedSecretReport). Isso cobre o que o scan de CI não vê: imagens que ficaram vulneráveis depois do deploy, porque uma CVE nova foi publicada.

Docker Scout em detalhe

O Docker Scout é a solução de análise da cadeia de suprimentos integrada ao ecossistema Docker: ele aparece no Docker Desktop, no Docker Hub, na CLI (docker scout) e em uma GitHub Action oficial. Em vez de apenas listar CVEs, ele conecta vulnerabilidades à imagem base, às políticas da organização e à evolução da imagem no tempo.

Como ele funciona

O Scout gera um índice de componentes (um SBOM) da imagem e o cruza com um banco de vulnerabilidades próprio, que agrega várias fontes de advisories e é atualizado continuamente. Quando a imagem está em um repositório com o Scout habilitado, a análise é guardada e reavaliada conforme novas CVEs surgem, sem exigir um novo scan manual. Para imagens locais, o mesmo motor roda sob demanda pela CLI.

Comandos do dia a dia

# Visão geral rápida: vulnerabilidades e base image
docker scout quickview minha-app:1.0.0

# Lista detalhada de CVEs, filtrando por severidade e correção disponível
docker scout cves --only-severity critical,high --only-fixed minha-app:1.0.0

# Escanear o diretório local, sem construir a imagem
docker scout cves --type fs .

# Recomendações de atualização da base image
docker scout recommendations minha-app:1.0.0

# Comparar duas versões e ver apenas o que mudou
docker scout compare --to minha-app:1.0.0 minha-app:1.1.0

# Exportar SBOM
docker scout sbom --format spdx minha-app:1.0.0

# Avaliar a imagem contra as políticas da organização
docker scout policy minha-app:1.0.0 --org minha-org

# Saída SARIF e exit code para CI
docker scout cves --format sarif --output scout.sarif --exit-code --only-severity critical,high minha-app:1.0.0

Recomendações de base image

Esse é o recurso mais característico. O docker scout recommendations compara a base atual com alternativas e propõe dois caminhos: atualizar para uma versão mais nova da mesma tag (menos CVEs com mudança mínima) ou trocar por outra variante (por exemplo, de uma imagem completa para uma slim). O relatório mostra quantas vulnerabilidades cada opção elimina, o que transforma a conversa sobre trocar de base image de opinião em número.

Políticas

O Scout avalia a imagem contra políticas e mostra o resultado como conforme ou não conforme. As políticas padrão cobrem, entre outras verificações, vulnerabilidades críticas e altas com correção disponível, vulnerabilidades de alto perfil, bases desatualizadas, licenças copyleft, presença de atestados de cadeia de suprimentos e usuário não root por padrão. Cada política pode ser ajustada ou criada sob medida na organização.

SBOM e provenance

O Scout lê os atestados que o BuildKit anexa à imagem. Para alimentá-lo com dados melhores, gere SBOM e provenance no build:

docker buildx build \
  --sbom=true \
  --provenance=mode=max \
  --tag minha-org/minha-app:1.0.0 \
  --push .

Com isso, a análise passa a usar o SBOM gerado no próprio build, mais fiel ao conteúdo real que a inferência feita depois, e a política de atestados fica satisfeita.

Limitações a considerar

O Scout é focado em imagens e dependências: ele não analisa IaC (Terraform, manifestos Kubernetes) nem procura secrets embutidos. Os recursos de monitoramento contínuo, políticas e integração com Docker Hub dependem do plano da organização, então confira o plano vigente antes de basear um processo nele.

Docker Scout vs Trivy

O Trivy é a escolha por amplitude e independência de plataforma; o Scout é a escolha por integração com o fluxo Docker e por orientação de ação (base image e políticas). A tabela resume as diferenças.

Critério	Trivy	Docker Scout
Modelo	Open source (Apache 2.0), binário único	Recurso do ecossistema Docker, com planos por organização
Escopo	Vulnerabilidades, misconfiguration, secrets, licenças, IaC, Kubernetes	Vulnerabilidades, licenças, SBOM, políticas, recomendações de base image
Alvos	Imagem, filesystem, repositório, cluster, SBOM, IaC	Imagem e diretório local
Execução	Local ou em CI, com possibilidade de operar offline com banco em cache	CLI local, Docker Desktop, Docker Hub e GitHub Action
Recomendação de base image	Não nativa	Sim, com comparação de opções
Políticas	Via flags, exit code e Rego para misconfiguration	Políticas nativas com status de conformidade
Monitoramento contínuo	Trivy Operator no Kubernetes ou reexecução agendada	Reavaliação automática em repositórios habilitados
Formatos de saída	Table, JSON, SARIF, CycloneDX, SPDX, template	Texto, SARIF, SPDX, CycloneDX
Registry	Qualquer um	Melhor experiência com Docker Hub; funciona com outros registries
Ponto forte	Cobertura ampla e neutra	Orientação de correção e integração com Docker

Quando usar cada um

Trivy quando o pipeline envolve IaC, Kubernetes ou detecção de secrets, quando é preciso rodar em ambiente isolado ou quando se quer uma ferramenta neutra em relação a registry e nuvem.
Docker Scout quando a equipe já vive no Docker Desktop e no Docker Hub, quando o objetivo é decidir qual base image adotar ou quando políticas por organização e comparação entre versões são prioridade.
Os dois quando se quer cobertura ampla no CI (Trivy) e orientação de remediação para o time de desenvolvimento (Scout). Resultados podem divergir, porque cada ferramenta usa suas próprias fontes de dados e regras de correspondência. Divergência não indica erro de um dos lados: investigue o pacote e a fonte do advisory antes de decidir.

Integração em CI/CD com GitHub Actions

O padrão mais útil é construir a imagem uma vez, escaneá-la com os dois, publicar o relatório no GitHub e só então fazer o push. O pipeline abaixo bloqueia o merge quando há vulnerabilidade crítica com correção disponível e envia os resultados para a aba Security do repositório.

name: build-and-scan

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write   # necessário para enviar SARIF
  pull-requests: write     # comentário do Scout no PR

env:
  IMAGE: minha-org/minha-app:${{ github.sha }}

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<commit-sha>

      - uses: docker/setup-buildx-action@<commit-sha>

      - name: Build (sem push)
        uses: docker/build-push-action@<commit-sha>
        with:
          context: .
          load: true
          tags: ${{ env.IMAGE }}
          sbom: true
          provenance: mode=max

      # --- Trivy: cobertura ampla, falha o job em CRITICAL com correção ---
      - name: Trivy (imagem)
        uses: aquasecurity/trivy-action@<commit-sha>
        with:
          image-ref: ${{ env.IMAGE }}
          format: sarif
          output: trivy.sarif
          severity: CRITICAL,HIGH
          ignore-unfixed: true
          exit-code: '0'   # o SARIF sempre é gerado; o gate vem no próximo passo

      - name: Trivy (gate)
        uses: aquasecurity/trivy-action@<commit-sha>
        with:
          image-ref: ${{ env.IMAGE }}
          severity: CRITICAL
          ignore-unfixed: true
          exit-code: '1'

      - name: Enviar SARIF do Trivy
        if: always()
        uses: github/codeql-action/upload-sarif@<commit-sha>
        with:
          sarif_file: trivy.sarif
          category: trivy

      # --- Docker Scout: orientação de correção e comparação com main ---
      - name: Login no Docker Hub
        uses: docker/login-action@<commit-sha>
        with:
          username: ${{ secrets.DOCKERHUB_USER }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Docker Scout
        uses: docker/scout-action@<commit-sha>
        with:
          command: cves,recommendations
          image: ${{ env.IMAGE }}
          only-severities: critical,high
          sarif-file: scout.sarif
          write-comment: true
          github-token: ${{ secrets.GITHUB_TOKEN }}

      - name: Enviar SARIF do Scout
        if: always()
        uses: github/codeql-action/upload-sarif@<commit-sha>
        with:
          sarif_file: scout.sarif
          category: docker-scout

Pontos de atenção no pipeline

Fixe as actions por commit SHA, como nos <commit-sha> acima, em vez de tags móveis. Uma action de scanner roda com acesso ao seu runner e aos seus secrets, então ela própria é parte da cadeia de suprimentos que você quer proteger.
Separe o relatório do gate. Gerar o SARIF com exit-code: 0 e aplicar o bloqueio em um passo próprio garante que o relatório chegue ao GitHub mesmo quando o build falha.
Escaneie antes do push. Construir com load: true, escanear e só depois publicar impede que uma imagem reprovada chegue ao registry.
Cacheie o banco do Trivy com actions/cache para evitar falhas por limite de requisições e reduzir o tempo do job.
Reescaneie periodicamente. Um workflow agendado (schedule) sobre as imagens já publicadas detecta CVEs descobertas depois do deploy, que o scan no momento do build não pode ver.

Boas práticas e armadilhas comuns

O scanner mostra o problema, mas quem reduz o risco é a imagem que você constrói. As práticas abaixo têm o maior retorno.

Reduza a superfície antes de escanear

Use bases mínimas: variantes slim, alpine ou distroless eliminam pacotes que você nunca usa e, com eles, as CVEs associadas.
Use multi-stage build: compile em uma etapa e copie só o artefato final, deixando compiladores e ferramentas de build fora da imagem de produção.
Fixe a base por digest (FROM imagem@sha256:...) e atualize de forma deliberada, para que o resultado do scan seja reprodutível.
Rode como usuário não root com USER no Dockerfile.
Reconstrua com frequência: uma imagem sem mudança de código acumula CVEs novas com o tempo.

Defina critérios de bloqueio realistas

Bloquear qualquer CVE de qualquer severidade paralisa o time e leva à desativação do scan. Um ponto de partida comum é bloquear CRITICAL e HIGH com correção disponível e apenas reportar o restante. O filtro --ignore-unfixed (Trivy) e --only-fixed (Scout) existem para isso, mas lembre que CVEs sem correção continuam sendo risco: elas devem ser acompanhadas, não esquecidas.

Trate exceções como dívida com prazo

Toda supressão deve ter justificativa e data de revisão. Prefira VEX ou entradas com expiração a um .trivyignore que só cresce. Uma CVE suprimida sem registro de por quê é indistinguível de uma CVE esquecida.

Armadilhas frequentes

Achar que zero CVEs significa seguro. O scan cobre vulnerabilidades conhecidas em componentes inventariados; não detecta falhas de lógica na sua aplicação nem configuração insegura em runtime.
Escanear só no build. O risco muda depois do deploy; combine o scan de CI com reescaneamento agendado, Trivy Operator ou o monitoramento do Scout.
Priorizar só por CVSS. Combine severidade com correção disponível, presença no catálogo KEV e EPSS; uma CVE crítica em um pacote que a aplicação não carrega pode esperar, uma média explorada ativamente não.
Ignorar divergências entre ferramentas. Se Trivy e Scout discordam, verifique a fonte do advisory e a versão do pacote antes de concluir qual está certo.
Deixar o banco desatualizado. Um scan com banco antigo gera falsa sensação de segurança, especialmente em ambientes isolados com --skip-db-update.

Conclusão

Trivy e Docker Scout se complementam mais do que competem. O Trivy entrega cobertura ampla, neutra e executável em qualquer ambiente, incluindo IaC, secrets e Kubernetes. O Docker Scout entrega contexto: qual base image trocar, o que mudou entre duas versões e se a imagem cumpre as políticas da organização.

Um caminho prático para começar:

Rode trivy image e docker scout quickview na imagem de produção atual e compare os resultados.
Use docker scout recommendations para escolher uma base image menor ou mais atual.
Adicione o pipeline de GitHub Actions com bloqueio apenas para CRITICAL com correção disponível.
Passe a gerar SBOM e provenance no build.
Agende o reescaneamento das imagens publicadas e, em Kubernetes, avalie o Trivy Operator.

Referências

Flags, nomes de inputs das actions e recursos dependem da versão e do plano; confirme sempre na documentação oficial antes de adotar um comando em produção.

Kyverno Policy as Code no Kubernetes

Kauê Matos — Wed, 07 Oct 2026 02:51:01 +0000

Kyverno (do grego "governar") é um motor de políticas nativo do Kubernetes, projeto da CNCF, que permite validar, alterar e gerar recursos do cluster usando apenas YAML, sem aprender uma linguagem nova.

Em clusters compartilhados, qualquer pessoa com acesso ao kubectl apply pode criar um Pod privilegiado, uma imagem sem tag ou um Service exposto sem querer. Revisão manual não escala, e documentação de boas práticas não impede ninguém de errar. O Kyverno resolve isso aplicando regras no momento em que o recurso chega à API do Kubernetes, antes de ele ser persistido no etcd.

O diferencial frente a outras ferramentas é que as políticas são recursos Kubernetes comuns (ClusterPolicy, Policy), versionáveis em Git e entregues por GitOps. Quem já escreve manifests consegue escrever políticas no mesmo dia.

O que o Kyverno faz, em resumo:

Validar: bloquear ou apenas auditar recursos fora do padrão (por exemplo, containers rodando como root).
Mutar: injetar valores padrão (labels, securityContext, imagePullPolicy) automaticamente.
Gerar: criar recursos derivados, como NetworkPolicy e ResourceQuota em todo novo namespace.
Verificar imagens: exigir assinaturas e atestações (Cosign/Sigstore) antes de rodar uma imagem.
Limpar: remover recursos expirados por regras de TTL ou de agendamento.

Arquitetura

O Kyverno roda dentro do cluster como um conjunto de controladores, e o principal deles é um admission webhook registrado no API Server.

[embedded content: fluxo de admissão e componentes do Kyverno]

Quando uma requisição de criação ou atualização chega ao API Server, ele consulta o webhook do Kyverno, que avalia as políticas e devolve a decisão: aprovar, negar ou aprovar com alterações (patch). Só o que é aprovado é gravado no etcd.

Os componentes:

Admission controller: atende o webhook, aplicando as regras validate, mutate e verifyImages em tempo real.
Background controller: processa regras generate e mutate sobre recursos existentes.
Reports controller: consolida os resultados em PolicyReport e ClusterPolicyReport.
Cleanup controller: executa as políticas de limpeza e a remoção por TTL.

Como cada controlador é um Deployment separado, dá para dimensionar e escalar cada um de forma independente. Por exemplo, o admission controller, que fica no caminho de toda requisição, merece mais réplicas e mais atenção que os demais.

Tipos de regras

Uma política tem uma ou mais regras, e cada regra declara um match (a quais recursos se aplica), condições opcionais (exclude, preconditions) e uma ação. Existem cinco tipos de ação.

Tipo	O que faz	Quando roda
`validate`	Aprova ou rejeita o recurso conforme um padrão, uma expressão CEL ou `deny` com condições	Admissão e varredura em background
`mutate`	Altera o recurso, via merge patch, JSON patch ou `foreach`	Admissão (e sobre recursos existentes, se configurado)
`generate`	Cria ou sincroniza outros recursos a partir de um gatilho	Quando o recurso gatilho é criado ou atualizado
`verifyImages`	Confere assinaturas e atestações de imagens de container	Admissão de Pods e workloads
`cleanup`	Apaga recursos que casam com uma condição, em um cronograma	Periodicamente (`CleanupPolicy`)

A ordem importa: o Kubernetes executa as mutações antes das validações, então uma política mutate pode preencher um campo que uma política validate exige logo depois.

A ação de uma política validate depende do campo validationFailureAction. Com Audit, a violação é registrada, mas o recurso passa. Com Enforce, a requisição é negada e o usuário recebe a mensagem de erro definida na política. Nas versões mais recentes essa configuração pode ser refinada por namespace, o que facilita uma adoção gradual.

Exemplos práticos

Os três exemplos abaixo usam a API kyverno.io/v1 (ClusterPolicy). Os nomes de campos podem variar entre versões, então confira a documentação da versão instalada.

1. Validar: exigir limites de recursos

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: check-limits
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Todos os containers devem definir limits de CPU e memória."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

2. Mutar: adicionar um padrão de segurança

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-security-context
spec:
  rules:
    - name: set-run-as-non-root
      match:
        any:
          - resources:
              kinds: [Pod]
      mutate:
        patchStrategicMerge:
          spec:
            securityContext:
              +(runAsNonRoot): true

O prefixo +() é um "anchor" de adição: o valor só é inserido se o campo ainda não existir, respeitando o que o desenvolvedor já definiu.

3. Gerar: NetworkPolicy padrão em todo namespace novo

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: default-deny-ingress
spec:
  rules:
    - name: generate-default-deny
      match:
        any:
          - resources:
              kinds: [Namespace]
      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny-ingress
        namespace: "{{request.object.metadata.name}}"
        synchronize: true
        data:
          spec:
            podSelector: {}
            policyTypes: [Ingress]

Com synchronize: true, se alguém apagar ou editar a NetworkPolicy gerada, o Kyverno a restaura. Isso transforma a regra em uma garantia contínua, e não apenas em um passo inicial.

Policy Reports, Audit vs Enforce e exceções

O caminho seguro para adotar o Kyverno em um cluster existente é começar em Audit, medir o impacto e só então passar para Enforce.

O Kyverno grava os resultados de cada avaliação em recursos PolicyReport (por namespace) e ClusterPolicyReport, no formato padronizado da comunidade (Policy WG). Com background: true, as políticas também varrem recursos que já existem, e não só os novos. Assim você descobre quantos workloads violariam a regra antes de bloquear qualquer deploy.

kubectl get policyreport -A
kubectl get clusterpolicyreport -o wide

Um roteiro de adoção que funciona bem:

Instale a política em Audit e deixe rodar alguns dias.
Leia os relatórios (ou exporte para Prometheus/Grafana) e corrija os workloads que violam.
Trate os casos legítimos com exceções, nunca afrouxando a regra para todos.
Mude para Enforce, começando por namespaces não críticos.

Para exceções pontuais existem duas ferramentas: o bloco exclude dentro da própria regra (por namespace, label, usuário ou role) e o recurso PolicyException, que permite a uma equipe pedir a isenção de uma política específica sem editar a política original. O PolicyException costuma ser mais auditável, porque cada exceção vira um objeto próprio, com dono e histórico no Git.

Também vale excluir os namespaces do sistema (kube-system, o próprio namespace do Kyverno) das políticas mais restritivas, para não travar componentes essenciais do cluster.

Kyverno CLI e testes no CI/CD

O Kyverno CLI aplica as mesmas políticas fora do cluster, o que permite barrar um manifest inválido no pull request, bem antes do deploy.

Há dois comandos principais:

kyverno apply: avalia políticas contra manifests locais (ou contra recursos de um cluster) e imprime aprovações e violações.
kyverno test: roda uma suíte de testes declarativa, comparando o resultado esperado de cada regra com o obtido.

# Valida os manifests do repositório contra as políticas
kyverno apply ./policies --resource ./k8s/deployment.yaml

# Executa os testes das políticas
kyverno test ./policies

Um arquivo kyverno-test.yaml lista as políticas, os recursos de entrada e o resultado esperado (pass, fail, skip) por regra. Tratar políticas como código significa testá-las como código: um teste de que o recurso ruim falha e o recurso bom passa evita que uma edição "inocente" na política abra uma brecha.

Em um pipeline do GitHub Actions, o fluxo típico é:

Fazer checkout do repositório de manifests e de políticas.
Instalar o CLI (ação oficial ou download do binário).
Rodar kyverno test nas políticas e kyverno apply nos manifests da aplicação.
Falhar o job se houver violações em políticas de severidade alta.

O resultado é um feedback em segundos para quem abriu o PR, e o admission controller do cluster fica como última linha de defesa, não como a primeira.

Instalação e operação em produção

A instalação recomendada é via Helm, em um namespace dedicado e com réplicas suficientes para alta disponibilidade.

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm install kyverno kyverno/kyverno \
  -n kyverno --create-namespace \
  --set admissionController.replicas=3

Em produção, alguns pontos merecem atenção desde o primeiro dia:

Alta disponibilidade: use três réplicas do admission controller, com PodDisruptionBudget e anti-afinidade. Como o webhook está no caminho de toda requisição de criação, uma indisponibilidade pode travar deploys.
failurePolicy do webhook: com Fail, se o Kyverno estiver fora do ar, as requisições são negadas (mais seguro, menos disponível). Com Ignore, elas passam sem validação. Escolha de forma consciente por cluster.
Recursos e escala: o consumo de memória cresce com o número de recursos no cluster e de políticas. Defina requests e limits e acompanhe as métricas.
Observabilidade: o Kyverno expõe métricas Prometheus (latência de admissão, resultados por política). O Policy Reporter, projeto complementar, entrega dashboards e notificações a partir dos PolicyReport.
Políticas via GitOps: mantenha as políticas em um repositório próprio e aplique com Argo CD ou Flux, para que toda mudança tenha revisão e histórico.
Evite o webhookConfiguration ruidoso: restrinja o match aos tipos de recurso necessários, para o Kyverno não ser chamado em requisições irrelevantes.

Kyverno vs OPA/Gatekeeper e ValidatingAdmissionPolicy

Kyverno se destaca pela curva de aprendizado baixa e pelo escopo amplo (mutar, gerar e verificar imagens); o Gatekeeper é a escolha de quem já usa OPA e Rego em outros sistemas; a ValidatingAdmissionPolicy nativa cobre validações simples sem instalar nada.

Critério	Kyverno	OPA/Gatekeeper	ValidatingAdmissionPolicy (nativa)
Linguagem das regras	YAML, com CEL e JMESPath em casos avançados	Rego (via `ConstraintTemplate`)	CEL
Valida	Sim	Sim	Sim
Muta	Sim	Sim, com recursos mais limitados	Há política de mutação nativa, mais recente
Gera recursos	Sim	Não	Não
Verifica assinatura de imagens	Sim (Cosign/Notary)	Não nativamente	Não
Componente extra no cluster	Sim	Sim	Não, roda dentro do API server
Curva de aprendizado	Baixa para quem conhece YAML	Alta (Rego)	Média (CEL)

Na prática, as três opções não são excludentes. Há times que usam a ValidatingAdmissionPolicy para regras simples e de alta performance e o Kyverno para mutação, geração e verificação de imagens. O próprio Kyverno vem incorporando CEL e novos tipos de política para se aproximar do modelo nativo, então vale conferir na documentação o estado atual dessa evolução antes de escolher o formato das suas políticas.

Uma regra de bolso: se o time já domina Rego e usa OPA fora do Kubernetes, o Gatekeeper preserva o investimento. Se a prioridade é adotar rápido, com políticas legíveis por qualquer pessoa que escreva manifests, o Kyverno costuma ser o caminho mais curto.

Boas práticas e armadilhas comuns

A maior parte dos problemas com Kyverno vem de adotar rápido demais ou de escrever regras amplas demais.

Comece em Audit: bloquear no primeiro dia é o jeito mais rápido de gerar resistência das equipes.
Mensagens de erro claras: diga o que está errado e como corrigir. Uma mensagem boa economiza um chamado de suporte.
Uma política, um objetivo: políticas pequenas e nomeadas pelo que fazem (require-labels, disallow-latest-tag) são mais fáceis de testar, excluir e auditar.
Reaproveite as políticas da comunidade: o catálogo de políticas do Kyverno cobre o Pod Security Standards, boas práticas de rede e supply chain, e serve de ponto de partida.
Cuidado com generate e mutate em cascata: regras que geram recursos que disparam outras regras são difíceis de depurar. Teste com kyverno test antes.
Exclua componentes críticos: o kube-system e o próprio Kyverno devem ficar fora das regras mais restritivas, para evitar o deadlock de um cluster que não consegue subir os próprios pods.
Revise exceções periodicamente: exceções temporárias tendem a virar permanentes se ninguém as reavalia.
Versione tudo no Git: políticas, testes e exceções, com revisão por pull request.

Conclusão

O Kyverno transforma boas práticas de segurança e governança em regras executáveis, escritas na mesma linguagem dos manifests que o time já domina. Ele valida e muta na admissão, gera recursos que precisam existir em todo namespace e confere a origem das imagens, tudo versionado em Git e testável no CI.

Para começar, instale o Kyverno em um cluster de teste, aplique uma política de validação em Audit, leia os PolicyReport e evolua gradualmente até o Enforce. Em poucos dias você terá uma visão concreta do quanto o cluster se afasta do padrão desejado, e um caminho seguro para corrigir isso.

Amazon Aurora Serverless v2 guia detalhado de arquitetura, escala, custo e operação

Kauê Matos — Tue, 06 Oct 2026 01:20:35 +0000

O Amazon Aurora Serverless v2 é uma configuração do Aurora em que a capacidade de computação do banco acompanha a demanda em tempo real, em vez de ser fixada na criação da instância. Você define uma faixa (mínimo e máximo) e o Aurora ajusta a capacidade dentro dela, sem reiniciar o banco e sem derrubar conexões.

Ele não é um produto separado, e sim um tipo de instância dentro de um cluster Aurora comum (db.serverless). Por isso herda o armazenamento distribuído, o Multi-AZ, as réplicas de leitura e o restante do ecossistema do Aurora.

Os valores de preço, limites de ACU e disponibilidade por versão de motor mudam com o tempo. Os números deste artigo são referências para raciocínio. Confirme sempre na documentação e na página de preços da AWS.

2. Um pouco de contexto: v1 vs. v2

	Serverless v1	Serverless v2
Modelo	Cluster inteiro escala	Instâncias escalam individualmente
Escala	Em degraus, com pausa para encontrar "ponto seguro"	Contínua, em incrementos pequenos
Interrompe conexões ao escalar	Pode interromper	Não
Multi-AZ, réplicas, Global DB	Limitado	Suportado
Granularidade	Capacidade dobra	0,5 ACU
Status	Legado	Modelo atual

A v2 foi desenhada para eliminar as limitações da v1 e é o modelo recomendado para novas cargas.

3. Como funciona por dentro

3.1 O ACU (Aurora Capacity Unit)

Cada ACU equivale a aproximadamente 2 GiB de memória, com CPU e rede proporcionais. A capacidade vai de frações de ACU até centenas de ACUs, e o incremento é de 0,5 ACU.

Pense no ACU como uma "fatia" de instância: um banco a 16 ACU tem algo na ordem de 32 GiB de memória disponíveis.

3.2 Escala em linha (in-place)

Diferentemente da troca de classe de instância, a v2 ajusta CPU e memória dentro do próprio processo do banco. As consequências práticas:

Sem failover para escalar.
Conexões e transações em andamento são preservadas.
A escala responde a CPU, memória e rede, não só ao número de conexões.

A velocidade da escala depende da capacidade atual: quanto maior a instância já está, mais rápido ela cresce. Um banco parado em 0,5 ACU sobe mais devagar que um que já opera em 16 ACU. Isso é relevante para quem usa mínimo muito baixo e espera picos bruscos.

3.3 Faixa mínima e máxima

Você configura:

min_capacity: piso de capacidade (pode ser 0 ACU com auto-pause, em versões de motor compatíveis).
max_capacity: teto de capacidade e teto de custo.

O ACU em uso nunca sai dessa faixa. Além de controlar custo, o piso e o teto influenciam parâmetros do banco, como o tamanho do buffer pool e o número máximo de conexões, que são derivados da configuração de capacidade.

3.4 Auto-pause (scale-to-zero)

Com min_capacity = 0, o banco pode pausar após um período de inatividade que você configura, e a computação deixa de ser cobrada. Ao chegar uma nova conexão, o banco retoma, o que leva algum tempo (na casa de segundos).

Pontos de atenção:

O armazenamento continua sendo cobrado.
A primeira requisição após a pausa sofre a latência de retomada.
É ideal para dev, teste e ferramentas internas, e arriscado para produção com usuários esperando.
Conexões em pool e health checks frequentes podem impedir a pausa, mantendo o banco acordado sem você perceber.

3.5 Armazenamento

O armazenamento é o mesmo do Aurora convencional: volume distribuído em 3 AZs, com 6 cópias, crescendo automaticamente. Você não provisiona disco. A cobrança de storage e I/O é independente do tipo de instância, e existem as opções de configuração Standard e I/O-Optimized.

3.6 Tiers de promoção em clusters com readers

Em clusters com mais de uma instância, os tiers de failover (0 a 15) influenciam como os readers escalam:

Tiers 0 e 1: o reader acompanha a capacidade do writer, para estar pronto para assumir em caso de failover.
Tiers 2 a 15: o reader escala de forma independente, de acordo com a própria carga.

Essa escolha afeta diretamente custo e prontidão para failover.

4. Recursos suportados

Em geral, a v2 funciona com o ecossistema do Aurora:

Multi-AZ e failover automático
Até 15 réplicas de leitura
Aurora Global Database
RDS Proxy
Performance Insights e Enhanced Monitoring
Backups, snapshots e Point-in-Time Recovery
Criptografia com KMS e autenticação IAM
Integração com Secrets Manager (manage_master_user_password)
Blue/Green Deployments
Data API (conforme versão e região)

Compatível com Aurora MySQL e Aurora PostgreSQL, em versões de motor específicas. Vale checar a matriz de versões antes de criar o cluster.

5. Modelo de custo

5.1 Como é cobrado

Computação: ACU-hora consumido, medido por segundo, com mínimo de cobrança por período de capacidade.
Armazenamento: por GB-mês.
I/O: por requisição no modo Standard. No modo I/O-Optimized não há cobrança de I/O, mas o preço de computação e storage é maior.
Backups além da retenção gratuita, transferência de dados, Performance Insights além do tier gratuito, etc.

5.2 Raciocínio de break-even

O ACU-hora é, por unidade de memória, mais caro que uma instância provisionada equivalente. Ilustrando com valores aproximados de us-east-1:

1 ACU ≈ US$ 0,12/h → rodando 24x7 ≈ US$ 87/mês por ACU.
Uma instância db.r6g.large (16 GiB) custa em torno de US$ 0,26/h ≈ US$ 190/mês.
16 GiB equivalem a ~8 ACUs, que custariam ≈ US$ 0,96/h ≈ US$ 700/mês se ficassem sempre ligados.

A conclusão é que, sob carga constante e alta, o provisionado é bem mais barato. Já se o banco usa em média menos de ~25–30% da capacidade equivalente, o serverless costuma sair na frente, e com auto-pause em dev pode custar uma fração.

O raciocínio correto é: custo = média de ACUs consumidos ao longo do tempo × preço do ACU-hora. Por isso o monitoramento de ACU médio importa mais que o pico.

5.3 O que não esquecer

Reserved Instances não se aplicam ao ACU da mesma forma. Savings Plans para banco de dados podem se aplicar, conforme as regras vigentes.
O max_capacity é seu limite de gasto de computação, então defina-o conscientemente.
Readers com tier 0/1 acompanham o writer, e isso multiplica o custo.

6. Quando usar (e quando evitar)

Bons casos de uso

Cargas variáveis ou imprevisíveis: e-commerce com campanhas, apps com picos em horário comercial.
Aplicações novas sem histórico de consumo.
Dev, teste e homologação: principalmente com auto-pause.
SaaS multi-tenant com muitos bancos de perfis diferentes.
Workloads com picos curtos: relatórios noturnos, processamento em lote.
Arquiteturas serverless (Lambda + RDS Proxy) em que o tráfego é irregular.

Quando reconsiderar

Carga alta e constante 24x7: provisionado com Reserved Instance tende a custar menos.
Latência ultra-previsível exigida: variações de cache durante escalas podem incomodar.
Produção com auto-pause: a latência de retomada geralmente é inaceitável.
Falta de limite de custo definido: um max_capacity alto sem alarmes pode gerar conta alta com uma query mal escrita.

7. Arquitetura de referência

Um padrão comum para uma aplicação web em produção:

Usuários
   │
CloudFront ── ALB ── ECS/EKS (aplicação)
                         │
                    RDS Proxy
                         │
        ┌────────────────┴───────────────┐
   Writer (Serverless v2)        Reader(s) (Serverless v2)
        └────────────────┬───────────────┘
              Volume Aurora (3 AZs, 6 cópias)

Pontos de design:

Writer em Serverless v2 com mínimo que mantenha o cache aquecido.
Readers em tier 2+ se você quer que escalem de forma independente e mais barata.
RDS Proxy na frente, para absorver conexões e reduzir o impacto de connection storms.
Secrets Manager para credenciais, com rotação.
Subnets privadas, com Security Groups restritos à camada de aplicação.
Alarmes de ACU, CPU, conexões e latência.

Variação: cluster misto

Como o storage é compartilhado, é possível ter um writer provisionado (carga estável, com desconto) e readers Serverless v2 para absorver picos de leitura. É um bom caminho para quem quer previsibilidade na escrita e elasticidade na leitura.

8. Implementação com Terraform

resource "aws_db_subnet_group" "this" {
  name       = "app-aurora-subnets"
  subnet_ids = var.private_subnet_ids
}

resource "aws_security_group" "db" {
  name   = "app-aurora-sg"
  vpc_id = var.vpc_id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [var.app_security_group_id]
  }
}

resource "aws_rds_cluster" "this" {
  cluster_identifier = "app-aurora-sv2"
  engine             = "aurora-postgresql"
  engine_mode        = "provisioned"   # Serverless v2 usa o modo provisioned
  engine_version     = "16.4"

  database_name               = "appdb"
  master_username             = "dbadmin"
  manage_master_user_password = true

  db_subnet_group_name   = aws_db_subnet_group.this.name
  vpc_security_group_ids = [aws_security_group.db.id]

  storage_encrypted       = true
  backup_retention_period = 7
  deletion_protection     = true
  copy_tags_to_snapshot   = true

  serverlessv2_scaling_configuration {
    min_capacity = 1
    max_capacity = 16
    # seconds_until_auto_pause = 600   # só com min_capacity = 0
  }
}

resource "aws_rds_cluster_instance" "writer" {
  identifier           = "app-aurora-sv2-writer"
  cluster_identifier   = aws_rds_cluster.this.id
  engine               = aws_rds_cluster.this.engine
  engine_version       = aws_rds_cluster.this.engine_version
  instance_class       = "db.serverless"
  promotion_tier       = 0
  performance_insights_enabled = true
}

resource "aws_rds_cluster_instance" "reader" {
  identifier           = "app-aurora-sv2-reader"
  cluster_identifier   = aws_rds_cluster.this.id
  engine               = aws_rds_cluster.this.engine
  engine_version       = aws_rds_cluster.this.engine_version
  instance_class       = "db.serverless"
  promotion_tier       = 2   # escala de forma independente do writer
  performance_insights_enabled = true
}

Observações:

O engine_mode continua provisioned. O que torna a instância serverless é o instance_class = "db.serverless" junto com o bloco serverlessv2_scaling_configuration.
A capacidade é configurada no cluster, e vale para todas as instâncias serverless dele.
Verifique a versão do provider AWS para suporte a recursos mais novos, como o auto-pause.

9. Observabilidade

Métricas essenciais (CloudWatch)

Métrica	O que mostra
`ServerlessDatabaseCapacity`	ACUs em uso no momento
`ACUUtilization`	% do `max_capacity` em uso
`CPUUtilization`	CPU, no contexto da capacidade atual
`FreeableMemory`	Memória livre
`DatabaseConnections`	Conexões abertas
`BufferCacheHitRatio`	Eficiência do cache
`AuroraReplicaLag`	Atraso dos readers

Alarmes recomendados

ACUUtilization alto por tempo prolongado, o que indica max_capacity apertado.
ServerlessDatabaseCapacity encostando no máximo, o que sinaliza risco de saturação e de custo.
BufferCacheHitRatio caindo após escalas para baixo.
Conexões se aproximando do limite.

Um padrão útil: acompanhar a média de ACU por dia e cruzar com a fatura, para validar se o serverless está compensando em relação ao provisionado.

10. Boas práticas

Dimensione o mínimo pelo cache, não só pelo custo. Um piso muito baixo faz o working set sair da memória, e a latência piora quando a carga volta.
Dimensione o máximo pelo teto de custo aceitável e pelo pior pico real.
Use RDS Proxy com Lambda ou aplicações com muitas conexões curtas.
Não use auto-pause em produção com usuários finais, a menos que a latência de retomada seja aceitável.
Escolha o tier de promoção dos readers de acordo com a necessidade de failover rápido versus economia.
Defina alarmes de custo (AWS Budgets) e de ACU. Uma query descontrolada pode manter o banco no máximo por horas.
Otimize queries antes de aumentar o máximo. Escalar infraestrutura para esconder SQL ruim é caro.
Teste carga com perfil realista, incluindo picos súbitos, para validar a velocidade de escala partindo do mínimo escolhido.
Mantenha IaC e proteção contra deleção ligadas em produção.
Reavalie a cada trimestre: se a carga estabilizou, talvez o writer deva migrar para uma instância fixa.

11. Migração

De Aurora provisionado para Serverless v2: como o storage é o mesmo, adicione uma instância db.serverless ao cluster, promova-a via failover e remova a instância antiga. É necessário que a versão do motor seja compatível.
De Serverless v1 para v2: o caminho é por snapshot/restauração ou por upgrade de versão com recriação, conforme a documentação vigente. Planeje uma janela de manutenção e teste no ambiente de homologação.
De RDS comum para Aurora Serverless v2: use réplica de leitura Aurora ou o AWS DMS, dependendo do motor e da tolerância a downtime.

12. Armadilhas comuns

Achar que serverless é sempre mais barato. Em carga constante e alta, é o contrário.
Mínimo em 0,5 ACU em produção e depois estranhar a lentidão no primeiro pico.
Esquecer que readers de tier 0/1 acompanham o writer e dobram o custo.
Deixar o max_capacity muito alto sem alarmes.
Pools de conexão que impedem o auto-pause em ambientes de dev.
Ignorar limites de conexão derivados da capacidade configurada.

13. Conclusão

O Aurora Serverless v2 resolve um problema clássico: pagar por capacidade que você só usa em parte do tempo. Ele entrega elasticidade fina, sem downtime ao escalar, e mantém todos os recursos do Aurora. Em troca, cobra mais caro por unidade de capacidade e exige disciplina com limites, monitoramento e dimensionamento de mínimo e máximo.

A decisão certa não é "serverless ou fixo" de forma absoluta, e sim medir a utilização real, calcular o custo nos dois modelos e, quando fizer sentido, combiná-los no mesmo cluster.

Artifact Hub: o guia completo do repositório central de pacotes Kubernetes

Kauê Matos — Sun, 04 Oct 2026 13:45:52 +0000

Quem trabalha com Kubernetes conhece o ritual: precisa de um ingress controller, um operador de banco, uma política de segurança ou um plugin do kubectl, e começa a busca no GitHub, em blogs e em READMEs. Cada projeto publica de um jeito, em um lugar diferente, com níveis variados de documentação e de cuidado com segurança.

O Artifact Hub centraliza essa descoberta. Ele indexa pacotes de centenas de repositórios e mostra, numa interface única, documentação, versões, licença, mantenedores, vulnerabilidades conhecidas e o comando de instalação. Este artigo explica o que ele é, como funciona por dentro, como consumir e publicar pacotes e quais cuidados de segurança e governança times de plataforma devem ter.

O que é o Artifact Hub

O Artifact Hub é uma aplicação web de código aberto, hospedada pela CNCF em artifacthub.io, para descobrir, instalar e publicar pacotes e configurações de projetos cloud native. Ele nasceu a partir do antigo Helm Hub, que foi incorporado a ele, e hoje é um projeto da CNCF (confira o nível de maturidade atual na página do projeto na CNCF, pois ele muda com o tempo).

O ponto mais importante: o Artifact Hub é um catálogo, não um registry. Ele não armazena seus charts nem suas imagens. Quem publica continua hospedando os artefatos onde já hospeda (um repositório Helm em GitHub Pages, um registry OCI, um repositório Git) e o Artifact Hub apenas indexa os metadados e os apresenta.

Na prática, isso traz três consequências:

Você não depende dele para instalar: helm install continua apontando para o repositório de origem.
Se um repositório sai do ar, o pacote some da fonte, mesmo que a página continue listada por um tempo.
A confiança vem dos sinais que ele exibe (publisher verificado, status oficial, scan de segurança, assinatura), e não do simples fato de o pacote estar listado.

Tipos de artefatos suportados

Helm charts são a maior parte do catálogo, mas o Artifact Hub cobre muito mais do que isso. A lista abaixo mostra os tipos mais usados; ela cresce conforme projetos da CNCF adotam a plataforma, então vale conferir a documentação para o conjunto atual.

Tipo	O que é	Onde costuma ser usado
Helm charts	Pacotes de manifests Kubernetes com templates e values	Instalar aplicações e componentes de cluster
OLM operators	Operadores empacotados para o Operator Lifecycle Manager	Bancos de dados, mensageria e outros serviços com ciclo de vida complexo
Tekton tasks e pipelines	Blocos reutilizáveis de CI/CD nativo de Kubernetes	Pipelines de build e deploy
Políticas (OPA, Gatekeeper, Kyverno, Kubewarden)	Regras de admissão e conformidade	Governança e segurança de cluster
Regras Falco	Detecção de comportamento anômalo em runtime	Observabilidade de segurança
Plugins do kubectl (Krew)	Extensões da CLI do Kubernetes	Produtividade e troubleshooting
Backstage plugins	Plugins para portais de desenvolvedores	Plataformas internas (IDP)
Imagens de container	Referências a imagens publicadas	Descoberta e avaliação de segurança
Outros	KEDA scalers, plugins do CoreDNS, templates Argo, entre outros	Casos específicos de cada projeto

Para times de plataforma, essa diversidade é a vantagem real: um único lugar para procurar tanto o chart do cert-manager quanto a política Kyverno que impõe limites de recursos.

Arquitetura: como o catálogo é montado

O Artifact Hub é composto por poucos serviços em torno de um banco PostgreSQL: o hub (API e interface), o tracker, o scanner e o notifier.

[embedded content: arquitetura do Artifact Hub · 5 serviços e os repositórios de origem]

O tracker lê os repositórios de origem e grava os metadados no banco; o scanner analisa as imagens com o Trivy; o notifier envia alertas por e-mail e webhook. O hub serve a interface e a API a partir do banco, enquanto a instalação com helm install vai sempre direto à origem.

Como usar: buscar, avaliar e instalar

O fluxo de consumo tem três passos: buscar, avaliar o pacote e instalar a partir do repositório de origem.

Buscar. Use a busca em artifacthub.io e filtre por tipo (por exemplo, apenas Helm charts), por publisher verificado, por status oficial ou por licença.
Avaliar. Abra a página do pacote e olhe, nessa ordem: quem publica (selos de Verified publisher e Official), data da última versão, changelog, relatório de segurança, licença, links de documentação e o values.yaml com seu schema.
Instalar. O botão Install mostra os comandos exatos. Para um chart Helm, o formato é este (exemplo com o cert-manager):

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

Use sempre os comandos da página do pacote, porque flags como a que habilita os CRDs mudam entre versões. Para inspecionar antes de instalar, helm show values jetstack/cert-manager e helm template ajudam a revisar o que será aplicado.

O Artifact Hub também tem uma API REST pública, útil para automação. Um exemplo de busca por charts (confirme os parâmetros na documentação da API):

curl -s "https://artifacthub.io/api/v1/packages/search?ts_query_web=cert-manager&kind=0&limit=5"

Com uma conta gratuita você também pode seguir pacotes, receber notificações de novas versões e de alertas de segurança por e-mail ou webhook, e dar star nos pacotes que sua equipe usa.

Publicando seus pacotes

Publicar no Artifact Hub é registrar um repositório que você já mantém, não subir arquivos. O processo tem quatro etapas.

Hospede o chart em um repositório Helm (GitHub Pages com o chart-releaser, por exemplo) ou em um registry OCI.
Adicione o repositório no painel de controle do Artifact Hub (conta necessária), informando tipo, nome e URL.
Comprove a propriedade com o arquivo artifacthub-repo.yml, publicado na raiz do repositório (ou como tag especial em registries OCI), contendo o repositoryID gerado pela plataforma e o e-mail do dono. Isso concede o selo Verified publisher.
Enriqueça os metadados com annotations no Chart.yaml.

Exemplo de artifacthub-repo.yml:

repositoryID: 00000000-0000-0000-0000-000000000000
owners:
  - name: Time de Plataforma
    email: plataforma@exemplo.com.br

E de annotations no Chart.yaml, que melhoram a página do pacote:

annotations:
  artifacthub.io/license: Apache-2.0
  artifacthub.io/images: |
    - name: minha-app
      image: ghcr.io/minha-org/minha-app:1.4.2
  artifacthub.io/changes: |
    - kind: added
      description: Suporte a ServiceMonitor
    - kind: fixed
      description: Probe de readiness com timeout incorreto
  artifacthub.io/links: |
    - name: Documentação
      url: https://exemplo.com.br/docs

A annotation artifacthub.io/images é a mais importante para segurança: é por ela que o scanner sabe quais imagens analisar. Outras annotations úteis cobrem mantenedores, CRDs com exemplos, recomendações e marcação de versões prerelease ou com correções de segurança.

O selo Official é diferente: indica que o publicador é o dono do software empacotado, e é concedido pela equipe do Artifact Hub após solicitação.

No CI (GitHub Actions, por exemplo), rode o ah lint (CLI do projeto) sobre o chart antes de cada release para pegar annotations malformadas antes que o tracker as rejeite.

Segurança: o que o Artifact Hub verifica e o que não verifica

O Artifact Hub oferece sinais úteis de segurança, mas nenhum deles substitui a revisão do seu próprio time. Entender o limite de cada sinal evita falsa sensação de proteção.

Sinal	O que significa	O que não garante
Verified publisher	O dono do repositório comprovou controle sobre ele via `artifacthub-repo.yml`	Que o conteúdo do chart é seguro ou bem mantido
Official	O publicador é o dono do software empacotado	Ausência de vulnerabilidades nas imagens
Security report	Resultado do scan com Trivy nas imagens listadas no pacote	Cobertura de imagens não declaradas ou de vulnerabilidades ainda desconhecidas
Signed	O pacote tem assinatura verificável (provenance do Helm; em alguns tipos, Cosign)	Que a chave de assinatura é confiável para você
Stars e uso	Popularidade entre usuários	Qualidade ou segurança

Boas práticas para quem consome:

Trate o security report como triagem, não como aprovação. Reescaneie as imagens no seu pipeline com o scanner que sua empresa adota.
Fixe versões de chart e de imagem (de preferência por digest) e revise o helm template antes de atualizar.
Prefira publishers verificados e oficiais, e desconfie de pacotes sem manutenção recente.
Verifique assinaturas quando disponíveis e imponha isso por política (Kyverno ou Gatekeeper no cluster).
Mantenha um mirror interno para charts críticos, para não depender da disponibilidade do repositório de origem.

Self-hosting e API

Como o projeto é de código aberto, você pode rodar sua própria instância do Artifact Hub, por exemplo para catalogar apenas charts internos e aprovados. O repositório oficial inclui um chart Helm para instalar a aplicação.

O que você precisa preparar:

PostgreSQL como banco de dados principal, com as migrações aplicadas pelo próprio chart.
Servidor SMTP, se quiser notificações por e-mail.
Autenticação: contas locais ou provedores OAuth/OIDC, conforme a configuração.
Repositórios privados: repositórios com autenticação podem ser registrados informando credenciais, o que torna a instância útil como portal interno.

A configuração fica em um arquivo de valores do chart; consulte o guia de instalação na documentação oficial, porque as opções mudam entre versões.

A API REST (pública em artifacthub.io e idêntica na instância própria) permite integrar o catálogo a outras ferramentas: buscar pacotes, obter detalhes de uma versão, ler o security report e listar repositórios. Alguns usos comuns em plataformas internas:

Um bot que avisa no Slack quando um chart usado pela empresa publica versão com correção de segurança.
Um job de CI que consulta a última versão estável de um chart e abre um pull request de atualização.
Um portal de desenvolvedores (como o Backstage) que mostra o catálogo aprovado da empresa.

Limitações, alternativas e boas práticas

O Artifact Hub é excelente para descoberta, mas não resolve sozinho a governança de pacotes de uma empresa.

Limitações a ter em mente

Qualidade desigual: qualquer pessoa pode registrar um repositório, e a listagem não implica revisão.
Metadados dependem do publisher: sem annotations, a página fica pobre e o scan de segurança pode ficar incompleto.
Há atraso entre a publicação de uma versão e sua aparição no catálogo, porque o tracker roda periodicamente.
É um catálogo: disponibilidade e integridade dos artefatos continuam sendo responsabilidade do repositório de origem.

Alternativas e complementos

Ferramenta	Papel	Quando usar
Registries OCI privados (Harbor, ECR, GHCR)	Armazenar charts e imagens com controle de acesso	Fonte de verdade interna e mirror de pacotes externos
OperatorHub.io	Catálogo focado em operadores	Descobrir operadores OLM (que também aparecem no Artifact Hub)
Docker Hub	Catálogo e registry de imagens	Descobrir imagens, não pacotes Kubernetes completos
Artifact Hub próprio	Catálogo interno com repositórios privados	Portal de pacotes aprovados pela empresa

Boas práticas para times de plataforma

Use o Artifact Hub público para descobrir e avaliar, e um registry interno para consumir.
Defina critérios mínimos de aceite: publisher verificado, manutenção recente, licença compatível e scan sem vulnerabilidades críticas sem correção.
Faça o mirror dos charts aprovados e aponte o GitOps (Argo CD ou Flux) para o mirror.
Assine seus próprios charts e imagens e verifique as assinaturas no admission controller.
Se publica pacotes, mantenha changelog, annotations e ah lint no CI, tratando a página do Artifact Hub como a vitrine do seu produto.

Conclusão

O Artifact Hub é a porta de entrada mais prática para o ecossistema de pacotes do Kubernetes: reúne Helm charts, operadores, políticas e plugins num só lugar, com sinais de confiança e segurança visíveis. O cuidado essencial é lembrar que ele cataloga e não garante: a decisão de adotar um pacote continua sendo do seu time.

Como próximos passos, escolha um chart que sua equipe já usa e avalie a página dele pelos critérios deste artigo. Se você publica pacotes, registre seu repositório, adicione o artifacthub-repo.yml e as annotations, e rode o ah lint no CI. Para plataformas internas, considere uma instância própria combinada a um registry privado como fonte de verdade.

Argo CD a fundo como funciona o GitOps na prática

Kauê Matos — Sat, 03 Oct 2026 19:01:42 +0000

O Argo CD resolve um problema simples e caro: garantir que o que está rodando no Kubernetes é exatamente o que está versionado no Git. Ele é um controlador declarativo de entrega contínua (CD) para Kubernetes, mantido pela comunidade Argo e projeto graduado da CNCF.

Sem uma ferramenta assim, o fluxo típico é um pipeline de CI que termina com kubectl apply ou helm upgrade contra o cluster. Isso funciona até o dia em que alguém altera um recurso na mão, o pipeline falha pela metade ou o cluster perde o estado e ninguém sabe qual era a versão "correta". É o chamado configuration drift.

Neste artigo você vai ver:

o que é GitOps e por que o modelo pull muda o jogo;
como o Argo CD é construído por dentro, componente por componente;
o ciclo de reconciliação, do commit até o recurso saudável no cluster;
os recursos principais (Application, AppProject, ApplicationSet) com exemplos em YAML;
sync policies, waves e hooks para controlar a ordem do deploy;
multi-cluster, segurança, escala e observabilidade;
um comparativo com Flux e com pipelines push, e um exemplo prático do zero.

GitOps em poucas palavras

GitOps é tratar o Git como a única fonte de verdade do estado desejado da infraestrutura e das aplicações, e deixar um agente dentro do cluster trazer a realidade até esse estado. O Argo CD é uma implementação desse agente.

Os quatro princípios, resumidos:

Declarativo: o sistema inteiro é descrito em manifestos (YAML, Helm, Kustomize), não em scripts de passo a passo.
Versionado e imutável: cada mudança é um commit, com autor, revisão por pull request e histórico para auditoria.
Aplicado automaticamente: um agente puxa o estado aprovado, sem que alguém precise rodar comandos contra o cluster.
Reconciliado continuamente: se o estado real divergir do desejado, o agente detecta e corrige (ou ao menos avisa).

Push versus pull

A diferença central está em quem tem a credencial do cluster. No modelo push, o pipeline de CI fica de fora e precisa de acesso administrativo ao cluster para aplicar mudanças. No modelo pull, o agente já está dentro do cluster e só precisa de permissão de leitura no repositório Git.

Aspecto	Push (CI faz o deploy)	Pull (Argo CD)
Credenciais do cluster	Ficam no sistema de CI	Ficam só dentro do cluster
Detecção de drift	Não existe, só no próximo deploy	Contínua
Rollback	Reexecutar pipeline antigo	Reverter o commit no Git
Quem aplica	Job efêmero do pipeline	Controlador sempre ativo
Superfície de ataque	Maior (chave do cluster exposta ao CI)	Menor

Arquitetura: os componentes por dentro

O Argo CD é um conjunto de serviços pequenos, cada um com uma responsabilidade, que rodam juntos em um namespace (normalmente argocd) e conversam com o repositório Git e com os clusters de destino.

[embedded content: arquitetura do Argo CD · 7 componentes e 2 sistemas externos]

O caminho principal é este: o Application Controller pede ao Repo Server os manifestos renderizados a partir do Git, compara com o que existe no cluster e aplica a diferença. O API Server serve a interface, a CLI e a API, e delega o login ao Dex.

Componente	Workload padrão	Responsabilidade
`argocd-server`	Deployment	Expõe a UI, a CLI e a API; aplica RBAC e valida tokens
`argocd-repo-server`	Deployment	Mantém clones locais dos repositórios e gera os manifestos finais (Helm, Kustomize, plugins)
`argocd-application-controller`	StatefulSet	Observa as aplicações e o cluster, calcula o diff, executa a sincronização e avalia a saúde dos recursos
`argocd-redis`	Deployment	Cache do estado dos recursos e dos manifestos renderizados, para reduzir leituras no Git e na API do Kubernetes
`argocd-dex-server`	Deployment	Intermedia o login com provedores de identidade externos
`argocd-applicationset-controller`	Deployment	Gera e mantém objetos `Application` a partir de `ApplicationSet`
`argocd-notifications-controller`	Deployment	Envia alertas quando uma aplicação muda de estado

Uma consequência importante do desenho: o Repo Server só gera manifestos, e quem toca nos clusters é o Application Controller. Isso permite escalar cada parte separadamente e limitar o que cada uma enxerga.

Ciclo de reconciliação: do commit ao cluster

A cada ciclo, o Argo CD compara o Git com o cluster antes de aplicar qualquer coisa, e só age quando encontra diferença e a política permite.

[embedded content: ciclo de reconciliação · 6 etapas e 2 decisões]

Há duas formas de o Argo CD descobrir que algo mudou. A primeira é o polling do repositório, a cada 3 minutos por padrão. A segunda é um webhook (GitHub, GitLab, Bitbucket e outros), que avisa na hora e dispensa a espera. Mudanças feitas direto no cluster são percebidas de outro jeito: o Application Controller observa os recursos vivos continuamente.

Dois eixos de status

Na interface aparecem dois status independentes, e confundi-los é um erro comum.

Eixo	Pergunta que responde	Valores principais
Sync status	O cluster está igual ao Git?	`Synced`, `OutOfSync`, `Unknown`
Health status	Os recursos estão funcionando?	`Healthy`, `Progressing`, `Degraded`, `Suspended`, `Missing`, `Unknown`

Uma aplicação pode estar Synced e Degraded ao mesmo tempo: o manifesto foi aplicado exatamente como está no Git, mas o Pod não sobe. O contrário também vale, com OutOfSync e Healthy, quando alguém alterou algo à mão e o serviço continua funcionando.

O Argo CD sabe avaliar a saúde de recursos nativos (Deployment, StatefulSet, Ingress, Job e outros). Para CRDs, é possível escrever uma verificação de saúde customizada em Lua.

Para ver a diferença antes de sincronizar, use argocd app diff <aplicação>.

Recursos principais: Application, AppProject e ApplicationSet

O Argo CD é configurado por CRDs do próprio Kubernetes, então a configuração do Argo CD também pode (e deve) viver no Git. Três recursos cobrem quase todo o uso.

Application

A Application liga uma origem (repositório, revisão e caminho) a um destino (cluster e namespace). É a unidade que o Argo CD sincroniza e cujo status ele mostra.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: loja-api
  namespace: argocd
spec:
  project: loja
  source:
    repoURL: https://github.com/minha-org/loja-gitops.git
    targetRevision: main
    path: apps/api/overlays/producao
  destination:
    server: https://kubernetes.default.svc
    namespace: loja
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

O campo path pode apontar para YAML puro, um chart Helm, uma pasta Kustomize ou um plugin de geração de manifestos.

AppProject

O AppProject é a fronteira de segurança e de organização. Ele define de quais repositórios um grupo de aplicações pode ler, para quais clusters e namespaces pode implantar e quais tipos de recurso são permitidos.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: loja
  namespace: argocd
spec:
  sourceRepos:
    - https://github.com/minha-org/loja-gitops.git
  destinations:
    - server: https://kubernetes.default.svc
      namespace: loja
  clusterResourceWhitelist: []
  namespaceResourceBlacklist:
    - group: ""
      kind: ResourceQuota

Com clusterResourceWhitelist vazio, o time dono do projeto não consegue criar recursos de escopo de cluster (como ClusterRole), mesmo que escreva isso no repositório.

ApplicationSet

O ApplicationSet gera várias Application a partir de um modelo e de generators. É a resposta para "preciso da mesma aplicação em 30 clusters" ou "uma aplicação por pasta do repositório".

Generator	O que ele faz
List	Itera sobre uma lista fixa de valores
Cluster	Gera uma aplicação por cluster cadastrado no Argo CD
Git (diretórios)	Gera uma aplicação por pasta encontrada no repositório
Git (arquivos)	Lê arquivos JSON/YAML e usa o conteúdo como parâmetros
Pull Request	Cria um ambiente efêmero por pull request aberto
Matrix / Merge	Combina dois generators (por exemplo, cluster × diretório)

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: servicos
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/minha-org/loja-gitops.git
        revision: main
        directories:
          - path: apps/*
  template:
    metadata:
      name: "{{path.basename}}"
    spec:
      project: loja
      source:
        repoURL: https://github.com/minha-org/loja-gitops.git
        targetRevision: main
        path: "{{path}}"
      destination:
        server: https://kubernetes.default.svc
        namespace: "{{path.basename}}"

Com isso, criar uma nova pasta em apps/ basta para que uma nova aplicação apareça no Argo CD, sem tocar em nenhum outro arquivo.

Sync policies, waves e hooks

Por padrão a sincronização é manual: o Argo CD mostra OutOfSync e espera alguém clicar em Sync. Três mecanismos controlam o quanto disso é automático e em que ordem as coisas acontecem.

Política de sincronização automática

Quando syncPolicy.automated está ativo, o Argo CD aplica sozinho qualquer diferença entre o Git e o cluster. Duas opções mudam bastante o comportamento:

prune: true: remove do cluster recursos que foram apagados do Git. Sem isso, o que sai do repositório continua rodando.
selfHeal: true: desfaz alterações feitas diretamente no cluster (por exemplo, um kubectl edit em um Deployment) e volta ao estado do Git.

Outras opções úteis ficam em syncOptions, como CreateNamespace=true, ServerSideApply=true e PruneLast=true. Há também retry, com backoff exponencial, para tentar de novo quando uma sincronização falha por motivo transitório.

Sync waves

Os recursos de uma aplicação são aplicados em ordem de wave, definida pela anotação argocd.argoproj.io/sync-wave. O padrão é 0, valores menores vêm antes e valores negativos são permitidos. O Argo CD só avança para a próxima wave quando todos os recursos da atual estão saudáveis.

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # roda antes dos recursos da wave 0

Um uso típico: Namespace e CRD na wave -2, ConfigMap e Secret na wave -1, o Deployment na wave 0 e um Ingress na wave 1.

Hooks

Hooks são recursos (normalmente Job) que rodam em fases específicas da sincronização, marcados com a anotação argocd.argoproj.io/hook.

Hook	Quando roda	Uso comum
`PreSync`	Antes de aplicar os manifestos	Migração de banco de dados
`Sync`	Junto com a aplicação dos manifestos	Passos que dependem da ordem das waves
`PostSync`	Depois que tudo ficou saudável	Teste de fumaça, notificação
`SyncFail`	Quando a sincronização falha	Limpeza, alerta

A anotação argocd.argoproj.io/hook-delete-policy define quando o Job é apagado (HookSucceeded, HookFailed ou BeforeHookCreation). Se um PreSync falhar, a sincronização é interrompida e os manifestos principais não são aplicados, o que protege contra subir uma versão nova com o banco no estado antigo.

Multi-cluster, RBAC, SSO e segurança

Uma única instância do Argo CD pode gerenciar vários clusters, e é isso que o torna útil em empresas com ambientes separados para desenvolvimento, homologação e produção.

Multi-cluster

O cluster onde o Argo CD roda se chama in-cluster (https://kubernetes.default.svc). Para adicionar outros, usa-se argocd cluster add <contexto>, que cria uma ServiceAccount no cluster remoto e guarda o token em um Secret no namespace argocd. Há dois desenhos comuns:

Hub e spokes: um Argo CD central gerencia todos os clusters. É mais simples de operar, mas esse cluster central passa a guardar credenciais de todos os outros e vira um alvo importante.
Uma instância por cluster (ou por ambiente): cada Argo CD gerencia só o próprio cluster. Isola o impacto de uma falha ou invasão, ao custo de operar várias instâncias.

RBAC e SSO

A autenticação delega para um provedor externo via Dex (embutido) ou OIDC direto, com suporte a GitHub, GitLab, Google, Okta, Azure AD, Keycloak e LDAP. A autorização usa uma política no estilo Casbin, no ConfigMap argocd-rbac-cm:

p, role:dev-loja, applications, get, loja/*, allow
p, role:dev-loja, applications, sync, loja/*, allow
g, grupo-loja-devs, role:dev-loja

As linhas p definem permissões (papel, recurso, ação, objeto) e as linhas g ligam grupos do provedor de identidade a papéis. O objeto loja/* restringe o acesso às aplicações do projeto loja.

Segredos

O Argo CD não resolve o problema de guardar segredos no Git, ele só aplica o que está lá. Como Secret do Kubernetes é apenas Base64, as abordagens mais comuns são:

Abordagem	Como funciona	Observação
Sealed Secrets	O segredo é cifrado com a chave pública de um controlador e só o cluster consegue abrir	Cifrado no próprio Git
External Secrets Operator	O Git guarda só a referência; o operador busca o valor no AWS Secrets Manager, Vault etc.	Nenhum valor no Git
SOPS com plugin	Arquivos cifrados com KMS ou age, decifrados na hora de gerar manifestos	Exige configurar o repo server

Outros cuidados

Use AppProject para restringir repositórios, destinos e tipos de recurso por time.
Desative o usuário admin local depois de configurar o SSO.
Use um repositório de leitura (deploy key ou token só de leitura) para o Argo CD.
Habilite TLS no argocd-server e limite o acesso à API por rede, já que ele tem poder sobre todos os clusters conectados.

Escala, alta disponibilidade e observabilidade

O Argo CD é em grande parte stateless: o estado vive em objetos do Kubernetes, e o que pesa quando a escala cresce é o Application Controller, que mantém em memória o estado dos clusters que gerencia (documentação de alta disponibilidade).

[embedded content: sharding de clusters no Application Controller · exemplo ilustrativo]

Onde ajustar cada componente

Application Controller: quando ele gerencia muitos clusters e consome muita memória, o caminho é distribuir os clusters entre réplicas. Aumente replicas no StatefulSet e repita o número na variável ARGOCD_CONTROLLER_REPLICAS. Cada réplica usa duas filas, uma para reconciliação (milissegundos) e outra para sincronização (segundos), e o número de processors pode ser aumentado para muitas aplicações.
Repo Server: guarda em cache os manifestos gerados, por padrão por 24 horas, usando o SHA do commit como chave. Ele mantém um clone local por repositório, o que pode ficar lento em monorepos com muitas aplicações; a anotação argocd.argoproj.io/manifest-generate-paths ajuda a evitar regenerar manifestos à toa.
API Server e Redis: o projeto oferece manifests de alta disponibilidade, com réplicas do servidor e uma variante de Redis em HA.

Em uso real, a pesquisa de 2025 com usuários do Argo CD, conduzida pela CNCF e pelos mantenedores, reportou que 97% usam em produção e 42% gerenciam mais de 500 aplicações por instância, e que quase 60% dos clusters dos respondentes usam Argo CD.

Observabilidade

Cada componente expõe métricas no formato Prometheus. Três delas cobrem a maior parte dos painéis e alertas:

Métrica	O que mostra	Uso típico
`argocd_app_info`	Status de sync e de saúde de cada aplicação	Alerta para aplicações `OutOfSync` ou `Degraded` por muito tempo
`argocd_app_sync_total`	Quantidade de sincronizações e seus resultados	Taxa de falha de deploy
`argocd_app_reconcile`	Duração da reconciliação das aplicações	Mapa de calor para detectar controller sobrecarregado

Além das métricas, o Argo CD Notifications envia o evento a Slack, e-mail ou webhook no momento em que a saúde muda ou a sincronização falha.

Argo CD, Flux e pipeline push: como se comparam

Argo CD e Flux são projetos graduados da CNCF que seguem o mesmo modelo pull. A escolha costuma depender do que a equipe valoriza: uma plataforma integrada com interface web (Argo CD) ou um conjunto modular de controllers guiado por linha de comando (Flux), como resume a matéria do The New Stack.

[embedded content: The New Stack, jun/2025 · Octopus Deploy (State of GitOps) e pesquisa da CNCF]

O desnível aparece nas duas pesquisas, mas o valor exato depende de quem foi perguntado e de como a pergunta foi feita.

Aspecto	Argo CD	Flux	Pipeline push (CI)
Modelo de entrega	Pull, por um controlador no cluster	Pull, por controllers no cluster	Push, o CI aplica no cluster
Interface web	Embutida	Sem UI embutida	Depende do CI
Arquitetura	Plataforma integrada; instância central ou uma por cluster	Conjunto de controllers independentes	Job efêmero a cada pipeline
Multi-cluster	Clusters registrados e `ApplicationSet`	Repositório organizado e um Flux em cada cluster	Credencial de cada cluster guardada no CI
Segredos	Via ferramentas externas	Suporte nativo a SOPS	Segredos do próprio CI
Detecção de drift	Contínua	Contínua	Só no próximo deploy

Um pipeline push costuma bastar para projetos pequenos, com um ou dois ambientes. O GitOps começa a compensar quando surgem vários clusters, vários times e a necessidade de auditoria e de detectar drift.

Exemplo prático: do zero à primeira aplicação

O roteiro abaixo leva cerca de dez minutos em um cluster de testes (kind, minikube ou um cluster gerenciado).

1. Instalar o Argo CD

kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Em produção, prefira o chart Helm oficial (argo/argo-cd) com os valores versionados no Git, e fixe a versão em vez de usar stable.

2. Acessar a interface e a CLI

# senha inicial do usuário admin
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

# encaminhar a porta do servidor
kubectl port-forward svc/argocd-server -n argocd 8080:443

# login pela CLI
argocd login localhost:8080 --username admin --insecure

3. Organizar o repositório

Uma estrutura simples e muito usada separa a base dos ambientes com Kustomize:

loja-gitops/
├── apps/
│   └── api/
│       ├── base/
│       │   ├── deployment.yaml
│       │   ├── service.yaml
│       │   └── kustomization.yaml
│       └── overlays/
│           ├── homologacao/
│           │   └── kustomization.yaml
│           └── producao/
│               └── kustomization.yaml
└── argocd/
    └── applications/
        └── loja-api-producao.yaml

4. Criar a aplicação

argocd app create loja-api \
  --repo https://github.com/minha-org/loja-gitops.git \
  --path apps/api/overlays/producao \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace loja \
  --sync-policy automated --auto-prune --self-heal

O mesmo resultado sai de aplicar o YAML da Application mostrado antes, que é a forma recomendada porque fica versionada.

5. Ver a reconciliação funcionando

Altere replicas no deployment.yaml, faça commit e push. Em poucos minutos (ou na hora, se houver webhook), a aplicação passa a OutOfSync e logo volta a Synced.
Rode kubectl scale deployment api -n loja --replicas=1 na mão. Com selfHeal ativo, o Argo CD desfaz a mudança e volta ao valor do Git.
Apague o service.yaml do repositório. Com prune ativo, o Service é removido do cluster.
Use argocd app history loja-api e argocd app rollback loja-api <id> para voltar a uma revisão anterior. Em modo automático, o rollback pela CLI exige desativar a sincronização automática antes; o caminho mais limpo é um git revert.

Boas práticas e armadilhas comuns

A maior parte dos problemas com Argo CD vem de decisões de organização, não da ferramenta em si.

O que fazer

Separe o repositório de código do repositório de configuração. Um commit de código não deve disparar uma mudança de manifesto sem passar por um passo explícito (por exemplo, o CI atualiza a tag da imagem no repositório GitOps por pull request).
Use o padrão app of apps ou ApplicationSet para que a própria lista de aplicações esteja no Git, e não cadastrada à mão.
Uma pasta por ambiente, com Kustomize overlays ou arquivos de valores do Helm, em vez de branches por ambiente. Branches divergem e a promoção vira merge doloroso.
Fixe versões: tags de imagem imutáveis (nunca latest), versões de chart e targetRevision por tag ou SHA em produção.
Automatize com cuidado: automated em homologação quase sempre vale a pena; em produção, muitos times preferem sincronização automática com prune e selfHeal, mas com janelas de sincronização (sync windows) e revisão obrigatória de pull request.
Ative notificações (Argo CD Notifications) para Slack, e-mail ou webhook nos eventos de falha de sincronização e degradação de saúde.

Armadilhas

Armadilha	O que acontece	Como evitar
HPA e `replicas` fixo no Git	O Argo CD e o autoscaler brigam pelo número de réplicas	Remover `replicas` do manifesto ou usar `ignoreDifferences`
Campos gerados por controladores	Aplicação fica `OutOfSync` para sempre por causa de campos que o cluster preenche	`ignoreDifferences` ou `RespectIgnoreDifferences=true`
CRDs grandes	Falha de `apply` por limite da anotação `last-applied`	`ServerSideApply=true`
Segredos em texto no Git	Vazamento de credenciais	Sealed Secrets, External Secrets ou SOPS
Um único repositório gigante	Renderização lenta e cache do repo server sempre invalidado	Dividir por domínio e usar anotação `manifest-generate-paths`
`prune` sem entender o escopo	Recursos apagados por engano	Testar primeiro com `argocd app sync --dry-run` e usar `Prune=false` em recursos críticos

Conclusão e próximos passos

O Argo CD é um laço de controle: ele lê o estado desejado no Git, observa o estado real no cluster e fecha a diferença, com visibilidade, política e auditoria em volta disso. O ganho prático vem de três hábitos: tudo no Git, nada aplicado à mão e sincronização automática onde o risco permite.

Para colocar em prática:

Suba o Argo CD em um cluster de testes e siga o exemplo prático deste artigo.
Crie um AppProject por time antes de liberar acesso, e configure SSO e RBAC no primeiro dia.
Decida como os segredos serão tratados (Sealed Secrets, External Secrets ou SOPS) antes de migrar a primeira aplicação real.
Use ApplicationSet para que a lista de aplicações também seja versionada.
Ative métricas e notificações, e só depois habilite selfHeal e prune em produção.

Instâncias AWS Graviton Arquitetura ARM na Nuvem

Kauê Matos — Sun, 13 Sep 2026 17:04:17 +0000

O AWS Graviton é uma família de processadores desenvolvidos pela própria AWS, baseados em arquitetura ARM (64-bit, Arm Neoverse), em vez da arquitetura x86 tradicional (Intel/AMD). Lançado inicialmente em 2018, o Graviton se tornou uma das principais estratégias da AWS para oferecer melhor custo-benefício e eficiência energética em instâncias EC2.

Hoje, praticamente todas as famílias de instância "de uso geral" da AWS (M, C, R, T e derivadas) possuem uma variante Graviton, identificada pelo sufixo g no nome (ex.: m7g, c7g, r7g, t4g).

Este artigo explica o que é o Graviton, como evoluiu ao longo das gerações, quando vale a pena adotar e quais são os principais cuidados de migração.

O que é o Graviton

Graviton é um System on Chip (SoC) projetado pela AWS Annapurna Labs (empresa israelense adquirida pela AWS em 2015), otimizado especificamente para rodar dentro da infraestrutura da própria AWS. Diferente de depender de fornecedores externos (Intel, AMD), a AWS controla o design do chip ponta a ponta — o que permite ajustar a arquitetura ao perfil real de uso dos seus data centers.

Principais vantagens declaradas pela AWS:

Melhor custo-benefício — em geral, 20% a 40% mais barato que instâncias x86 equivalentes.
Melhor performance por watt — até ~60% mais eficiente energeticamente, o que também contribui para metas de sustentabilidade (ESG) das empresas.
Performance competitiva ou superior em cargas de trabalho compatíveis, especialmente as que escalam horizontalmente.

Evolução das gerações

Graviton1 (2018)

Primeira geração, lançada com as instâncias a1. Voltada principalmente para cargas escaláveis horizontalmente e workloads que não exigiam alta performance de CPU por núcleo. Adoção limitada, mas serviu como prova de conceito.

Graviton2 (2019/2020)

Salto significativo de performance — baseado em núcleos Arm Neoverse N1. Introduziu as variantes g em famílias já conhecidas: m6g, c6g, r6g, t4g. Trouxe suporte a mais casos de uso de produção, com performance comparável a instâncias x86 de geração equivalente.

Graviton3 (2021/2022)

Presente em m7g, c7g, r7g, além de instâncias especializadas como c7gn (rede otimizada) e hpc7g (HPC). Trouxe ganhos relevantes em:

Performance de ponto flutuante (importante para HPC e ML)
Criptografia acelerada por hardware
Maior largura de banda de memória (DDR5)

Graviton4 (2023/2024)

Geração mais recente, presente em instâncias como r8g e m8g. Foco em maior número de núcleos, maior largura de banda de memória e melhorias de segurança, mantendo compatibilidade com o ecossistema ARM já validado nas gerações anteriores.

Famílias disponíveis com Graviton

Família x86 equivalente	Variante Graviton	Foco
M (uso geral)	m6g, m7g, m8g	Aplicações web, microsserviços
C (compute optimized)	c6g, c7g, c7gn	CPU intensiva, rede otimizada
R (memory optimized)	r6g, r7g, r8g	Bancos de dados, cache
T (burstable)	t4g	Cargas variáveis, dev/test
X (memória alta)	x2gd	In-memory databases
I (storage optimized)	i4g	NoSQL, alta taxa de I/O
Hpc	hpc7g	HPC fortemente acoplado

Quando vale a pena migrar para Graviton

Bons candidatos:

Aplicações stateless rodando em containers (Docker/Kubernetes) com imagens multi-arquitetura.
Linguagens/runtimes com suporte nativo e maduro a ARM: Java (JVM), Go, Python, Node.js, .NET.
Cargas de trabalho gerenciadas pela própria AWS que já oferecem variante Graviton nativamente: Amazon RDS, ElastiCache, OpenSearch, EMR.
Workloads horizontalmente escaláveis, onde trocar a arquitetura de um conjunto de instâncias idênticas é simples de validar.

Pontos de atenção antes de migrar:

Dependências binárias nativas (bibliotecas compiladas, extensões C/C++) precisam ter build para ARM64 disponível.
Imagens de container precisam ser multi-arquitetura (docker buildx com suporte a linux/arm64) ou reconstruídas especificamente para ARM.
Softwares proprietários de terceiros (agentes de monitoramento, APM, drivers específicos) precisam ter suporte oficial a ARM confirmado pelo fornecedor.
Testes de performance e carga são recomendados antes de migrar workloads críticas de produção, mesmo com boa compatibilidade declarada.

Estratégia de migração recomendada

Inventariar as aplicações e suas dependências, verificando compatibilidade com ARM64 (bibliotecas, imagens base de container, agentes de terceiros).
Começar pelo menos crítico — ambientes de desenvolvimento/homologação ou workloads stateless de baixo risco.
Rodar testes de carga comparativos entre a instância x86 atual e a equivalente Graviton, validando performance e custo real.
Migrar gradualmente ambientes de produção, aproveitando Auto Scaling Groups com múltiplos tipos de instância (mixed instance policy) durante a transição.
Consolidar o ganho de custo validado nas etapas anteriores em Savings Plans ou Reserved Instances específicas para a família Graviton escolhida.

Conclusão

O Graviton deixou de ser uma opção experimental e se tornou, hoje, a recomendação padrão da AWS para novas cargas de trabalho — quando a stack permite. A combinação de menor custo, menor consumo energético e performance competitiva faz da migração para ARM uma das otimizações de maior impacto disponíveis em uma conta AWS, especialmente quando combinada com outras estratégias de FinOps como Savings Plans e Spot Instances.

Antes de migrar qualquer workload crítica, o caminho mais seguro é sempre: validar compatibilidade, testar performance real e migrar de forma incremental — começando pelos ambientes de menor risco.

The Twelve-Factor App: o guia que todo sistema deveria seguir (mas poucos seguem)

Kauê Matos — Sat, 12 Sep 2026 22:29:40 +0000

Se você já trabalhou num sistema que funcionava perfeitamente no seu computador mas quebrava assim que ia pra produção, ou já se irritou com uma atualização que exigiu reconstruir tudo só porque mudou a senha do banco de dados, você já sentiu na pele o problema que o Twelve-Factor App tenta resolver.

Essa ideia surgiu por volta de 2010, dentro da empresa Heroku, com Adam Wiggins à frente. Na época, a empresa já hospedava centenas de milhares de sistemas de clientes diferentes na mesma plataforma, o que deu a eles uma visão privilegiada de tudo que costuma dar errado quando um time constrói software sem pensar em portabilidade, crescimento e manutenção. O resultado foi uma lista de doze práticas — nenhuma delas revolucionária sozinha, mas que juntas formam uma base sólida pra qualquer sistema que roda como serviço na internet.

O interessante é que, mesmo com toda a evolução das ferramentas desde então, essas doze práticas continuam extremamente válidas. Vamos passar por cada uma.

1. Um único código-fonte, várias versões em uso

Cada sistema deve viver em um único repositório de código com histórico de versões (como o Git), e a partir dele você gera quantas cópias precisar: uma pra testes, outra pra homologação, outra pra produção. Se você tem vários repositórios diferentes pra uma coisa que deveria ser "um sistema só", provavelmente não é mais um sistema — é vários sistemas conectados, e cada um deveria seguir essa regra separadamente.

2. Deixe claro do que o sistema depende

Nada de assumir que uma determinada ferramenta ou biblioteca já está instalada no computador ou servidor só porque "sempre esteve". Liste tudo isso de forma explícita, em um arquivo próprio do projeto, e mantenha isso separado do que já vem instalado no sistema operacional. É isso que garante que o sistema funcione do mesmo jeito em qualquer máquina, seja no notebook de quem está desenvolvendo, seja no servidor de produção.

3. Mantenha as configurações fora do código

Senhas de banco de dados, chaves de acesso a serviços externos, endereços de outros sistemas — nada disso deveria estar escrito dentro do código-fonte. Isso deve ficar guardado separadamente, em variáveis de ambiente do próprio servidor. Além de ser mais seguro (menos risco de vazar uma senha sem querer), isso permite trocar de ambiente sem precisar reconstruir o sistema do zero.

4. Trate serviços externos como peças substituíveis

Banco de dados, fila de mensagens, sistema de cache, serviço de envio de e-mail — tudo isso deveria ser tratado como uma peça que se conecta por meio de um endereço e uma credencial, sem diferença entre se está rodando no próprio computador ou em outro lugar. Trocar um banco de dados local por um banco hospedado por um provedor de nuvem não deveria exigir mudar uma linha do código, só a configuração.

5. Separe bem as etapas de construir, preparar e executar

Essas três etapas precisam ser bem distintas:

construir: transforma o código escrito em algo pronto pra rodar;
preparar: junta esse resultado com a configuração daquele ambiente específico;
executar: efetivamente coloca isso em funcionamento.

Cada versão preparada deveria ter uma identificação única, pra que, se algo der errado, seja possível voltar rapidamente pra versão anterior.

6. Não guarde informação importante dentro do próprio sistema em execução

O sistema deveria funcionar sem depender de guardar informações importantes na própria memória entre um pedido e outro. Qualquer coisa que precise ser lembrada deve ficar armazenada em um lugar próprio pra isso, como um banco de dados. Isso parece óbvio, mas é justamente o que permite aumentar a capacidade do sistema adicionando mais cópias dele rodando ao mesmo tempo, sem risco de perder informação ou gerar comportamento estranho.

7. O sistema deve se apresentar sozinho, sem depender de outro programa

O sistema deveria ser completo por si só e ficar disponível através de uma porta de comunicação própria, sem precisar que outro programa seja instalado por fora pra fazer essa ponte. A maioria das ferramentas modernas de desenvolvimento já vem com isso embutido — é só configurar em qual porta o sistema vai atender.

8. Aumente a capacidade dividindo o trabalho em partes

Divida o sistema em partes diferentes conforme o tipo de tarefa — uma parte pra atender pedidos que chegam pela internet, outra pra processar tarefas em segundo plano, outra pra rodar tarefas programadas — e aumente cada parte de forma independente conforme a necessidade. Assim, se o gargalo está no processamento em segundo plano, você aumenta só aquela parte, sem precisar mexer no resto.

9. Deixe o sistema pronto pra ligar e desligar rápido

Um sistema bem construído é aquele que consegue começar a funcionar rapidamente e também parar de forma organizada, terminando o que estava fazendo antes de desligar de vez. Isso é fundamental pra atualizações ágeis, pra aumentar ou diminuir a capacidade automaticamente conforme a demanda, e pra se recuperar rápido quando algo dá errado.

10. Mantenha o ambiente de testes parecido com o de produção

Esse é um dos pontos mais esquecidos na prática. A ideia é diminuir ao máximo a diferença entre o ambiente onde o sistema é desenvolvido e testado e aquele onde ele realmente atende os usuários — usar a mesma versão de banco de dados, atualizar com frequência, e ter as mesmas pessoas cuidando das duas pontas. É basicamente a receita pra nunca mais ouvir a frase "mas funcionava aqui". Ferramentas que automatizam a criação de ambientes ajudam bastante a diminuir essa distância.

11. Registros de atividade não devem ser um arquivo pra gerenciar

O sistema não deveria se preocupar em decidir onde guardar seus próprios registros de atividade (o famoso "log"). Ele apenas deveria escrevê-los de forma simples, e outra ferramenta, especializada nisso, deveria cuidar de coletar, organizar e guardar essas informações. Isso simplifica bastante o trabalho de quem constrói o sistema.

12. Tarefas administrativas rodam do mesmo jeito que o resto

Corrigir dados no banco, rodar um ajuste pontual, abrir uma sessão pra investigar um problema em produção — tudo isso deveria ser feito usando o mesmo ambiente, o mesmo código e a mesma configuração do sistema normal. Nada de manter um script separado, guardado em outro lugar, que só uma pessoa lembra de atualizar de vez em quando.

Usar contêineres não resolve isso sozinho

Vale desfazer um mal-entendido comum: muita gente pensa que, ao usar ferramentas modernas de empacotamento e orquestração de sistemas, essas doze práticas "vêm de graça" junto com elas. Não vêm. Essas ferramentas ajudam bastante em algumas partes — como isolar dependências e permitir que o sistema ligue e desligue rápido —, mas manter a configuração separada do código, evitar guardar informação importante dentro do sistema em execução e organizar bem as versões continua sendo trabalho de quem projeta o sistema, não da ferramenta.

No fim das contas

Essas doze práticas não são regras burocráticas de manual. São o tipo de coisa que a maioria das pessoas aprende depois de passar por um problema chato em produção, e que, depois de adotada, ninguém mais quer abrir mão. Seguir esses princípios é o que diferencia um sistema fácil de manter e fazer crescer de um que só continua funcionando porque alguém está sempre correndo atrás de apagar incêndio.

Baseado em 12factor.net

AWS Well-Architected Framework

Kauê Matos — Sat, 05 Sep 2026 18:12:41 +0000

Construir na nuvem é fácil. Construir bem na nuvem é outra história. É justamente para preencher essa lacuna que a AWS criou o Well-Architected Framework (WAF): um conjunto estruturado de princípios de design, boas práticas e perguntas orientadoras que ajudam arquitetos e engenheiros a avaliar workloads sob a ótica de seis pilares — Excelência Operacional, Segurança, Confiabilidade, Eficiência de Performance, Otimização de Custos e Sustentabilidade.

O framework não é uma checklist genérica de "boas práticas de nuvem". Ele é, na prática, uma metodologia de trade-offs conscientes: toda decisão arquitetural — usar um banco relacional ou NoSQL, multi-AZ ou multi-região, autoscaling agressivo ou conservador — implica abrir mão de algo em troca de outra coisa. O WAF força você a nomear esses trade-offs em vez de descobri-los tarde demais, em produção, sob incidente.

Um pouco de história

O framework nasceu em 2012 como um documento interno de arquitetos de soluções da AWS e virou whitepaper público em 2015. Em 2016 ganhou o pilar de Excelência Operacional; em 2017 chegaram os Lenses (recortes especializados por domínio) e, em 2018, a ferramenta gratuita AWS Well-Architected Tool, disponível direto no Console. O sexto pilar, Sustentabilidade, foi incorporado no fim de 2021, refletindo a pressão crescente por eficiência energética e redução de pegada de carbono em cargas de trabalho de nuvem.

De lá para cá, a AWS vem tornando o conteúdo cada vez mais prescritivo: cada boas práticas hoje tem página dedicada, com antipadrões comuns, nível de risco, passos de implementação e recursos relacionados — uma resposta direta ao feedback de que o framework antigo dizia "o que" fazer, mas pouco sobre "como".

Os princípios gerais de design

Antes de entrar pilar por pilar, vale destacar os princípios transversais que sustentam o framework:

Pare de adivinhar sua capacidade — use autoscaling e elasticidade em vez de dimensionar para o pico teórico.
Teste sistemas em produção (com segurança) — ambientes controlados de teste em escala real, não só em staging.
Automatize experimentações arquiteturais — infraestrutura como código torna barato testar variações de arquitetura.
Permita evolução arquitetural — desenhe para mudar, não para ser definitivo.
Direcione arquiteturas com dados — decisões baseadas em métricas reais de uso, não em intuição.
Melhore através de "game days" — simule falhas e eventos reais para validar respostas antes que aconteçam de verdade.

Os seis pilares

1. Excelência Operacional

Trata da capacidade de operar e monitorar sistemas para entregar valor de negócio, e de melhorar processos e procedimentos continuamente. Na prática, envolve:

Infraestrutura como código (Terraform, CloudFormation, CDK) para operações reproduzíveis e auditáveis.
Observabilidade real: métricas, logs e traces centralizados (CloudWatch, X-Ray) com alarmes acionáveis, não apenas dashboards bonitos.
Runbooks e playbooks versionados para resposta a incidentes.
Deploys pequenos, frequentes e reversíveis (blue/green, canary), reduzindo o "blast radius" de cada mudança.
Retrospectivas pós-incidente sem culpabilização, com ações de melhoria rastreadas.

2. Segurança

O pilar de Segurança foca em proteger informação, sistemas e ativos, mantendo o valor do negócio através de avaliação de risco e estratégias de mitigação. Pontos centrais:

Identidade forte como novo perímetro: IAM com privilégio mínimo, roles em vez de credenciais estáticas, MFA obrigatório para operações sensíveis.
Defesa em profundidade: VPCs segmentadas, security groups e NACLs, WAF e Shield contra ataques na borda.
Criptografia em repouso e em trânsito por padrão, com KMS gerenciando chaves e rotação.
Visibilidade contínua: GuardDuty para detecção de ameaças, Security Hub para consolidar postura de segurança, Config para compliance contínuo de configuração.
Automação de resposta a incidentes, para reduzir o tempo entre detecção e contenção.

A atualização mais recente do framework incorporou também uma área dedicada de AppSec (segurança de aplicação), reforçando que testes de segurança devem fazer parte do ciclo de desenvolvimento — SAST, DAST e dependency scanning como etapas normais de CI/CD, não como auditoria pontual.

3. Confiabilidade

Aqui o foco é a capacidade de um workload realizar sua função corretamente e de forma consistente, incluindo a habilidade de operar e testar o sistema durante todo o seu ciclo de vida. Boas práticas típicas:

Arquiteturas multi-AZ como padrão mínimo; multi-região para workloads críticos.
Recuperação automática de falhas (self-healing) via health checks e auto-replacement de instâncias.
Gestão de capacidade com margem de segurança e testes de carga regulares.
Estratégias de disaster recovery bem definidas (backup and restore, pilot light, warm standby, multi-site ativo-ativo), apoiadas por serviços como Elastic Disaster Recovery e Resilience Hub para medir e validar objetivos de RTO/RPO.
Circuit breakers e retries com backoff exponencial para conter falhas em cascata entre serviços distribuídos.

4. Eficiência de Performance

Trata do uso eficiente de recursos computacionais para atender requisitos e manter essa eficiência conforme a demanda muda e as tecnologias evoluem:

Escolha deliberada de tipo de computação (EC2, containers em ECS/EKS, serverless com Lambda) conforme o padrão de carga do workload.
Uso de cache em múltiplas camadas (CloudFront, ElastiCache) para reduzir latência e carga em backends.
Bancos de dados adequados ao padrão de acesso — relacional para transações complexas, NoSQL para escala horizontal e baixa latência, data warehouse para analytics.
Revisão periódica de novas famílias de instância e serviços gerenciados, já que "o melhor recurso hoje pode não ser o melhor em seis meses".
Testes de carga e benchmarking como parte do pipeline, não como evento isolado antes de um lançamento.

5. Otimização de Custos

Foca em evitar gastos desnecessários e obter o melhor retorno pelo dinheiro investido em nuvem:

Modelos de compra corretos: On-Demand para picos imprevisíveis, Savings Plans/Reserved Instances para baseline previsível, Spot para workloads tolerantes a interrupção.
Rightsizing constante com apoio do Compute Optimizer e Trusted Advisor, eliminando recursos superdimensionados ou ociosos.
Tagging consistente de recursos para permitir chargeback/showback real por time, produto ou ambiente.
Orçamentos e alertas proativos via AWS Budgets, evitando surpresas na fatura.
Cultura de FinOps: custo como métrica de engenharia, revisada com a mesma seriedade que performance e disponibilidade.

6. Sustentabilidade

O pilar mais recente do framework, focado em minimizar o impacto ambiental de workloads em nuvem:

Priorizar regiões com matriz energética mais limpa quando a latência permitir.
Maximizar utilização de recursos provisionados, evitando superprovisionamento "por segurança".
Preferir serviços gerenciados e serverless, que se beneficiam de ganhos de eficiência agregados da AWS em escala.
Adotar políticas de ciclo de vida de dados (arquivamento e exclusão automática) para reduzir armazenamento desnecessário.
Escolher arquiteturas e algoritmos eficientes, já que menos processamento também significa menos consumo energético.

A ferramenta e o processo de revisão

O AWS Well-Architected Tool, gratuito no Console, permite conduzir uma revisão estruturada de um workload: você responde a um conjunto de perguntas por pilar, e a ferramenta identifica riscos (baixo, médio ou alto) e sugere ações de remediação com base nas boas práticas atualizadas.

Na prática, uma revisão Well-Architected segue um fluxo simples:

Definir o workload e seu contexto de negócio (criticidade, SLAs, requisitos regulatórios).
Responder às perguntas de cada pilar com a equipe técnica responsável, documentando decisões e justificativas.
Identificar riscos altos (HRIs) — os itens que mais ameaçam o sucesso do workload.
Priorizar e planejar remediação, tratando os HRIs como itens de backlog com dono e prazo.
Repetir periodicamente, já que arquiteturas e boas práticas evoluem — uma revisão não é um evento único, é um hábito.

Lenses: recortes especializados

Além do framework geral, a AWS mantém Lenses — extensões que aplicam os seis pilares a domínios específicos. Existem lenses para arquiteturas serverless, machine learning, SaaS, IoT, containers, entre outros. A adição mais notável recentemente foi o Generative AI Lens, lançado em 2025, que aplica os seis pilares ao ciclo de vida completo de workloads de IA generativa — do escopo de impacto e seleção de modelo até customização, integração, deployment e iteração contínua, com atenção especial a temas como veracidade, explicabilidade e uso responsável de LLMs.

Como aplicar isso na prática, sem virar teatro corporativo

O maior risco de qualquer framework é ele virar um exercício de preenchimento de formulário. Algumas recomendações práticas para evitar isso:

Comece pequeno: revise um workload real e crítico antes de tentar aplicar o framework em toda a organização de uma vez.
Trate os pilares como lentes de discussão, não como categorias isoladas — a maioria das decisões arquiteturais toca vários pilares ao mesmo tempo.
Automatize o que for possível (Config Rules, Security Hub, Trusted Advisor) para que parte da revisão aconteça continuamente, não só numa reunião trimestral.
Conecte os riscos identificados a itens reais de backlog, com dono e prazo — um relatório de revisão que não vira ação é apenas um documento a mais.

Conclusão

O AWS Well-Architected Framework não é sobre seguir regras cegamente, é sobre tornar explícitos os trade-offs que toda arquitetura de nuvem já carrega implicitamente. Usado com disciplina — revisões periódicas, HRIs viram backlog, métricas acompanhadas ao longo do tempo — ele funciona como um mecanismo de melhoria contínua genuíno. Usado como checklist de auditoria pontual, vira só mais um documento arquivado. A diferença entre as duas coisas não está no framework, está no processo que você constrói ao redor dele.

Por que a Prime Video trocou microsserviços serverless por um monólito

Kauê Matos — Sat, 05 Sep 2026 17:48:34 +0000

Em março de 2023, a equipe de engenharia da Amazon Prime Video publicou um post técnico que causou bastante repercussão na comunidade de cloud: eles haviam redesenhado um de seus serviços internos, saindo de uma arquitetura distribuída baseada em serverless para uma aplicação monolítica rodando em containers — e reduziram o custo operacional em 90%.

O caso ficou conhecido de forma simplificada como "Prime Video abandona microsserviços", mas essa leitura esconde um detalhe importante: o problema não estava no conceito de microsserviços em si, e sim em como serverless (Step Functions e Lambda) havia sido usado para orquestrar um fluxo de altíssima frequência de eventos. Vale entender o caso com mais profundidade, porque as lições dele valem para qualquer arquiteto de cloud que precisa decidir entre desacoplar componentes ou simplificar a orquestração.

O serviço em questão: monitoramento de qualidade de áudio/vídeo

O time responsável era o de Video Quality Analysis (VQA), que mantém uma ferramenta capaz de detectar problemas de qualidade em streams de vídeo em tempo real — coisas como corrupção de blocos de imagem, congelamento de vídeo e dessincronização entre áudio e vídeo. Essa ferramenta já existia, mas não havia sido projetada para operar na escala de milhares de streams simultâneos, que é o volume real de tráfego da Prime Video.

A arquitetura original

A primeira versão do serviço foi construída como um sistema distribuído usando componentes serverless, o que fazia todo sentido do ponto de vista de velocidade de entrega. Em linhas gerais, o desenho contava com:

Media Converter: um componente responsável por quebrar os streams de áudio/vídeo em frames de imagem e buffers de áudio decodificados.
Defect Detectors: microsserviços que analisavam esses frames e buffers usando algoritmos de machine learning para identificar defeitos, executados via AWS Lambda.
Orquestração via AWS Step Functions: controlando as transições de estado entre as etapas do pipeline de análise.
Amazon S3: usado como armazenamento intermediário, guardando os frames de imagem entre uma etapa e outra do pipeline.
Amazon SNS: usado para notificar os resultados da análise.

Esse desenho tinha uma vantagem clara: escalabilidade horizontal teórica, já que cada componente poderia escalar de forma independente, e uma implementação rápida, aproveitando serviços gerenciados da AWS.

Onde a conta não fechou

O problema apareceu quando o serviço começou a operar em escala real. Dois gargalos concentraram praticamente todo o impacto negativo:

1. Step Functions como orquestrador de alta frequência. O fluxo realizava múltiplas transições de estado a cada segundo de stream analisado. Como o Step Functions cobra por transição de estado, e como existem limites de conta para volume de transições, o serviço atingiu limites de escala em torno de apenas 5% da carga esperada — bem abaixo do necessário para operar com todos os streams da plataforma.

2. Custo de chamadas de camada 1 ao S3. Passar frames de vídeo entre componentes usando S3 como intermediário gerava um volume enorme de chamadas de escrita e leitura (chamadas "tier-1", que são as mais caras no modelo de precificação do S3), o que tornava o custo de operação proibitivo em escala.

Em resumo: o desenho não estava "errado" em teoria, mas o padrão de uso — altíssima frequência de eventos pequenos, orquestrados por um serviço que cobra por evento, trocando dados por um armazenamento intermediário que cobra por chamada — é exatamente o cenário em que orquestração serverless tende a sair cara.

A nova arquitetura

A solução da equipe foi consolidar as etapas do pipeline (conversão de mídia e detecção de defeitos) em um único processo, eliminando a orquestração via Step Functions e a troca de dados via S3. Os frames passaram a ser transferidos em memória, dentro do mesmo processo, e não mais por chamadas de rede a um serviço de armazenamento.

Essa aplicação consolidada passou a rodar sobre EC2 e ECS, com uma camada leve de orquestração para distribuir as requisições dos clientes entre instâncias. Para lidar com o problema de escala vertical de um único processo, a equipe replicou o serviço em múltiplas tarefas ECS, cada uma com um subconjunto de detectores — ou seja, ainda existe distribuição de carga, só que em um nível de granularidade bem mais grosso do que antes.

O resultado

A mudança de arquitetura reduziu o custo operacional do serviço em 90% e resolveu o gargalo de escala, permitindo cobrir a totalidade dos streams monitorados. A lógica de negócio (os algoritmos de detecção de defeitos) permaneceu praticamente a mesma — o que mudou foi a camada de orquestração e transporte de dados entre etapas.

Uma ressalva importante: monólito ou só "menos serverless"?

O post original gerou um debate acalorado na comunidade técnica, incluindo críticas de arquitetos conhecidos do setor. O ponto central da discussão é que, tecnicamente, o novo desenho não é um monólito no sentido tradicional do termo: a Prime Video como um todo continua operando como um conjunto de serviços independentes (cobrança, catálogo, streaming, etc.), e mesmo o novo serviço de VQA ainda é replicado em múltiplas instâncias ECS.

O que de fato mudou foi a granularidade da orquestração: em vez de fragmentar cada etapa do processamento em funções Lambda separadas e coordená-las por um serviço de estado que cobra por transição, a equipe passou a executar todas as etapas de um mesmo stream dentro de um único processo. É mais preciso descrever isso como uma migração de serverless orientado a eventos para compute tradicional em containers, do que como "microsserviços versus monólito" — ainda que essa segunda formulação tenha sido a usada no post original e seja a que pegou popularmente.

Lições para quem projeta arquiteturas em cloud

Alguns pontos ficam claros ao analisar o caso:

O modelo de cobrança do serviço gerenciado importa tanto quanto sua elasticidade. Step Functions e Lambda são excelentes para orquestrar fluxos de baixa a média frequência ou eventos assíncronos, mas cobrar por transição de estado ou por invocação se torna um problema quando a frequência de eventos é da ordem de múltiplas vezes por segundo, por stream, multiplicado por milhares de streams simultâneos.
Armazenamento intermediário tem custo de chamada, não só de armazenamento. Usar S3 como "fila" ou buffer entre etapas de um pipeline parece simples, mas o custo por operação pode superar rapidamente o custo do armazenamento em si, especialmente em payloads pequenos e frequentes.
Desacoplamento tem um custo de rede e serialização que nem sempre se paga. Quando as etapas de um pipeline sempre são executadas juntas, para o mesmo item de trabalho, colocá-las no mesmo processo elimina overhead de rede sem necessariamente sacrificar a capacidade de escalar — desde que a unidade de escala (nesse caso, a instância ECS) seja bem dimensionada.
A escolha de arquitetura depende do padrão de acesso, não de uma regra geral. O próprio caso não é uma prova de que "monólitos são melhores que microsserviços" — é uma prova de que a granularidade da orquestração precisa ser compatível com a frequência e o volume dos eventos que ela processa.

Conclusão

O caso da Prime Video se tornou um símbolo do debate entre microsserviços e monólitos, mas seu valor real está em outro lugar: ele mostra como escolhas de orquestração e transporte de dados, tomadas cedo no design de um sistema, podem determinar se uma arquitetura escala de forma sustentável ou colide com limites de conta e custos inesperados assim que sai do piloto para a produção em escala real. Antes de escolher entre serverless, containers ou uma combinação dos dois, vale simular o padrão real de tráfego esperado e o modelo de cobrança de cada serviço envolvido — não só a elegância teórica do desenho distribuído.

Fontes

Prime Video Tech Blog — Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
InfoQ — Prime Video Switched from Serverless to EC2 and ECS to Save Costs
The New Stack — Amazon Prime Video's Microservices Move Doesn't Lead to a Monolith after All

Kiro: a IDE agêntica da AWS — o que é, como funciona e vale a pena usar?

Kauê Matos — Wed, 02 Sep 2026 15:41:07 +0000

Em julho de 2025, a AWS lançou o Kiro, uma IDE agêntica construída sobre a base open-source do VS Code (Code OSS), entrando em um mercado já disputado por ferramentas como Cursor, Windsurf, GitHub Copilot e Claude Code. O produto saiu do modo preview e alcançou disponibilidade geral no fim de 2025/início de 2026, e desde então vem se consolidando como a aposta oficial da AWS para desenvolvimento assistido por IA — a ponto de a própria empresa ter anunciado, em janeiro de 2026, o fim de novos cadastros no Amazon Q Developer (efetivo a partir de 15 de maio de 2026), direcionando explicitamente os usuários ao Kiro.

O que diferencia o Kiro do restante da concorrência não é o modelo de IA por trás dele (ele roda sobre modelos Claude via Amazon Bedrock, com roteamento também para a Amazon Nova), mas sim sua filosofia de trabalho: em vez de "chat primeiro, código depois", o Kiro é spec-first — a unidade de trabalho não é um prompt solto, e sim uma especificação estruturada que o agente usa para planejar, implementar, verificar e documentar uma funcionalidade de ponta a ponta.

O que é o Kiro, na prática

O Kiro está disponível em quatro superfícies que compartilham o mesmo agente e o mesmo histórico de créditos:

IDE desktop (macOS, Windows e Linux), com a interface familiar de quem já usa VS Code
CLI para quem prefere trabalhar via terminal
Interface web, incluída em todos os planos pagos, que ganhou suporte a GitLab e specs completos em meados de 2026
App mobile, para acompanhar e disparar tarefas em trânsito

Não é necessário ter conta AWS para começar: dá para entrar com GitHub ou Google, o que reduz a barreira de adoção — embora todo o poder de integração nativa com ambientes AWS só apareça para quem já usa a nuvem da Amazon.

O conceito central: desenvolvimento orientado por especificação (spec-driven)

Quando você inicia uma nova funcionalidade no Kiro, a ferramenta não parte direto para o código. Primeiro, ela gera três artefatos estruturados:

requirements.md — histórias de usuário e critérios de aceitação
design.md — desenho do sistema, decomposição de componentes e fluxo de dados
tasks.md — lista de tarefas sequenciadas e executáveis

Só depois que essas especificações são revisadas (e aprovadas) pelo desenvolvedor é que os agentes começam a implementar, rodando comandos e testes ao longo do caminho — inclusive em paralelo, quando o plano permite. Uma atualização de maio de 2026 reforçou esse fluxo em torno de TDD: o agente escreve primeiro os testes que devem falhar a partir da especificação, depois a implementação, e por fim roda a suíte de testes — uma forma de manter um agente autônomo "honesto" em mudanças que tocam vários arquivos.

Diferente de especificações tradicionais em cascata, que são escritas uma vez e esquecidas, as specs do Kiro evoluem junto com o código e continuam servindo de referência para onboarding, refatoração e novas funcionalidades.

Principais recursos

Specs: como descrito acima, o núcleo do produto
Hooks (ganchos de agente): automações que disparam em eventos do repositório — salvar um arquivo, criar um componente — para atualizar testes, documentação ou rodar varreduras de segurança automaticamente
Steering: arquivos markdown que guiam o comportamento do Kiro com regras e contexto específicos do projeto
Agentic Chat: conversa em linguagem natural que entende o contexto do projeto inteiro
MCP (Model Context Protocol): conexão com ferramentas e fontes de dados externas
Kiro Autonomous Agent: agente em segundo plano que pega tarefas, implementa e abre pull requests sem que o desenvolvedor precise acompanhar em tempo real
Memória persistente entre sessões e agentes que aprendem com cada interação
Verificação determinística, como testes baseados em propriedades, para checar se o código gerado realmente corresponde à especificação

Pontos positivos

Rastreabilidade e disciplina: quebrar o trabalho em specs e tarefas revisáveis torna o desenvolvimento assistido por IA mais previsível — você não está apostando que um "despejo" gigante de código vai funcionar de primeira.
Bom para produção, não só prototipagem: enquanto ferramentas como Cursor otimizam velocidade de iteração, o Kiro otimiza para projetos maiors, em equipe, onde documentação e trilha de decisões importam.
Integração nativa com AWS: para quem já é cliente AWS, o Kiro capta contexto do ambiente de nuvem sem configuração extra, o que economiza um trabalho real de "engenharia de contexto".
Suporte a GovCloud: coloca o Kiro na lista de opções viáveis para setores regulados, onde a maioria dos concorrentes de IA não pode operar.
Múltiplas superfícies com o mesmo agente: IDE, CLI, web e mobile compartilham a mesma lógica e o mesmo pool de créditos, sem métricas separadas para gerenciar.
Hooks como colaborador constante: automatizam tarefas repetitivas e viram, na prática, um "parceiro" que trabalha em segundo plano.
Guardrails de segurança reforçados após um incidente de destaque (ver seção de controvérsias abaixo), o que tornou o produto mais maduro para uso em ambientes de produção.

Pontos negativos

Modelo de preços por créditos é agressivo e difícil de prever: os planos vão de um tier gratuito (50 créditos/mês) a um Power de US$ 200/mês (cerca de 20.000 créditos), passando por Pro (US$ 20), Pro+ (US$ 40) e Pro Max (US$ 100). Uma construção completa de feature via spec custa, em média, de 15 a 25 créditos — ou seja, o tier gratuito só permite 2 ou 3 features completas por mês.
Overhead para tarefas simples: se o seu dia a dia é fazer pequenas edições pontuais em um único arquivo, a estrutura de specs adiciona etapas e reduz a sensação de velocidade — o Kiro "compensa" mais em features grandes e multi-etapas do que em ajustes rápidos.
Custo de add-ons: créditos extras saem a US$ 0,04 cada, e o consumo varia conforme o modelo escolhido (usar Claude Sonnet diretamente, por exemplo, consome cerca de 30% mais créditos do que o modo Auto de roteamento).
GovCloud custa ~20% a mais e não tem tier gratuito.
Produto ainda "jovem": alcançou disponibilidade geral só no fim de 2025/início de 2026, e usuários relatam lentidão e arestas na interface em threads de comunidades como o r/kiroIDE — problemas típicos de uma ferramenta recente.
Incidente de reputação em fevereiro de 2026: código gerado por um usuário do Kiro foi apontado, num primeiro momento, como possível causa de uma interrupção de serviço na AWS. A narrativa "o Kiro vibrou demais e derrubou a AWS" viralizou; a AWS negou oficialmente que o Kiro tivesse causado o problema, mas o episódio expôs um risco real: código gerado por IA que interage com infraestrutura de produção precisa de barreiras de segurança bem definidas.
Dependência de um ecossistema (Bedrock/Claude): por rodar sobre modelos de terceiros via Bedrock, o Kiro fica sujeito a mudanças de disponibilidade e custo desses modelos.

Preços (panorama de 2026)

Plano	Preço/mês	Créditos aproximados
Free	US$ 0	50
Pro	US$ 20	1.000
Pro+	US$ 40	~2.500
Pro Max	US$ 100	~7.000
Power	US$ 200	~20.000

Além disso, novos usuários costumam receber créditos-bônus por tempo limitado, e startups elegíveis (até Series B) podem se candidatar a até um ano do plano Pro+ gratuito. Times contam com planos equivalentes, faturamento consolidado, analytics de uso e SSO via AWS IAM Identity Center.

Kiro vs. concorrentes

Cursor / Windsurf: mais rápidos para começar e mais "leves" para quem trabalha sozinho e quer iteração ágil; o Kiro compensa quando o time precisa de planejamento repetível e rastreabilidade de implementação.
Claude Code: também terminal-first e forte em tarefas de codificação profundas, mas sem o andaime formal de specs (requirements/design/tasks) que o Kiro impõe por padrão.
GitHub Copilot: mais focado em autocomplete e sugestões inline do que em orquestrar uma feature inteira a partir de uma especificação.
Amazon Q Developer: era o assistente da AWS mais atrelado ao console e à infraestrutura AWS; a própria AWS está descontinuando novos cadastros nele, direcionando os usuários para o Kiro como sucessor para assistência de IA em IDE.

Para quem o Kiro faz sentido

Times que precisam que o código gerado por IA seja revisável, documentado e auditável — não apenas rápido.
Organizações que já compram serviços via AWS e querem aproveitar a relação de billing existente.
Equipes em setores regulados que dependem de GovCloud.
Desenvolvedores avaliando Cursor ou Windsurf, mas que querem uma alternativa com etapa de planejamento explícita e maior flexibilidade de modelos.

Já para prototipagem rápida, ajustes pontuais em um único arquivo ou projetos pessoais pequenos, o overhead do fluxo de specs pode não compensar — nesses casos, ferramentas mais leves e "chat-first" tendem a parecer mais ágeis no dia a dia.

Conclusão

O Kiro representa uma aposta filosófica clara da AWS: em vez de tratar a IA como um autocomplete mais rápido, ele tenta resolver o problema de raiz do "vibe coding" — a falta de planejamento antes da implementação. Isso o torna, para muitos, uma das opções mais sólidas para desenvolvimento de produção com IA em 2026, especialmente em times e em ambientes AWS. Por outro lado, o modelo de créditos exige atenção ao orçamento, a estrutura de specs pode ser overkill para tarefas simples, e o produto ainda carrega as arestas normais de uma ferramenta que amadureceu rápido demais para o holofote que recebeu — inclusive um episódio de reputação que, apesar de desmentido pela AWS, deixou claro o quanto guardrails de segurança são essenciais quando agentes de IA tocam infraestrutura real.

Na prática, a recomendação mais comum entre quem testou a ferramenta a fundo é: rodar o Kiro em paralelo com a ferramenta que você já usa, reservando-o para features maiores e mais estruturadas, e usar algo mais leve para o trabalho do dia a dia.