AWS em 2025: coisas que você acha que sabe, mas agora estão erradas

• Os serviços principais da AWS estão evoluindo rapidamente
• Recursos importantes como EC2, S3 e Lambda agora oferecem desempenho e flexibilidade que superam as expectativas dos usuários em relação ao passado
• Também houve muitas mudanças e otimizações em áreas como rede, autenticação e redução de custos
• Posts de blog antigos ou informações desatualizadas podem causar confusão
• Entender as atualizações mais recentes e as políticas alteradas é essencial para usar bem a AWS

---

AWS 2025: o presente mudou em relação à visão do passado

• A AWS é uma plataforma de nuvem com quase 20 anos de história e, por isso, o “senso comum” sobre seus serviços continua mudando
• Até mesmo usuários antigos têm dificuldade para acompanhar a velocidade das mudanças, de tanto que os recursos centrais foram melhorados
• Ainda existem muitos posts de blog com informações antigas, então é importante entender corretamente o que mudou na configuração real

EC2

• Agora é possível alterar security groups e funções do IAM de instâncias EC2 sem interrupção
• É possível redimensionar, anexar e desanexar volumes EBS em instâncias em execução
• Hoje já é possível forçar a parada ou o encerramento de instâncias EC2, sem precisar esperar timeouts longos
• Foi introduzida a funcionalidade de migração ao vivo entre hosts físicos, tornando raros os alertas de degradação de desempenho da instância
• A confiabilidade das instâncias aumentou muito, e quase não acontece mais de uma instância desaparecer sem aviso como antigamente
• A variação de preço das instâncias Spot passou a ser mais gradual, reduzindo a necessidade de monitoramento em tempo real como se fosse um pregão
• Casos que realmente exigem instâncias dedicadas se tornaram extremamente raros (até o HIPAA BAA praticamente não exige isso há quase 10 anos)
• AMI Block Public Access vem ativado por padrão em contas novas (e, desde 2023, também se aplica a contas sem AMIs públicas há mais de 90 dias)

S3

• O S3 não é mais eventually consistent e agora oferece read-after-write consistency
• Já não é necessário aleatorizar o início das chaves de objeto, reduzindo preocupações com distribuição de dados e hotspots
• ACLs (Access Control Lists) não são mais recomendadas e vêm desativadas por padrão em buckets novos
• Buckets novos têm Block Public Access configurado por padrão
• A criptografia de dados armazenados é aplicada automaticamente
• Antes de o Glacier virar uma classe de armazenamento do S3, ele era um serviço separado, mas hoje está integrado; só restam vestígios disso em itens como a cobrança
• O custo e a velocidade de restauração do Glacier se tornaram bem mais previsíveis e baratos do que antes. Aquele medo antigo de custos assustadores de restauração já não corresponde à realidade

Rede (Networking)

• O EC2-Classic desapareceu completamente
• Endereços IPv4 públicos agora não são mais gratuitos e têm o mesmo custo de um Elastic IP
• Em vez de VPC Peering, surgiram opções melhores como Transit Gateway, compartilhamento de VPC/recursos e Cloud WAN
• Com VPC Lattice e Tailscale, é possível resolver problemas complexos de rede com mais facilidade
• O tempo para refletir atualizações no CloudFront caiu de 45 minutos para cerca de 5 minutos (embora ainda possa parecer demorado ao esperar por deploys do CloudFormation)
• O ELB Classic cobrava tráfego entre AZs, enquanto o ALB cobra apenas LCUs. Já o NLB ainda cobra tráfego entre AZs, e isso exige atenção
• O Network Load Balancer passou a oferecer suporte a security groups
• Os IDs de zonas de disponibilidade (Availability Zone) variavam entre contas, mas agora é possível alinhar os Zone IDs com o Resource Access Manager

Lambda

• O tempo máximo de execução do Lambda foi de 5 minutos para 15 minutos, com suporte adicional a imagens de contêiner (Docker), armazenamento compartilhado via EFS, até 10 GB de RAM e /tmp de 10 GB
• A velocidade de invocação do Lambda dentro de VPCs melhorou bastante
• O problema de cold start foi bastante reduzido em comparação com o passado

EFS

• O ajuste de desempenho de I/O do EFS agora pode ser controlado separadamente da capacidade, eliminando a necessidade de preencher espaço com dados inúteis

