Como você executa containers na AWS (ECS, EKS, Fargate)?

Question

Accepted Answer

A AWS oferece várias formas de executar **containers** — **ECS** (Elastic Container Service, seu próprio orquestrador), **EKS** (Kubernetes gerenciado) e **Fargate** (containers serverless, sem servidores para gerenciar). Compreender as opções ajuda a escolher a plataforma de container certa.

## ECS — orquestrador de containers da AWS

```text
ECS runs and orchestrates Docker containers on AWS:
  → simpler than Kubernetes; deeply integrated with AWS (IAM, ALB, CloudWatch, VPC)
  → TASK (a running container set), TASK DEFINITION (the spec), SERVICE (keeps N tasks
    running, integrates with load balancers, auto-scales)
  → good for teams wanting container orchestration without Kubernetes complexity
```

## EKS — Kubernetes gerenciado

```text
EKS runs managed KUBERNETES on AWS:
  → standard Kubernetes (portable skills/tooling, huge ecosystem) — AWS manages the
    control plane
  → choose this for Kubernetes (industry-standard) or if you need its power/ecosystem
  → more complex than ECS, but standard and powerful
```

## Fargate — containers serverless

```text
FARGATE is a SERVERLESS compute engine for containers (works with ECS or EKS):
  → NO servers/EC2 to manage — you just run containers; AWS provisions the compute
  → pay per container resources used; auto-scales
  → vs running containers on EC2 instances YOU manage (patching, scaling the hosts)
→ Fargate = run containers without managing the underlying servers.
```

## Escolhendo

```text
ECS + EC2     → full control over the instances; manage the hosts
ECS + Fargate → AWS orchestration, NO server management (simple, common)
EKS           → standard Kubernetes (portability, ecosystem) — more complex
EKS + Fargate → Kubernetes without managing nodes
→ Fargate for less ops; ECS for AWS-native simplicity; EKS for Kubernetes.
```

## Por que isso importa

Compreender como executar containers na AWS é valioso porque containers são centrais para a implantação moderna de aplicações e a AWS oferece múltiplas opções com diferentes trade-offs, então compreendê-las ajuda a escolher a plataforma certa.

As opções atendem a necessidades diferentes: **ECS** (orquestrador próprio da AWS) é **mais simples que Kubernetes e profundamente integrado com a AWS** (IAM, load balancers, CloudWatch), tornando-se uma boa escolha para times que desejam orquestração de containers sem a complexidade do Kubernetes; **EKS** (Kubernetes gerenciado) fornece **Kubernetes padrão e portável** com seu enorme ecossistema e skills/ferramentas de padrão industrial (AWS gerenciando o control plane), adequado para times que desejam especificamente Kubernetes; e **Fargate** (containers serverless, funcionando com ECS ou EKS) elimina completamente o gerenciamento de servidores — executando containers sem provisionar ou gerenciar instâncias EC2.

Compreender o **modelo serverless do Fargate** é particularmente valioso: remove a carga operacional de gerenciar hosts de container (patches, scaling dos servidores subjacentes), permitindo apenas executar containers e pagar pelos recursos utilizados — uma simplificação significativa.

Compreender as **escolhas** (ECS+EC2 para controle total, ECS+Fargate para simplicidade nativa da AWS sem gerenciamento de servidor, EKS para Kubernetes padrão, EKS+Fargate para Kubernetes sem gerenciamento de nós) reflete os trade-offs entre controle, simplicidade, padronização e carga operacional — ajudando a alinhar a plataforma com as necessidades e expertise do time.

Como containers são centrais para a implantação moderna e a AWS oferece múltiplas plataformas de container com trade-offs significativos (nativo da AWS vs Kubernetes, servidor gerenciado vs serverless), e como escolher apropriadamente depende de compreender essas opções, compreender como executar containers na AWS (ECS, EKS, Fargate) é conhecimento valioso e praticamente relevante da AWS para implantar aplicações containerizadas — ajudando a selecionar a plataforma de container certa baseado em simplicidade, padronização e quanto gerenciamento operacional o time deseja, uma decisão importante para workloads containerizados na AWS.