AWS (Compute, Storage, Database, Networking)

A AWS é a nuvem pública mais madura do mercado e o ponto de partida natural para o estudo de arquitetura de produção em nuvem. Sua oferta se organiza em categorias que cobrem todo o ciclo de vida de uma aplicação: computação, armazenamento, banco de dados e rede. Entender quais serviços existem em cada categoria e qual problema cada um resolve é mais valioso do que decorar nomes, porque toda decisão arquitetural nascem desse mapa. Em produção, a relevância prática é direta: escolher EC2, Lambda ou ECS define o modelo operacional do time, e escolher S3, EBS ou EFS define o modelo de acesso a dados. O panorama por categoria abaixo funciona como referência rápida para desenhar sistemas na AWS com vocabulário correto.

Regiões, zonas de disponibilidade e responsabilidade compartilhada

Todo serviço da AWS vive em uma região, que é uma área geográfica com múltiplas zonas de disponibilidade. Cada zona de disponibilidade é um ou mais datacenters com energia e rede independentes, conectados por enlaces de baixa latência. Arquiteturas de produção distribuem componentes entre AZs para sobreviver à falha de um datacenter inteiro sem indisponibilidade perceptível.

O modelo de responsabilidade compartilhada complementa o mapa físico: a AWS é responsável pela segurança da nuvem, que inclui datacenters, hardware e virtualização; o cliente é responsável pela segurança na nuvem, que inclui configuração de Security Groups, IAM, criptografia e dados. A maior parte dos incidentes de segurança em nuvem nasce do lado do cliente, tipicamente buckets S3 abertos ou credenciais expostas, e não de falha do provedor.

A escolha de região combina quatro critérios objetivos: latência até os usuários, exigências legais de residência de dados, preço por serviço e disponibilidade de serviços específicos, pois nem toda região oferta todo o catálogo. Em produção, a convenção usual é operar em uma região primária com backup replicado para uma região secundária, e validar periodicamente que o plano de recuperação de desastre considera a falta total da região primária.

Compute: EC2, ECS, EKS e Lambda

A categoria de computação oferece um espectro que vai da máquina virtual pura à função serverless. A escolha define quanto controle de infraestrutura o time retém e quanto custo fixo assume.

O EC2 segue sendo a base quando há necessidade de ambientes longevos, hardware especializado ou instâncias reservadas para custo previsível. ECS processa na casa de 3 bilhões de tasks por semana e, em 2025, ganhou o lançamento do ECS Managed Instances, que combina a simplicidade do Fargate com controle de instâncias EC2, cobrindo cargas com GPU, privileged containers e memória acima do teto de 120 GB do Fargate. Lambda fecha o espectro cobrando por execução, com zero administração de servidor.

O modelo de preço acompanha o modelo de execução e influencia a decisão tanto quanto a capacidade técnica. EC2 permite Reserved Instances e Savings Plans para cargas estáveis; Fargate cobra por segundo de vCPU e memória consumidos por task; Lambda cobra por invocação e por GB-segundo de execução. A regra prática em produção é combinar: base estável em EC2 reservado ou Savings Plan, pico e variabilidade em Fargate ou Lambda, e revisão periódica com dados reais de utilização.

Storage: S3, EBS e EFS

O armazenamento da AWS se divide em três modelos de acesso com propósitos distintos, e confundi-los é uma fonte clássica de custo e desempenho ruins.

O S3 organiza dados em buckets com classes de armazenamento por frequência de acesso, como Standard, Standard-IA e Glacier, e é a peça central de pipelines de dados e arquivos de aplicação. O EBS entrega discos gp3 e io1/volumes de IOPS provisionadas, a escolha padrão para volumes de banco de dados em EC2, com snapshots incrementais para backup. O EFS escala automaticamente e serve cenários em que várias instâncias precisam ver o mesmo sistema de arquivos, com preço superior por GB e latência maior que EBS.

O ciclo de vida do S3 automatiza a transição de classes e a exclusão, reduzindo custo sem intervenção manual, o que o torna essencial para buckets de log, artefatos e backups.

# Regra de lifecycle: logs passam para IA em 30 dias e expiram em 1 ano
Rules:
  - Id: rotacao-logs-producao
    Status: Enabled
    Filter:
      Prefix: logs/
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
    Expiration:
      Days: 365

Sem regras assim, buckets acumulam dados frios em classe Standard por anos, e a conta de storage cresce silenciosamente como um dos maiores itens de custo do sistema.

Database: RDS, DynamoDB e ElastiCache

Na categoria de banco de dados, a AWS cobre desde o relacional totalmente gerenciado até o NoSQL de latência de milissegundos de um dígito.

O RDS abstrai provisionamento, patching, backup e failover dos motores PostgreSQL, MySQL, MariaDB, SQL Server e Oracle, sendo o ponto de partida para a maioria dos sistemas transacionais. O DynamoDB remove o teto de escala relacional cobrando por requisição e oferecendo consistência eventual ou forte por item, com impacto direto no modelo de dados, que precisa ser desenhado em função dos padrões de acesso. O ElastiCache é o complemento de leitura quente, reduzindo carga no banco primário e latência percebida.

A decisão entre eles é menos sobre preferência e mais sobre padrões de acesso. Relacionais brilham em consultas ad hoc, joins e integridade referencial forte; DynamoDB brilha quando a chave de partição cobre os padrões de leitura e a escala precisa ser elástica; caches entram quando uma consulta é lida centenas de vezes por segundo e aceita dados ligeiramente defasados. Sistemas maduros combinam os três sem conflito: RDS como fonte da verdade transacional, DynamoDB para agendas e filas de leitura pesada, ElastiCache para o caminho quente.

