Serverless e contêineres

Pontos-chave

• Memória e CPU: de 128 MB a 10.240 MB, em passos de 1 MB. A CPU é alocada na proporção da memória, e 1.769 MB equivalem a 1 vCPU. Mais memória é a principal alavanca para funções limitadas por CPU ou rede.
• Timeout: até 900 segundos (15 minutos) por invocação.
• Payloads: 6 MB para requisição e resposta síncronas, 1 MB para eventos assíncronos. Variáveis de ambiente somam até 4 KB.
• Empacotamento: .zip de até 50 MB compactado e 250 MB descompactado com layers, ou imagem de contêiner de até 10 GB. /tmp de 512 MB a 10.240 MB.
• Layers: até 5 por função, extraídas em /opt, para compartilhar bibliotecas entre funções. Só para funções .zip, não para imagens de contêiner.
• Ajuste: o AWS Lambda Power Tuning e o AWS Compute Optimizer ajudam a escolher a memória.

Pontos-chave

• Reserved concurrency: uma fatia do pool que é ao mesmo tempo o mínimo garantido e o máximo da função. Protege funções críticas ou limita uma que sobrecarregaria um recurso a jusante. Sem custo.
• Provisioned concurrency: ambientes de execução pré-inicializados que respondem sem cold start. Tem custo adicional e pode seguir agenda ou utilização via Application Auto Scaling.
• Limites: cada função escala até 1.000 ambientes de execução a cada 10 segundos. O Lambda mantém 100 unidades sem reserva, então só 900 das 1.000 padrão podem ser reservadas. As requisições por segundo ficam limitadas a 10 vezes a concorrência.
• SnapStart: tira um snapshot do ambiente inicializado ao publicar uma versão e retoma a partir dele, com inicialização que pode ficar abaixo de 1 segundo. Java 11+, Python 3.12+ e .NET 8+. Gratuito no Java, com cobrança de cache e restauração nos demais.
• Limites do SnapStart: só em versões publicadas e sem combinar com provisioned concurrency, EFS ou /tmp acima de 512 MB.

Pontos-chave

• Triggers (push): S3, SNS, API Gateway e outros invocam a função assim que o evento acontece. O trigger é configurado e guardado no serviço de origem.
• Event source mappings (poll): pollers do Lambda leem SQS, Kinesis, DynamoDB, Amazon MSK, Kafka autogerenciado, Amazon MQ e DocumentDB e invocam a função com lotes de registros.
• Lotes: um lote fecha ao atingir o batch size, a batching window (0 a 300 segundos) ou 6 MB de payload. Lotes maiores diluem o custo de cada invocação e aumentam o throughput.
• Pelo menos uma vez: mappings podem processar um registro mais de uma vez, então o handler precisa ser idempotente. Em erro, lotes de stream são reprocessados e o shard pausa para manter a ordem.
• Provisioned mode: pollers dedicados com mínimo e máximo para mappings de SQS, Amazon MSK e Kafka, quando a latência precisa ser constante. Tem custo adicional.

Pontos-chave

• Amazon ECS: orquestrador nativo da AWS, sem control plane para operar. A task definition é a planta, a task a executa e o service mantém o número desejado de tasks rodando.
• Amazon EKS: control plane Kubernetes gerenciado e certificado como conformante. Reaproveita manifests, ferramentas e conhecimento de Kubernetes e mantém as cargas portáveis.
• EKS Auto Mode: a AWS também gerencia os nós, incluindo provisionamento, escolha de instância, escala e patches do sistema operacional.
• Escala: o Service Auto Scaling do ECS muda o número de tasks, e o Cluster Auto Scaling muda as instâncias EC2 registradas no cluster.
• Custo: a orquestração do ECS não tem cobrança adicional. O EKS cobra por cluster, além da computação.

Pontos-chave

• Fargate: você define CPU e memória por task, e cada task tem seu próprio limite de isolamento, sem compartilhar kernel, CPU, memória ou interface de rede. Cobrança por segundo de vCPU, memória e armazenamento, com mínimo de 1 minuto no Linux.
• Tamanhos de task: de 0,25 vCPU com 512 MiB até 32 vCPU com 244 GB no Linux. 20 GB de armazenamento efêmero estão incluídos.
• Rede: sempre no modo awsvpc, com uma interface de rede por task, então os target groups do load balancer usam o target type ip.
• Fargate Spot: até 70% de desconto para tasks ECS que toleram interrupção, com aviso de 2 minutos. Só Linux.
• Launch type EC2: você gerencia instâncias, AMIs e capacidade do cluster e, em troca, tem GPUs, contêineres privilegiados e qualquer tipo de instância, nada disso suportado no Fargate.

Pontos-chave

• Registry: repositórios privados com permissões baseadas em recurso no IAM, mais o ECR Public. Imagens Docker, imagens OCI e artefatos OCI.
• Image scanning: scan on push para encontrar vulnerabilidades de software em cada imagem nova.
• Lifecycle policies: regras que limpam imagens sem uso, testáveis antes de valerem.
• Replicação e cache: replicação entre Regiões e entre contas, e regras de pull through cache que mantêm imagens de registries externos no seu registry privado.
• Conteinerização: empacote a aplicação e suas dependências em uma imagem, envie ao ECR, descreva-a em uma task definition ou pod spec e rode no Fargate ou no EC2. A mesma imagem roda igual em todo ambiente.
• Pull privado: tasks em subnets privadas baixam imagens do ECR por um interface VPC endpoint, sem NAT gateway.

Pontos-chave

• ECS Anywhere: registra servidores ou VMs locais como instâncias externas de um cluster ECS (launch type EXTERNAL) por meio do SSM Agent. Cobrança por instância registrada por hora.
• Limites do ECS Anywhere: sem balanceamento de carga, sem service discovery, sem modo awsvpc e sem volumes EFS. Melhor para cargas que geram tráfego de saída ou processam dados.
• EKS Anywhere: cria e opera clusters Kubernetes na sua infraestrutura (VMware vSphere, bare metal, Nutanix, AWS Snow), inclusive sem conexão com a internet. Open source e gratuito, com Enterprise Subscriptions opcionais.
• EKS Distro: a distribuição Kubernetes usada pelo Amazon EKS e a base do EKS Anywhere.
• EKS Hybrid Nodes: servidores locais e de borda que entram como nós de um cluster Amazon EKS.

Pontos-chave

• Lambda: tráfego orientado a eventos ou imprevisível, tarefas abaixo de 15 minutos, pagamento por requisição e duração, sem sistema operacional ou runtime para gerenciar.
• Fargate: serviços ou jobs longos em contêiner sem servidores para gerenciar, com qualquer linguagem ou binário dentro da imagem.
• ECS ou EKS no EC2: GPUs, tipos de instância específicos, acesso privilegiado ou controle total dos hosts.
• Desacoplamento: coloque SQS, SNS ou EventBridge entre os componentes para que cada camada escale sozinha pela própria métrica.
• AWS Serverless Application Repository: publica e implanta aplicações serverless reutilizáveis, definidas em templates AWS SAM, compartilhadas publicamente ou com contas específicas. Sem custo além dos recursos implantados.