Lab 34 — EKS quando ECS não basta: o que muda de verdade

{
  "source": "cadencia.pedidos",
  "detail-type": "PedidoPago",
  "detail": {
    "pedidoId": "b7e4b8b0-1c2d-4e3f-9a1b-8f7c6d5e4a3b",
    "tentativa": 1,
    "ocorridoEm": "2026-08-07T13:04:11Z"
  }
}

// Program.cs — o mesmo binário nos dois desenhos, sem um `#if` sequer

var builder = WebApplication.CreateBuilder(args);

// A cadeia de credencial padrão do SDK da AWS resolve para os dois casos sem
// nenhuma configuração explícita: no ECS ela lê o endpoint de metadados do
// Fargate; no EKS ela lê AWS_ROLE_ARN e AWS_WEB_IDENTITY_TOKEN_FILE, que o
// webhook de identidade de pod injeta quando a ServiceAccount está anotada.
// É por isso que este arquivo não muda entre os dois desenhos.
builder.Services.AddDefaultAWSOptions(builder.Configuration.GetAWSOptions());
builder.Services.AddAWSService<IAmazonSQS>();
builder.Services.AddAWSService<IAmazonSimpleEmailServiceV2>();
builder.Services.AddHostedService<ConsumidorDeFila>();

builder.Services.AddHealthChecks()
    .AddCheck("self", () => HealthCheckResult.Healthy(), tags: ["live"])
    .AddCheck<FilaAcessivelCheck>("fila", tags: ["ready"]); // valida sqs:GetQueueAttributes

var app = builder.Build();

app.MapHealthChecks("/health/live", new HealthCheckOptions { Predicate = r => r.Tags.Contains("live") });
app.MapHealthChecks("/health/ready", new HealthCheckOptions { Predicate = r => r.Tags.Contains("ready") });

// Única rota administrativa que existe. O time de suporte é a única audiência
// humana deste serviço nos dois desenhos.
app.MapPost("/admin/reenviar/{pedidoId:guid}", async (Guid pedidoId, IAmazonSimpleEmailServiceV2 ses, AppDb db) =>
{
    var pedido = await db.Pedidos.FindAsync(pedidoId);
    if (pedido is null) return Results.NotFound();
    await EnviarConfirmacao.Executar(ses, pedido);
    return Results.Accepted();
});

app.Run();

# ecs.tf — a linha de base: papel de tarefa, grupo de destino, serviço

# Uma identidade só, e ela é explícita: duas ações, dois recursos, nenhum "*"
# que não se justifique.
data "aws_iam_policy_document" "notificacoes_task" {
  statement {
    sid       = "ConsumirFila"
    effect    = "Allow"
    actions   = ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"]
    resources = [aws_sqs_queue.pedidos_pagos.arn] # a fila do L31/L33, por ARN
  }
  statement {
    sid       = "EnviarConfirmacao"
    effect    = "Allow"
    actions   = ["ses:SendEmail", "ses:SendRawEmail"]
    resources = [aws_sesv2_email_identity.dominio.arn] # restrito à identidade verificada
  }
}

resource "aws_iam_role" "notificacoes_task" {
  name               = "${var.projeto}-notificacoes-task"
  assume_role_policy  = data.aws_iam_policy_document.confianca_ecs_tasks.json
}

resource "aws_iam_role_policy" "notificacoes_task" {
  role   = aws_iam_role.notificacoes_task.id
  policy = data.aws_iam_policy_document.notificacoes_task.json
}

resource "aws_lb_target_group" "notificacoes_admin" {
  name        = "${var.projeto}-notif-admin"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.principal.id
  target_type = "ip"

  health_check {
    path                = "/health/ready"
    interval            = 10
    timeout             = 5
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }
}

resource "aws_ecs_task_definition" "notificacoes" {
  family                   = "${var.projeto}-notificacoes"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 256
  memory                   = 512
  execution_role_arn       = aws_iam_role.execucao.arn   # ECR + logs — mesmo papel do L03
  task_role_arn             = aws_iam_role.notificacoes_task.arn

  container_definitions = jsonencode([{
    name         = "notificacoes"
    image        = "${aws_ecr_repository.notificacoes.repository_url}:${var.sha_da_imagem}"
    essential    = true
    portMappings = [{ containerPort = 8080, protocol = "tcp" }]
    environment = [
      { name = "FILA_URL", value = aws_sqs_queue.pedidos_pagos.url },
    ]
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = aws_cloudwatch_log_group.notificacoes.name
        "awslogs-region"        = var.regiao
        "awslogs-stream-prefix" = "notificacoes"
      }
    }
  }])
}