EBS

• Novos volumes EBS podem usar desempenho máximo imediato se não tiverem dados de base
• Volumes criados a partir de snapshots podem ficar lentos na primeira leitura dos dados, por isso é recomendável ler o disco inteiro uma vez (embora também existam opções mais rápidas)
• Volumes io1 podem ser conectados simultaneamente a várias instâncias EC2, mas isso só é recomendado em situações muito específicas

DynamoDB

• Agora passou a permitir campos vazios nos itens
• O desempenho ficou muito mais estável, reduzindo a necessidade de monitorar hot keys com ferramentas separadas como no passado
• Com as mudanças de pricing, para a maioria dos usuários o modo On-Demand é mais razoável

Opções de economia de custos (Cost Savings Vehicles)

• Reserved Instances estão sendo gradualmente descontinuadas, e os Savings Plans são o padrão daqui para frente. O desconto dos Savings Plans caiu em relação aos RIs, mas a flexibilidade aumentou
• O uso de EC2 é cobrado por segundo, então ligar instâncias por períodos muito curtos também pode ser eficiente em custo
• O Cost Anomaly Detector detecta padrões inesperados de uso com excelente precisão e é gratuito
• O Compute Optimizer oferece recomendações confiáveis para diversos recursos, incluindo EBS. Já as recomendações do Trusted Advisor ainda carecem de consistência

Autenticação (Authentication)

• A concessão de permissões via funções do IAM é a abordagem recomendada, enquanto usuários IAM servem mais para aplicações legadas
• O IAM Identity Center substitui o AWS SSO e é usado para acesso às contas, o que ainda causa alguma confusão
• É possível registrar múltiplos dispositivos MFA na conta root
• Não é necessário configurar credenciais root separadas para contas-membro da organização

Outros (Miscellaneous)

• A confiabilidade e a durabilidade da us-east-1 melhoraram muito em relação ao passado. Interrupções frequentes como as de antigamente agora já seriam notícia
• A descontinuação (deprecation) de serviços AWS ainda é rara, mas está aumentando, então vale considerar isso ao depender de serviços menores
• O problema de o último ponto dos dados do CloudWatch aparecer anormalmente baixo por inconsistência não acontece mais
• A conta root agora também pode encerrar (fechar) diretamente contas-membro da organização AWS

[roxie]

Uau, mudou muito mesmo

[howudoin]

Agora não dá mais para escolher e usar um único serviço da AWS.
Se você quer fazer qualquer coisa, precisa conectar e usar várias coisas juntas.
Definitivamente não é simples.
Para usar numa startup, você precisa gastar não só com a nuvem, mas também com mão de obra de DevOps.
Para construir direito, a carga de trabalho aumenta tanto que chega ao ponto de consumir todo o tempo de desenvolvimento.
Além disso, há cada vez mais casos em que usar serviços gerenciados é melhor, então no nível do código você já fica dependente da plataforma.

[GN⁺]

Opiniões no Hacker News

• Ao ver que o "Block Public Access" do S3 agora é aplicado por padrão a novos buckets, achei uma decisão obviamente correta; houve muitos vazamentos enormes de dados por causa de buckets S3 mal configurados. Mas às vezes eu quero criar um bucket S3 com permissão de leitura pública para servir arquivos publicamente, e toda vez algo muda, a receita antiga deixa de funcionar e eu tenho que estudar tudo de novo do zero.
  • Eu diria para prestar bastante atenção na configuração de "Block Public Access". Isso é uma espécie de proteção para impedir que as pessoas cometam erros graves. Mesmo que você configure uma bucket policy muito fraca ou uma ACL (antiga, mas ainda usada), se o Block Public Access estiver ativado, o acesso público fica impossível. Por outro lado, se você desativar o Block Public Access e usar uma política de bucket muito bem projetada, tudo bem também. A bucket policy determina integralmente quem pode acessar. Claro, no longo prazo a política pode mudar por acidente, um papel IAM pode ser adicionado inesperadamente ou a trust policy pode ser alterada, então é importante administrar isso.
  • Eu uso LLM com frequência nesses casos. Peço para ler a documentação e extrair o código de demonstração espalhado pela documentação oficial da AWS. Depois que obtenho isso, também peço na hora as modificações personalizadas que quero.
  • Isso me dá uma sensação de déjà vu, como se já tivéssemos feito isso antes. Há 10 anos todo mundo também deixava buckets abertos, então parece que já tomaram medidas assim antes.
  • Por causa dessas mudanças, a pergunta de entrevista "você conhece essa tecnologia?" fica muito ambígua. A tecnologia muda todo mês, então dá vontade de perguntar: conhece com base em quando?
  • Para aprender oficialmente, eles até deixam você pagar $250 e fazer uma prova de certificação.
