Lab 26 — API 100% serverless, e onde ela não serve

# Rode ANTES de mudar qualquer coisa. Compara RequestCount do ALB de homolog
# com o tempo que a task ficou reservada na mesma janela.
aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
  --metric-name RequestCount --dimensions Name=LoadBalancer,Value="$ARN_ALB_HOMOLOG" \
  --start-time "$(date -u -d -7days +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 86400 --statistics Sum --query "Datapoints[].Sum" --output text
# Na Cadencia, sete dias: 214 requisicoes no total, contra 604.800 segundos de
# task reservada. Menos de 40 requisicoes por dia em media — e dois dos sete
# dias, ZERO. A task nao soube da diferenca.

// Trecho do log de acesso do API Gateway (formato declarado em apigateway.tf).
// E o dado que prova a cadeia de latencia, em vez de supor qual camada pesa.
{
  "requestId": "a1b2c3d4-...",
  "routeKey": "GET /api/pedidos/{id}",
  "status": "200",
  // Tempo so da chamada a Lambda — inclui Init quando o ambiente esta frio.
  "integrationLatency": "812",
  // Tempo TOTAL, do ponto de vista do cliente — borda incluida.
  "responseLatency": "841"
}
// A diferenca (841 - 812 = 29 ms) e o que o proprio Gateway gasta resolvendo
// rota e formatando resposta — pequena aqui, mas e a parcela que cresce se um
// dia entrar um autorizador ou transformacao de payload no meio.

# apigateway.tf — a borda sem plano de uso, porque nao ha parceiro aqui

# HTTP API, nao REST API: a distincao que o L11 fixou por causa de cota de
# parceiro se aplica ao contrario aqui. Sem plano de uso a administrar, o tipo
# mais barato e tambem o que menos coisa ha para configurar errado.
resource "aws_apigatewayv2_api" "pedidos" {
  name          = "${var.projeto}-pedidos-serverless"
  protocol_type = "HTTP"
}

# Integracao PROXY: o Gateway repassa o payload inteiro (metodo, path, query,
# corpo) e devolve a resposta da funcao sem reformatar nada no meio. E o modo
# que exige menos configuracao de mapeamento, e o unico que este modulo usa.
resource "aws_apigatewayv2_integration" "pedidos" {
  api_id                 = aws_apigatewayv2_api.pedidos.id
  integration_type       = "AWS_PROXY"
  integration_uri        = aws_lambda_function.leitura_pedido.invoke_arn
  payload_format_version = "2.0"
}

resource "aws_apigatewayv2_route" "get_pedido" {
  api_id    = aws_apigatewayv2_api.pedidos.id
  route_key = "GET /api/pedidos/{id}" # a MESMA rota que o ALB do L01/L03 sempre serviu
  target    = "integrations/${aws_apigatewayv2_integration.pedidos.id}"
}

resource "aws_apigatewayv2_stage" "producao" {
  api_id      = aws_apigatewayv2_api.pedidos.id
  name        = "$default"
  auto_deploy = true

  # A primeira linha de defesa contra rajada: nao e cota de parceiro (nao ha
  # parceiro), e sim protecao de conta contra pico que estoura a concorrencia
  # da Lambda ou vira fatura inesperada — o "ataque de negacao de carteira"
  # da secao de seguranca. O padrao da conta e mais alto; aqui e explicito.
  default_route_settings {
    throttling_burst_limit = 100
    throttling_rate_limit  = 50
  }

  access_log_settings {
    destination_arn = aws_cloudwatch_log_group.acesso_apigw.arn
    # integrationLatency e responseLatency sao os dois numeros que provam a
    # cadeia de latencia: o primeiro e so a chamada a Lambda; o segundo e o
    # que o cliente sente, borda incluida.
    format = jsonencode({
      requestId         = "$context.requestId"
      routeKey           = "$context.routeKey"
      status              = "$context.status"
      integrationLatency  = "$context.integrationLatency"
      responseLatency     = "$context.responseLatency"
    })
  }
}

