Início do Bloco B (Cloud e Infraestrutura). Foco: você entende quando cliente diz "rodamos em AWS na região sa-east-1 com VPC privada e Aurora multi-AZ" e consegue propor onde Team Studio se hospeda sem cair em vendor lock-in desnecessário ou em custo cloud explosivo.

Pré-requisito: Semana 1 (SQL) ajuda mas não é obrigatória. Tempo estimado: 3-4 horas de leitura + 1 hora explorando consoles cloud. Output prático: você avalia proposta de cloud do cliente, identifica custos escondidos e propõe arquitetura defensável.

Por que essa semana importa

Em 99% das empresas médias-grandes hoje, infra roda em cloud (AWS, GCP, Azure). Mas "cloud" vira termo vago se você não entende as camadas. Quando cliente fala:

"Nosso backend roda em Kubernetes na EKS, o banco é Aurora multi-AZ com read replicas em us-east-1 e sa-east-1, latência média p95 de 150ms"

...ele tá falando 8 conceitos distintos em uma frase. Sem entender, você fica passageiro.

Pior: cliente leigo (mas com TI técnico atrás) PODE estar gastando 5x mais que necessário e nem saber. Você consegue identificar isso? Vira proposta de valor.

Bônus: pra hospedar Team Studio na infra do cliente, você precisa decidir entre rodar lá (mais barato pro cliente, mais complexo pra você) ou trazer pra sua infra (mais simples pra você, custo seu).

1. O modelo mental: responsabilidade compartilhada

Cloud é "alugar computador da Amazon/Google/Microsoft". Mas o que você aluga varia bastante. Existem 3 níveis principais, em ordem de "quanto eles fazem por você":

1.1 IaaS (Infrastructure as a Service) - você aluga a máquina

Você pega máquina virtual nua. Sistema operacional escolhido por você. Você instala tudo (servidor web, banco, monitoring, segurança).

Exemplos: AWS EC2, Google Compute Engine, Azure VM, Hostinger VPS (nosso caso atual).

Você gerencia: aplicação, runtime (Node, Python), middleware, OS, segurança, atualizações. Provider gerencia: hardware físico, virtualização, rede física, energia, refrigeração.

Quando usa: máximo controle, custo otimizado, deploy custom. Custo de operação alto: você é o sysadmin.

1.2 PaaS (Platform as a Service) - você aluga a plataforma

Você sobe seu CÓDIGO. Plataforma cuida do resto (provisioning, scaling, OS, runtime).

Exemplos: Heroku, Vercel, Railway, Render, AWS Elastic Beanstalk, Google App Engine.

Você gerencia: aplicação, dados. Provider gerencia: tudo abaixo (runtime, middleware, OS, infra).

Quando usa: startup acelerado, time pequeno sem sysadmin, MVP rápido. Custo alto em escala: você paga premium pela conveniência.

1.3 SaaS (Software as a Service) - você aluga o produto

Você USA software pronto. Nenhuma instalação, nenhuma config infra.

Exemplos: Gmail, Notion, Salesforce, Stripe, Asaas, Anthropic API, Supabase.

Você gerencia: dados (parcialmente), configuração. Provider gerencia: tudo.

Quando usa: solução pronta resolve, custo de oportunidade de construir é alto. Custo: previsível, mas escala com uso.

1.4 O ponto que confunde

Empresa moderna usa OS TRÊS ao mesmo tempo:

  • IaaS: roda apps customizados na AWS EC2
  • PaaS: front-end deploya na Vercel
  • SaaS: usa Stripe pra pagamento, Slack pra comunicação, Supabase pra auth

E entre esses extremos, tem variações: BaaS (Backend as a Service: Supabase, Firebase), FaaS (Function as a Service: AWS Lambda), CaaS (Container as a Service: AWS ECS, Google Cloud Run).

Não precisa decorar siglas. Reconhecer e saber onde sua aplicação se encaixa é suficiente.

1.5 Modelo de responsabilidade compartilhada (security)

Cada nível tem "linha de quem responde pela segurança":

SaaS:    [Você responde por: configuração, acesso]
         [Provider responde por: TUDO ABAIXO]

PaaS:    [Você: aplicação, dados, config]
         [Provider: runtime, OS, infra, rede]

