Serviços essenciais da AWS: IAM, VPC, EC2, S3, RDS, Lambda e o que os conecta

A Amazon Web Services oferece bem mais de duzentos serviços, mas um sistema de produção típico usa talvez quinze — e são quase sempre os mesmos quinze. Este guia faz um tour por eles: para que serve cada um, quais decisões você toma ao configurá-lo e como ele se conecta aos vizinhos. Ele parte do princípio de que você leu o guia de fundamentos de cloud e sabe o que são uma região, uma zona de disponibilidade e o modelo de responsabilidade compartilhada. Os nomes dos serviços são os oficiais atuais; quando a AWS renomeou algo recentemente, o nome antigo é mencionado uma vez.

Contas, organizações e IAM

Tudo na AWS vive dentro de uma conta, que é ao mesmo tempo uma fronteira de cobrança e uma fronteira rígida de segurança. Empresas raramente operam com uma única conta: o AWS Organizations permite criar várias contas sob uma conta de gerenciamento, agrupá-las em unidades organizacionais e aplicar service control policies (SCPs) que limitam o que qualquer identidade dentro dessas contas pode fazer — por exemplo, proibir a criação de recursos fora das regiões aprovadas. Contas separadas para produção, não produção, ferramentas de segurança e arquivamento de logs são a base padrão.

Dentro de uma conta, o AWS Identity and Access Management (IAM) decide quem pode chamar qual API em qual recurso. O vocabulário:

• Principals são identidades: usuários IAM (de longa duração, com senha ou chaves de acesso), roles IAM (assumidas temporariamente, sem credenciais permanentes) e identidades federadas de um provedor externo via IAM Identity Center ou SAML/OIDC.
• Políticas são documentos JSON que permitem ou negam ações sobre recursos, opcionalmente sob condições. Políticas baseadas em identidade são associadas a principals; políticas baseadas em recurso são associadas ao próprio recurso (um bucket S3, uma fila, uma chave KMS).
• Roles são o burro de carga. Uma role tem uma trust policy que diz quem pode assumi-la e políticas de permissão que dizem o que quem a assume pode fazer. Instâncias EC2, funções Lambda, tasks do ECS e pods do Kubernetes obtêm suas permissões ao serem associados a uma role; a plataforma injeta credenciais de curta duração que são rotacionadas automaticamente.

A lógica de avaliação é simples de enunciar e vale a pena decorar: tudo é negado por padrão; um Allow explícito em uma política aplicável concede acesso; um Deny explícito em qualquer lugar prevalece sobre todo Allow; SCPs e permission boundaries definem um teto externo que as políticas de identidade não podem ultrapassar.

Uma política de privilégio mínimo para um serviço que lê objetos de um prefixo de bucket e escreve em uma fila fica assim:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadInvoices",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-billing-prod/invoices/*"
    },
    {
      "Sid": "ListInvoicePrefixOnly",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::acme-billing-prod",
      "Condition": { "StringLike": { "s3:prefix": ["invoices/*"] } }
    },
    {
      "Sid": "EnqueueWork",
      "Effect": "Allow",
      "Action": ["sqs:SendMessage"],
      "Resource": "arn:aws:sqs:eu-west-1:123456789012:invoice-processing"
    }
  ]
}

Todo recurso é identificado por um Amazon Resource Name (ARN) no padrão arn:partition:service:region:account-id:resource. Serviços globais como S3 e IAM deixam o campo de região vazio. Curingas no campo Resource são a origem da maioria das políticas permissivas demais: "Resource": "*" combinado com "Action": "s3:*" dá ao principal todos os buckets da conta.

Rede: a VPC

Uma Amazon Virtual Private Cloud (VPC) é uma rede logicamente isolada em uma região, com uma faixa CIDR IPv4 escolhida por você (e, opcionalmente, IPv6). Dentro dela você cria sub-redes, cada uma vinculada a uma zona de disponibilidade. Uma sub-rede é pública se sua tabela de rotas envia 0.0.0.0/0 para um internet gateway; caso contrário, é privada. Essa distinção é puramente uma decisão de roteamento — não existe nenhuma outra flag.