resource "aws_cloudwatch_log_group" "acesso_apigw" {
  name              = "/aws/apigateway/${var.projeto}-pedidos-serverless"
  retention_in_days = 30
}

# Politica de RECURSO, nao papel assumido: e assim que o API Gateway invoca
# Lambda. E diferente do EventBridge Scheduler do L21, que usa uma role IAM
# propria — cada servico de origem tem seu proprio mecanismo de "quem pode
# chamar", e confundir os dois e um erro comum de quem generaliza cedo demais.
resource "aws_lambda_permission" "apigw_invoca" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.leitura_pedido.function_name
  principal     = "apigateway.amazonaws.com"
  # Escopado a ESTA api e a ESTA rota: nao "*", nao a api inteira sem rota.
  source_arn = "${aws_apigatewayv2_api.pedidos.execution_arn}/*/GET/api/pedidos/{id}"
}

output "url_api_serverless" {
  value       = aws_apigatewayv2_stage.producao.invoke_url
  description = "URL da rota GET /api/pedidos/{id}, servida por API Gateway + Lambda"
}

# lambda.tf — a funcao sem VPC, e a permissao estreita a uma Query so

data "aws_iam_policy_document" "execucao_assume" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "execucao" {
  name               = "${var.projeto}-leitura-pedido-execucao"
  assume_role_policy = data.aws_iam_policy_document.execucao_assume.json
}

# So Query na tabela do L16, e so escrita no proprio log. Nao ha PutItem,
# UpdateItem nem DeleteItem aqui — esta funcao LE; quem escreve continua
# sendo o outbox do L14/L16, alimentado pelo Aurora.
data "aws_iam_policy_document" "execucao_permissoes" {
  statement {
    effect    = "Allow"
    actions   = ["dynamodb:Query"]
    resources = [data.aws_dynamodb_table.pedidos.arn]
  }
  statement {
    effect    = "Allow"
    actions   = ["logs:CreateLogStream", "logs:PutLogEvents"]
    resources = ["${aws_cloudwatch_log_group.funcao.arn}:*"]
  }
}

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

# A tabela e um DATA SOURCE, nao um recurso novo: e a MESMA `pedidos_cadencia`
# que o L16 modelou e o outbox do L14 alimenta. Recriá-la aqui duplicaria a
# fonte de leitura e é exatamente o "repetir em vez de reaproveitar" que o
# briefing deste laboratório pede para evitar.
data "aws_dynamodb_table" "pedidos" {
  name = "${var.projeto}-pedidos-cadencia"
}

resource "aws_cloudwatch_log_group" "funcao" {
  name              = "/aws/lambda/${var.projeto}-leitura-pedido"
  retention_in_days = 30
}

resource "aws_lambda_function" "leitura_pedido" {
  function_name = "${var.projeto}-leitura-pedido"
  role          = aws_iam_role.execucao.arn
  handler       = "LeituraPedido::LeituraPedido.Function::FunctionHandler"
  runtime       = "dotnet8"
  architectures = ["arm64"]
  filename      = data.archive_file.pacote.output_path
  timeout       = 10 # bem abaixo do teto de 900 s: e leitura, nao processamento de longa duracao
  memory_size   = 512 # ponto de partida; a secao de provas mede e ajusta

  # NENHUM vpc_config, pela mesma razao do L21: o destino (DynamoDB) e
  # regional. Anexar VPC aqui so acrescentaria ENI ao Init sem beneficio, e
  # consumiria da cota de 500 ENIs por VPC — que voce vai precisar inteira o
  # dia em que uma rota de verdade precisar de RDS atras desta funcao.

  # Protege o RESTANTE da conta: sem este teto, um pico nesta funcao pode
  # consumir toda a concorrencia de 1.000 compartilhada com outras funcoes.
  # E a resposta de infraestrutura ao risco de "negacao de carteira" da secao
  # de seguranca — throttle na borda contem o CLIENTE; isto contem A CONTA.
  reserved_concurrent_executions = 50

  environment {
    variables = {
      TABELA_PEDIDOS = data.aws_dynamodb_table.pedidos.name
    }
  }

  tracing_config {
    mode = "Active" # X-Ray separa integrationLatency (borda) de Init/Invoke (funcao)
  }
}