IaaS:    [Você: tudo da aplicação ao OS, patches, firewall]
         [Provider: hardware físico, virtualização]

Cliente corporativo vai perguntar: "Como você gerencia o modelo de responsabilidade compartilhada nesse caso?" Você precisa saber a resposta CASO A CASO.

2. Os 3 grandes provedores (AWS, GCP, Azure)

Mercado é dominado por três players. Posicionamento de cada um:

2.1 AWS (Amazon Web Services)

Posicionamento: maior, mais maduro, mais serviços (200+), pioneiro do mercado (2006).

Forças: - Catálogo gigantesco (qualquer coisa você precisa, eles têm) - Documentação extensa - Comunidade enorme - Mais empresas grandes usam (mais fácil contratar profissional)

Fraquezas: - Complexidade absurda (curva de aprendizado íngreme) - Console feio e confuso (admitido por todos) - Pricing labirinto (calcular custo é dor) - Lock-in subtil em serviços proprietários

Serviços que vão aparecer em reunião: - EC2: máquinas virtuais (IaaS) - S3: armazenamento de objetos (arquivos, lake) - RDS / Aurora: bancos relacionais gerenciados - DynamoDB: NoSQL gerenciado - Lambda: serverless (functions) - EKS / ECS: Kubernetes / containers - CloudFront: CDN - Route 53: DNS - IAM: gerenciamento de identidade - VPC: rede privada virtual

2.2 GCP (Google Cloud Platform)

Posicionamento: segundo lugar histórico, forte em data/AI, ascensão rápida pós-2018.

Forças: - Melhor em dados/ML/AI (BigQuery é referência) - Networking superior (rede privada do Google é mundial) - Pricing mais transparente que AWS - Foco em developer experience

Fraquezas: - Menor catálogo que AWS - Histórico de descontinuar produtos (gera receio em enterprise) - Suporte menos consistente - Menos profissionais no mercado

Serviços que vão aparecer: - Compute Engine: máquinas virtuais - Cloud Storage: armazenamento de objetos - Cloud SQL: bancos gerenciados - BigQuery: data warehouse (estrela do GCP) - Cloud Functions / Cloud Run: serverless - GKE: Kubernetes gerenciado - Cloud CDN - Cloud DNS - IAM - VPC

2.3 Azure (Microsoft)

Posicionamento: forte em enterprise, ecossistema Microsoft (Active Directory, Office 365, .NET), terceiro lugar histórico mas crescendo.

Forças: - Integração nativa com produtos Microsoft (Active Directory, Teams, etc) - Forte em hybrid cloud (parte on-prem, parte cloud) - Vendas enterprise impecáveis (Microsoft tem time gigante) - Forte em SaaS Office, Power Platform

Fraquezas: - Documentação pior que AWS - Interface compartimentada (parece patchwork) - Histórico de pricing complicado - Algumas regiões fracas em comparação

Serviços que vão aparecer: - Virtual Machines: VMs - Blob Storage: armazenamento - Azure SQL: SQL Server gerenciado - Cosmos DB: NoSQL multimodel - Azure Functions: serverless - AKS: Kubernetes - Azure Front Door: CDN - Azure AD (agora Entra ID): identidade - VNet: rede privada

2.4 Qual escolher (pra propor cliente)

Resposta honesta: depende.

  • Cliente já tem AWS: continue na AWS, custo de migração não justifica
  • Cliente já tem Azure: idem, Azure
  • Empresa pesada em dados/ML: GCP ou Databricks-on-AWS
  • Empresa Microsoft-shop: Azure
  • Startup começando do zero: AWS (mais empresas, mais profissionais) ou GCP (developer experience)

Vendor lock-in real: mais perceptível em serviços proprietários (Aurora, DynamoDB, BigQuery, Cosmos). Menos perceptível em commodities (EC2, S3 equivalente).

Pergunta de reunião:

"Qual provider de cloud principal? Tem multi-cloud ou tudo centralizado num? Por que essa escolha?"

Resposta revela maturidade. Se cliente diz "AWS porque sempre foi", é pouco crítico. Se diz "GCP porque migrar 50TB pra AWS custava $200k em egress", é maduro.

