Provedores de nuvem oferecem aos times de CloudOps a infraestrutura, os serviços gerenciados e o ferramental para rodar workloads confiáveis e escaláveis sem precisar montar e manter hardware físico. Para quem administra ambientes em AWS, Google Cloud, Azure e plataformas especializadas, a relação com o provedor define os resultados operacionais de ponta a ponta — do tempo de resposta a incidentes à precisão na atribuição de custos. Escolher e governar bem os CSPs é uma das decisões de maior alavancagem que um time de CloudOps toma.
A maior parte dos times de CloudOps não escolhe seus provedores de nuvem do zero. Herda ambientes que cresceram de forma orgânica: um workload na AWS aqui, um pipeline de dados no Google Cloud ali, uma exigência de compliance que empurrou determinados dados para o Azure. O resultado: segundo o Flexera 2025 State of the Cloud Report, 89% das empresas hoje operam ambientes multi-cloud.
Isso, por si só, não é um problema. Ambientes multi-cloud trazem vantagens reais: flexibilidade para posicionar workloads, resiliência via diversificação de provedores e a possibilidade de combinar os melhores serviços de cada categoria em toda a stack.
O problema operacional aparece na complexidade. Cada CSP tem seu próprio modelo de cobrança, seu próprio sistema de identidade e controle de acesso, seu próprio toolchain de monitoramento e seu próprio caminho de escalonamento de suporte. Gerenciar dois ou três desses provedores de forma consistente, sem duplicar overhead operacional nem abrir lacunas de atribuição, exige um nível de padronização que a maioria dos times só constrói no susto, em vez de planejar antes.
Este guia trata exatamente dessa lacuna. Para uma visão mais ampla dos padrões de infraestrutura que os times de CloudOps montam sobre sua stack de CSPs, nosso guia de arquitetura de nuvem aborda as decisões estruturais que conectam a escolha do provedor ao desenho operacional.
O que são provedores de nuvem e como eles habilitam os times de CloudOps?
Provedores de nuvem disponibilizam recursos computacionais, infraestrutura, plataformas e serviços gerenciados pela internet, com cobrança por consumo. Em vez de comprar e manter servidores físicos, equipamentos de rede e hardware de armazenamento, os times de CloudOps consomem essas capacidades como serviço e pagam pelo que usam.
A definição parece simples. A realidade operacional vai bem além.
A relação com um CSP cobre muito mais do que acesso a computação e armazenamento. Os SLAs definem o que acontece durante incidentes. Os tiers de suporte determinam com que rapidez os problemas chegam a engenheiros que de fato podem resolvê-los. Os sistemas de cobrança produzem os dados de custo que os times de CloudOps precisam para atribuir e governar gastos. As camadas de serviços gerenciados reduzem o overhead operacional ou apenas o redistribuem, dependendo de como são configuradas.
Para os times de CloudOps, especificamente, os CSPs viabilizam quatro resultados operacionais críticos:
- Resolução de incidentes mais rápida: monitoramento nativo do CSP, dashboards de saúde e caminhos de escalonamento de suporte afetam diretamente o tempo médio de resolução quando algo quebra. Provedor com ferramental ruim ou suporte lento não causa só inconveniência — prolonga interrupções que custam dinheiro de verdade.
- Escalonamento automatizado: autoscaling gerenciado, computação serverless e serviços nativos para Kubernetes permitem absorver variações de demanda sem intervenção manual às 2 da manhã.
- Infraestrutura para atribuição de custos: exportações de billing, frameworks de tagging e ferramentas de alocação de custo embutidas na camada do CSP formam a base de qualquer prática de FinOps. Sem isso, governança de gastos vira planilha.
- Menos overhead operacional: bancos de dados gerenciados, control planes de Kubernetes gerenciados e serviços de rede gerenciados transferem a responsabilidade operacional para o provedor em camadas que não diferenciam o seu negócio.
Os provedores que entregam esses resultados de forma consistente e previsível geram alavancagem para os times de CloudOps. Os que não entregam acrescentam atrito a cada decisão operacional.
Quais são os principais tipos de provedores de nuvem?
O cenário de CSPs se fragmentou bem além dos três hyperscalers. Hoje, os times de CloudOps gerenciam relações com nuvens públicas hyperscale, plataformas especializadas em dados e analytics e provedores de infraestrutura híbrida ou de edge. Cada categoria tem características operacionais distintas e diferentes alavancas de otimização.
Provedores de nuvem pública hyperscale: AWS, Google Cloud e Azure
Os três hyperscalers — Amazon Web Services, Google Cloud Platform e Microsoft Azure — respondem pela maior parte do gasto corporativo em nuvem e oferecem os catálogos de serviços mais amplos. A AWS detém cerca de 30% do mercado de nuvem pública, o Azure cerca de 20% e o Google Cloud cerca de 13%, segundo dados de mercado de 2025. Não são apenas provedores de infraestrutura: são plataformas com centenas de serviços gerenciados que cobrem computação, armazenamento, rede, bancos de dados, machine learning e segurança.
Para os times de CloudOps, a relação com o hyperscaler concentra o grosso da complexidade operacional. Cada provedor desenvolveu pontos fortes próprios:
AWS lidera em amplitude de serviços e maturidade de ecossistema. Seu catálogo de serviços gerenciados cobre mais casos de uso do que qualquer outro provedor, e o ecossistema de parceiros e ferramentas em torno dele — monitoramento de terceiros, gestão de custos, segurança e automação — tem uma profundidade que nenhuma outra nuvem alcança. O trade-off: ambientes AWS acumulam complexidade ao longo do tempo, com desafios de custo e governança que crescem junto com a estrutura de contas.
Google Cloud lidera em workloads de dados e analytics. O modelo serverless do BigQuery para análise em larga escala, o Vertex AI para pipelines de machine learning e o Kubernetes — criado pelo próprio Google — dão ao GCP uma posição diferenciada para arquiteturas data-intensive. O desempenho de rede no backbone global do Google também se destaca em aplicações sensíveis a latência.
Azure lidera em integração corporativa. Empresas que rodam Microsoft 365, Active Directory ou que já têm licenciamento Microsoft ganham vantagens significativas de custo e operação ao executar workloads no Azure. Sua cobertura de compliance em setores regulados — saúde, finanças, governo — supera a dos demais provedores em amplitude de certificações.
A maioria dos times de CloudOps não otimiza para um único hyperscaler. Otimiza para a aderência do workload, colocando cada categoria de workload no provedor onde ela roda de forma mais eficiente em custo e mais confiável — e gerenciando a complexidade cross-provider que vem disso.
Plataformas de nuvem especializadas e serviços de dados
Ao lado dos hyperscalers, um conjunto crescente de plataformas de nuvem especializadas entra no radar operacional dos times de CloudOps — não porque alguém as escolheu como alternativa à AWS ou ao Azure, mas porque times específicos de engenharia as adotaram para resolver problemas específicos.
Plataformas de dados são o exemplo mais claro. Snowflake, Databricks e Google BigQuery operam como serviços de nuvem gerenciados, cada um com seu próprio modelo de custo, suas próprias alavancas de otimização e seus próprios requisitos de governança. Um ambiente Snowflake rodando na AWS continua gerando faturas Snowflake que demandam otimização específica do Snowflake — dimensionamento de warehouse, ajustes de suspensão, gestão de custo de queries — somadas aos custos de infraestrutura AWS por baixo.
Plataformas de observabilidade como Datadog, New Relic e Grafana Cloud entram na mesma categoria. O mesmo vale para serviços de container registry, plataformas de segurança e CDNs. Cada uma adiciona uma relação de cobrança, um pipeline de dados e uma área operacional ao escopo do time de CloudOps.
O desafio operacional: essas plataformas, em geral, não aparecem na mesma visão de relatórios de custo que o gasto com hyperscalers. Um time pode fazer right-sizing de cada instância EC2 e ainda assim deixar passar o pico de custo no Snowflake responsável por 30% da fatura total de infraestrutura de engenharia.
Provedores de infraestrutura híbrida e multi-cloud
Alguns workloads nunca chegam à nuvem pública — não por questões técnicas, e sim práticas. Uma exigência de compliance impõe que os dados fiquem em uma jurisdição específica. Restrições de latência de edge tornam round-trips a uma nuvem regional inaceitáveis. Computação on-premises de alto throughput sai mais barata do que capacidade equivalente em nuvem em escala suficiente. Isso não é caso extremo. É comum o bastante para que a maioria das organizações trate infraestrutura híbrida como prática operacional padrão.
Em arquiteturas bem desenhadas, os provedores de infraestrutura híbrida — instalações de colocation, plataformas de edge, soluções de nuvem privada — estendem o ambiente de nuvem pública em vez de funcionarem como um silo à parte. O Kubernetes serve como principal camada de portabilidade: a mesma aplicação containerizada roda no EKS na AWS, no GKE no Google Cloud ou em um cluster on-premises, com a troca de provedor abstraída da aplicação.
Para os times de CloudOps que gerenciam ambientes híbridos, o desafio de governança espelha o do multi-cloud: estabelecer tagging, monitoramento, controle de acesso e atribuição de custos consistentes em uma infraestrutura que abrange provedores com modelos de cobrança e observabilidade fundamentalmente distintos.
Como avaliar e comparar provedores de nuvem para o sucesso do CloudOps
A maior parte dos frameworks de avaliação de CSP vira checklist de funcionalidades: qual provedor tem Kafka gerenciado, qual entrega melhor disponibilidade de GPU, qual cobre determinado framework de compliance. Essas perguntas importam para decisões de arquitetura. Mas não respondem à pergunta que os times de CloudOps de fato enfrentam: qual relação com o provedor gera o menor atrito operacional à medida que o ambiente escala?
Quatro critérios pesam mais do que qualquer comparação de funcionalidades para os resultados de CloudOps.
Passo 1: avalie a confiabilidade operacional e o desempenho dos SLAs
Os SLAs publicados estabelecem o piso contratual de garantias de disponibilidade, mas não dizem o que de fato acontece durante um incidente. Um SLA de 99,99% de uptime permite 52 minutos de downtime por ano — e a distribuição desse downtime importa tanto quanto o total. Uma única indisponibilidade de 52 minutos no horário de pico tem um impacto bem diferente de 52 interrupções de um minuto distribuídas ao longo do ano.
Segundo o Uptime Institute Annual Outage Analysis 2025, mais da metade das organizações relata que sua interrupção significativa mais recente custou mais de US$ 100.000, e uma em cada cinco passou de US$ 1 milhão. Vale destacar: indisponibilidades atribuídas a problemas de TI e rede — categoria mais influenciada pela configuração do provedor de nuvem e pela complexidade do toolchain — subiram para 23% das interrupções de impacto em 2024.
O que avaliar além da papelada de SLA: a arquitetura de failover regional e com que rapidez o tráfego é redirecionado quando uma zona ou região se degrada. O histórico de comunicação de incidentes do provedor — ele notifica clientes de forma proativa, ou os times descobrem indisponibilidades pelo próprio monitoramento? E os caminhos de escalonamento por tier de suporte: em que ponto seu incidente chega a um engenheiro capaz de influenciar correções no nível da infraestrutura?
Passo 2: avalie a transparência de custos e o ferramental de otimização
Todo CSP relevante publica páginas de preços. Nenhum deles facilita responder à pergunta que de fato importa em produção: por que a fatura do mês passado subiu 23%, qual time é dono desse delta e qual recurso ou padrão de uso específico está por trás disso?
Transparência de custos, na prática, exige três capacidades trabalhando juntas: dados de billing exportáveis em formato consultável (AWS Cost and Usage Report, exportação de billing do GCP para o BigQuery, exportações do Azure Cost Management); tagging consistente de recursos que mapeie gastos a times e workloads; e detecção de anomalias que evidencie mudanças inesperadas de custo antes que elas se acumulem.
A distância entre o que os provedores oferecem nativamente e o que os times de CloudOps de fato precisam só aumenta em ambientes multi-cloud. O ferramental nativo de custo mostra gastos dentro de um único provedor. Não mostra que os custos de transferência de dados cross-AZ no seu ambiente AWS estão ligados ao job do BigQuery no GCP que consulta esses dados do outro lado.
Avaliar o ferramental de custos de um CSP é perguntar: a exportação de dados de billing nos dá a granularidade necessária para showback e chargeback? O sistema de tagging exige tags no momento do provisionamento ou só sinaliza violações depois? E, criticamente: o suporte do provedor a ferramentas de gestão de custos de terceiros nos permite construir uma visão unificada de toda a stack? Nosso guia de estratégias de otimização de custos em nuvem mostra como os times de CloudOps constroem a camada de atribuição que transforma exportações de billing em dados acionáveis. Para quem está avaliando ferramental de FinOps específico para AWS, nosso comparativo de ferramentas de FinOps para AWS cobre todo o cenário de opções.
Passo 3: avalie as capacidades de automação e integração
As capacidades de automação de um CSP determinam quanto overhead operacional os times de CloudOps carregam manualmente. Provedores que investiram pesado em serviços gerenciados, ferramental de infraestrutura como código e automação orientada a eventos reduzem esse overhead. Os que exigem configuração manual em cada camada o multiplicam.
Áreas-chave para avaliar:
- Maturidade de autoscaling: o autoscaling do provedor se comporta de forma previsível sob carga variável? Qual é o tempo de warm-up? Como o escalonamento interage com commitments de custo, como Reserved Instances ou Committed Use Discounts?
- Suporte a infraestrutura como código: quão bem o provedor se integra ao Terraform, Pulumi ou ferramental nativo de IaC? Suporte inconsistente a IaC cria drift entre o que está implantado e o que está documentado.
- Automação orientada a eventos: respostas operacionais — remediação, escalonamento, alertas — podem ser disparadas automaticamente a partir de eventos do provedor? Ou exigem intervenção manual no console?
- Profundidade de API e integração: o provedor expõe os dados de telemetria, custo e operação de que seu toolchain atual precisa? Provedor com cobertura de API ruim força os times a contornar suas limitações em vez de trabalhar com elas.
A ferramenta DoiT Cloud Diagrams é uma forma útil de visualizar como esses pontos de integração se conectam na sua arquitetura — veja as atualizações recentes dos recursos de diagramas de nuvem para entender como o mapeamento visual de arquitetura ajuda os times a enxergar a complexidade de integração antes que ela vire problema operacional.
Passo 4: avalie a qualidade do suporte e o acesso à expertise
A qualidade do suporte é subestimada em quase toda avaliação de CSP. Não deveria ser. Todo provedor relevante vende planos de suporte em tiers, com diferentes compromissos de tempo de resposta. A distinção que importa operacionalmente não tem nada a ver com o nome do tier ou com o SLA: importa se os engenheiros do outro lado do ticket entendem a sua arquitetura específica e conseguem, de fato, influenciar correções no nível da infraestrutura.
Nos tiers de suporte mais baixos, o suporte dos hyperscalers entrega basicamente referências de documentação e orientação de configuração. Tiers mais altos — AWS Enterprise Support, Google Cloud Premium Support, Azure Unified Support — liberam acesso a technical account managers com visibilidade no nível do provedor sobre a saúde da infraestrutura e alerta antecipado sobre degradação de serviço.
A terceira opção: contratar um Managed Service Provider (MSP) com expertise profunda no provedor e relação direta com os times de engenharia do CSP. Uma relação com MSP pode oferecer um nível de escalonamento e advocacy que a maioria das organizações não acessa pelos tiers de suporte padrão, somado à expertise operacional para resolver incidentes mais rápido do que o escalonamento tier a tier pela estrutura padrão de suporte do provedor.
Quais são as melhores práticas para gerenciar ambientes multi-cloud e híbridos?
Gerenciar múltiplos provedores de nuvem de forma consistente sempre supera, em complexidade, a operação com um único provedor. Isso não torna o multi-cloud a escolha errada — os benefícios de posicionamento de workload e resiliência continuam de pé. O que isso torna inegociável é construir as bases operacionais de forma deliberada, e não reativa.
Quatro práticas separam os times de CloudOps que gerenciam multi-cloud bem daqueles que acumulam dívida técnica a cada novo provedor que adicionam.
Como estabelecer governança consistente entre provedores de nuvem?
A governança em ambientes multi-cloud falha nas fronteiras — nos pontos em que uma política definida para AWS não se aplica a um workload no GCP, ou em que um padrão de tagging imposto em uma conta não é replicado nas outras.
Governança consistente exige políticas que vivem acima da camada do provedor, e não dentro dela. Isso significa:
- Padrões de tagging definidos e aplicados no nível da organização, não da conta. Um schema de tags que funciona para resource groups da AWS, mas não mapeia para labels do GCP, cria lacunas de atribuição que crescem a cada novo workload.
- Políticas de controle de acesso implementadas por meio de uma camada de identidade centralizada sempre que possível — identidade federada com o IAM do CSP como mecanismo de aplicação, não como fonte da verdade.
- Logs de auditoria e compliance padronizados entre provedores, agregados em um único repositório consultável, em vez de armazenados em silos específicos de cada provedor.
- Runbooks de resposta a incidentes que digam explicitamente qual provedor é dono de qual camada da stack de cada workload — para que, quando algo quebrar, propriedade e caminho de escalonamento não precisem ser descobertos sob pressão.
Como implementar gestão unificada de custos entre provedores de nuvem?
Gestão unificada de custos em ambientes multi-cloud exige mais do que agregar dados de billing de múltiplos provedores. Exige um modelo comum de atribuição — uma resposta consistente para "qual time, produto ou unidade de negócio é dono deste custo?" — que se sustente independentemente de qual provedor gerou a cobrança. A prática de FinOps da DoiT trata exatamente desse problema em AWS, GCP e Azure.
Os passos práticos:
- Exporte os dados de billing de todos os provedores para um único repositório consultável. AWS CUR para o S3, exportação de billing do GCP para o BigQuery e exportações do Azure Cost Management para o Azure Storage produzem dados de billing brutos. Levá-los a um formato comum, ou usar uma plataforma unificada de gestão de custos que ingere os três, viabiliza análise cross-provider.
- Imponha tagging consistente entre provedores usando políticas no nível da organização. Tags que existem na AWS, mas não no GCP, criam lacunas de showback que os times de finanças não conseguem reconciliar.
- Faça análise de cobertura de commitments por provedor, separadamente. AWS Reserved Instances e Savings Plans, GCP Committed Use Discounts e Azure Reserved VM Instances têm mecânicas distintas. Otimizar a cobertura de commitments exige entender o modelo de cada provedor, não aplicar uma estratégia única aos três.
- Defina limites de detecção de anomalia no nível do workload, não só no nível da conta. Um alerta de conta que dispara quando o gasto total sobe 20% deixa passar o pico no nível do time que está, de fato, por trás dele.
Como manter padrões de segurança e compliance entre provedores?
A postura de segurança em ambientes multi-cloud se degrada nas bordas — nos pontos em que uma má configuração nos controles de acesso de um provedor expõe dados ou serviços em outro. Os modos de falha mais comuns: roles de IAM cross-cloud excessivamente permissivas, políticas de criptografia inconsistentes entre camadas de armazenamento e frameworks de compliance aplicados em um provedor, mas não replicados nos demais.
O baseline operacional para segurança multi-cloud:
- Princípio do menor privilégio aplicado de forma consistente em todos os provedores. Uma service account com permissões amplas em uma nuvem não deve ser o modelo de como o acesso é concedido em outra.
- Criptografia em repouso e em trânsito imposta por política, não por convenção. Os defaults variam entre provedores — presumir que a criptografia está habilitada sem verificar cria lacunas que auditorias de compliance trazem à tona no pior momento possível.
- Varredura de segurança e detecção de má configuração rodando continuamente em todas as contas de provedor. A superfície de ataque em um ambiente multi-cloud cresce com o número de contas, serviços e pontos de integração — não apenas com o volume de workloads.
- Limites de responsabilidade compartilhada documentados para cada provedor e cada tier de serviço. O que o CSP cuida e o que o time de CloudOps cuida varia por serviço — Kubernetes gerenciado transfere a responsabilidade pelo control plane ao provedor, mas a segurança do runtime de containers continua sendo do time.
Como otimizar o posicionamento de workloads e a movimentação de dados entre provedores?
Decisões de posicionamento de workload trazem consequências diretas de custo e desempenho que se acumulam ao longo do tempo. Um workload colocado no provedor errado para seu padrão de uso gera custo excedente todo mês, e o custo de movê-lo aumenta à medida que volumes de dados crescem e serviços dependentes se multiplicam.
O framework prático para posicionamento de workloads:
- Mantenha a computação perto dos dados. Os custos de transferência de dados cross-provider se acumulam mais rápido do que quase qualquer outra categoria de custo de nuvem. Uma aplicação na AWS consultando um banco de dados no GCP paga taxas de egress em cada query. Projetar para localidade dos dados — mantendo computação e armazenamento no mesmo provedor e região sempre que possível — é uma das decisões arquiteturais de maior alavancagem para controle de custo de rede.
- Combine as características do workload com os pontos fortes do provedor. Workloads de analytics data-intensive se encaixam no modelo BigQuery do GCP. Workloads corporativos com dependências Microsoft se encaixam no Azure. Workloads de propósito geral com requisitos complexos de serviços gerenciados se encaixam no catálogo mais amplo da AWS.
- Avalie custos de movimentação de dados antes de adicionar um novo provedor. Trazer um novo CSP para a stack significa novos custos de egress em cada ponto de integração. Esse cálculo precisa acontecer antes de implantar o workload, não depois do primeiro ciclo de billing.
- Trate o Kubernetes como camada de portabilidade. Workloads baseados em containers rodando em Kubernetes gerenciado podem migrar entre provedores sem mudanças na aplicação. Essa portabilidade reduz o risco de lock-in e viabiliza a otimização do posicionamento de workloads ao longo do tempo.
Escolhendo a estratégia de provedor de nuvem certa para o seu time de CloudOps
Nenhum provedor de nuvem entrega tudo de forma perfeita. A AWS lidera em amplitude de serviços. O Google Cloud lidera em workloads de dados. O Azure lidera em integração corporativa. Plataformas especializadas resolvem problemas específicos melhor do que qualquer hyperscaler. O objetivo não é eleger um vencedor — é construir uma estratégia de CSP que produza resultados operacionais previsíveis e gastos defensáveis à medida que os workloads escalam.
Os times que gerenciam multi-cloud bem não padronizam um provedor; padronizam a camada acima do provedor. Monitoramento unificado, tagging consistente, atribuição cross-provider e políticas de governança que não dependem do ferramental de um único fornecedor criam alavancagem que escala com o ambiente, em vez de empilhar overhead.
Os times que sofrem acumulam ferramental específico de provedor, processos específicos de provedor e silos de conhecimento específicos de provedor. Cada novo CSP adicionado à stack multiplica a superfície operacional, em vez de se somar a ela de forma limpa.
Conheça toda a gama de soluções DoiT para times de CloudOps e FinOps; ou, se o seu ambiente já ficou mais complexo do que o ferramental atual consegue governar, fale com o nosso time sobre como outras organizações de CloudOps abordaram esse cenário.