Networking: VPC, ELB e Route 53

A rede da AWS é o primeiro serviço que todo desenho toca. A VPC cria uma rede virtual privada isolada, subdividida em sub-redes públicas e privadas distribuídas entre AZs, com tabelas de rotas e gateways controlando o tráfego. Security Groups e Network ACLs aplicam filtragem em camadas, e endpoints privados permitem consumir serviços como S3 e DynamoDB sem sair da rede própria.

O ELB (Elastic Load Balancing) oferece três flavors de produção: o ALB para roteamento HTTP e HTTPS em camada 7, com host e path routing e integração nativa com ECS e EKS; o NLB para tráfego TCP de altíssima performance em camada 4, com IP estático por AZ; e o Gateway Load Balancer para appliances de segurança. O Route 53 completa o conjunto com DNS gerenciado, health checks e políticas de roteamento como failover, weighted e latency-based, sendo frequentemente a porta de entrada de todo o tráfego de produção.

# Esqueleto de rede de produção: VPC com duas sub-redes privadas em AZs distintas
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications \
  'ResourceType=vpc,Tags=[{Key=Name,Value=prod-vpc}]'

aws ec2 create-subnet --vpc-id vpc-0abc123 --cidr-block 10.0.1.0/24 \
  --availability-zone sa-east-1a   # sub-rede privada da AZ 1a

aws ec2 create-subnet --vpc-id vpc-0abc123 --cidr-block 10.0.2.0/24 \
  --availability-zone sa-east-1b   # sub-rede privada da AZ 1b

# Load balancer de aplicação distribuído nas mesmas AZs
aws elbv2 create-load-balancer --name prod-alb --type application \
  --subnets subnet-0aaa111 subnet-0bbb222

IAM: a camada transversal de permissões

O IAM atravessa todas as categorias anteriores e define quem pode fazer o quê em cada serviço. O modelo usa principals, policies JSON e ações granulares por serviço, com roles assumíveis temporariamente no lugar de chaves de acesso de longo prazo. Em arquiteturas de produção, cada componente recebe uma role dedicada com menor privilégio: a aplicação de pedidos lê a fila de SQS, mas não toca no bucket de backup; o pipeline de deploy escreve no ECR, mas não altera o banco.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::prod-relatorios/*"
    },
    {
      "Effect": "Deny",
      "Action": ["s3:DeleteBucket"],
      "Resource": "*"
    }
  ]
}

Essa policy concede apenas leitura de objetos do bucket de relatórios e nega explicitamente exclusão de qualquer bucket, ilustrando o grau de granularidade esperado em produção. Auditorias periódicas com IAM Access Analyzer e revisão de políticas por permissões não utilizadas mantêm o modelo saudável conforme o sistema cresce.

Aplicação prática: topologia de referência de produção

As categorias se encaixam em uma topologia de referência que aparece repetidamente em sistemas reais. O Route 53 resolve o domínio para o ALB, que distribui requisições HTTPS entre tasks ECS em sub-redes privadas de duas AZs; as tasks assumem task roles do IAM e gravam logs no CloudWatch. O RDS em Multi-AZ fica em sub-redes privadas, acessível apenas pelo Security Group das tasks, com snapshots criptografados; o S3 recebe uploads de usuários via presigned URLs, e o ElastiCache acelera o caminho de leitura.

Essa topologia cobre alta disponibilidade, menor privilégio e separação de camadas com meia dúzia de serviços, e é o esqueleto sobre o qual se agregam SQS para processamento assíncrono, CloudFront para cache de conteúdo e WAF para filtragem de ataques. O valor do panorama por categoria aparece exatamente aqui: cada peça nova do desenho é identificada pela categoria do problema antes da escolha do serviço.

Comparação entre as categorias

Esse mapeamento evita o erro mais comum de quem chega à AWS: sobre-engenheirar com serviços avançados antes de esgotar o serviço padrão. Em produção, a combinação VPC, ALB, ECS, RDS e S3 resolve a maioria absoluta dos sistemas web corporativos, e cada desvio desse caminho deve ter justificativa explícita em uma decision record.

Erros comuns e boas práticas

• Colocar tudo em uma única AZ: qualquer manutenção ou falha de datacenter derruba o sistema; distribua sub-redes, instâncias e réplicas entre ao menos duas AZs.
• Confundir EBS com EFS ou S3: usar objeto para banco de dados ou disco compartilhado para HTTP de arquivos gera custo e latência ruins.
• Deixar Security Groups abertos na porta de banco de dados; restrinja a source ao Security Group do load balancer ou da sub-rede de aplicação.
• Tratar responsabilidade compartilhada como responsabilidade zero: IAM mal configurado e dados sem criptografia continuam sendo risco do cliente.
• Ignorar tags de custo desde o início: sem tags por serviço e ambiente, a alocação de custo em escala se torna impraticável.
• Criar dependências entre AZs que presumem latência baixa entre regiões; sincronização entre regiões exige desenho explícito de replicação.

Como prática consolidada, padronize infraestrutura como código desde o primeiro recurso, habilite CloudTrail em todas as regiões para auditoria, e trate o panorama por categoria acima como um mapa mental de produção: primeiro identifique a categoria do problema, depois escolha o serviço, e só então examine limites, preço e integrações específicas.