3. Geografia: regiões e zonas de disponibilidade

3.1 Região (Region)

Localização geográfica do data center. Cada região é independente - desastre em uma região não afeta outra.

Exemplos AWS: - us-east-1 (Norte Virginia, USA) - mais barata, mais serviços, mais bugs - us-west-2 (Oregon, USA) - eu-west-1 (Irlanda) - sa-east-1 (São Paulo, Brasil) - ap-southeast-1 (Singapura)

3.2 Availability Zone (AZ)

Data centers FÍSICOS DISTINTOS dentro da mesma região, conectados por rede de alta velocidade.

Região us-east-1 tem AZs: us-east-1a, us-east-1b, us-east-1c, etc. Cada AZ é prédio diferente, energia diferente, refrigeração diferente.

Por que importa: pra alta disponibilidade, você roda em 2-3 AZs. Se uma AZ inteira pega fogo (raro mas acontece), outras AZs assumem.

3.3 Edge locations

Pontos de presença CDN espalhados pelo mundo (centenas de cidades). Servem conteúdo cacheado perto do usuário.

Não confunda: regiões têm 4-6 AZs. Edge locations são centenas, mas só servem cache.

3.4 Decisão prática: qual região usar pro Brasil?

  • Cliente todo no Brasil: sa-east-1 (São Paulo) ou GCP southamerica-east1
  • Cliente Brasil + público no Brasil: idem
  • Cliente Brasil mas com público global: us-east-1 ou multi-região

Custo: sa-east-1 é geralmente 20-40% mais caro que us-east-1. Empresa pequena às vezes roda em us-east-1 pra economizar (aceitando ~150ms a mais de latência pra usuário brasileiro).

Data residency (LGPD): alguns dados precisam ficar no Brasil. Verifique antes de propor região estrangeira.

Pergunta de reunião:

"Em qual região vocês rodam? Tem replicação cross-region? Como vocês balanceiam custo vs latência vs compliance?"

4. VPC e networking - a rede privada que protege seu app

4.1 VPC (Virtual Private Cloud)

Rede privada isolada DENTRO da cloud. Equivalente a montar sua própria rede dentro do data center.

Por que existe: você não quer que app do cliente A acesse banco do cliente B. VPC garante isolamento.

4.2 Subnets

Subdivisões da VPC. Geralmente:

  • Public subnet: tem acesso à internet (apps web que recebem tráfego externo)
  • Private subnet: SEM acesso direto à internet (bancos, services internos)

Padrão: app fica em public subnet, banco em private subnet. App alcança banco via rede privada interna. Banco não é alcançável de fora.

4.3 Security Groups

Firewalls aplicados a recursos. Define "essa máquina aceita conexões da porta X vindas de Y".

Exemplo: - Security Group "web-server": aceita porta 443 de qualquer IP, porta 22 só de IPs específicos (admin) - Security Group "database": aceita porta 5432 SÓ do Security Group "web-server"

Resultado: banco só responde se request vier dos servidores autorizados.

4.4 NAT Gateway / Internet Gateway

  • Internet Gateway: porta de saída pra internet
  • NAT Gateway: permite recursos em private subnet ACESSAREM internet (pra fazer outbound), sem expor pra internet INBOUND. Cobra por GB.

4.5 VPN, Direct Connect, Peering

  • VPN: túnel encriptado entre VPC e rede on-prem do cliente
  • Direct Connect (AWS): conexão física dedicada (mais cara, baixa latência)
  • VPC Peering: conectar duas VPCs entre si

Pergunta de reunião:

"Vocês têm VPN ou Direct Connect entre on-prem e cloud? Vamos precisar plugar agentes nessa rede?"

5. Custos cloud - a parte que pega todo mundo

Cloud é "pay-as-you-go". Parece justo, mas tem PEGADINHAS.

5.1 As 4 dimensões de custo

  1. Compute: CPU e RAM (EC2, Compute Engine, VMs)
  2. Storage: armazenamento (EBS, S3, etc)
  3. Network: tráfego ENTRANDO é grátis. Tráfego SAINDO (egress) cobra.
  4. Services adicionais: cada SaaS dentro da cloud (RDS, Lambda invocations, API Gateway calls)

