A maioria dos times de SaaS na AWS que rodam Kubernetes usa um serviço de Kubernetes gerenciado, normalmente o Amazon EKS. A palavra “gerenciado” leva muitos fundadores e CTOs a achar que a parte difícil já está resolvida. Não está. Os serviços de Kubernetes gerenciado tiram o control plane das suas mãos e, em alguns modos, os nós também, mas o cluster continua precisando de atualizações, add-ons, rede, políticas de segurança, observabilidade, controle de custos e alguém que atenda quando o alerta disparar. Este post explica o que cada opção realmente cobre, que trabalho continua com você, quem pode assumi-lo e quando vale pular o Kubernetes por completo.

O que um serviço de Kubernetes gerenciado realmente gerencia

Kubernetes gerenciado, às vezes vendido como Kubernetes as a service, significa que um provedor opera parte do cluster para você. Para saber qual parte, ajuda entender que um cluster Kubernetes tem três camadas de trabalho.

O control plane: o servidor de API do Kubernetes e o banco etcd, que guarda o estado do cluster.
O data plane: os nós (instâncias EC2 ou Fargate) onde seus contêineres rodam, mais a rede, o armazenamento e o balanceamento de carga de que dependem.
Tudo o que você roda por cima: suas cargas de trabalho, pipelines de deploy, ingress, secrets, políticas, monitoramento e os add-ons que mantêm tudo de pé.

O Amazon EKS sempre cuida da camada um. A AWS opera o servidor de API e o etcd e cobra US$ 0,10 por cluster por hora para uma versão do Kubernetes em suporte padrão. No modo padrão, a camada dois é compartilhada: a AWS oferece managed node groups, mas a documentação do EKS é explícita ao dizer que os managed node groups não são atualizados automaticamente quando o control plane é. A camada três é sua.

O EKS Auto Mode transfere mais da camada dois para a AWS. Ela assume o provisionamento, a aplicação de patches e o escalonamento dos nós (usando o Karpenter), além da integração com load balancers, da rede dos pods e dos drivers de armazenamento em bloco. Os nós rodam uma imagem restrita baseada em Bottlerocket e são substituídos pelo menos a cada 21 dias. Mesmo assim, a AWS afirma que o cliente continua responsável pelos “contêineres da aplicação, incluindo disponibilidade, segurança e monitoramento”, além da VPC e da configuração do cluster. O Auto Mode adiciona uma taxa de gerenciamento sobre as instâncias EC2 que ele lança, e o valor varia conforme o tipo de instância.

Então a resposta honesta para “o que o Kubernetes gerenciado cobre?” é: o control plane sempre, os nós às vezes e as suas aplicações nunca.

Opção 1: construir você mesmo

Dá para rodar Kubernetes em EC2 com ferramentas como kubeadm ou kops e ser dono de todas as camadas, incluindo backups do etcd, certificados do control plane e alta disponibilidade entre Zonas de Disponibilidade.

Para uma empresa de SaaS na AWS, isso raramente faz sentido. O control plane é a parte do Kubernetes em que os erros são mais difíceis de reverter, e o EKS cobra uma taxa horária pequena para tirá-lo das suas costas. Só vale considerar o autogerenciamento se você tem um requisito rígido que o EKS não atende, um time de plataforma com experiência profunda em Kubernetes e um motivo para gastar o tempo dele no control plane em vez de no seu produto. A maioria dos times não tem nenhum dos três.

Opção 2: comprar Kubernetes gerenciado na AWS com o EKS

O EKS é a escolha padrão para Kubernetes na AWS, e com razão: ele se integra a IAM, rede VPC, load balancers e CloudWatch, e elimina o trabalho operacional de maior risco.

A decisão dentro desta opção é modo padrão ou Auto Mode. O modo padrão dá mais controle sobre a configuração dos nós e custa menos em taxas. O Auto Mode custa mais por nó, mas tira da sua lista o patching dos nós, a escolha de AMIs e a manutenção do autoscaler. Para um time pequeno, sem engenheiro de plataforma dedicado, o Auto Mode costuma ser a melhor troca. Para um time com requisitos específicos de nós, como determinadas famílias de instância ou ajustes de kernel, o modo padrão com managed node groups pode servir melhor.

De qualquer forma, comprar o EKS é comprar uma fundação, não um time de operações.

Gestão de cluster Kubernetes: o trabalho que o EKS deixa com você

Esta é a lista que surpreende os times depois que o primeiro cluster entra no ar.