Um layout convencional para uma aplicação de três camadas em três zonas:

VPC 10.20.0.0/16 (eu-west-1)
├── public-a  10.20.0.0/24   ALB nodes, NAT gateway      → route 0.0.0.0/0 → internet gateway
├── public-b  10.20.1.0/24   ALB nodes, NAT gateway
├── public-c  10.20.2.0/24   ALB nodes, NAT gateway
├── app-a     10.20.10.0/24  EC2 / ECS tasks             → route 0.0.0.0/0 → NAT gateway (same AZ)
├── app-b     10.20.11.0/24
├── app-c     10.20.12.0/24
├── data-a    10.20.20.0/24  RDS primary                 → no default route at all
├── data-b    10.20.21.0/24  RDS standby
└── data-c    10.20.22.0/24

As instâncias da aplicação ficam em sub-redes privadas e acessam a internet para chamadas de saída por um NAT gateway que fica em uma sub-rede pública. Implante um NAT gateway por zona: um único compartilhado cria uma dependência entre zonas e uma cobrança de transferência de dados entre zonas. As sub-redes de banco de dados não têm nenhuma rota para a internet.

O controle de tráfego tem duas camadas. Security groups são firewalls stateful associados a interfaces de rede, e seu melhor recurso é que uma regra pode referenciar outro security group: "liberar a 5432 a partir do security group da camada de aplicação" sobrevive à substituição das instâncias, enquanto regras baseadas em IP não. Network ACLs são listas stateless no nível da sub-rede; deixe-as no padrão permissivo, a menos que você tenha um requisito específico de bloqueio.

Mais duas peças aparecem em quase toda VPC real. Os VPC endpoints permitem que sub-redes privadas alcancem serviços da AWS como S3, DynamoDB, Secrets Manager e ECR sem passar pela internet nem por um NAT gateway. O VPC peering ou, em escala, o AWS Transit Gateway conecta VPCs entre si e a redes on-premises via AWS Site-to-Site VPN ou AWS Direct Connect.

Computação: EC2, contêineres e Lambda

O Amazon Elastic Compute Cloud (EC2) fornece máquinas virtuais. As escolhas que importam ao lançar uma são a Amazon Machine Image (AMI), que é o template do disco de boot; o tipo de instância, cuja letra de família indica a finalidade (uso geral, otimizada para computação, memória ou armazenamento, acelerada) e cujo tamanho define vCPUs e memória; a sub-rede e os security groups; o instance profile do IAM que carrega sua role; e o user data, um script executado no primeiro boot. As instâncias têm um ciclo de vida (pending, running, stopping, stopped, terminated) e, o que é importante, o disco instance store de alguns tipos desaparece quando a instância é parada, enquanto os volumes EBS persistem.

As opções de compra mudam a conta sem mudar a máquina: On-Demand para flexibilidade, Savings Plans ou Reserved Instances para descontos por compromisso em cargas estáveis, e Spot Instances — capacidade ociosa que a AWS pode retomar com um aviso de dois minutos — para jobs batch interrompíveis e cargas stateless.

Um Auto Scaling group mantém em execução um número desejado de instâncias a partir de um launch template, substitui as que não estão íntegras, distribui-as pelas sub-redes que você listar e ajusta a quantidade de acordo com políticas de escalonamento (target tracking sobre CPU ou número de requisições é o ponto de partida usual). Na frente dele, o Elastic Load Balancing oferece um Application Load Balancer para HTTP/HTTPS com roteamento por caminho e por host, um Network Load Balancer para TCP/UDP com throughput muito alto e IPs estáticos, e um Gateway Load Balancer para appliances virtuais.