5.2 Egress - o vilão silencioso

Empresa migra pra cloud sem prestar atenção, e em 6 meses descobre que 40% da conta é egress (dados saindo da cloud pra internet, pra outra cloud, pra outra região).

Caso real: empresa puxava 5 TB/mês do S3 pra processar fora. AWS cobra ~US$ 0.09/GB de egress = US$ 460/mês só nisso. Migrar processamento PRA DENTRO da AWS reduziu pra US$ 50.

Pergunta de reunião:

"Onde estão os dados que Team Studio vai consumir? Se forem 100GB/mês saindo da cloud do cliente, é dinheiro real."

5.3 Idle costs - máquinas dormindo cobrando

Você cria 5 EC2 pra teste, esquece, paga 3 meses. Acontece com TODO MUNDO.

Boas práticas que clientes maduros têm: - Auto-shutdown (máquinas de dev desligam à noite) - Reserved Instances (commit de 1-3 anos = desconto de 30-70%) - Spot Instances (capacidade ociosa, 80% de desconto, mas pode ser interrompida) - Tagging consistente (cada recurso tem team, project, environment pra rastrear custo)

5.4 FinOps - disciplina de otimizar custo cloud

Função relativamente nova: pessoa/time dedicado a monitorar, alocar e otimizar gasto cloud.

Sinal de empresa madura: tem FinOps. Empresa imatura paga 2-3x do necessário sem perceber.

Pergunta de reunião:

"Vocês têm FinOps ou alguém olhando otimização de custo cloud? Última auditoria foi quando?"

5.5 Cálculo realista pra Team Studio

Quando você for hospedar um agente Team Studio na infra do cliente:

  • Compute: 1 VM pequena (2 vCPU, 4GB RAM) ~ US$ 50/mês em AWS, US$ 30 em GCP
  • Storage: insignificante pra agente (poucos GB)
  • Network: depende do volume de mensagens. WhatsApp agente conversando 1000 vezes/dia = ~5GB/mês = ~US$ 0.50
  • API calls (LLM): ESSA é a dimensão de custo real. Anthropic/OpenAI cobra por token. 1000 conversas × 5k tokens = 5M tokens = US$ 15 (Claude Sonnet) ou US$ 50 (GPT-4).

Total mensal: US$ 70-100 pra um agente. Margem pro Team Studio precisa cobrir isso + entrega.

6. Quando NÃO usar cloud

Cloud não é solução universal. Casos onde on-prem ou colocation faz mais sentido:

  1. Custos previsíveis e escala estável: empresa madura, sem picos. On-prem amortiza em 3-5 anos.
  2. Latência ultra-baixa: trading financeiro, real-time gaming.
  3. Dados regulados que NÃO PODEM sair do país (alguns casos LGPD/GDPR específicos).
  4. Volume gigante de dados que sai/entra: egress mata.
  5. Empresa muito específica: sistemas industriais, médicos, militares.

Maioria das empresas não se encaixa. Cloud é default por bons motivos. Mas saber QUANDO contrariar te diferencia.

7. Hybrid cloud e multi-cloud

7.1 Hybrid cloud

Parte do sistema na cloud, parte on-prem. Conectados via VPN/Direct Connect.

Exemplo: sistema legado mainframe on-prem + apps modernos na AWS, comunicando via API.

7.2 Multi-cloud

Sistema usa duas ou mais clouds (parte em AWS, parte em GCP).

Razões legítimas: melhor preço por serviço, redundância, evitar lock-in, requisito de compliance.

Razões ruins: "vamos usar todos pra ter melhor de cada" geralmente não funciona (complexidade > benefício).

Pergunta de reunião:

"Vocês são single-cloud, hybrid ou multi-cloud? Por quê?"

8. Cinco perguntas que destravam reunião sobre cloud

8.1 "Qual provider principal? Em qual região rodam? Tem multi-AZ?"

Por que importa: mapa básico. Conhecer região define latência. Multi-AZ define disponibilidade.

8.2 "Vocês têm FinOps ou alguém otimizando custo? Qual gasto mensal de cloud aproximado?"

Por que importa: revela maturidade e magnitude. US$ 10k/mês é uma realidade, US$ 100k/mês é outra.