output "nome_funcao_leitura" {
  value       = aws_lambda_function.leitura_pedido.function_name
  description = "usado nos comandos de prova, para filtrar log e medir cold start"
}

// Function.cs — le a chave base do L16, sem tocar em nenhuma escrita

using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.Model;
using Amazon.Lambda.APIGatewayEvents;
using Amazon.Lambda.Core;
using Amazon.Lambda.RuntimeSupport;
using Amazon.Lambda.Serialization.SystemTextJson;
using System.Text.Json;
using System.Text.Json.Serialization;

namespace LeituraPedido;

public class Function
{
    // ── CODIGO ESTATICO: roda uma vez por ambiente, dentro do Init ───────────
    // O cliente do DynamoDB e criado AQUI, igual ao padrao do L21 com o S3. E
    // o motivo de o Init desta funcao ser dominado por Function init, nao por
    // Runtime init: abrir o cliente e resolver credencial e o trabalho real.
    private static readonly AmazonDynamoDBClient _ddb = new();
    private static readonly string _tabela =
        Environment.GetEnvironmentVariable("TABELA_PEDIDOS")!;

    private static async Task Main()
    {
        Func<APIGatewayHttpApiV2ProxyRequest, ILambdaContext, APIGatewayHttpApiV2ProxyResponse> handler
            = FunctionHandler;
        await LambdaBootstrapBuilder.Create(handler,
                new SourceGeneratorLambdaJsonSerializer<ContextoSerializacao>())
            .Build()
            .RunAsync();
    }

    // ── HANDLER: roda a cada invocacao, quente ou fria ────────────────────────
    public static async Task<APIGatewayHttpApiV2ProxyResponse> FunctionHandler(
        APIGatewayHttpApiV2ProxyRequest evento, ILambdaContext ctx)
    {
        // Instrumento do laboratorio, igual ao L21: torna o cold start
        // OBSERVAVEL na propria linha de log, sem depender so do REPORT.
        ctx.Logger.LogInformation(
            $"inicio do handler, ambiente ativo ha {Environment.TickCount64} ms");

        if (!evento.PathParameters.TryGetValue("id", out var id) || !Guid.TryParse(id, out _))
        {
            return Responder(400, new { erro = "id invalido" });
        }

        // Query na CHAVE BASE, exatamente como o L16 modelou: PK = PEDIDO#<id>,
        // sem condicao de SK. Devolve o cabecalho (SK=METADADOS) e todos os
        // itens (SK=ITEM#<n>) na MESMA chamada, porque os dois moram na mesma
        // particao — a decisao que este modulo reaproveita, nao repete.
        var resp = await _ddb.QueryAsync(new QueryRequest
        {
            TableName              = _tabela,
            KeyConditionExpression = "PK = :pk",
            ExpressionAttributeValues = new Dictionary<string, AttributeValue>
            {
                [":pk"] = new AttributeValue { S = $"PEDIDO#{id}" },
            },
        });

        if (resp.Items.Count == 0)
        {
            return Responder(404, new { erro = "pedido nao encontrado" });
        }

        var cabecalho = resp.Items.First(i => i["SK"].S == "METADADOS");
        var itens = resp.Items.Where(i => i["SK"].S.StartsWith("ITEM#")).Count();

        // Mesmo FORMATO que a API em ECS Fargate sempre devolveu — o contrato
        // nao muda; so a hospedagem por tras dele mudou. E a prova de
        // paridade funcional que a secao de implantacao vai medir.
        return Responder(200, new
        {
            id,
            total = decimal.Parse(cabecalho["total"].N),
            status = cabecalho["status"].S,
            itensCount = itens,
        });
    }