# Launch one instance in a private subnet with a role and a startup script
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.small \
  --subnet-id subnet-0a1b2c3d \
  --security-group-ids sg-0f1e2d3c \
  --iam-instance-profile Name=order-service-profile \
  --user-data file://bootstrap.sh \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=service,Value=orders},{Key=env,Value=prod}]'

Os contêineres têm dois orquestradores. O Amazon Elastic Container Service (ECS) é o scheduler próprio da AWS, mais simples de operar, com o AWS Fargate como tipo de lançamento serverless que elimina totalmente a necessidade de gerenciar hosts. O Amazon Elastic Kubernetes Service (EKS) roda Kubernetes upstream para times que querem portabilidade ou já dominam Kubernetes; veja o guia de fundamentos de Kubernetes para o modelo de orquestração em si. Ambos puxam imagens do Amazon Elastic Container Registry (ECR).

O AWS Lambda executa uma função em resposta a um evento — uma requisição HTTP pelo API Gateway ou por uma function URL, um novo objeto no S3, uma mensagem em uma fila, um agendamento — sem nenhuma instância para gerenciar. Você escolhe um runtime (Java, Python, Node.js, .NET, Go e runtimes customizados via contêineres), um tamanho de memória que também escala a fatia de CPU e um timeout com limite máximo medido em minutos. O Lambda se encaixa em cargas orientadas a eventos, com picos ou de "cola" entre sistemas; processos de longa duração, cargas que precisam de conexões persistentes e qualquer coisa sensível à latência de cold start ficam melhor em contêineres.

Armazenamento: EBS, EFS e S3

O Amazon Elastic Block Store (EBS) fornece volumes de bloco que se conectam a uma instância EC2 na mesma zona de disponibilidade — o disco de uma máquina virtual. Os tipos de volume equilibram custo contra throughput e IOPS; o SSD de uso geral (gp3) é a escolha padrão, e o SSD com IOPS provisionadas (io2) existe para bancos de dados exigentes. Snapshots são cópias incrementais armazenadas no S3 e são a forma de fazer backup e clonar volumes. Como um volume é vinculado à sua zona, uma instância em outra zona não consegue montá-lo; só essa restrição já descarta o EBS como armazenamento compartilhado.

O Amazon Elastic File System (EFS) é um sistema de arquivos NFS gerenciado que pode ser montado por muitas instâncias em várias zonas ao mesmo tempo, para cargas que realmente precisam de um sistema de arquivos POSIX compartilhado, como sistemas de gerenciamento de conteúdo ou aplicações migradas em lift-and-shift que escrevem em um diretório compartilhado.

O Amazon Simple Storage Service (S3) é armazenamento de objetos: buckets guardam objetos endereçados por chave, acessados via HTTPS, sem semântica de sistema de arquivos e com capacidade praticamente ilimitada. É o destino padrão para backups, logs, sites estáticos, arquivos de data lake, mídia e qualquer coisa que seja escrita uma vez e lida muitas. Recursos que vale conhecer desde o primeiro dia:

• Classes de armazenamento (Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant/Flexible/Deep Archive) equilibram velocidade de recuperação e custo por requisição contra custo de armazenamento; lifecycle rules movem objetos entre classes e os fazem expirar.
• O versionamento guarda cada sobrescrita e cada exclusão, e é sua proteção contra exclusões acidentais e sobrescritas no estilo ransomware.
• O Block Public Access no nível da conta deve ficar ligado, a menos que você esteja servindo um site público de propósito.
• A criptografia no lado do servidor vem ativada por padrão; você pode escolher uma chave gerenciada pela AWS ou sua própria chave no AWS Key Management Service (KMS).
• URLs pré-assinadas concedem acesso por tempo limitado a um único objeto sem tornar o bucket público.

aws s3api put-bucket-versioning --bucket acme-billing-prod \
  --versioning-configuration Status=Enabled
aws s3 cp ./reports/2026-09.pdf s3://acme-billing-prod/reports/2026-09.pdf \
  --storage-class STANDARD_IA