resource "aws_ecs_service" "notificacoes" {
  name            = "${var.projeto}-notificacoes"
  cluster         = aws_ecs_cluster.principal.id
  task_definition = aws_ecs_task_definition.notificacoes.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets         = aws_subnet.privada[*].id
    security_groups = [aws_security_group.notificacoes.id]
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.notificacoes_admin.arn
    container_name    = "notificacoes"
    container_port    = 8080
  }
}

# O objeto inteiro de orquestração deste desenho: um serviço, uma task
# definition, um grupo de destino, um papel de tarefa. Conte com a seção
# "Implantar, e provar" — é o número 1 da segunda prova.

# eks.tf — o cluster, o perfil Fargate, e as DUAS identidades novas

resource "aws_iam_role" "cluster" {
  name               = "${var.projeto}-eks-cluster"
  assume_role_policy = data.aws_iam_policy_document.confianca_eks.json
}

resource "aws_iam_role_policy_attachment" "cluster" {
  role       = aws_iam_role.cluster.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
}

resource "aws_eks_cluster" "principal" {
  name     = "${var.projeto}-eks"
  role_arn = aws_iam_role.cluster.arn

  vpc_config {
    subnet_ids              = concat(aws_subnet.privada[*].id, aws_subnet.publica[*].id)
    endpoint_public_access  = false # o painel de administração acessa via VPN/bastion
    endpoint_private_access = true
  }

  # Cobra por hora a partir daqui, ANTES de existir um perfil Fargate ou um
  # pod. Suporte padrão e suporte estendido têm taxas diferentes — confira o
  # valor atual no Pricing Calculator; o que não muda é que a cobrança é por
  # cluster-hora, não por uso.
}

# ── Identidade 1: o papel de execução do Fargate Pod ─────────────────────────
# Só deixa o kubelet se registrar no cluster e puxar imagem/log. O contêiner
# NUNCA herda isto — é a distinção que a seção de construção do manifesto
# reforça, porque é onde mais gente erra.
data "aws_iam_policy_document" "confianca_fargate_pod" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["eks-fargate-pods.amazonaws.com"]
    }
    condition {
      test     = "ArnLike"
      variable = "aws:SourceArn"
      values   = ["arn:aws:eks:${var.regiao}:${var.conta}:fargateprofile/${var.projeto}-eks/*"]
    }
  }
}

resource "aws_iam_role" "fargate_pod_execution" {
  name               = "${var.projeto}-eks-fargate-pod-execution"
  assume_role_policy = data.aws_iam_policy_document.confianca_fargate_pod.json
}

resource "aws_iam_role_policy_attachment" "fargate_pod_execution" {
  role       = aws_iam_role.fargate_pod_execution.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy"
}

resource "aws_eks_fargate_profile" "notificacoes" {
  cluster_name           = aws_eks_cluster.principal.name
  fargate_profile_name   = "notificacoes"
  pod_execution_role_arn = aws_iam_role.fargate_pod_execution.arn
  subnet_ids              = aws_subnet.privada[*].id

  # Seletor por namespace + rótulo. Pod fora deste par não é agendado no
  # Fargate — fica Pending, e é a Falha 3 da seção de quebrar de propósito.
  selector {
    namespace = "notificacoes"
  }
}

# ── OIDC: a ponte que faz uma ServiceAccount virar identidade AWS ───────────
data "tls_certificate" "oidc" {
  url = aws_eks_cluster.principal.identity[0].oidc[0].issuer
}

resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.oidc.certificates[0].sha1_fingerprint]
  url             = aws_eks_cluster.principal.identity[0].oidc[0].issuer
}

# ── Identidade 2: IRSA — a permissão que o contêiner de fato usa ────────────
# Mesmas duas ações do papel de tarefa do ECS. A DIFERENÇA não é o que ela
# autoriza — é a QUEM ela confia: aqui é uma ServiceAccount específica,
# amarrada pelo `sub` do token OIDC, não uma task inteira.
data "aws_iam_policy_document" "confianca_irsa_notificacoes" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.cluster.arn]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(aws_iam_openid_connect_provider.cluster.url, "https://", "")}:sub"
      values   = ["system:serviceaccount:notificacoes:notificacoes-sa"]
    }
  }
}

