A diversidade de compute na AWS
Uma das grandes vantagens da AWS é oferecer múltiplos paradigmas de computação, cada um projetado para perfis diferentes de workload. EC2 entrega máquinas virtuais com controle total sobre o sistema operacional. Containers via ECS e EKS permitem empacotar aplicações em unidades portáteis e orquestradas. Lambda elimina completamente a gestão de servidores com execução event-driven e escala automática.
Escolher o modelo certo não é trivial: a decisão impacta diretamente o custo da infraestrutura, o overhead operacional da equipe e a capacidade de escalar. Este artigo compara as três abordagens em profundidade para orientar essa escolha.
O que é cada opção?
EC2: Elastic Compute Cloud
Lançado em 2006, o EC2 é o bloco fundamental de computação na AWS. Cada instância é uma máquina virtual com SO, CPU, memória e armazenamento configuráveis. As famílias de instância cobrem desde uso geral (t3, m6i) até workloads especializados como computação intensiva (c6g), memória otimizada (r6i) e aceleração por GPU (p4, g5). O modelo de cobrança inclui on-demand, reserved instances (desconto de até 72%) e spot (desconto de até 90% para workloads tolerantes a interrupções).
Containers: ECS e EKS
A conteinerização empacota a aplicação com todas as suas dependências em uma imagem Docker portátil. O Amazon ECS é o orquestrador nativo da AWS, ideal para quem quer simplicidade sem abrir mão de recursos avançados. O Amazon EKS entrega Kubernetes gerenciado, com toda a portabilidade e o vasto ecossistema de ferramentas K8s. Ambos podem rodar sobre instâncias EC2 (você gerencia os nodes) ou sobre o AWS Fargate, camada serverless que elimina a gestão de servidores para containers.
Lambda: Serverless Functions
O AWS Lambda executa código em resposta a eventos sem qualquer gestão de servidor. A função escala automaticamente de zero a milhares de execuções paralelas em milissegundos. Suporta até 10 GB de memória e 15 minutos de timeout por invocação, com integração nativa com mais de 200 serviços AWS (S3, SQS, DynamoDB, EventBridge, etc.). A cobrança é feita exclusivamente pelo tempo de execução e número de invocações, sem custo por ociosidade.
Vantagens e desvantagens de cada abordagem
| EC2 | Containers (ECS/EKS) | Lambda | |
|---|---|---|---|
| Gestão de infra | Manual (SO, patches, scaling) | Parcial (Fargate abstrai nodes) | Nenhuma |
| Escalabilidade | Auto Scaling em minutos | Auto Scaling em segundos | Automática em milissegundos |
| Cold start | Nenhum após início | Nenhum após início | Sim (ms a segundos, conforme runtime) |
| Custo em ociosa | Alto (instância sempre ativa) | Médio (Fargate pode escalar a 0) | Zero |
| Portabilidade | Baixa | Alta (imagem Docker) | Baixa (vendor lock-in AWS) |
| Suporte a GPU | Total (p4, g5, trn1) | Parcial (via EC2 nodes) | Não |
| Timeout máximo | Sem limite | Sem limite | 15 minutos |
| Complexidade operacional | Alta | Média–Alta | Baixa |
O cold start do Lambda merece atenção especial: em runtimes interpretados como Python e Node.js, o tempo adicional em invocações frias costuma ficar entre 100ms e 500ms. Para APIs com SLA de latência abaixo de 50ms em 100% das requisições, Provisioned Concurrency elimina o cold start ao custo de uma cobrança contínua, aproximando o modelo ao custo de containers. Uma análise detalhada de cold starts por runtime está disponível em lambda-perf.
Quando cada abordagem é mais adequada
EC2 é a escolha natural para workloads que exigem controle total do sistema operacional, uso de hardware especializado como GPU, ou cargas com perfil de uso previsível e constante onde Reserved Instances amortizam bem o custo. Bancos de dados self-managed (PostgreSQL, Redis), pipelines de treinamento de ML e projetos de lift-and-shift de sistemas legados se encaixam nesse perfil. A FINRA, por exemplo, usa EC2 para processar dezenas de bilhões de eventos de mercado diariamente com controle preciso sobre o ambiente de execução.
Containers (ECS/EKS) brilham em arquiteturas de microsserviços com múltiplos times e serviços independentes, especialmente quando portabilidade entre ambientes (dev, staging, prod) ou multi-cloud é um requisito. EKS é particularmente adequado para organizações que já investiram no ecossistema Kubernetes ou precisam de um plano de saída de vendor lock-in. A Mobileye usa EKS para orquestrar o processamento massivo de dados de veículos autônomos, onde a consistência de latência e a portabilidade da plataforma são críticas.
Lambda é a escolha ideal para workloads event-driven e APIs com tráfego variável. A integração nativa com o ecossistema AWS permite construir pipelines complexos sem escrever uma linha de infraestrutura: triggers de S3 disparam processamento de arquivos, filas SQS alimentam workers de forma assíncrona, EventBridge agenda tarefas recorrentes. O Booking.com migrou parte de seus sistemas para arquitetura serverless, reduzindo custos operacionais e aumentando a velocidade de entrega de novas funcionalidades. Segundo o Gartner, serverless é a opção de compute de mais rápido crescimento em adoção entre empresas que operam na nuvem.
Comparativo de custo entre as abordagens
A estrutura de custos difere fundamentalmente entre as três abordagens. Enquanto EC2 e Containers cobram pela disponibilidade da infraestrutura (independente do uso), Lambda cobra exclusivamente pelo consumo real.
| Componente | EC2 | ECS Fargate | EKS | Lambda |
|---|---|---|---|---|
| Compute | Por hora de instância | Por vCPU/hora + GB/hora | Por hora de node + $0,10/hr de cluster | Por GB-s de execução |
| Rede / Gateway | ALB obrigatório + transferência | ALB obrigatório + transferência | ALB obrigatório + transferência | API Gateway ou Function URL |
| Armazenamento | EBS obrigatório | Efêmero (sem custo extra) | Efêmero (sem custo extra) | 512 MB efêmero incluso |
| Custo em ociosa | Alto (instância ativa) | Médio (pode escalar a 0) | Alto (cluster sempre pago) | Zero |
| Desconto por volume | Reserved (até 72%), Spot (até 90%) | Savings Plans | Reserved nodes + Savings Plans | Compute Savings Plans |
Para ilustrar o impacto prático, a tabela abaixo estima o custo mensal de uma API REST com 10 milhões de requisições por mês, tempo médio de resposta de 200ms, na região us-east-1. Os valores são aproximados e consideram a configuração mínima viável para cada serviço. Consulte as páginas de preços de EC2, Fargate, EKS e Lambda para valores atualizados.
| Serviço | Compute | Rede / Gateway | Armazenamento | Total aprox./mês |
|---|---|---|---|---|
| EC2 t3.small | ~$15 (on-demand, 24/7) | ~$22 (ALB) | ~$1 (EBS 8 GB) | ~$38/mês |
| ECS Fargate 0,25 vCPU · 0,5 GB |
~$9 (24/7) | ~$22 (ALB) | — | ~$31/mês |
| EKS t3.small + cluster |
~$88 (node + $73 cluster) | ~$22 (ALB) | — | ~$110/mês |
| Lambda 512 MB · 200ms médios |
~$12 (duração + invocações) | ~$10 (HTTP API Gateway) | — | ~$22/mês |
Dois pontos merecem destaque nesse comparativo. Primeiro, o EKS não é adequado para workloads isolados de baixa escala: o custo fixo do cluster ($73/mês) só se justifica quando múltiplos serviços compartilham a mesma infraestrutura, diluindo esse custo. Segundo, Lambda apresenta a melhor relação custo-benefício em tráfego variável, em períodos de baixo uso, o custo cai proporcionalmente a zero, enquanto EC2 e containers continuam cobrados pela disponibilidade.
Resumo e recomendações
Não existe uma única resposta certa para a escolha de compute na AWS. Cada paradigma resolve um conjunto específico de problemas com eficiência diferente:
Na prática, arquiteturas modernas combinam as três abordagens: Lambda para APIs e automações event-driven, Fargate para serviços de longa duração que precisam de containers, e EC2 para workloads de ML que demandam GPU. O AWS Well-Architected Serverless Lens é uma referência excelente para avaliar arquiteturas serverless segundo as melhores práticas da AWS.