Quiz

B — Railway ou Fly.io.

Railway e Fly.io conseguem fazer o deploy de uma aplicação Spring Boot com Docker em minutos, sem nenhuma configuração de infraestrutura. O EKS exige dias de configuração (VPC, node groups, roles IAM, add-ons, ingress controllers); o ECS Fargate ainda exige configurar VPC, task roles IAM, ALB e ECR; o Lightsail é simples, mas ainda precisa de uma imagem enviada a um registry e da criação manual de um container service. Quando o tempo até estar no ar é a restrição, uma PaaS que faz o build direto do repositório vence.

B — O ECS Fargate é serverless; o EKS exige gerenciar node groups e toda a superfície da API do K8s.

Com o ECS Fargate, a AWS provisiona e aplica patches no processamento subjacente — você define uma task (CPU, memória, imagem do container, variáveis de ambiente) e a AWS a executa. Com o EKS, você paga pelo control plane (~US$ 73/mês) e gerencia os node groups por conta própria: tipos de instância, atualizações de AMI, drenagem de nós durante upgrades e todos os add-ons do Kubernetes. Com 10 desenvolvedores, a simplicidade operacional do ECS normalmente supera a perda do ecossistema Kubernetes.

C — Falso. Control plane do EKS + node group mínimo superam o custo total das alternativas mais simples.

O control plane do EKS custa US$ 0,10/hora × 730 horas ≈ US$ 73/mês antes de um único container rodar. Um node group mínimo (2 × t3.medium) acrescenta cerca de US$ 61/mês, e um balanceador de carga e um pequeno banco RDS levam o modelo de custos da aula a aproximadamente US$ 180/mês — contra algo em torno de US$ 15–25/mês para os mesmos três serviços no Fly.io, no Railway ou em uma VM Lightsail (preços de tabela de outubro de 2026, us-east-1). (O projeto da disciplina usa EKS mesmo assim, porque seu objetivo é aprender Kubernetes.) Além do custo, o EKS exige um conhecimento operacional significativo (roles IAM para service accounts, rede com VPC CNI, configuração de ingress controller) que desvia a atenção dos conceitos de nível de aplicação que a disciplina busca ensinar.

B — O K3s é uma distribuição de Kubernetes leve e totalmente compatível com a API, para deploys on-prem, na borda ou sensíveis a custo.

O K3s roda a API completa do Kubernetes em um binário com menos de 100 MB, substituindo o etcd por SQLite por padrão e removendo as integrações com provedores de nuvem. Você escolheria o K3s em vez do EKS quando precisa de Kubernetes em servidores bare-metal (o data center de uma universidade, o chão de uma fábrica, um cluster de Raspberry Pi), quando a conexão com a internet não é confiável ou quando a taxa de ~US$ 73/mês do control plane do EKS não se justifica. O trade-off é que você é dono de todas as operações — upgrades, backups e configuração de HA — sem suporte gerenciado da AWS.

B — Amazon ECS Express Mode.

A AWS fechou o App Runner para novos clientes em 30 de abril de 2026 (os clientes existentes continuam com ele, sem novas funcionalidades) e recomenda o ECS Express Mode como substituto. O Express Mode não tem cobrança extra — você paga pelas tasks Fargate, pelo balanceador de carga e pelos demais recursos que ele cria — e, como tudo o que ele cria fica visível e editável na sua conta, o time pode depois "se formar" para o ECS Fargate completo sem migrar. Ao contrário do App Runner, ele não faz build a partir do código-fonte: o pipeline de CI precisa antes construir a imagem e enviá-la ao ECR.

B — Implantar em regiões adicionais; o roteamento Anycast do Fly.io direciona os usuários para a instância mais próxima.

O Fly.io atribui a cada aplicação um endereço IP Anycast. Quando um usuário europeu se conecta, sua requisição é roteada via BGP até o nó de borda do Fly mais próximo que roda o seu container — normalmente lhr (Londres) ou ams (Amsterdã). Adicionar regiões é um único comando, por exemplo fly scale count 3 --region gru,lhr,ams. O trade-off: serviços stateless escalam globalmente sem esforço, mas serviços com estado (bancos de dados, sessões) exigem estratégias deliberadas de replicação ou de consistência global — o Fly Postgres clássico é uma app que você mesmo opera, e o mais recente Managed Postgres elimina esse trabalho a um preço fixo maior.

C — Domínio privado entre recursos do Lightsail; VPC peering para o RDS.

O Lightsail não usa a rede VPC padrão da AWS. Cada container service recebe um endpoint público e um domínio privado <service-name>.service.local, acessível a partir de outros recursos do Lightsail na mesma Region — o suficiente para gateway → account. Recursos fora do Lightsail, como uma instância RDS em uma VPC comum, só ficam acessíveis depois de habilitar o Lightsail VPC peering com a VPC padrão da Region, um passo que muitos tutoriais pulam. Também não há security groups nem políticas de rede para ajustar, o que é um dos motivos pelos quais os times acabam superando o Lightsail.

B — A presença de um engenheiro de plataforma dedicado é o fator decisivo.

Com 40 microsserviços, tanto o ECS Fargate quanto o EKS são tecnicamente capazes. A questão real é quem é dono da operação. O EKS exige alguém que entenda a rede do Kubernetes (CNI, services, ingress), gerencie os upgrades dos node groups, configure RBAC, instale e mantenha add-ons (Karpenter, ArgoCD, external-secrets-operator) e responda a incidentes do cluster. Sem um engenheiro de plataforma dedicado, essas tarefas caem sobre os desenvolvedores de funcionalidades, atrasando a entrega do produto. O ECS Fargate cobre a maior parte das necessidades de um sistema de microsserviços típico sem taxa de control plane e sem nós para operar — e é a resposta certa para a maioria dos times nessa escala, a menos que GitOps, multi-tenancy ou portabilidade entre nuvens sejam requisitos obrigatórios.

B — Custos fixos dominam em pequena escala.

Três pequenas tasks Fargate (0,25 vCPU / 0,5 GB) custam cerca de US$ 27/mês; a taxa por hora do ALB, as unidades de capacidade e os endereços IPv4 públicos custam cerca de US$ 30, e a menor instância RDS cerca de US$ 14 — tudo cobrado por hora, cheguem requisições ou não. O EKS acrescentaria um control plane de US$ 73 e ainda precisaria de um balanceador de carga. É por isso que plataformas com taxa fixa perdem com três serviços e ganham com cinquenta, e por isso que NAT gateways, balanceadores de carga e clusters esquecidos são a clássica surpresa na conta de um aluno.

C — Ficar, e definir os gatilhos de migração.

Cada migração deve ser motivada por um problema concreto, não por especulação ou por valorizar o currículo. O EKS acrescentaria uma taxa fixa de control plane, operação de nós e um conhecimento de Kubernetes de que o time ainda não precisa — horas de trabalho de plataforma que não entregam nenhuma funcionalidade. Manter a aplicação 12-factor faz de uma mudança futura um exercício de deploy, e não uma reescrita, então esperar custa pouco.

C — Do control plane gerenciado e altamente disponível.

O K3s é uma distribuição certificada pela CNCF, então seus Deployments, Services e Ingresses funcionam sem alterações. O que os US$ 0,10/hora do EKS compram é um control plane que a AWS roda em várias Availability Zones, mantém atualizado e com backup. Com K3s em uma VM, perder a VM é perder o cluster e todos os workloads nele; auto-hospedar transfere o trabalho para você, e não apenas tira o custo do caminho.