Atualizações de versão num calendário fixo. O Kubernetes lança uma nova versão minor mais ou menos a cada quatro meses, segundo a documentação do ciclo de vida de versões do EKS. O EKS dá a cada versão 14 meses de suporte padrão e depois 12 meses de suporte estendido a US$ 0,60 por cluster por hora, seis vezes a tarifa padrão. Quando o suporte estendido termina, o EKS atualiza o control plane automaticamente, em um horário que não é anunciado com antecedência, e você ainda precisa atualizar por conta própria os add-ons e os nós que não são gerenciados pelo Auto Mode. Na prática, alguém precisa planejar e testar uma atualização várias vezes por ano, incluindo a verificação de APIs obsoletas nos seus manifests e Helm charts.

Add-ons. O VPC CNI, o CoreDNS, o kube-proxy, o driver EBS CSI, um controlador de ingress ou de load balancer, o cert-manager, o external-dns, uma integração de secrets e um pipeline de métricas têm, cada um, suas próprias versões e regras de compatibilidade. O Auto Mode absorve alguns deles. O resto é seu.

Identidade e acesso. Mapear o IAM para o RBAC do Kubernetes, dar aos pods permissões AWS com escopo restrito e manter pessoas longe do cluster-admin.

Rede. Planejamento de endereços IP para os pods, security groups, network policies, regras de ingress e os custos de NAT e de transferência de dados, que crescem sem alarde.

Deploys. Um processo de deploy via GitOps ou pipeline, para que ninguém rode kubectl apply do notebook contra a produção.

Observabilidade e plantão. Métricas, logs e traces do cluster e das cargas de trabalho, alertas com runbooks e uma pessoa que responde de madrugada.

Custos. Requests e limits compatíveis com o uso real, consolidação de nós, Spot onde for seguro e ambientes ociosos desligados.

Segurança. Varredura de imagens, políticas de admissão, tratamento de secrets e atualização das próprias cargas de trabalho.

Nada disso é exótico. É apenas contínuo, e recai sobre quem é dono do cluster.

Opção 3: terceirizar a operação

O terceiro caminho é um serviço de gestão de Kubernetes: um time externo que opera o cluster e o caminho de entrega sobre o EKS. Note a diferença em relação às duas primeiras opções. Você continua comprando o EKS da AWS. O que você terceiriza é o trabalho da seção anterior.

Isso serve para times que precisam de Kubernetes mas não conseguem justificar um engenheiro de plataforma dedicado, ou que têm um único engenheiro carregando tudo sozinho. Os provedores de Kubernetes gerenciado desse tipo variam bastante em escopo, então pergunte:

Vocês cuidam das atualizações de versão de ponta a ponta, incluindo add-ons, APIs obsoletas e testes em staging antes?
Tudo fica em código nos nossos repositórios? A configuração do cluster, os Helm charts ou manifests e os pipelines devem morar no seu Git, não no do provedor.
Quem fica de plantão e qual é o processo de resposta? Peça detalhes concretos.
Como as mudanças chegam à produção? Procure pull requests, revisão e um pipeline automatizado.
O que acontece se nós formos embora? Você deve conseguir passar o cluster para outro time com a documentação intacta.

Quando você não precisa de Kubernetes

Muitos times de SaaS rodam Kubernetes porque é o padrão, não porque precisam. Na AWS existe um caminho mais simples que atende boa parte das aplicações web e APIs.

O Amazon ECS é o orquestrador de contêineres da própria AWS. Não há cobrança adicional pela orquestração do ECS; você paga pela capacidade de computação em que ele roda. Com o Fargate, não há nós para aplicar patches, e não há atualizações de versão de cluster do tipo Kubernetes para agendar. O ECS Express Mode vai além: você fornece uma imagem de contêiner e duas roles do IAM, e o ECS configura um serviço Fargate, um load balancer com TLS, auto scaling e rede.

O AWS App Runner era a outra opção simples, mas a AWS fechou o App Runner para novos clientes. Os clientes atuais podem continuar usando, e a AWS recomenda o ECS Express Mode para migrações. Se você está começando hoje, planeje com o ECS.

O Kubernetes começa a compensar o próprio custo operacional quando:

Você roda muitos serviços com necessidades diferentes de escalonamento e agendamento, e o time quer uma plataforma consistente para todos.
Você precisa especificamente do ecossistema Kubernetes: operators para sistemas com estado, service mesh ou ferramentas que só são distribuídas como Helm charts.
Você precisa de portabilidade entre nuvens ou para dentro do ambiente dos clientes, por exemplo um produto que os clientes instalam nos próprios clusters.
Você já tem engenheiros que conhecem bem o Kubernetes e seriam mais lentos com qualquer outra coisa.

Se nenhum desses casos se aplica, o ECS no Fargate costuma dar menos trabalho para o mesmo resultado. Um time de oito engenheiros rodando meia dúzia de serviços no ECS não está atrasado; tem mais tempo para trabalhar no produto.

Como as opções se comparam

	Autogerenciado em EC2	EKS (padrão)	EKS Auto Mode	ECS no Fargate
Control plane	Você	AWS	AWS	AWS (sem taxa)
Nós e patching	Você	Você, com managed node groups	AWS	AWS (Fargate)
Atualizações de versão	Você	Você planeja; a AWS força no fim do suporte	Você planeja; os nós se atualizam sozinhos	Sem versões de Kubernetes
Add-ons e ingress	Você	Você	Em parte a AWS	Não se aplica
Cargas de trabalho, deploys, plantão	Você	Você	Você	Você
Bom para	Casos raros, times especialistas	Times que precisam de controle dos nós	Times pequenos que precisam de Kubernetes	A maioria das aplicações web e APIs

A linha “cargas de trabalho, deploys, plantão” é a que importa: em todas as opções, alguém continua sendo dono das suas cargas de trabalho, dos deploys e do plantão. Escolher um serviço de Kubernetes gerenciado define quanta infraestrutura esse alguém também precisa carregar.

Para uma visão mais ampla do que a AWS opera por você e do que faz um provedor de DevOps, leia nosso post sobre serviços gerenciados da AWS e DevOps gerenciado.

Perguntas frequentes

O Kubernetes ainda é relevante em 2026?

Sim, para times que precisam do que ele oferece: muitos serviços com necessidades de escalonamento diferentes, o ecossistema Kubernetes de operators e Helm charts, ou portabilidade entre nuvens e ambientes de clientes. O que mudou é que ele deixou de ser a escolha automática. Na AWS, o ECS no Fargate atende muitas aplicações web e APIs com menos trabalho operacional.

Quais são as desvantagens de usar Kubernetes?

A principal desvantagem é o trabalho operacional contínuo. Mesmo com um serviço gerenciado, alguém precisa planejar as atualizações de versão várias vezes por ano, manter os add-ons compatíveis, cuidar de identidade, rede e custos e atender quando o alerta disparar. O suporte estendido do EKS também custa seis vezes a tarifa padrão do control plane se as atualizações ficarem para trás.

Quais são os quatro tipos de serviço no Kubernetes?

O Kubernetes define quatro tipos de Service: ClusterIP, o padrão, que expõe o serviço apenas dentro do cluster; NodePort, que o expõe em uma porta estática em cada nó; LoadBalancer, que usa o load balancer do provedor de nuvem para expô-lo externamente; e ExternalName, que mapeia o serviço para um nome DNS externo. No EKS, os serviços LoadBalancer normalmente são atendidos por load balancers da AWS.

Onde a Webera entra

A Webera é uma assinatura de DevOps para times de SaaS na AWS, com engenheiros seniores trabalhando ao lado de nove agentes de IA. Os agentes fazem a vigilância, o roteamento e a primeira análise 24 horas por dia; os engenheiros tomam as decisões e entregam as correções. Seja no EKS, no ECS ou ainda decidindo entre os dois, o trabalho descrito neste post entra na mesma fila de solicitações, com monitoramento 24/7 e resposta a incidentes em todos os planos.

Pro, US$ 4.999 por mês: solicitações ilimitadas, duas em andamento por vez, e prazo de entrega médio de 36 horas.
Elite, US$ 9.999 por mês: engenheiro designado, gerente de sucesso do cliente, concierge de compliance para SOC 2, HIPAA e PCI, e prazo de entrega médio de 24 horas.
Platform, US$ 14.999 por mês: um time trabalhando dentro das suas sprints, com operação multi-conta e de Kubernetes e transferência de conhecimento para os seus engenheiros.

Todos os planos têm mínimo de três meses, cobrado mensalmente, e depois seguem mês a mês, e todo o código é seu. Se a operação do Kubernetes está tomando mais tempo do seu time do que o produto, compare os planos na nossa página de preços.

Serviços de Kubernetes gerenciado: construir, comprar ou terceirizar