Bancos de dados: RDS, Aurora e DynamoDB

O Amazon Relational Database Service (RDS) roda instâncias gerenciadas de PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server e Db2. A AWS cuida do provisionamento, da aplicação de patches em uma janela de manutenção, dos backups automáticos com recuperação para um ponto no tempo e — com o Multi-AZ ativado — de uma instância standby replicada de forma síncrona em outra zona, com failover automático. Read replicas são cópias assíncronas para escalar leituras e não substituem o Multi-AZ. O esquema, as consultas, os índices e o parameter group continuam sendo responsabilidade sua.

O Amazon Aurora é o motor relacional próprio da AWS, compatível no nível de protocolo com PostgreSQL e MySQL, com armazenamento replicado seis vezes em três zonas e failover medido em segundos. As variantes Aurora Serverless ajustam a capacidade conforme a carga. Escolha Aurora quando quiser a ergonomia do RDS com mais disponibilidade e escalabilidade de leitura e não estiver preso a outro motor.

O Amazon DynamoDB é um banco de dados chave-valor e de documentos totalmente gerenciado, com latência consistente de poucos milissegundos em qualquer escala. As tabelas têm uma chave de partição (e, opcionalmente, uma chave de ordenação), e você consulta por essas chaves ou por índices secundários projetados com antecedência. A capacidade é sob demanda ou provisionada; não há servidor, nem patches, nem pool de conexões para dimensionar. O preço dessa simplicidade é que os padrões de acesso precisam ser conhecidos e modelados desde o início.

O Amazon ElastiCache (Redis ou Valkey, e Memcached) cobre cache e armazenamento de sessões; o Amazon OpenSearch Service cobre busca full-text e análise de logs.

Mensageria e integração

Desacoplar componentes com filas e eventos é como as arquiteturas na AWS absorvem picos e isolam falhas.

O Amazon Simple Queue Service (SQS) é uma fila de mensagens. Filas standard oferecem entrega at-least-once com ordenação best-effort e throughput quase ilimitado; filas FIFO garantem a ordem e o processamento exactly-once dentro de um message group, com throughput menor. Um consumidor recebe uma mensagem, processa e a exclui; se não a excluir dentro do visibility timeout, a mensagem reaparece e, depois de um número configurado de tentativas, vai parar em uma dead-letter queue.

O Amazon Simple Notification Service (SNS) é publish/subscribe: um tópico distribui uma mensagem para muitos assinantes — filas SQS, funções Lambda, endpoints HTTPS, e-mail, SMS. O fan-out de SNS para SQS é o padrão quando vários serviços precisam do mesmo evento.

O Amazon EventBridge é um barramento de eventos com regras baseadas em conteúdo que roteiam eventos de serviços da AWS, das suas aplicações e de parceiros SaaS para destinos, além de um agendador. Ele substitui o antigo CloudWatch Events. Para orquestrar workflows de várias etapas com retentativas e ramificações, o AWS Step Functions oferece uma máquina de estados.

Edge, DNS e observabilidade

O Amazon Route 53 é um DNS com health checks e políticas de roteamento (ponderado, por latência, failover, geolocalização) que transformam o DNS em uma ferramenta de direcionamento de tráfego. O Amazon CloudFront é a rede de distribuição de conteúdo: faz cache em edge locations, termina TLS com certificados do AWS Certificate Manager e fica na frente de buckets S3, load balancers ou qualquer origem HTTP. O AWS WAF é associado ao CloudFront ou a um ALB para filtrar requisições.

O Amazon CloudWatch coleta métricas, logs e alarmes. Todo serviço emite métricas automaticamente; suas aplicações enviam logs pelo agente do CloudWatch ou pelo runtime do Lambda; alarmes disparam com base em limites e podem acionar o Auto Scaling ou notificações do SNS. O AWS CloudTrail registra toda chamada de API na conta — quem fez o quê, de onde e quando — e é sua trilha de auditoria; ative-o em todas as regiões e envie os registros para um bucket blindado na conta de arquivamento de logs. O AWS X-Ray acrescenta tracing distribuído.

