Migração para cloud. AWS, Azure, GCP. "O fornecedor garante alta disponibilidade". Tudo isso parece padrão. Aí o incidente acontece e o cliente descobre o que estava de verdade no contrato.

Vou contar um caso real. Mudei detalhes para preservar identidade.

Empresa de logística. Migrou ERP para AWS em 2023. SLA AWS para EC2: 99,99%. Parecia ótimo.

Junho de 2024, instabilidade na região us-east-1. 4 horas de degradação severa. Operação do cliente parada.

Quando foi reclamar, descobriu três coisas que não tinha entendido na hora de contratar:

Primeiro: SLA EC2 de 99,99% só vale para configuração multi-AZ. Eles tinham single-AZ porque era mais barato.

Segundo: violação de SLA AWS gera crédito de serviço, não dinheiro de volta. E o crédito é limitado a 30% da fatura mensal do serviço afetado.

Terceiro: "degradação severa" da AWS naquele dia não foi classificada oficialmente como "downtime" porque alguns componentes ficaram parcialmente disponíveis. O SLA tecnicamente não foi violado, mesmo a operação tendo parado.

Cliente perdeu R$ 480 mil em receita. Recebeu R$ 8.500 em crédito de serviço.

SLA de cloud não é o que parece. Vou destrinchar.

O que o SLA padrão dos clouds cobre — e o que não cobre

AWS, Azure e GCP têm SLAs públicos por serviço. Vou usar AWS como exemplo, mas a lógica é similar nos outros.

O que está coberto

Cada serviço tem seu SLA específico. Não há SLA do "sistema todo". Cada componente é independente.

O que não está coberto

O SLA cobre o que a AWS controla. Não cobre o que está no seu controle ou em terceiros.

Multi-region vs single-region: como isso afeta seu SLA real

Aqui entra arquitetura, que muda completamente o SLA real.

Single-region, single-AZ

SLA EC2: 99,5%. Tradução: 3,6 horas de downtime por mês permitido pela AWS sem multa. Para sistemas não-críticos, ok. Para sistemas críticos, inaceitável.

Single-region, multi-AZ

SLA EC2: 99,99%. 4,3 minutos por mês. Mas atenção: se a região inteira cair (raro mas acontece, como us-east-1 em dezembro/2021 ou junho/2024), seu sistema cai.

Multi-region, multi-AZ

SLA composto. Se uma região cai, a outra assume. Disponibilidade real pode chegar a 99,999%.

Custo: 1,8x a 2,5x do single-region por causa da replicação contínua e infraestrutura duplicada.

Multi-cloud

Disponibilidade ainda maior. Você não fica refém de uma falha global de um provedor (caso GCP global outage de novembro/2023). Custo: complexidade operacional alta, custo geralmente 2,5x-3x do single-cloud.

A escolha de arquitetura precede a discussão de SLA. Se sua arquitetura é single-AZ, o SLA negociado não pode ser 99,99%, porque não existe.

Créditos de SLA: o que parecem mas não são

SLA cloud não paga dinheiro. Paga crédito.

Crédito tem limitações:

Para uma empresa que gasta R$ 50 mil/mês em AWS e tem violação de SLA: crédito máximo de R$ 15 mil (30% da fatura). Para um incidente que pode custar R$ 200-500 mil ao negócio.

O SLA do cloud não é proteção financeira. É declaração de compromisso operacional do fornecedor.

Proteção financeira real vem de:

Antes de migrar para cloud, calcule seu SLA ideal com a calculadora.

Calcular meu SLA e custo de downtime →

Responsabilidade compartilhada: onde termina o cloud e começa você

Cliente quase nunca entende esse ponto.

AWS, Azure e GCP usam modelo de "responsabilidade compartilhada". Eles cuidam da infraestrutura. Você cuida do que roda em cima.

Onde está a fronteira:

Responsabilidade do cloud

Responsabilidade do cliente

Quando o sistema cai, a primeira pergunta é: caiu pelo lado do cloud (problema deles) ou pelo lado da aplicação (problema seu)?

70% dos incidentes em ambientes cloud são do lado do cliente. Configuração errada, falta de monitoramento, processo de deploy ruim. SLA do cloud não cobre nada disso.

O que incluir no contrato de cloud antes de migrar

Lista do que negocio em contrato com fornecedor de cloud, além do SLA padrão.

1. Suporte técnico premium

O SLA básico não inclui suporte rápido. Para sistemas críticos, contratar tier Enterprise ou similar (tempo de resposta < 15 min para P1).

2. Cláusula de portabilidade

Direito de exportar dados em formato estruturado em prazo definido, sem custo. Especialmente importante para bancos de dados, onde o fornecedor pode dificultar saída.

