- Modelos de Isolamento de Sandbox
- Política de Egresso e Rede do Sandbox
- Acesso a Arquivos e Sistema de Arquivos do Host
- Estado da Sessão e Persistência
- Instalações de Pacotes e Dependências de Tempo de Execução
- Segredos e Tratamento de Credenciais
- Logs de Auditoria e Observabilidade
- Conformidade e Revisão de Segurança
- Preços do Sandbox e Fatores de Custo
- Autohospedagem vs. Sandbox de Agente de IA Gerenciado
- Artigos Recomendados
Os sandboxes de agentes de IA isolam o código gerado dos sistemas hospedeiros, mas os detalhes — como o isolamento funciona, que acesso de rede os agentes têm, para onde os arquivos vão, como os segredos são tratados — variam significativamente entre as implementações. Esta FAQ consolida as perguntas mais comuns em uma única referência, com apontamentos para os artigos mais aprofundados em cada área.
Modelos de Isolamento de Sandbox
O que significa “isolamento” em um sandbox de agente de IA?
Isolamento significa que o código, arquivos, processos e acesso à rede do agente estão confinados a um ambiente delimitado que não pode afetar o sistema hospedeiro ou outros inquilinos. Na prática, o isolamento é um espectro: isolamento em nível de processo usa primitivas do SO (namespaces, cgroups, seccomp) para restringir chamadas de sistema e acesso a recursos; o isolamento de contêiner adiciona uma fronteira de sistema de arquivos e namespace de rede; e o isolamento de microVM envolve a carga de trabalho em uma máquina virtual leve com seu próprio kernel convidado. Cada passo acima na pilha aumenta a força da fronteira ao custo de alguma sobrecarga de inicialização e complexidade operacional. Consulte Firecracker para Sandboxes de Agente de IA para uma estrutura de avaliação detalhada.
O Docker é suficiente para executar código gerado por agente?
Os contêineres fornecem imagens repetíveis e bons controles de recursos, mas todos os contêineres no mesmo host compartilham o kernel do host. Uma vulnerabilidade do kernel, ou uma chamada de sistema que passe pelo filtro seccomp, pode afetar outras cargas de trabalho. Para tarefas de baixo risco e curta duração executando código confiável ou quase confiável, os contêineres são frequentemente adequados quando devidamente endurecidos — sem modo privilegiado, capacidades mínimas, sem montagem do socket Docker, sistema de arquivos raiz somente leitura quando possível. Para código gerado por IA não confiável que pode instalar pacotes, criar subprocessos ou chamar comandos shell arbitrários, uma fronteira mais forte vale a pena ser avaliada. A resposta depende do seu modelo de ameaça real. Consulte Sandbox de Código Gerado por IA: Requisitos para Aplicações de Produção para a lista de verificação em cada nível de isolamento.
Qual é a diferença entre isolamento de contêiner e microVM?
A diferença principal é a fronteira do kernel. Contêineres compartilham o kernel do host; microVMs executam cada um um kernel convidado dentro de uma máquina virtual leve, apoiada por virtualização de hardware (KVM). Um sandbox baseado em microVM usando tecnologia como Firecracker fornece uma fronteira do tipo VM sem a sobrecarga total de uma VM tradicional: a latência de inicialização é projetada para ser rápida, o modelo de dispositivo é mínimo para reduzir a superfície de ataque, e o convidado é isolado do kernel do host por design. A implicação prática é que uma exploração do kernel no convidado não afeta automaticamente o host ou outros convidados, enquanto em um modelo de contêiner de kernel compartilhado isso pode acontecer. Consulte Firecracker para Sandboxes de Agente de IA para onde a fronteira de microVM ajuda e onde ela não resolve todo o problema.
Existe um sandbox por agente, por usuário ou por tarefa?
Isso depende da plataforma e de como a aplicação é projetada. O padrão mais seguro para aplicações multi-inquilino é um ambiente de sandbox isolado por execução de agente ou por tarefa — ou seja, cada sessão de usuário tem sua própria árvore de processos, sistema de arquivos, namespace de rede e escopo de credenciais. Compartilhar um sandbox entre usuários ou entre tarefas não relacionadas é a fonte mais comum de vazamento de estado em aplicações de agente em produção. Ao avaliar uma plataforma, verifique se as sessões concorrentes são isoladas nos níveis de sistema de arquivos, processo e rede, e não apenas no nível de roteamento de API. Consulte Sandbox de Código Gerado por IA: Requisitos para Aplicações de Produção para a lista de verificação de isolamento por sessão.
Política de Egresso e Rede do Sandbox
Um agente de IA pode fazer chamadas de rede de saída a partir de um sandbox?
Depende da política de egresso do sandbox. Por padrão, muitos sandboxes permitem conexões de saída, o que é conveniente para pesquisa na web, chamadas de API e instalações de pacotes. Para cargas de trabalho de produção executando código não confiável, o egresso aberto por padrão é um risco: um agente comprometido ou malcomportado pode exfiltrar dados, alcançar serviços internos de metadados ou puxar código inesperado de URLs arbitrárias. Uma postura de produção mais forte é negar egresso por padrão com uma lista de permissões explícita de destinos permitidos. Qualquer política que você escolher, deve ser explícita e registrada. Consulte Firecracker para Sandboxes de Agente de IA para como avaliar controles de rede.
Como o DNS é controlado em um sandbox?
O DNS é uma lacuna comum na política de egresso: uma lista de permissões para destinos HTTP não restringe automaticamente a resolução de DNS. Um agente que pode resolver nomes de domínio arbitrários pode inferir topologia de rede, sondar nomes internos ou usar DNS como um canal lateral, mesmo quando o HTTP está bloqueado. Para uma política de egresso coerente, a resolução de DNS deve ser tratada de forma consistente — seja apontando para um resolvedor interno que respeite a lista de permissões, ou restringindo a resolução a domínios aprovados. Verifique com seu provedor de sandbox como o DNS é escopo em relação à política de egresso mais ampla.
Como as buscas de pacotes são controladas durante sessões com restrição de rede?
Instalações de pacotes são operações de rede. Se o egresso estiver restrito a uma lista de permissões, a lista deve incluir os registros de pacotes que o agente precisa legitimamente, ou o sandbox deve fornecer um cache de pull-through dentro da rede confiável. O cache de pull-through tem o benefício adicional de servir como um ponto de inspeção: você pode ver quais pacotes são buscados, detectar dependências inesperadas e reduzir o egresso redundante. Algumas equipes usam modelos de sandbox pré-construídos para cargas de trabalho onde a reprodutibilidade é mais importante que a flexibilidade, o que elimina totalmente as buscas de pacotes em tempo de execução. Consulte a seção Instalações de Pacotes para mais sobre como governar instalações em tempo de execução.
Acesso a Arquivos e Sistema de Arquivos do Host
Que acesso a arquivos um agente em sandbox tem?
Um agente em sandbox deve ter acesso apenas aos arquivos explicitamente montados em seu espaço de trabalho. Para um agente de codificação, isso pode ser um repositório verificado e um diretório de trabalho para artefatos gerados. Para um agente de análise de dados, isso pode ser um CSV enviado e uma pasta de saída. O agente não deve ser capaz de alcançar o sistema de arquivos do host, espaços de trabalho de outros inquilinos, segredos do servidor de aplicação ou diretórios do sistema fora de seus caminhos montados. Uma boa prática é montar o material de origem como somente leitura e fornecer um diretório de saída separado de leitura e escrita para artefatos gerados. Consulte Sandbox de Servidor MCP: Servidores MCP Isolados com Controles de Sistema de Arquivos, Segredos e Rede para como escopear montagens de sistema de arquivos por ferramenta.
O sistema de arquivos do host está acessível de dentro de um sandbox?
Não deveria estar. Um sandbox configurado corretamente — contêiner ou microVM — restringe a visão do agente ao seu próprio sistema de arquivos convidado. Acessar o sistema de arquivos do host de dentro de um sandbox é uma falha de configuração, não um comportamento esperado. Erros comuns que quebram essa fronteira incluem montar diretórios amplos (como o diretório home de um desenvolvedor ou /), usar modo privilegiado em contêineres ou montar o socket Docker dentro do sandbox. Ao avaliar uma plataforma ou construir a sua própria, verifique o que está montado, quais são as permissões do sistema de arquivos raiz e se escapes de link simbólico ou truques de extração de arquivo podem alcançar caminhos fora do espaço de trabalho pretendido.
O que acontece com os arquivos após o término de uma sessão?
Para sessões efêmeras, o diretório de trabalho e todos os arquivos gerados são destruídos quando a sessão termina. Este é o padrão correto para conclusão de código, execuções de avaliação e qualquer tarefa onde a reprodutibilidade importa mais que a continuidade. Para espaços de trabalho persistentes (agentes de codificação de longa duração, sessões de desenvolvimento iterativas), os arquivos podem sobreviver entre chamadas de execução dentro de uma sessão e podem ser mantidos após o término da sessão se a plataforma suportar persistência ou snapshots do espaço de trabalho. As perguntas-chave a responder são: quem é o proprietário de um espaço de trabalho mantido, quando ele é limpo e se o espaço de trabalho de um usuário pode vazar para o de outro? Consulte Sandbox de Código Gerado por IA: Requisitos para Aplicações de Produção para a lista de verificação do modelo de persistência.
Estado da Sessão e Persistência
Uma sessão de sandbox é com estado ou efêmera?
Ambos os padrões existem e servem a diferentes cargas de trabalho. Sessões efêmeras começam de uma linha de base limpa para cada tarefa — sem pacotes, arquivos ou histórico acumulados. São mais fáceis de raciocinar e ideais para execuções de avaliação ou execução de código única. Sessões com estado preservam arquivos, pacotes instalados, histórico do shell e estado do ambiente em várias chamadas de execução, o que é necessário para agentes de codificação de várias etapas, análise de dados interativa e fluxos de trabalho de longa duração. A maioria das plataformas de produção suporta ambos. A troca é que sessões com estado exigem políticas de limpeza explícitas e isolamento de inquilino mais cuidadoso.
Por quanto tempo o estado persiste em um sandbox gerenciado?
A duração da sessão varia conforme a plataforma e o plano. Alguns provedores definem um tempo limite de sessão padrão (comumente 60 minutos a 24 horas), após o qual a sessão é encerrada e o estado é perdido, a menos que seja persistido em um snapshot ou armazenamento externo. Fluxos de trabalho de agente de longa duração — sessões que podem pausar entre chamadas de LLM por minutos ou horas — precisam de uma plataforma que suporte pausa e retomada ou pausa automática para evitar cobrança por tempo ocioso, preservando o estado. Verifique o comprimento máximo da sessão e o que acontece com o estado em andamento quando ocorre um tempo limite. O Novita Agent Sandbox suporta sessões de até 24 horas e documenta um recurso de Pausa/Retomada Automática para gerenciar tempo ocioso. Consulte Novita Sandbox: Uma Alternativa Econômica ao E2B Pro com Compatibilidade Perfeita para uma comparação de funcionalidades.
As sessões podem ser pausadas e retomadas?
Algumas plataformas suportam pausa e retomada, onde a sessão é suspensa para o disco e pode ser reiniciada posteriormente a partir do mesmo estado. Isso é útil para agentes que aguardam respostas do LLM entre etapas, para limitar cargas de trabalho caras e para sessões que abrangem múltiplas interações do usuário ao longo do tempo. Os principais pontos a verificar são: por quanto tempo uma sessão pausada pode permanecer suspensa, o que acontece com as conexões de rede mantidas durante uma pausa e se as credenciais injetadas no início da sessão permanecem válidas após a retomada ou precisam ser atualizadas.
O estado do sandbox pode ser capturado em snapshot e reutilizado?
Modelos e snapshots são relacionados, mas distintos. Um modelo é um ambiente de linha de base pré-construído — runtimes, ferramentas, pacotes aprovados — a partir do qual novas sessões começam. Um snapshot captura o estado atual de uma sessão em execução e o usa como ponto de partida para sessões futuras. Modelos reduzem a sobrecarga de inicialização por sessão e garantem que todos os agentes comecem a partir de uma linha de base consistente e governada. Snapshots são úteis para preservar trabalho parcial ou iniciar trabalhos iterativos aquecidos. Ambos precisam de governança: quem pode criá-los, quem pode lê-los, a qual inquilino pertencem e como são versionados.
Instalações de Pacotes e Dependências de Tempo de Execução
Os agentes podem instalar pacotes em tempo de execução?
A maioria dos ambientes de sandbox permite instalações de pacotes em tempo de execução (pip install, npm install, apt-get, etc.) por padrão, porque muitas cargas de trabalho de agente precisam delas. A questão não é se as instalações são permitidas, mas se cada instalação é governada. Instalações de pacotes não governadas são uma das operações de maior risco em um sandbox: elas puxam código externo para o ambiente de execução em tempo real, podem incluir scripts pós-instalação que executam comandos arbitrários e podem introduzir risco de cadeia de suprimentos.
Quais políticas governam as instalações de pacotes em tempo de execução?
Uma política de pacotes de produção normalmente inclui alguma combinação de lista de permissões de registros (buscar apenas de registros ou mirrors de pacotes aprovados), caches de pull-through (inspecionar o que entra antes de executar), registro de instalação (gravar o nome do pacote, versão, origem e resultado para cada instalação) e modo offline opcional (pré-construir dependências no modelo e proibir instalações em tempo de execução para pipelines de avaliação onde a reprodutibilidade importa). A política certa depende da carga de trabalho: um agente de codificação ajudando um desenvolvedor a depurar código pode precisar de acesso flexível a pacotes; um pipeline de avaliação automatizado provavelmente deve ser executado a partir de um ambiente congelado. Consulte Construa um Analista de Dados de IA com Python em Sandbox e Acesso Controlado a Pacotes para um exemplo de implementação prática.
Segredos e Tratamento de Credenciais
Como segredos e credenciais são tratados em um sandbox?
Segredos devem ser injetados de forma estreita — apenas a credencial que uma tarefa específica precisa, pela duração dessa sessão. O antipadrão comum é montar um arquivo de ambiente amplo contendo todas as chaves de API em cada sessão; isso significa que qualquer sessão, se comprometida, pode acessar todas as credenciais nesse arquivo. Prefira tokens de curta duração com escopo para a tarefa, e prefira mecanismos de injeção (variáveis de ambiente ou arquivos montados) em vez de codificação fixa. Para as credenciais mais sensíveis, uma API de segredos em tempo de execução que fornece valores apenas a um processo explicitamente autorizado oferece isolamento mais forte do que uma variável de ambiente plana disponível para todos os processos.
O modelo pode ver variáveis de ambiente injetadas no sandbox?
Sim, se a variável de ambiente for injetada no processo onde o código do modelo é executado. As variáveis de ambiente são visíveis para todos os processos na mesma sessão por padrão. O modelo não pode lê-las diretamente de sua janela de contexto, mas o código gerado que é executado dentro do sandbox pode lê-las com os.environ, process.env ou equivalente. É por isso que o escopo estreito é importante: injete apenas as credenciais que a tarefa requer, e prefira tokens de curta duração para que uma credencial vazada tenha uma janela de utilidade limitada. A redação é responsabilidade da aplicação: não registre stdout completo por padrão se segredos podem aparecer em mensagens de erro ou instruções de impressão.
O que acontece com os segredos quando uma sessão termina?
Variáveis de ambiente e arquivos de segredo montados devem ser limpos como parte do encerramento da sessão. Se a plataforma preserva o estado entre sessões (snapshots, volumes persistentes), verifique se as credenciais gravadas no sistema de arquivos ou armazenadas em cache por um provedor de credenciais também são limpas ou rotacionadas. Credenciais obsoletas em um snapshot retomável são um risco — após o encerramento da sessão, o snapshot não deve reter tokens que eram válidos apenas para a duração da sessão original.
Logs de Auditoria e Observabilidade
Quais eventos são registrados em um sandbox?
Registros de auditoria úteis de sandbox incluem criação e encerramento de sessão (ID da sessão, inquilino, versão do modelo, alocação de recursos, duração), eventos de execução (qual código ou categoria de comando foi executado, hora de início/término, status de saída), instalações de pacotes (nome, versão, origem, resultado), contatos de rede de saída (domínios, IPs, portas), arquivos lidos ou gravados de caminhos específicos e resultado da limpeza. O objetivo é tornar o comportamento do agente reconstruível após o fato, sem transformar o log de auditoria em um segundo armazenamento de segredos. Arquivos brutos de clientes, saída completa de comandos e prompts completos geralmente não pertencem a logs de auditoria, a menos que sua retenção e controles de acesso sejam especificamente projetados para esses dados.
Quem pode acessar os logs de auditoria?
Os controles de acesso aos logs de auditoria devem ser escopo para o operador e, quando relevante, para o inquilino. Em plataformas multi-inquilino, os registros de auditoria de um inquilino não devem ser visíveis para outros inquilinos. Para implantações sensíveis à conformidade, a trilha de auditoria precisa ser à prova de violação, retida pelo período exigido e acessível a revisores autorizados (equipe de segurança, oficial de conformidade) sob demanda. Pergunte ao seu provedor de sandbox qual período de retenção de logs é fornecido por padrão, se os logs podem ser exportados para seu próprio SIEM ou armazenamento e quais controles de acesso protegem os dados dos logs.
Conformidade e Revisão de Segurança
Que revisão de conformidade é necessária antes de usar um sandbox em produção?
Os requisitos específicos dependem do seu setor e jurisdição, mas as perguntas padrão para qualquer sistema de agente em produção incluem: quais dados entram no sandbox (e esses dados estão sujeitos a GDPR, HIPAA, SOC 2 ou outras estruturas), onde o sandbox está hospedado e isso satisfaz os requisitos de residência de dados, qual é o modelo de isolamento e você pode documentá-lo para um auditor, como as credenciais são gerenciadas e rotacionadas, e como é a trilha de auditoria? A maioria das revisões de segurança também perguntará se o código gerado poderia alcançar bancos de dados de produção, superfícies administrativas internas ou dados de clientes fora do escopo pretendido. Estes são controles arquiteturais, não apenas certificações de fornecedores.
Que perguntas as equipes de segurança devem fazer ao avaliar um sandbox de agente de IA?
Uma lista de verificação prática de avaliação para revisão de segurança:
- Isolamento: Qual é a fronteira — processo, contêiner ou microVM? Cada sessão de agente está isolada nos níveis de sistema de arquivos, processo e rede?
- Egresso: Qual é a política de egresso padrão? Os destinos de saída podem ser colocados em lista de permissões? Como o DNS é controlado?
- Segredos: Como as credenciais são injetadas? Elas têm escopo para a tarefa? São limpas no encerramento da sessão?
- Auditoria: Quais eventos são registrados? Quem pode acessar os logs? Qual é o período de retenção?
- Residência de dados: Onde os sandboxes estão hospedados? A implantação pode ser escopo para uma região ou conta de nuvem específica?
- Postura de conformidade: O provedor possui certificações relevantes (SOC 2, ISO 27001)? Qual é o modelo de responsabilidade compartilhada?
- Alcance de rede: Um sandbox pode alcançar serviços internos de metadados, APIs privadas ou recursos de outros inquilinos? Como o movimento lateral é prevenido?
Enquadre estas como perguntas a serem avaliadas, não como requisitos que qualquer fornecedor individual atenda automaticamente. Alegações de segurança e conformidade na documentação do fornecedor devem ser verificadas contra os documentos atuais do produto, não aceitas pelo valor nominal. Para equipes com requisitos regulatórios ou contratuais, peça à sua equipe de segurança para concluir a revisão antes da implantação em produção, não depois.
Quando o BYOC (traga sua própria nuvem) ou implantação VPC é relevante?
Requisitos de residência de dados, políticas de segurança de rede ou restrições regulatórias que proíbem dados de sair de uma conta de nuvem específica são as principais razões pelas quais as equipes escolhem BYOC ou implantação VPC em vez de um serviço gerenciado compartilhado. Executar sandboxes dentro de sua própria VPC da AWS ou GCP significa que o ambiente de execução está dentro do perímetro da sua rede, os controles de acesso da sua conta de nuvem se aplicam e o egresso do sandbox pode ser governado por suas políticas de rede existentes. A troca é a responsabilidade operacional: você gerencia a infraestrutura, aplicação de patches e dimensionamento. O Novita Agent Sandbox documenta a implantação BYOC em contas AWS ou GCP como um recurso para equipes com esses requisitos. Verifique a disponibilidade atual e opções de configuração na documentação do Novita Agent Sandbox.
Preços do Sandbox e Fatores de Custo
O que impulsiona os custos do sandbox?
Os custos do sandbox são tipicamente uma combinação de tempo de computação (vCPU e memória cobrados por segundo ou por minuto), sobrecarga de sessão (uma taxa de inicialização por sessão em algumas plataformas), armazenamento persistente acima do nível gratuito incluído e transferência de dados de saída (egresso). O peso relativo de cada um depende da sua carga de trabalho: um interpretador de código de sessão curta é principalmente computação; um agente de automação de navegador que baixa arquivos grandes pode gerar egresso significativo; um espaço de trabalho de codificação persistente acumulará armazenamento. O tratamento do tempo ocioso é um grande diferencial — plataformas com pausa automática param de cobrar quando um sandbox está esperando uma resposta do LLM, o que pode reduzir custos significativamente para fluxos de trabalho interativos. Consulte Modelos de Preços de Sandbox de Agente de IA: Por Sessão, Computação, Armazenamento e Egresso para uma análise detalhada de cada eixo de preço.
Como o tempo de sessão, computação e egresso interagem no custo?
Para a maioria das cargas de trabalho, o tempo de computação domina. Uma sessão de codificação de 10 minutos em 1 vCPU custa mais que 1 GB de egresso a taxas típicas. Mas a interação importa para cargas de trabalho específicas: um agente de dados que baixa um grande conjunto de dados de treinamento gerará cobranças de egresso que superam o custo de computação. Um agente de navegador que mantém sessões abertas entre turnos do LLM acumulará computação ociosa se a pausa automática não estiver ativada. A abordagem prática é estimar cada dimensão em relação ao seu perfil de carga de trabalho real antes de se comprometer com uma plataforma. O Novita Agent Sandbox cobra por segundo com base no uso real de vCPU e memória, sem taxa de inicialização por sessão; a partir de meados de 2026, 1 vCPU custa $0,0000098/s. (Fonte: página de preços da Novita AI, verificado na documentação publicada. Sempre verifique as taxas atuais antes do planejamento orçamentário.)
Autohospedagem vs. Sandbox de Agente de IA Gerenciado
Quando as equipes devem auto-hospedar em vez de usar um sandbox gerenciado?
A autohospedagem (executar sua própria infraestrutura de sandbox, frequentemente no Firecracker ou uma camada de microVM comparável) faz sentido quando: requisitos de residência de dados ou política de rede proíbem o uso de um serviço gerenciado de terceiros, o volume de carga de trabalho é alto o suficiente para que o custo do serviço gerenciado exceda o custo operacional de executar sua própria infraestrutura, ou a equipe tem capacidade de engenharia de plataforma existente e deseja controle total sobre o modelo de isolamento, governança de imagens e política de rede. A autohospedagem é mais difícil do que parece: gerenciar kernels, sistemas de arquivos raiz, imagens, snapshots, limitadores de taxa, métricas, limpeza e isolamento multi-inquilino é trabalho real. Consulte Firecracker para Sandboxes de Agente de IA para saber como é o escopo operacional.
Quando um sandbox gerenciado faz mais sentido?
Para a maioria das equipes construindo agentes de codificação, ferramentas de análise de dados, fluxos de trabalho de automação de navegador ou pipelines de avaliação, um sandbox gerenciado é o caminho mais rápido para a produção. A plataforma cuida do provisionamento de infraestrutura, endurecimento de segurança, atualizações de imagem, dimensionamento e gerenciamento do ciclo de vida. A equipe se concentra na arquitetura do agente, não nos detalhes internos do sandbox. A comparação de custos não é apenas as taxas de computação em nuvem: leve em consideração o tempo de engenharia para construir e manter a camada de isolamento, o trabalho de conformidade para documentá-la e a resposta a incidentes quando algo inesperado acontece. Para equipes sem capacidade de engenharia de plataforma dedicada, os serviços gerenciados geralmente chegam à produção mais rápido e mantêm um custo total de propriedade mais baixo. Consulte Modelos de Preços de Sandbox de Agente de IA para uma estrutura para comparar o custo total gerenciado vs. autohospedado.
Que perguntas as equipes devem fazer ao avaliar provedores de sandbox gerenciado?
Perguntas práticas de avaliação além do preço principal:
- Qual é o modelo de isolamento por sessão (microVM, contêiner, processo)?
- Qual é a política de egresso padrão e configurável?
- Quais opções de governança de instalação de pacotes existem?
- Como os segredos são injetados e limpos?
- Quais dados de log de auditoria estão disponíveis e como são acessados?
- Quais são os limites de comprimento de sessão e concorrência no seu nível necessário?
- O provedor suporta BYOC ou implantação VPC?
- Qual é o comportamento de pausa/retomada e como isso afeta o faturamento?
- Como a latência de inicialização se comporta em escala (pool aquecido, snapshot, inicialização a frio)?