Configurações e segredos também têm seu lugar: o AWS Systems Manager Parameter Store para valores de configuração e o AWS Secrets Manager para credenciais com rotação automática. Lê-los na inicialização por meio da role da instância é o substituto cloud native dos arquivos de propriedades com senhas dentro — uma prática que o guia twelve-factor aprofunda.

Juntando tudo no CloudFormation

O AWS CloudFormation descreve recursos em templates YAML ou JSON e os cria, atualiza ou exclui como uma stack. É a opção nativa de infraestrutura como código; Terraform e o AWS CDK são alternativas comuns, e o guia de infraestrutura como código os compara. Uma stack mínima com uma fila, sua dead-letter queue e uma role que um serviço poderia assumir:

AWSTemplateFormatVersion: "2010-09-09"
Description: Invoice processing queue and worker role

Resources:
  InvoiceDlq:
    Type: AWS::SQS::Queue
    Properties:
      MessageRetentionPeriod: 1209600          # 14 days, the maximum

  InvoiceQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 120                    # longer than the worst-case processing time
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt InvoiceDlq.Arn
        maxReceiveCount: 5

  WorkerRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal: { Service: ecs-tasks.amazonaws.com }   # only ECS tasks may assume it
            Action: sts:AssumeRole
      Policies:
        - PolicyName: consume-invoices
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action: [sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes]
                Resource: !GetAtt InvoiceQueue.Arn

Outputs:
  QueueUrl:
    Value: !Ref InvoiceQueue

Erros comuns

Chaves de acesso no código ou em variáveis de CI. Use roles na computação e federação OIDC a partir de sistemas de CI como o GitHub Actions; se uma chave precisar existir, restrinja bem o escopo dela e faça a rotação.

Um único NAT gateway, em uma única zona. Quando essa zona cai, todas as sub-redes privadas perdem o acesso à internet. Implante um por zona e roteie cada sub-rede privada para o gateway local.

Tratar read replicas como alta disponibilidade. Uma réplica é assíncrona e a promoção é manual, a menos que você a automatize. O recurso de disponibilidade é o Multi-AZ; réplicas servem para escalar leituras.

Buckets S3 públicos por acidente. Mantenha o Block Public Access ligado no nível da conta e sirva conteúdo público pelo CloudFront com um origin access control.

Ignorar o CloudTrail e as tags de alocação de custos. Sem o CloudTrail você não consegue responder "quem apagou isso?", e sem um esquema consistente de tags service/env/owner você não consegue responder "quem está pagando por isso?". Os dois são baratos de configurar no primeiro dia e trabalhosos de acrescentar depois.

Principais conclusões

• Contas são a fronteira de segurança e de cobrança; cargas de trabalho obtêm permissões por roles IAM com credenciais de curta duração, e as políticas negam por padrão.
• Uma VPC é sua rede privada: sub-redes públicas roteiam para um internet gateway, as privadas saem por NAT gateways por zona ou por VPC endpoints, e security groups referenciam uns aos outros em vez de IPs.
• EC2 dá controle total, ECS/EKS roda contêineres e Lambda executa funções orientadas a eventos; escolha pelo controle necessário e pelo perfil de uso, não por modismo.
• EBS é um disco vinculado a uma zona, EFS um sistema de arquivos compartilhado e S3 o armazenamento de objetos durável com versionamento, lifecycle rules e Block Public Access.
• RDS e Aurora atendem às necessidades relacionais com failover Multi-AZ; DynamoDB atende ao acesso por chave em qualquer escala quando os padrões são conhecidos de antemão.
• SQS, SNS e EventBridge desacoplam componentes; CloudWatch, CloudTrail e X-Ray mostram o que está acontecendo; CloudFormation torna tudo isso reproduzível.