resource "aws_iam_role" "irsa_notificacoes" {
  name               = "${var.projeto}-irsa-notificacoes"
  assume_role_policy = data.aws_iam_policy_document.confianca_irsa_notificacoes.json
}

resource "aws_iam_role_policy" "irsa_notificacoes" {
  role   = aws_iam_role.irsa_notificacoes.id
  policy = data.aws_iam_policy_document.notificacoes_task.json # mesma policy do ECS, reaproveitada
}

# ── Identidade 3: IRSA do próprio Load Balancer Controller ──────────────────
# Ele age em nome do CLUSTER inteiro — por isso a política dele é sobre
# elasticloadbalancing, não sobre sqs/ses. Ver a seção de manifestos para a
# versão completa e a ressalva sobre a política oficial.
data "aws_iam_policy_document" "confianca_irsa_lbcontroller" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.cluster.arn]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(aws_iam_openid_connect_provider.cluster.url, "https://", "")}:sub"
      values   = ["system:serviceaccount:kube-system:aws-load-balancer-controller"]
    }
  }
}

resource "aws_iam_role" "irsa_lbcontroller" {
  name               = "${var.projeto}-irsa-lb-controller"
  assume_role_policy = data.aws_iam_policy_document.confianca_irsa_lbcontroller.json
}

# Conte os recursos IAM deste arquivo contra os dois do ecs.tf: é a Prova 2
# da seção de implantação.

# notificacoes.yaml — os manifestos Kubernetes; o binário não muda, só a moldura

apiVersion: v1
kind: Namespace
metadata:
  name: notificacoes # tem de bater com o `selector.namespace` do perfil Fargate
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: notificacoes-sa
  namespace: notificacoes
  annotations:
    # É esta linha que liga a ServiceAccount à role IRSA. Sem ela, o pod sobe
    # com a mesma identidade fraca de qualquer outro no namespace, e a
    # aplicação recebe AccessDenied de todas as chamadas de negócio.
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/ffv-lab-irsa-notificacoes
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: notificacoes
  namespace: notificacoes
spec:
  replicas: 2
  selector:
    matchLabels: { app: notificacoes }
  template:
    metadata:
      labels: { app: notificacoes }
    spec:
      serviceAccountName: notificacoes-sa # sem isto, IRSA não se aplica ao pod
      containers:
        - name: notificacoes
          image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/ffv-lab-notificacoes:SHA_DA_IMAGEM
          ports: [{ containerPort: 8080 }]
          env:
            - name: FILA_URL
              value: https://sqs.us-east-1.amazonaws.com/111122223333/ffv-lab-pedidos-pagos
          readinessProbe:
            httpGet: { path: /health/ready, port: 8080 }
            periodSeconds: 5
          livenessProbe:
            httpGet: { path: /health/live, port: 8080 }
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: notificacoes
  namespace: notificacoes
spec:
  type: ClusterIP # o ALB não fala com o pod direto; fala com este Service
  selector: { app: notificacoes }
  ports: [{ port: 80, targetPort: 8080 }]
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: notificacoes-admin
  namespace: notificacoes
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internal        # equivalente ao ALB interno do desenho ECS
    alb.ingress.kubernetes.io/target-type: ip          # aponta direto ao IP do pod, não a um nó
    alb.ingress.kubernetes.io/healthcheck-path: /health/ready
spec:
  rules:
    - http:
        paths:
          - path: /admin
            pathType: Prefix
            backend:
              service: { name: notificacoes, port: { number: 80 } }

# instalar-lb-controller.sh — a peça que o ECS não tem, instalada uma vez por cluster

helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  --namespace kube-system \
  --set clusterName="${PROJETO}-eks" \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller

# A ServiceAccount `aws-load-balancer-controller` já existe (criada à parte,
# com a mesma anotação de IRSA do manifesto de Notificações) e aponta para a
# role `irsa_lbcontroller` do Terraform. A política ANEXADA a essa role é a
# oficial do projeto — ela é longa (dezenas de ações de elasticloadbalancing,
# ec2, acm, wafv2, shield) e não está reproduzida aqui por completo: use o
# `iam_policy.json` publicado no repositório do AWS Load Balancer Controller,
# porque uma versão resumida daria à role menos — ou mais — do que ela precisa.

# provas.sh — cinco medições; a quinta é a que este laboratório existe para fazer

PROJETO=ffv-lab; REGIAO=us-east-1