• Já era possível, há alguns anos, trocar security groups ou papéis IAM no EC2 sem encerrar a instância. Instâncias spot no passado eram um mercado de lances, mas agora os lances desapareceram, então ficou muito melhor porque não há mais oscilações bruscas de preço nem situações em que só certos usuários conseguem acesso. E antes diziam que era preciso aleatorizar o prefixo das chaves de objetos para evitar hotspots, mas isso não é mais necessário. Levei um bom tempo para convencer meus colegas, mas no fim eles só armazenavam arquivos minúsculos que nem tinham relação com gargalos de backend no S3. O Lambda antes tinha limite de 5 minutos e nem suportava imagens de contêiner; agora suporta runtime de 15 minutos, imagens Docker, compartilhamento via EFS, até 10 GB de RAM e 10 GB de armazenamento em /tmp. Uma coisa que eu também percebi é que o escopo global do Python sobrevive como o /tmp.
• Restaurar do Glacier não precisa mais ser dolorosamente lento. No estilo Amazon de imaginar as coisas, eu achava que o Glacier antigo devia realmente rodar em algum depósito logístico da Amazon. Quando você pedia dados, parecia que um funcionário ia pegar uma mídia removível da prateleira e conectá-la ao servidor. Era parecido com o método de backup em fita dos antigos sistemas de time-sharing; naquela época era preciso trocar fisicamente as fitas.
  • Na prática, acho bem provável que usassem equipamento automatizado, tipo robôs de fita. Exemplo em foto relacionada. Em vez de uma pessoa, um robô pega a fita, coloca no drive, avança até o offset, lê, rebobina e devolve. A latência vem de localizar a fita, rebobinar e esperar o drive. Imagino que, por eficiência, processassem todos os pedidos daquela fita antes de removê-la.
  • Não posso falar sobre detalhes internos, mas nunca vi ninguém acertar exatamente como o Glacier foi projetado. Eu também estive na AWS antigamente, e posso dizer que o Glacier operava nos mesmos datacenters que os outros serviços da AWS. Em engenharia e gestão de produto, o importante é administrar bem a expectativa do cliente. Se você diz que o limite de upload é 10, mas deixa subir 12, o cliente passa a esperar sempre 12. Gerenciar expectativas é importante.
  • Como discos rígidos são uniformes, imagino que esse tipo de armazém seja automatizado com robôs. Onde se usa pessoas é no tratamento de itens fora do padrão, com tamanhos e formatos variados.
  • De qualquer forma, esse tipo de equipamento já é robotizado há décadas.
• Eu não consigo mais fazer login na minha conta AWS porque não ativei MFA antes. Para emitir um dispositivo, preciso primeiro fazer login. Eu já tinha ouvido o aviso antes, mas é bem frustrante que a estrutura não permita solicitar um dispositivo MFA sem login.
  • Acho que vale entrar em contato com o suporte.
    Contato com o AWS Support
  • Parece o tipo de problema que o suporte resolveria facilmente.
• Acho que deve haver muita gente como eu: em vez de seguir o jeito AWS — a complexidade de ajustar API Gateway, Lambda serverless e ainda papéis IAM — agora dá vontade de largar isso e simplesmente usar EC2 ou LightSail VPS, um bucket S3, conectar o domínio com Route53 e não me preocupar com o resto.
  • Se você vai usar só storage + VPS, um VPS tradicional sai bem mais barato que AWS. Minha filosofia, ao contrário, é que se você vai usar AWS, então deve usar de verdade e bastante. Delegar ao máximo para a Amazon para ganhar eficiência e reduzir custos. Step Functions, Lambda e DynamoDB também superaram alternativas. O que acho uma pena é que os desenvolvedores não pensam tanto quanto deveriam em otimizar o uso do fornecedor.
  • Na prática, muitas empresas também simplificaram sua nuvem, por causa de restrições regionais de serviço ou da previsibilidade da cobrança.
  • Gerenciar IAM consome tanto tempo que a sensação é de que o tempo que antes ia para administração de sistemas agora vai todo para gerenciar permissões. IAM é tão difícil que, na prática, dá prejuízo líquido. Parece haver um ponto ideal entre VPS e o excesso de least privilege no serverless. Fargate parece um candidato, então quero continuar migrando e experimentando.