3. Limite de aumento de preço

Preço de serviços cloud sobe. Não muito por unidade, mas o consumo aumenta. Negocie compromisso de não-aumento de preço unitário por X anos.

4. Direito de auditoria

Em setores regulados, o cliente pode precisar auditar o fornecedor (ou ter relatório SOC 2 atualizado). Negocie acesso a relatórios de compliance.

5. Plano de continuidade do fornecedor

Para serviços críticos, exija demonstração de plano de continuidade do próprio fornecedor. Não basta confiar na marca.

6. Cláusula de mudança regulatória

Especialmente importante com discussão sobre soberania de dados. Direito de migrar dados para outra região se a regulação mudar.

Contrato de cloud bem negociado é diferente do contrato padrão que vem da prateleira. A diferença está em cláusulas que protegem o cliente quando o cenário muda — e o cenário sempre muda.

Suporte enterprise: vale o investimento?

AWS, Azure e GCP têm tiers de suporte. Básico (gratuito ou barato), Business (médio), Enterprise (caro).

Para sistemas críticos, Enterprise tipicamente vale.

O que muda:

Custo: 10% da fatura cloud mensal, mínimo R$ 30-50 mil/mês.

Para empresa com fatura cloud acima de R$ 100 mil/mês operando sistemas críticos, o ROI do suporte enterprise geralmente é positivo. Abaixo desse patamar, talvez não compense.

Arquitetura para SLA real, não SLA de marketing

O SLA do cloud é teórico se a arquitetura não suporta. Multi-AZ obrigatório para serviços críticos. Backup automatizado e testado. Failover documentado e exercitado.

Cliente real testou failover pela primeira vez 18 meses após migração. Falhou. Componentes de configuração não tinham sido replicados para região secundária. Recuperação levou 7 horas em vez dos 30 minutos prometidos.

SLA de cloud sem teste regular de failover é fé. Negocie cláusula de teste anual obrigatório com participação do fornecedor.

Renegociação periódica: o ponto de alavancagem

Contratos com cloud são geralmente de 1-3 anos. Renovação é momento de alavancagem.

O que vale negociar na renovação:

Fornecedores de cloud são extremamente sensíveis a churn de clientes corporativos. Renovação é a hora para extrair valor adicional. Cliente que renova automaticamente sem renegociação está deixando dinheiro na mesa.

Comece a preparar renovação 6 meses antes do vencimento. Tenha cotação de concorrentes em mãos. Use como base de negociação.

Em resumo: contratação inteligente de cloud em 6 pontos

  1. Entenda o modelo de responsabilidade compartilhada
  2. Arquitete para SLA real (multi-AZ, multi-region quando necessário)
  3. Contrate suporte enterprise para sistemas críticos
  4. Negocie cláusulas além do SLA padrão (portabilidade, auditoria, mudança regulatória)
  5. Teste failover regularmente — SLA sem teste é fé
  6. Use renovação como ponto de alavancagem para negociar melhores condições

Contrato de cloud bem negociado economiza dinheiro e reduz risco. Contrato padrão te coloca na média do mercado — que não é boa o suficiente para sistema crítico.

Cenários onde o SLA padrão é suficiente

Vou ser franco em algo: nem todo workload precisa de SLA negociado.

Para workloads não-críticos — ambientes de teste, desenvolvimento, sistemas internos de baixo impacto — o SLA padrão do cloud é suficiente.

Esforço de negociação tem custo (tempo da equipe, taxas de assessoria). Aplicar esforço em workload de baixo impacto é desperdício.

Onde concentrar negociação:

Categorize workloads antes de planejar negociação. SLA premium para tudo é desperdício; SLA padrão para tudo é risco.

Documentação que precisa estar no anexo do contrato

Contrato bom tem anexos técnicos. SLA de cloud especialmente precisa de:

Sem esses anexos, contrato fica em nível abstrato. Quando crise vem, ninguém sabe o que está combinado em detalhe.

Antes de fechar contrato com cloud, calcule qual SLA real seu negócio precisa. A calculadora te dá esse número em poucos minutos, com base em custo de downtime do seu setor.

Veja também

Guia Completo

SLA na prática: como calcular uptime real e definir penalidades que funcionam

99,9% de uptime parece bom. São 8,7 horas de downtime por ano. Se acontecer no fechamento do mês, você sabe o que isso representa. Veja como calcular e negociar SLA de verdade.

 Riscos

Por que 99,9% de uptime não é o que parece — e como calcular o que realmente importa

Dois fornecedores com 99,9% de uptime podem ser completamente diferentes. Um tem downtime distribuído em minutos. O outro tem um evento de 8 horas por ano. Saiba qual é o seu.