# ── Prova 1: tempo até o cluster ficar ACTIVE ─────────────────────────────────
# NAO verificado na documentacao — e a medicao do ambiente de exemplo, e serve
# so como ordem de grandeza. Meca no seu ambiente: o tempo varia por regiao e
# por versao do Kubernetes.
inicio=$(date +%s)
terraform apply -target=aws_eks_cluster.principal -auto-approve
aws eks wait cluster-active --name "${PROJETO}-eks" --region "$REGIAO"
echo "cluster ACTIVE em $(( $(date +%s) - inicio )) s"
# Na Cadencia: 11 min 42 s. O servico ECS equivalente ficou pronto em segundos.

# ── Prova 2: quantos objetos IAM para o MESMO resultado ──────────────────────
echo "-- ECS --"; grep -c 'resource "aws_iam_role"' ecs.tf
echo "-- EKS --"; grep -c 'resource "aws_iam_role"' eks.tf
# Esperado: 1 no ECS (o papel de tarefa; o de execucao ja existe desde o L03).
# 4 no EKS (cluster, execucao do pod, IRSA de Notificacoes, IRSA do controller).

# ── Prova 3: IRSA está de fato injetando credencial no pod ───────────────────
kubectl exec -n notificacoes deploy/notificacoes -- env | grep AWS_ROLE_ARN
# Esperado: a variavel aparece, apontando para a role irsa_notificacoes. Se
# vier vazia, a ServiceAccount nao esta anotada ou o Deployment nao a referencia.
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
  --query 'Events[0].EventName' --output text
# Esperado: AssumeRoleWithWebIdentity aparece no CloudTrail apos o pod subir.

# ── Prova 4: o ALB nasceu do controller, nao do Terraform ────────────────────
kubectl get ingress -n notificacoes notificacoes-admin -w
# Esperado: a coluna ADDRESS comeca vazia e preenche com um DNS de ALB em ate
# alguns minutos. Se ficar vazia por muito mais tempo, o controller nao tem
# permissao ou nao encontrou sub-rede com a tag kubernetes.io/role/elb.

# ── Prova 5: a que este laboratorio existe para fazer — horas de operacao ────
# NAO verificado na documentacao — e o numero que a Cadencia mediu, registrado
# em planilha de horas durante o piloto de um mes. Registre o seu.
echo "ECS: 40 min do zero ao servico saudavel (mesma pessoa, mesma tarde)"
echo "EKS: 3 h 10 min para o mesmo resultado, incluindo a primeira vez"
echo "     debugando IRSA e a primeira vez configurando o LB Controller"

#!/usr/bin/env bash
# limpar.sh — o EKS deixa recurso vivo que o ECS nunca teve
set -euo pipefail

PROJETO="${PROJETO:?defina PROJETO}"; REGIAO="${REGIAO:-us-east-1}"

# 1. O ALB do EKS foi criado PELO CONTROLLER, nao pelo Terraform — apague os
#    manifestos ANTES do terraform destroy, ou o ALB fica orfao, cobrando por
#    hora sem nenhum recurso do Terraform apontando para ele.
kubectl delete ingress -n notificacoes notificacoes-admin
kubectl delete -f notificacoes.yaml

# 2. So entao derrube o que o Terraform administra: cluster, perfil Fargate,
#    as tres roles IAM novas, o provedor OIDC.
terraform destroy -auto-approve

# 3. O CLUSTER as vezes demora minutos para deixar de existir de fato — e a
#    taxa do control plane corre ate esse instante, nao ate o `destroy` sair.
aws eks describe-cluster --name "${PROJETO}-eks" --region "$REGIAO" 2>&1 \
  | grep -q "ResourceNotFoundException" && echo "cluster removido" \
  || echo "cluster ainda existindo — cobrando"

# 4. O provedor OIDC as vezes sobrevive ao cluster se algo falhar no meio.
aws iam list-open-id-connect-providers --query 'OpenIDConnectProviderList[].Arn' --output table

# 5. O grupo de logs do controller tem ciclo proprio, como no L03.
aws logs delete-log-group --log-group-name "/aws/eks/${PROJETO}-eks/cluster" 2>/dev/null || true

# 6. O que veio do L31/L33 e continua cobrando: a fila, a ALB do desenho ECS,
#    o RDS. Rode a limpeza deles tambem se nao for seguir para outro laboratorio.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab \
  --query "ResourceTagMappingList[].ResourceARN" --output table