• Em vez de lançar um monte de coisas dispersas em IA tentando acompanhar outras áreas, eu gostaria que a AWS se concentrasse mais nos "serviços básicos, mas importantes" em que sempre foi boa. A liderança da AWS parece ter perdido a direção em GenAI, mas continua boa em infraestrutura básica. Por causa da IA, parece estar em pânico, e para o cliente isso fica disperso e incômodo.
  • A direção da liderança atual é tornar a infraestrutura algo em que qualquer pessoa possa simplesmente escolher um modelo e usar imediatamente. Buscam um ambiente utilizável na hora, sem complexidade de setup.
• É realmente absurdo que, mesmo quando o bucket S3 está na mesma região que a VPC, se você passa pela internet pública acaba pagando NAT Gateway. O padrão deveria ser opt-out, não opt-in. Imagino que o padrão atual exista porque a AWS ganha receita extra com essa estrutura. Pouquíssimos usuários devem realmente querer o caminho atual.
  • Isso foi projetado considerando que segurança é o padrão. Sem configurar NAT Gateway, VPC Gateway Endpoint (S3) ou alguma outra saída para a internet, a workload não consegue acessar o S3. O correto é a rede ficar fechada, e se o usuário cria algo sem entender bem os caminhos, a responsabilidade é do cliente. É melhor pensar que a AWS só fornece ferramentas brutas de Infrastructure as a Service (IaaS).
  • O S3 VPC Gateway Endpoint existe exatamente para isso, e é gratuito.
    Documentação oficial da AWS
  • Depois que você configura VPC, subnets, endpoints do PrivateLink e tudo mais, isso realmente parece ridículo. Até se esforçaram para dar o nome PrivateLink (embora tecnicamente faça sentido), mas acho que isso deveria existir por padrão, sem setup nenhum. Aliás, se você usa subnets privadas, não é o PrivateLink o único jeito de acessar S3 e afins? Parece estranho.
  • Acho que todos os VPC endpoints deveriam ser aplicados gratuitamente por padrão. Cobrar extra até para usar a API do próprio serviço é um pouco demais.
  • O objetivo disso é diferenciação de preço. Clientes menos sensíveis a preço nem se preocupam. Quem se preocupa tenta reduzir custos, e mesmo nessas situações muitas vezes ainda acaba precisando usar AWS.
• Esse artigo me deixou tranquilo. Eu sempre me preocupo com a possibilidade de a Amazon mudar algo grande e forçar migração, mas desde 2013 venho usando instâncias EC2 quase sem precisar gerenciá-las, então é bom saber que não houve mudanças inesperadas.
• É chocante saber que no passado as Availability Zones eram mapeadas aleatoriamente por conta.
  • Isso era para balanceamento de carga. Se várias contas fixassem uma AZ específica como 1b, por exemplo, o objetivo era garantir que a distribuição física real ficasse equilibrada. Depois passaram a fornecer nomes canônicos por AZ, provavelmente porque as contas que criavam hotspots e as contas que precisavam de metadados eram diferentes.
  • Acho que a ideia era evitar que, com a configuração padrão, todo mundo escolhesse us-east-1a e concentrasse tudo em uma AZ específica.
  • No começo isso ajudava no balanceamento, mas quando era preciso conectar redes entre várias contas (PrivateLink e afins), era confuso ter que verificar manualmente qual AZ correspondia a qual. Então criamos uma metodologia de mapeamento um a um por conta e até uma tabela interna de consulta, mas depois a AWS adicionou zone IDs aos metadados e ficou fácil consultar.
  • Já sofri bastante por causa dessa política.
• Tem uma coisa que eu queria corrigir: todo esse conhecimento inútil pode virar de cabeça para baixo.
  Weird Al: Everything You Know is Wrong
  Firesign Theatre: Everything You Know is Wrong