O que eu aprendi tentando usar AWS depois do GCP

Em alguns ambientes, você já entra com portas, papéis e fluxos definidos; em outros, o primeiro passo inevitável é justamente estabelecer quem pode acessar o quê antes de qualquer trabalho acontecer.

Eu tinha um projeto que era basicamente um serviço HTTP que salva e escreve dados em um banco de dados NoSQL e que emite logs para monitoramento.

Pelo Google Cloud, o fluxo natural seria autenticar, selecionar o projeto, criar uma conta de serviço que vai ficar responsável pela função, adicionar a permissão datastore.user nessa conta e fazer o deploy. Pela CLI, cada passo desse é apenas um comando.

Decidi tentar replicar o mesmo fluxo na AWS como aprendizado, apesar do risco de configurar algo errado e ter que vender o rim pra pagar a fatura no final do mês. Comecei seguindo uma recomendação da própria AWS para evitar usar a conta root para tarefas de CLI e criar identidades com privilégios separados, então fui no IAM Identity Center e criei um usuário.

Ao tentar usar a CLI com ele, apareceu “No AWS accounts are available to you” (o que era esperado, inesperado seria se funcionasse de primeira). Acontece que eu precisava vincular esse usuário a uma conta AWS e definir um permission set. Na tela do permission set, haviam vários níveis de acesso a serem escolhidos, como AdministratorAccess, DatabaseAdministrator, DataScientist.

Aí que notei a primeira diferença entre as plataformas: no GCP, se trabalha dentro de um ambiente já parcialmente estruturado; na AWS, se começa praticamente do zero e precisa modelar explicitamente permissões antes de qualquer ação relevante. Escolhi começar com ViewOnlyAccess e ir evoluindo as permissões conforme encontrava erros de acesso, como forma de entender na prática o que cada serviço exigia.

Tentei criar uma tabela no DynamoDB, mas precisava da permissão dynamodb:CreateTable. A partir daí, fui organizando meu modelo mental não mais em termos de serviços, mas em termos de identidades. Aí que veio a segunda diferença: no GCP, eu pensava principalmente no que a aplicação fazia; na AWS, precisei pensar primeiro em quem está fazendo cada ação.

Acabei separando três tipos de perfis: um para administrar a infraestrutura (criar tabelas e configurar API), um para deploy (atualizar código) e um para apenas consulta (ler logs e linhas do banco). Já para as identidades de workload (os próprios serviços da AWS interagindo entre si), separei somente uma única role que definia o que a função Lambda podia fazer (escrever logs, ler e gravar no banco).

Depois de criar as policies, associar com roles, receber 15 erros de acesso negado, consultar a documentação, desistir e pedir ajuda pro ChatGPT, consegui fazer o deploy. O aprendizado que fica é que a AWS te força a construir o “quem pode fazer o quê” antes de qualquer “o quê”, e isso muda completamente a forma de aprender e operar a plataforma.

Mas no final, não é sobre uma plataforma ser melhor que a outra, é sobre qual delas você está usando pra pagar suas contas.