Infraestrutura Cloud para SaaS: Guia AWS para CTOs

Por que a infraestrutura importa desde o MVP

A decisão comum de "a gente resolve infra depois quando precisar escalar" tem um problema: infra mal projetada no MVP não é refatorada — ela é contornada. E cada contorno adiciona custo, fragilidade e tempo de engenharia que poderia estar em produto.

Não é preciso uma infraestrutura enterprise desde o dia 1. É preciso uma infraestrutura que cresce com o produto sem exigir reescrita.

A estrutura de contas AWS que usamos

Uma estrutura simples e segura para SaaS desde o início:

AWS Organization
  ├── Management Account (billing consolidado)
  ├── Production Account (workloads de produção)
  ├── Staging Account (ambiente de pré-produção)
  └── Dev Account (sandbox para desenvolvimento)

Por que múltiplas contas?

Isolamento de segurança real. Um acidente no ambiente de dev não afeta produção. Billing separado mostra o custo real de cada ambiente. IAM e permissões mais simples de gerenciar.

Stack de infraestrutura recomendada por fase

Fase 1: MVP (até ~100 usuários simultâneos)

| Componente | Serviço AWS | Alternativa | |---|---|---| | Compute | ECS Fargate | Lambda (se estateless) | | Banco de dados | RDS PostgreSQL (db.t4g.medium) | Aurora Serverless v2 | | Cache | ElastiCache Redis (cache.t4g.micro) | Upstash (mais barato no início) | | Storage | S3 | — | | CDN | CloudFront | — | | DNS | Route 53 | — | | Secrets | AWS Secrets Manager | Parameter Store | | Logs | CloudWatch Logs | — |

Custo estimado: US$ 150–300/mês para um MVP com tráfego baixo.

Fase 2: Crescimento (100–10.000 usuários simultâneos)

Acrescente:

| Componente | Serviço AWS | Por quê | |---|---|---| | Read replicas | RDS Multi-AZ + Read Replica | Queries analíticas separadas do write | | Queue | SQS ou MSK (Kafka gerenciado) | Processamento assíncrono | | Search | OpenSearch | Full-text search | | Observabilidade | CloudWatch Container Insights + Grafana | Métricas de container | | WAF | AWS WAF | Proteção DDoS e OWASP |

Custo estimado: US$ 800–2.500/mês.

Fase 3: Scale (10.000+ usuários simultâneos)

| Componente | Serviço AWS | Decisão | |---|---|---| | Orquestração | EKS (Kubernetes gerenciado) | Se precisar de controle granular | | Banco de dados | Aurora PostgreSQL Global Database | Multi-região ativo/ativo | | Cache | ElastiCache Cluster Mode | Sharding horizontal | | Multi-região | Route 53 + Global Accelerator | Latência geográfica |

Custo estimado: US$ 5.000–25.000+/mês dependendo do tráfego.

ECS Fargate vs. EKS: a decisão mais comum

A maioria dos SaaS começa com ECS Fargate e migra para EKS quando o controle se torna necessário. Veja quando cada um faz sentido:

Use ECS Fargate quando:

Equipe de infra pequena (1–2 pessoas)
Menos de 20–30 serviços
Não precisa de funcionalidades avançadas de scheduling
Quer menos overhead de operação

Use EKS quando:

Precisa de custom scheduling (GPUs, spot diversification)
Time de platform engineering dedicado
Já tem expertise em Kubernetes
Precisa de portabilidade multi-cloud

A migração de ECS para EKS é possível, mas não trivial. Planeje cedo se EKS é o destino.

Infraestrutura como Código: Terraform desde o dia 1

Nunca crie recursos manualmente no console da AWS. Todo recurso deve ser criado e gerenciado via Terraform (ou CDK se preferir TypeScript).

Estrutura mínima de um projeto Terraform para SaaS:

infrastructure/
  modules/
    networking/      # VPC, subnets, security groups
    database/        # RDS, parameter groups
    compute/         # ECS cluster, task definitions
    cache/           # ElastiCache
    storage/         # S3 buckets
  environments/
    prod/
      main.tf
      variables.tf
      terraform.tfvars
    staging/
      main.tf
      ...
  shared/
    ecr.tf           # Container registry
    route53.tf       # DNS zones

Regras de ouro:

State remoto no S3 com locking via DynamoDB — nunca state local
Workspaces separados por ambiente (ou diretórios separados, mais explícito)
Modules para recursos reutilizados — não copie e cole
terraform plan sempre antes de apply — no CI/CD, não manual

CI/CD: deploy sem downtime

Um pipeline de deploy sólido para SaaS:

Pull Request
  → lint + typecheck
  → unit tests
  → integration tests (banco real em container)
  → build Docker image
  → push para ECR (tag: commit SHA)
  → deploy para staging (ECS rolling update)
  → smoke tests em staging
  
Merge para main
  → deploy para produção (ECS rolling update)
  → health check automatizado
  → rollback automático se health check falhar

ECS rolling update: o ECS substitui containers velhos pelos novos gradualmente. Com health checks bem configurados, deploys são zero-downtime mesmo durante tráfego.

Monitoramento: o mínimo que você precisa

Alertas obrigatórios em produção

Configurados via CloudWatch Alarms ou Datadog:

CPU > 80% por 5 minutos      → alerta imediato
Memory > 85%                 → alerta imediato
RDS connections > 80% max    → alerta imediato
Error rate > 1%              → alerta imediato
P99 latência > 2s            → alerta imediato
Disco RDS > 80%              → alerta imediato
Certificado SSL expira em 30 dias → alerta

Dashboard de operação

Um dashboard simples mas efetivo:

Requests/segundo (total e por endpoint crítico)
Taxa de erros 4xx e 5xx
P50 / P95 / P99 de latência
CPU e memória dos containers
Conexões ativas no banco
Cache hit rate (Redis)

Segurança de infraestrutura

Checklist de segurança de infra que aplicamos em todos os projetos:

[ ] VPC com subnets privadas para banco e cache (sem IP público)
[ ] Security Groups com menor privilégio (sem 0.0.0.0/0 desnecessário)
[ ] RDS sem acesso público — acesso via bastion host ou SSM Session Manager
[ ] S3 buckets com block public access habilitado por padrão
[ ] CloudTrail habilitado em todas as contas (auditoria de chamadas de API)
[ ] AWS Config para detectar drift de configuração
[ ] GuardDuty habilitado (detecção de ameaças)
[ ] Rotation automática de secrets no Secrets Manager
[ ] IMDSv2 obrigatório em instâncias EC2

Precisa de uma revisão da sua infraestrutura AWS ou está começando do zero?

Solicitar auditoria de infraestrutura → · Como escalar SaaS com AWS → · Desenvolvimento SaaS: guia completo →