AWS - Visão Geral dos Serviços

Como ler esta nota

Para cada serviço: o que é, caso de uso típico e a qual modelo de Tipos de Infraestrutura pertence. A ideia é montar um mapa mental de “qual peça usar para quê”, não decorar APIs.

Compute

EC2 (Elastic Compute Cloud)

O que é: máquinas virtuais sob demanda. Você escolhe tipo de instância (CPU/memória), AMI (imagem do SO), rede (VPC) e armazenamento (EBS).
Caso de uso típico: cargas que precisam de controle do SO, software legado, GPUs, ou base para plataformas próprias.
Modelo: IaaS — você gerencia SO pra cima.

ECS (Elastic Container Service)

O que é: orquestrador de containers da AWS. Roda em dois modos: EC2 launch type (você gerencia os nós) ou Fargate (serverless de containers, sem gerenciar nós).
Caso de uso típico: rodar uma aplicação de Microservices — cada serviço vira uma task definition com sua imagem, escalada de forma independente atrás de um load balancer.
Modelo: CaaS (com Fargate, tende ao serverless).

Storage

S3 (Simple Storage Service)

O que é: armazenamento de objetos (não é um filesystem nem um bloco). Buckets globalmente nomeados, durabilidade de 11 noves, versionamento, políticas de acesso e classes de storage (Standard, Infrequent Access, Glacier).
Caso de uso típico: assets estáticos (imagens, JS/CSS, uploads de usuário), backups, data lake, hospedagem de sites estáticos, destino de logs.
Modelo: serviço gerenciado/serverless de storage — sem servidores para você operar.

Rede e entrega

CloudFront

O que é: CDN (Content Delivery Network) global. Cacheia conteúdo em edge locations próximas do usuário, terminando TLS e reduzindo latência.
Caso de uso típico: servir os arquivos estáticos de um SPA a partir de um bucket S3, além de acelerar e proteger APIs (com WAF).
Modelo: serviço gerenciado de entrega de borda.

Route 53

O que é: DNS gerenciado e altamente disponível. Faz resolução de domínios, health checks e roteamento avançado (latency-based, weighted, failover, geolocation).
Caso de uso típico: apontar app.exemplo.com para uma distribuição CloudFront ou um load balancer; implementar failover entre regiões.
Modelo: serviço gerenciado de DNS/rede.

Observabilidade

CloudWatch

O que é: plataforma de métricas, logs e alarmes. Coleta métricas de serviços (CPU de EC2, invocações de Lambda), agrega logs (CloudWatch Logs), dispara alarmes e dashboards.
Caso de uso típico: alarmar quando CPU da ECS passa de 80%, centralizar logs de aplicação, acionar autoscaling.
Modelo: serviço gerenciado de observabilidade — transversal a todos os modelos de infra.

Tabela-resumo

Serviço	Categoria	O que é (1 linha)	Caso de uso típico	Modelo (Tipos de Infraestrutura)
EC2	Compute	VMs sob demanda	Controle de SO, legado, GPU	IaaS
ECS	Compute	Orquestrador de containers	Microservices em containers	CaaS (Fargate → serverless)
S3	Storage	Storage de objetos	Assets estáticos, backups, data lake	Gerenciado / serverless
CloudFront	Rede / entrega	CDN de borda	Servir estáticos do S3, acelerar APIs	Gerenciado
Route 53	Rede / entrega	DNS gerenciado	Domínio → CloudFront/LB, failover	Gerenciado
CloudWatch	Observabilidade	Métricas, logs e alarmes	Alarmar CPU, centralizar logs	Gerenciado (transversal)

Arquitetura de referência (diagrama)

Uma app típica de Microservices servindo um frontend estático: o app roda em ECS e os estáticos são servidos por S3 + CloudFront.

flowchart LR
    U[Usuário] --> R53[Route 53<br/>DNS]
    R53 --> CF[CloudFront<br/>CDN de borda]
    CF -->|assets estáticos| S3[(S3<br/>bucket de estáticos)]
    CF -->|/api/*| ALB[Application<br/>Load Balancer]
    ALB --> ECS

    subgraph ECS["ECS (CaaS)"]
    direction TB
    S1[Serviço A] 
    S2[Serviço B]
    S3svc[Serviço C]
    end

    ECS --> DB[(Banco de dados)]
    ECS -.métricas/logs.-> CW[CloudWatch]
    CF -.logs.-> CW
    style S3 fill:#166534,color:#fff
    style CF fill:#155e75,color:#fff
    style ECS fill:#854d0e,color:#fff
    style CW fill:#7c2d12,color:#fff

Leitura do fluxo: o usuário resolve o domínio no Route 53, cai no CloudFront, que serve estáticos direto do S3 e encaminha /api/* para o ALB → ECS, onde vivem os microserviços. Tudo emite métricas e logs para o CloudWatch.

Anti-padrões e erros comuns

Servir estáticos direto da aplicação (ECS/EC2) em vez de S3+CloudFront: desperdiça compute e piora latência global.
Buckets S3 públicos por engano. Vazamento clássico de dados. Prefira acesso via CloudFront com OAC (Origin Access Control) e mantenha “Block Public Access” ligado.
Tratar S3 como filesystem. Não há append, rename barato nem hierarquia real — é storage de objetos; “pastas” são só prefixos de chave.
EC2 quando bastava container/serverless. Assumir a operação de VMs (patching, autoscaling) sem necessidade real de controle de SO.
Não instrumentar CloudWatch desde o início. Descobrir que não há métricas/logs justamente durante um incidente.
DNS com TTL alto durante migração. Route 53 com TTL longo atrasa failover e cutover.

Relações

Cada serviço materializa um modelo de Tipos de Infraestrutura.
ECS orquestra Containers - Docker e Docker Compose e sustenta Microservices.
Provisionar tudo isso de forma reprodutível é papel de Terraform.
Faz parte de DevOps & Infraestrutura; o deploy de imagens costuma vir de um pipeline de CI - GitHub Actions.
A malha de serviços distribuídos se relaciona com Sistemas Distribuídos e o quadro geral em Como Tudo se Conecta.

Perguntas de revisão

Onde roda um app de microserviços na AWS e como você serve seu frontend estático de forma eficiente?

Resposta

Os microserviços rodam em ECS (cada serviço como uma task independente atrás de um load balancer). Os estáticos são armazenados no S3 e distribuídos pela CDN CloudFront, evitando gastar compute da aplicação e reduzindo latência global.

Qual a diferença de modelo de infraestrutura entre EC2 e ECS?

Resposta

EC2 é IaaS: você gerencia o SO das VMs. ECS é CaaS: você entrega imagens de container; com Fargate até os nós são abstraídos, aproximando-se do serverless.

Por que S3 não deve ser tratado como um sistema de arquivos tradicional?

Resposta

S3 é storage de objetos: não há hierarquia real de diretórios (as “pastas” são apenas prefixos de chave), nem append ou rename baratos. Cada objeto é imutável e substituído por completo. Operações de filesystem esperadas (locks, edição parcial) não existem nativamente.

Qual serviço amarra domínio, CDN e origem, e qual cuida da observabilidade transversal?

Resposta

Route 53 (DNS) resolve o domínio para o CloudFront (CDN), que tem como origens o S3 e o ALB/ECS. A observabilidade transversal — métricas, logs e alarmes de todos esses serviços — fica no CloudWatch.