Olá! Bem-vindo de volta! Este é o segundo post da série AWS para Não-Engenheiros. No primeiro artigo, falamos sobre serviços de nuvem e uma introdução ao AWS.

Vou continuar usando a empresa fictícia trips.com, que usamos como exemplo no post anterior. Se você perdeu, recomendo dar uma olhada primeiro.

Hoje, vou explicar de forma simples os conceitos de Conta AWS, Organização e, por fim, falar sobre o IAM, um dos serviços mais importantes da AWS.

Conta

“Uma Conta é um contêiner para os seus recursos da AWS. Você cria e gerencia os recursos dentro de uma conta, com controle total de acesso e cobrança.”

Como comentei antes, a AWS oferece mais de 250 serviços. Para usar qualquer um deles, basta criar uma conta na AWS Console.

Dentro de uma conta, você pode criar usuários, definir restrições, gerenciar serviços e acessar múltiplas regiões da AWS.

Vamos voltar ao nosso app favorito: trips.com. Usuários do mundo todo estão usando o app, cuja infraestrutura está hospedada na região us-west-2 (Oregon).

Porém, usuários de Singapura reclamam que o app está lento. Isso acontece porque os dados precisam viajar uma longa distância entre Singapura e Oregon. Para resolver, a equipe pode acessar o Console da AWS, mudar a região na interface para ap-southeast-1 (Singapura) e subir a infraestrutura lá também. Assim, o trips.com passará a operar em Oregon e Singapura, tudo dentro da mesma conta.

Importante:

Quando uma conta é criada, o e-mail usado no cadastro vira o usuário root da conta. Este é o usuário com todos os poderes administrativos. Algumas ações, como encerrar a conta, só podem ser feitas por ele. Por segurança, o ideal é nunca usar o root no dia a dia e sempre ativar o 2FA.

Organização

“Uma Organização é um conjunto de contas AWS que você pode organizar em hierarquias e gerenciar de forma centralizada.”

Com uma organização, você pode administrar várias contas de forma central, sem precisar gerenciar uma por uma.

Exemplo:

Você pode criar uma conta para o time de engenharia, outra para homologação, e outra para produção. Todas ficam dentro da mesma organização, vinculadas a uma conta de gerenciamento.

Também é possível criar Unidades Organizacionais (OUs) e organizar as contas conforme a estrutura da sua empresa.

Exemplo de estrutura:

  • OU Engenharia: contas de desenvolvimento e testes
  • OU Growth: contas de marketing e vendas

Benefícios de usar uma Organização:

  • Controle: Restringir o que cada conta pode fazer. Exemplo: impedir que o root da produção exclua a conta.
  • Compliance: Aplicar regras obrigatórias para todas as contas.
  • Cobrança Consolidada: Em vez de pagar separadamente, todas as contas são cobradas juntas. Assim, você pode até ter descontos por volume de uso (remember: pague menos usando mais).

Atenção:

Mesmo dentro da organização, o root da conta de gerenciamento continua com permissões totais e não pode ser restringido. Então, proteja bem esse usuário.
Agora que você já entendeu o que são Conta e Organização, vamos falar de IAM.

IAM: Identity and Access Management

O IAM é o serviço da AWS para gerenciar identidades e acessos.

Ele cuida tanto do acesso de usuários humanos quanto da comunicação entre os próprios serviços da AWS.

Comparando com o mundo real:

Imagine o Google Workspace da sua empresa: só funcionários têm acesso. E dentro dele, nem todo mundo pode acessar tudo — só quem tem permissão. O IAM faz isso na AWS.

Outro exemplo:

Você contrata o Apple Care e adiciona o cartão no Apple Pay. Agora imagine se a Apple cobrasse o Apple Care sem sua autorização. Seria péssimo, né? O IAM previne esse tipo de coisa entre serviços AWS: nada se conecta a nada sem permissão explícita.

Principais Componentes do IAM:

  • Usuários: Pessoas ou workloads que acessam a conta.
  • Grupos: Conjunto de usuários com as mesmas permissões.
  • Políticas: Conjunto de permissões aplicadas a usuários, grupos ou roles.
  • Roles: Identidades que podem ser assumidas por serviços para realizar tarefas específicas.

Usuários

São identidades criadas para pessoas ou workloads.

Podem ter senha (para acessar o Console) e/ou access keys (para acesso programático via API).

Por padrão, usuários novos não têm permissão para nada, é você quem precisa conceder.

Grupos

Permitem gerenciar permissões de vários usuários de uma só vez.

Importante: Grupos não podem ter outros grupos dentro e não servem para login.

Políticas

Definem o que uma identidade pode ou não pode fazer.

Exemplo de estrutura de uma Policy:

  • Effect: Allow ou Deny
  • Action: Serviço + Operação (Ex: S3:PutObject)
  • Resource: Recurso ao qual a ação se aplica

Sem uma policy atribuída, a identidade não tem permissão para nada.

Roles

Uma Role é uma identidade que não tem credenciais fixas, mas pode ser assumida por serviços ou usuários temporariamente.

Por exemplo:

O servidor do trips.com precisa salvar imagens no S3? Ele assume a Role com permissão para isso, e pronto.

Roles têm duas partes:

  1. Trust Policy: Quem pode assumir a Role.
  2. Policies: O que pode ser feito.

Se não tiver Policy associada, a Role não pode fazer nada.

Princípio do Menor Privilégio (Least Privilege)

O básico aqui é:

Só dê as permissões que realmente forem necessárias para aquela identidade.

Exemplo:

Se o servidor do trips.com só precisa fazer upload de imagem e mandar e-mail, ele só deve ter permissão para S3:PutObject e SNS:Publish.

Dica Final: Se puder, evite usar a região us-east-1 (N. Virginia). Por ser a mais antiga e a que hospeda a maioria dos serviços globais da AWS, também é a que mais apresenta instabilidades. Se puder, prefira us-west-2 (Oregon).