    private static APIGatewayHttpApiV2ProxyResponse Responder(int status, object corpo) => new()
    {
        StatusCode = status,
        Headers = new Dictionary<string, string> { ["Content-Type"] = "application/json" },
        Body = JsonSerializer.Serialize(corpo),
    };
}

[JsonSerializable(typeof(APIGatewayHttpApiV2ProxyRequest))]
[JsonSerializable(typeof(APIGatewayHttpApiV2ProxyResponse))]
public partial class ContextoSerializacao : JsonSerializerContext
{
}

#!/usr/bin/env bash
# medir-cruzamento.sh — coleta os numeros REAIS dos dois lados; o preco por
# unidade voce busca no Pricing Calculator para a sua regiao e cola abaixo.
set -euo pipefail

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

echo "== lado Fargate: quanto tempo a task ficou reservada =="
# Em homologacao com 1 task, o tempo ligado e simplesmente a janela medida —
# a task nao escala. Em producao, some o tempo de CADA task (elas se sobrepoem).
aws cloudwatch get-metric-statistics \
  --namespace ECS/ContainerInsights --metric-name TaskCount \
  --dimensions Name=ClusterName,Value="$PROJETO" \
  --start-time "$(date -u -d "-${JANELA_HORAS} hours" +%FT%TZ)" \
  --end-time "$(date -u +%FT%TZ)" --period 3600 --statistics Average \
  --region "$REGIAO" --query 'Datapoints[].Average'

echo "== lado serverless: quantas invocacoes, e a duracao media =="
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda --metric-name Invocations \
  --dimensions Name=FunctionName,Value="${PROJETO}-leitura-pedido" \
  --start-time "$(date -u -d "-${JANELA_HORAS} hours" +%FT%TZ)" \
  --end-time "$(date -u +%FT%TZ)" --period 3600 --statistics Sum \
  --region "$REGIAO" --query 'Datapoints[].Sum'

aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda --metric-name Duration \
  --dimensions Name=FunctionName,Value="${PROJETO}-leitura-pedido" \
  --start-time "$(date -u -d "-${JANELA_HORAS} hours" +%FT%TZ)" \
  --end-time "$(date -u +%FT%TZ)" --period 3600 --statistics Average \
  --region "$REGIAO" --query 'Datapoints[].Average'

# A partir daqui, aritmetica: cole os precos unitarios do Pricing Calculator
# (vCPU-hora, GB-hora, milhao de requisicoes, GB-segundo da Lambda, unidade
# de leitura do DynamoDB) e resolva n* = custo_fargate / custo_marginal.
# NENHUM valor de preco esta neste script de proposito — ele envelhece mais
# rapido do que este laboratorio, e varia por regiao.
echo "cole os precos da sua regiao no Pricing Calculator e resolva n*"

# provas.sh — cinco medicoes; nenhuma conclusao vem de "parece mais barato"

PROJETO=ffv-lab-serverless; REGIAO=us-east-1
FUNCAO="${PROJETO}-leitura-pedido"

# ── Prova 1: o Fargate cobra em homolog mesmo sem requisicao ─────────────────
# RequestCount do ALB no periodo, contra o tempo que a task ficou ligada.
aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
  --metric-name RequestCount --start-time "$(date -u -d -24hours +%FT%TZ)" \
  --end-time "$(date -u +%FT%TZ)" --period 3600 --statistics Sum \
  --region "$REGIAO" --query 'Datapoints[].Sum'
# Esperado na Cadencia: menos de 40 requisicoes em 24 h, contra 24 h inteiras
# de task reservada — a desproporcao que autoriza a migracao.

