Nuvem do cliente (BYOC): o que prometer

Selo de estado: Preview (teto atual do produto) · Curso ACD-260 — Arquitetura de solução · Aula 5 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai separar control plane de data plane e posicionar chave cifrada (Preview) de keyless (Roadmap) — e vai saber a frase exata que entra numa proposta sem virar promessa.

Vídeo#

Identificador: acd-260-05-nuvem-do-cliente-byoc · Duração-alvo: 7 min · Tela: /settings.

Roteiro de gravação (5 capítulos):

Conteúdo#

A linha que divide tudo

BYOC ("bring your own cloud") é sobre o data plane, nunca sobre o control plane. Em Configurações → Workspace existe o cartão "Cloud própria (Enterprise)", que descreve exatamente isso: o datalake (BigQuery + landing no GCS) roda no projeto GCP do cliente — os dados não saem da conta Google dele, e os custos de nuvem são faturados direto pela Google para ele. Sem isso, o workspace usa o projeto compartilhado da plataforma.

O control plane continua sendo nosso em qualquer arranjo: a aplicação, o cadastro, a orquestração, as credenciais cifradas e a interface seguem rodando na ingestia.io. BYOC não é "a ingestia.io instalada no cliente"; é o dado residindo na conta dele enquanto o cérebro continua aqui.

Na resolução de recursos isso aparece de forma concreta: com BYOC, o produto resolve bucket e conta de serviço do próprio workspace, não do projeto compartilhado.

Os dois arranjos — e por que só um existe

Aqui está o posicionamento que esta aula existe para fixar:

A distinção importa porque é exatamente a pergunta que a revisão de segurança de um cliente grande faz: "vocês suportam Workload Identity Federation, sem chave estática?" A resposta honesta é não, hoje é chave de conta de serviço cifrada. Responder "sim, temos BYOC" a essa pergunta é prometer o Roadmap como se fosse Preview — e o preço disso aparece na auditoria do cliente, não na reunião.

Vale lembrar também o único recurso que depende de nuvem própria: o modo de atualização ao vivo (rt). batch existe em todos os planos e near_rt do Growth para cima; rt só com BYOC (aula 2). Ou seja: quem pede tempo real está pedindo BYOC, mesmo sem saber.

Quando BYOC é a resposta certa

Quando BYOC é armadilha

Para a Comércio Aurora — 42 pessoas, plano Growth, uma pessoa cuidando de dados — o pedido "queremos no nosso Google" aparece com frequência, e a resposta de arquitetura é não agora. As razões, na ordem em que convencem:

1. Alguém passa a operar um projeto GCP. Cota, IAM, billing, alerta de orçamento e rotação de chave viram responsabilidade do cliente. A Maria, que já acumula suporte interno, herda um projeto de nuvem.
2. O arranjo é Preview e sem SLA. Pedir que a operação crítica dependa de um caminho sem SLA, para ganhar o que a Aurora não precisa hoje, é trocar risco por nada.
3. Ele é add-on do Business. No Growth, BYOC não está incluído: a conversa é de upgrade de plano, não de configuração.
4. A dor real dela não era localização do dado. Era o painel pronto antes das 8h — que a agenda noturna resolve (aula 1).

A recusa escrita, para a proposta: "o data plane pode rodar na conta GCP de vocês hoje, com chave de conta de serviço cifrada, em Preview e sem SLA; keyless (WIF) é Roadmap; o control plane é sempre nosso. Para o que vocês precisam agora — o número de ontem pronto antes das 8h — nada disso é necessário, e eu não recomendaria assumir a operação de um projeto GCP por isso."

O que nunca entra na promessa

• Uptime e disponibilidade (99,x%) — BLOCKED no registro de claims: não medido.
• RPO/RTO como compromisso contratual — não medido.
• Latência e throughput de consulta em nuvem — não medidos.
• Custo faturado em BRL — hoje é estimativa, não preço garantido (aula 7).
• Isolamento entre clientes "provado em produção" — é fail-closed por desenho e coberto por testes; a certificação com IAM real em nuvem está pendente.

Ter esses cinco itens de cor é metade do trabalho de um arquiteto de soluções numa negociação: o que o produto faz é generoso, e o que ele não mede não se promete.

Erros comuns de posicionamento

• Vender "BYOC keyless". É Roadmap — a arquitetura não foi construída.
• Dizer que a plataforma roda na nuvem do cliente. Só o data plane; o control plane é sempre nosso.
• Oferecer BYOC como se fosse configuração. É add-on no Business, incluído no Scale+, e é Preview.
• Prometer SLA junto com BYOC. BYOC move o dado, não cria compromisso de disponibilidade.
• Esquecer que rt depende de BYOC. Prometer ao vivo no Growth é prometer BYOC sem dizer.
• Dar número de uptime, RPO ou RTO. Não foram medidos; não há número a dar.

Faça você mesmo#

Esta aula é de conhecimento: não há exercício operacional — a decisão aqui é de posicionamento, e o artefato é um texto de proposta. Escreva, por conta própria:

1. O parágrafo de uma proposta que explica BYOC separando control plane (sempre nosso) de data plane (podendo rodar na conta do cliente).
2. A frase que posiciona chave cifrada = Preview, sem SLA e keyless/WIF = Roadmap, sem transformar roadmap em promessa.
3. A linha que diz quem paga a nuvem no arranjo BYOC (a Google fatura direto o cliente) e o que isso muda na sua estimativa de custo.
4. A lista dos cinco itens que você não promete: uptime, RPO/RTO, latência, custo em BRL faturado, isolamento "provado em produção".
5. A recusa para uma PME sem time de nuvem — com as duas consequências operacionais que ela estaria assumindo.
6. A resposta de uma linha para "vocês suportam Workload Identity Federation?".

Você terminou quando: você consegue ler o texto em voz alta para um cliente, ele entende onde o dado dele fica, e nenhuma frase do seu texto promete algo que não foi medido nem chama Roadmap de disponível.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• administracao/planos
• data/custo-limites-seguranca
• suporte/status-e-limitacoes
• administracao/ambientes-e-promocao

Capacidades ensinadas#

C12.6 · C12.1 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".