8.3 "Qual estratégia de disaster recovery? Outra região, outro provider?"

Por que importa: DR sério custa caro. Empresa madura tem. Empresa imatura "tem backup", o que não é DR.

8.4 "Como vocês fazem networking entre serviços? VPC peering, service mesh, gateway?"

Por que importa: revela arquitetura. Se cliente fala "tudo public, autenticação no app", é imaturo. "VPC peering com private endpoints" é maduro.

8.5 "Onde Team Studio se encaixa: na sua VPC, na minha cloud, ou SaaS dedicado?"

Por que importa: define arquitetura do serviço. Cada opção tem trade-off de custo/segurança/complexidade.

9. Exercício prático

Cenário: cliente Team Studio em discovery. Empresa de SaaS B2B (R$ 30M/ano de ARR), 50 funcionários, 12 anos de operação. Diz:

"Rodamos em AWS desde 2016. Conta de cloud passou de US$ 8k/mês pra US$ 35k em 3 anos sem que vendas crescesse na mesma proporção. Suspeitamos que tem MUITA coisa cobrando que não precisa. Vocês conseguem ajudar?"

Pratique: identifique 3 categorias de custo possivelmente infladas + 3 perguntas pra confirmar suspeita + 1 possível oportunidade pra Team Studio dentro disso (com IA).

(Sugestões no fim.)

10. Material extra

Leitura prática: - Blog FinOps Foundation (https://www.finops.org/) - vocabulário de otimização cloud - "AWS Pricing Calculator" (https://calculator.aws/) - simule cenários reais - Documentação "Well-Architected Framework" da AWS (5 pilares: operacional, segurança, confiabilidade, performance, custo)

Vídeos: - "AWS in 10 minutes" - várias opções no YouTube, escolha o mais visto - Apresentações da re:Invent (AWS), Google Cloud Next, Microsoft Ignite - 30-60 min cada, dá noção do que cada provider promove

Hands-on grátis (3-4 horas): - Crie conta grátis na AWS (US$ 0 de cobrança no Free Tier 1º ano) - Suba uma EC2 t2.micro - Crie um S3 bucket, suba arquivo - Crie uma VPC com public e private subnet - Tente acessar a EC2 via SSH

Em 3 horas você tem intuição que 50 páginas de leitura não dão.

11. Sugestões pro exercício prático (veja só depois de tentar)

3 categorias possivelmente infladas:

  1. Recursos esquecidos (10-30% comum): EC2s/EBS volumes/snapshots criados pra testes, jamais deletados. Cliente paga 3-5 anos sem usar.

  2. Tipos de instância errados (10-20%): instâncias m5.large quando t3.medium resolveria. Cliente não revisou após 2018 quando saíram tipos mais modernos e baratos.

  3. Egress não otimizado (5-15%): dados saindo de uma região pra outra desnecessariamente, ou de S3 pra fora da AWS.

3 perguntas pra confirmar suspeita:

  1. "Vocês fazem auditoria mensal de recursos? Tem ferramenta como AWS Cost Explorer + Trusted Advisor ativada?"
  2. "Última vez que revisaram tipos de instância foi quando? Tem alguma rodando há 3+ anos sem update?"
  3. "Olhando a fatura, qual o maior item de custo? Compute, storage, network ou serviços?"

Oportunidade pra Team Studio:

Agente "FinOps assistente": roda diariamente sobre AWS Cost Explorer + CloudTrail, identifica anomalias semanticamente ("esse VM mudou de pattern, será que tá idle?"), gera relatório semanal no WhatsApp do CFO/CTO. Não substitui FinOps real, mas faz triagem inicial. Setup: 3-5 dias. Valor entregue: provavelmente paga o Team Studio sozinho.

12. Próxima semana

A Semana 5 fecha o Bloco B (Cloud e Infra) com escalabilidade e disponibilidade: autoscaling em prática, CDN avançado, load balancers L4 vs L7, multi-region, SLA real dos provedores com números de downtime, RPO/RTO em decisões de DR. Inclui cenário Black Friday e avaliação realista de meta 99.99%.

Depois disso, o Bloco C (DevOps) começa com Docker, containers e Kubernetes (S6) e CI/CD + observability (S7).