Perguntas frequentes

Como negociar SLA com fornecedor de cloud?

Pontos críticos para negociar: 1) Crédito de serviço vs. penalidade real — a maioria dos contratos de cloud oferece crédito de serviço (desconto no próximo mês), não indenização pelo dano causado. 2) Exclusões — incidentes de 'força maior' e 'ataques DDoS' costumam estar excluídos do SLA. 3) Zona de disponibilidade — o SLA garante a região como um todo ou sua zona específica? 4) SLA de suporte — tempo de resposta para abertura de chamado crítico.

Os grandes provedores de cloud (AWS, Azure, GCP) têm SLA confiável?

Os grandes provedores têm SLA de 99,9% a 99,99% e histórico de cumprir esses números. O problema não é o SLA deles — é a arquitetura do que você coloca sobre eles. Uma aplicação mal arquitetada com single point of failure não se beneficia do SLA de 99,99% da infra. A confiabilidade real é min(SLA da cloud, confiabilidade da sua aplicação).

O que fazer quando o fornecedor de cloud não cumpre o SLA?

1) Documente o incidente com timestamps precisos — logs de monitoramento próprio, não só o dashboard do fornecedor. 2) Abra chamado formal durante o incidente, não depois. 3) Solicite o relatório de post-mortem por escrito. 4) Calcule o crédito devido e solicite formalmente. 5) Se o incidente for recorrente, avalie cláusula de rescisão por descumprimento reiterado. Fornecedores grandes raramente contestam créditos documentados adequadamente.

A negociação com os hyperscalers: o que muda

Negociar SLA com AWS, Azure ou GCP é diferente de negociar com fornecedor local. Os termos padrão são publicados e não-negociáveis para clientes de pequeno e médio porte. Mas há margem para grandes clientes — e para todos há estratégia.

O que efetivamente se negocia em contrato corporativo (Enterprise Agreement): descontos volumétricos sobre uso esperado; créditos por adoção de novos serviços; suporte premium incluído; revisões trimestrais formais; canal dedicado de escalation. SLA propriamente dito tipicamente fica fora da negociação direta — o termo é padrão público.

Mas há mecanismos indiretos para mitigar exposição: arquitetura multi-zone (compõe SLA superior ao de cada zona); arquitetura multi-region (proteção contra falha regional inteira); multi-cloud para componentes críticos; caching agressivo que mantém parte do serviço operacional mesmo durante falha upstream.

Empresa madura combina esses mecanismos e atinge na prática SLA muito superior ao publicado. Empresa imatura confia no SLA contratual e descobre nos primeiros incidentes que ele não cobre seu cenário real.

A cláusula esquecida: créditos vs. compensação real

Em SLA com provedor cloud, frequentemente o modelo de compensação é via crédito de serviço — quando o SLA é violado, o cliente recebe créditos para uso futuro. Esse modelo tem limite claro.

Cenário típico: incidente de 8 horas no provedor cloud causa prejuízo de R$ 2 milhões à empresa. Compensação contratual: 25% de crédito sobre o serviço afetado naquele mês, equivalente a talvez R$ 30 mil. Diferença massiva entre prejuízo real e compensação recebida.

O modelo de crédito de serviço cobre o custo direto que o cliente pagou ao fornecedor por aquela janela. NÃO cobre o impacto operacional ou financeiro no negócio do cliente. Empresa que confia em crédito de serviço como mitigação está mal protegida.

Mitigação real exige combinação de: arquitetura resiliente (não confiar em SLA contratual como única proteção), seguro cyber para perdas operacionais por indisponibilidade, e plano de continuidade testado. Crédito de serviço é só pequena parte do quebra-cabeças.

O modelo emergente: SLA por experiência do usuário

Tendência crescente em contratos sérios: SLA medido pela experiência real do usuário final, não apenas pela disponibilidade da infraestrutura.

O modelo clássico mede se o servidor está respondendo. O modelo emergente mede se o usuário consegue concluir a transação esperada dentro do tempo aceitável. Diferença grande: servidor pode estar online mas com performance degradada que torna a aplicação inviável.

Métricas modernas: Apdex (Application Performance Index), p95 e p99 de latência em jornadas críticas, taxa de erro por transação, tempo de carregamento percebido pelo usuário (Core Web Vitals).

Negociar SLA com essas métricas exige sofisticação técnica de ambas as partes. Mas resulta em contrato que protege o que de fato importa para o negócio — não apenas o uptime medido na infraestrutura.

Empresas pioneiras em adoção desse modelo: SaaS B2B mais maduros, fintechs, e algumas grandes empresas tradicionais que digitalizaram operação crítica. Em 3-5 anos, esse modelo se torna padrão.