# ── Prova 2: a proporcao de chamadas que pagam cold start no padrao real ────
for i in $(seq 1 5); do
  aws lambda invoke --function-name "$FUNCAO" --region "$REGIAO" \
    --payload '{"rawPath":"/api/pedidos/00000000-0000-0000-0000-000000000001"}' \
    --cli-binary-format raw-in-base64-out /tmp/saida.json > /tmp/meta.json
  sleep 3
done
aws logs filter-log-events --log-group-name "/aws/lambda/${FUNCAO}" \
  --region "$REGIAO" --filter-pattern "REPORT" \
  --start-time "$(( $(date +%s%3N) - 120000 ))" \
  --query 'events[].message' --output text
# Esperado: a PRIMEIRA chamada traz Init Duration; com 3 s de intervalo, as
# seguintes tendem a cair no mesmo ambiente quente e nao trazer.

# ── Prova 3: a cadeia de latencia, medida em cada elo ─────────────────────────
aws logs filter-log-events \
  --log-group-name "/aws/apigateway/${PROJETO}-pedidos-serverless" \
  --region "$REGIAO" --filter-pattern '{ $.responseLatency > 0 }' \
  --query 'events[].message' --output text
# Esperado: responseLatency >= integrationLatency, sempre. A diferenca entre
# os dois e o que a borda gasta ALEM de chamar a funcao — mede, nao supoe.

# ── Prova 4: paridade funcional entre os dois modelos de hospedagem ─────────
ID=00000000-0000-0000-0000-000000000001
curl -s "https://$(terraform output -raw dominio_producao)/api/pedidos/${ID}" > /tmp/via-fargate.json
curl -s "$(terraform output -raw url_api_serverless)/api/pedidos/${ID}" > /tmp/via-serverless.json
diff <(jq -S . /tmp/via-fargate.json) <(jq -S . /tmp/via-serverless.json) \
  && echo "OK: mesmo contrato" || echo "FALHA: a hospedagem mudou a resposta"

# ── Prova 5: o teto de concorrencia, provocado de proposito ──────────────────
# Dispara 60 chamadas em paralelo contra uma funcao com reserved=50, para ver
# o 429 aparecer ANTES de tocar o teto de 1.000 da conta inteira.
seq 1 60 | xargs -P60 -I{} curl -s -o /dev/null -w '%{http_code}\n' \
  "$(terraform output -raw url_api_serverless)/api/pedidos/${ID}"
# Esperado: parte das respostas em 429. E o reserved_concurrent_executions
# fazendo o trabalho para o qual foi configurado — proteger o RESTO da conta.

# 1. Zere o servico ECS de homologacao ANTES de destruir — e o passo que
#    realmente gera a economia. Sem ele, os dois modelos convivem cobrando.
aws ecs update-service --cluster ffv-lab-homolog --service ffv-lab-homolog-api \
  --desired-count 0
aws ecs wait services-stable --cluster ffv-lab-homolog --services ffv-lab-homolog-api

# 2. Derrube o que este laboratorio administra.
terraform destroy -auto-approve

# 3. GRUPOS DE LOGS: log group da funcao e do acesso do API Gateway tem
#    retencao propria e sobrevivem ao servico que os alimentava.
aws logs delete-log-group --log-group-name /aws/lambda/ffv-lab-leitura-pedido 2>/dev/null || true
aws logs delete-log-group --log-group-name /aws/apigateway/ffv-lab-pedidos-serverless 2>/dev/null || true

# 4. NAO APAGUE a tabela pedidos_cadencia nem o outbox do L16/L14 — este
#    laboratorio so LEU dela. Ela continua servindo o L16 e qualquer outra
#    rota que dependa da mesma projecao.
echo "NAO rode aws dynamodb delete-table nesta tabela — ela pertence ao L16"

# 5. Prova final: nada com nome do projeto de pe, dos DOIS lados.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab-serverless \
  --query "ResourceTagMappingList[].ResourceARN" --output table
aws ecs describe-services --cluster ffv-lab-homolog --services ffv-lab-homolog-api \
  --query "services[0].desiredCount" --output text