Resumo

  • A Cloudflare lista transferência de saída a US$ 0 por GB nas duas classes de armazenamento do R2. Na Infrequent Access, porém, a recuperação de dados custa separadamente US$ 0,01 por GB, além das operações e do armazenamento. São condições de tabela consultadas em 19 de setembro de 2026, não uma redução de preços identificada nessa data.
  • Existe um caminho documentado para retirar objetos: a orientação da Cloudflare para Rclone inclui uma cópia do R2 para um destino local. Isso demonstra uma possibilidade operacional descrita, não uma migração de produção realizada ou a substituição completa de uma aplicação.
  • Em um cálculo ilustrativo com 1.000 GB-mês, a diferença bruta entre os componentes de armazenamento é de US$ 5. Recuperar 500 GB na Infrequent Access acrescentaria os mesmos US$ 5, antes das diferenças entre operações e dos demais ajustes. A conclusão não é que essa classe sempre custe mais: é que o perfil de acesso importa.

No R2 da Cloudflare, a linha de transferência de saída pode permanecer zerada enquanto a conta necessária para retirar e reutilizar os dados continua crescendo. Não há contradição. Transferir bytes para fora, recuperar dados de uma classe de armazenamento e executar solicitações são grandezas diferentes. Colocá-las sob o mesmo rótulo de “custo de saída” esconde justamente o mecanismo econômico que o cliente precisa compreender.

A vantagem do egress zero é específica: esse item tarifário não acrescenta uma cobrança por GB transferido para fora. Isso tem valor mesmo quando outras despesas permanecem. O erro seria dar o salto seguinte sem evidência e concluir que uma migração inteira é gratuita, que o serviço de destino será equivalente ou que a empresa já dispõe de uma alternativa pronta para entrar em operação.

A documentação oferece algo mais sólido que uma promessa comercial isolada. Além da tabela de preços, a Cloudflare descreve uma maneira de copiar um objeto para fora do R2. O procedimento torna a saída testável. Ainda assim, demonstrar a existência de um comando é diferente de medir seu desempenho em uma carga representativa; medir a transferência é diferente de demonstrar que a aplicação continua funcionando depois dela.

Esta análise trata dessas condições documentadas, observadas em 19 de setembro de 2026. Não identifica uma nova política de preços, não mede uma migração de cliente e não compara faturas de fornecedores concorrentes. A pergunta é mais delimitada: qual obstáculo a tarifa elimina e o que ainda precisa ser demonstrado para transformar essa vantagem em capacidade efetiva de substituição?

O zero tem endereço na fatura

A tabela de preços da Cloudflare separa armazenamento, operações, recuperação e transferência de saída. A distinção entre Standard e Infrequent Access deixa claro por que olhar apenas para o preço do espaço ocupado pode produzir uma decisão incompleta.

Componente listado Standard Infrequent Access
Armazenamento por GB-mês US$ 0,015 US$ 0,01
Operações de Classe A, por milhão US$ 4,50 US$ 9,00
Operações de Classe B, por milhão US$ 0,36 US$ 0,90
Transferência de saída, por GB US$ 0,00 US$ 0,00
Recuperação de dados na Infrequent Access, por GB Não aplicável a essa classe US$ 0,01
Duração mínima de armazenamento Sem duração mínima 30 dias

O preço unitário do armazenamento Infrequent Access é um terço menor que o do Standard. Em contrapartida, seu preço por milhão de operações de Classe A é o dobro, e o de Classe B é 2,5 vezes maior. São relações aritméticas entre os valores listados, não mudanças ao longo do tempo. Também não dizem, sozinhas, qual classe terá a menor fatura para uma empresa.

As operações de Classe A abrangem, em termos gerais, ações de escrita, listagem e alteração; as de Classe B incluem leituras e consultas de metadados. O custo de uma transferência depende, portanto, não apenas dos bytes envolvidos, mas também das solicitações faturáveis que o procedimento realmente produz. A documentação consultada não estabelece uma quantidade universal de solicitações por objeto ou por migração. Não seria correto preencher essa lacuna com uma regra presumida.

Há ainda condições que uma simulação simplificada pode deixar de fora. Segundo a documentação de preços, a franquia gratuita mensal, exclusiva do Standard, inclui 10 GB-mês de armazenamento, um milhão de operações de Classe A e dez milhões de Classe B. A Infrequent Access não recebe essa franquia. A documentação também informa arredondamento do consumo para a próxima unidade de cobrança.

Essas regras impedem tratar a multiplicação linear de volume por tarifa como uma reprodução exata da fatura. A duração mínima de 30 dias da Infrequent Access exige atenção adicional, mas não fornece, por si só, todos os elementos para calcular uma cobrança específica por exclusão antecipada ou mudança de classe. É preciso conhecer as regras aplicáveis ao caso e o consumo efetivamente medido.

A leitura econômica é simples: a Cloudflare oferece combinações diferentes de preço fixado por armazenamento e preço associado ao uso. Uma classe pode ser adequada a um padrão de acesso e perder atratividade quando esse padrão muda. Isso não transforma o preço menor do armazenamento em propaganda vazia; torna necessário definir qual trabalho será realizado sobre os dados.

Como uma diferença de US$ 5 pode desaparecer

Um exercício limitado ajuda a separar os componentes. Considere 1.000 GB-mês de armazenamento, sem aplicar franquias, arredondamentos, duração mínima, tributos, descontos ou condições negociadas. Também deixe fora os custos do destino, o trabalho de engenharia, a validação e o funcionamento paralelo. Não se trata de uma carga observada nem de uma estimativa completa de migração.

Com os valores unitários publicados, o componente de armazenamento seria de US$ 15 no Standard e de US$ 10 na Infrequent Access. A diferença bruta é US$ 5. Recuperar 500 GB faturáveis na Infrequent Access acrescentaria US$ 5, consumindo essa diferença antes de considerar qualquer diferença de preço entre operações.

Com 1.000 GB faturáveis recuperados, armazenamento e recuperação na Infrequent Access somariam US$ 20. O componente de armazenamento do Standard continuaria em US$ 15 no exemplo. Essa comparação não afirma que as faturas finais seriam de US$ 20 e US$ 15: deliberadamente não inclui operações nem os demais fatores excluídos. Tampouco pressupõe que toda leitura recupere um objeto inteiro.

O mesmo raciocínio pode ser apresentado de forma auditável. Defina S como o armazenamento medido em GB-mês; A e B como os volumes de operações das respectivas classes, em milhões; e R como a recuperação faturável na Infrequent Access, em GB. Mantendo iguais o armazenamento e as quantidades de operações entre as duas classes, a aplicação linear das tarifas produz:

Standard, em US$ = 0,015 × S + 4,50 × A + 0,36 × B
Infrequent Access, em US$ = 0,010 × S + 9,00 × A + 0,90 × B + 0,010 × R
Diferença, em US$ = -0,005 × S + 4,50 × A + 0,54 × B + 0,010 × R

A expressão da diferença mostra o mecanismo, não uma recomendação universal. O termo negativo representa a vantagem bruta de armazenamento da Infrequent Access. Os termos positivos representam os preços adicionais de operações e recuperação dentro desse modelo. Não há um termo positivo de transferência de saída porque ambas as classes listam esse preço em zero.

O exemplo de 500 GB é, assim, uma referência para entender componentes, não um ponto de equilíbrio aplicável a qualquer conta. A franquia exclusiva do Standard pode alterar a comparação; o arredondamento também. Os períodos de armazenamento, as condições comerciais e a quantidade de solicitações precisam corresponder ao caso real. Uma conclusão confiável exige recolocar essas variáveis na conta, não esquecê-las depois de apresentar a fórmula.

Há uma consequência prática para quem aprova orçamento: GB armazenado, GB recuperado e milhões de operações não devem aparecer como um único indicador de “volume”. Dois procedimentos que lidem com a mesma quantidade de dados podem gerar solicitações diferentes. Sem medir essas dimensões separadamente, a área financeira não consegue distinguir uma mudança de tarifa de uma mudança no modo de usar o serviço.

A saída documentada é mais que uma intenção

A orientação da Cloudflare para configurar o Rclone descreve o uso do backend compatível com S3, a seleção do provedor Cloudflare R2 e a configuração de identificador da chave de acesso, chave secreta e endpoint da API S3. O procedimento envolve ainda a identificação da conta e um token de API R2 com permissões e escopo apropriados.

Mais importante para esta pergunta, a página fornece um exemplo de cópia de um objeto do R2 para um destino local:

rclone copy r2:user-uploads/dog.txt .

É uma direção de transferência relevante: do R2 para fora, e não apenas uma função de importação que facilitaria a chegada de novos clientes. Seria incorreto descrever o produto como desprovido de um caminho documentado de saída. Ao mesmo tempo, o exemplo não foi executado para esta análise e não informa duração, custo observado ou resultado de uma migração de produção.

As exigências de configuração também têm significado gerencial. Para ensaiar uma saída, uma equipe precisa saber quais credenciais, permissões e endpoints utilizará. Isso é uma lista de condições a verificar, não evidência de que a Cloudflare impeça algum cliente de obter acesso. A diferença importa: identificar um requisito operacional não autoriza convertê-lo automaticamente em acusação de bloqueio.

A documentação do próprio Rclone para copy informa que o comando copia entre origem e destino, ignora arquivos idênticos e não apaga arquivos do destino. Quando a origem é um diretório, o conteúdo é copiado, não o diretório em si. “Não apagar” não significa, porém, ser uma operação somente de leitura ou garantir que todo o conteúdo já existente no destino permaneça inalterado.

O Rclone também documenta a opção --dry-run, que permite visualizar uma operação sem realizar a cópia. Isso é útil para examinar o que se pretende fazer, mas não mede a velocidade real, não comprova a transferência e não valida uma aplicação no destino. Uma prévia pode melhorar a preparação do teste; não deve ser registrada como se fosse o resultado dele.

Há outra distinção que não pode desaparecer em uma recomendação genérica de migração. A documentação da Cloudflare alerta que sync pode apagar no destino arquivos ausentes na origem. Portanto, copiar e sincronizar não são instruções intercambiáveis. Um plano que dependa de sincronização destrutiva precisa de avaliação e testes específicos, sobretudo quando a intenção é preservar uma alternativa e não eliminar dados por engano.

O alcance da evidência permanece limitado ao procedimento descrito. Não há base aqui para prometer cópia entre fornecedores inteiramente no lado dos servidores, preservação automática de todos os metadados ou ausência de consumo de recursos intermediários. Essas condições devem ser confirmadas para o caminho escolhido. O benefício tarifário não preenche lacunas técnicas.

Compatibilidade precisa ser confrontada com a aplicação

A Cloudflare afirma, em sua documentação de compatibilidade com a API S3, que o R2 implementa a API para facilitar a migração de usuários e aplicações. A mesma documentação reconhece diferenças de funcionalidades e acompanha o estado de implementação. Isso sustenta uma conclusão mais cuidadosa que “é tudo igual”: é preciso confrontar as operações e os parâmetros exigidos pela aplicação com o que cada ponta oferece.

O material consultado não permite montar uma lista específica de funcionalidades ausentes. Também não demonstra equivalência integral. Ambas as extrapolações seriam excessivas. A investigação útil começa pelo trabalho que precisa continuar sendo feito: quais chamadas a aplicação realiza, quais resultados espera e quais elementos devem ser preservados ou reconstruídos quando o armazenamento muda.

Uma cópia de objetos pode ser parte importante dessa resposta sem ser a resposta inteira. A empresa precisa identificar, para sua própria carga, quais metadados, identificadores, permissões e outras dependências acompanham os bytes. Esses itens são perguntas para o teste, não defeitos do R2 estabelecidos pela documentação. O custo de tratá-los pode decorrer da arquitetura do cliente, da escala ou de diferenças entre serviços.

A ordem da demonstração também importa. Primeiro, existe um caminho descrito. Depois, esse caminho precisa funcionar com dados representativos. Por fim, o substituto deve executar as funções necessárias dentro das condições aceitas pelo cliente. Cada etapa acrescenta informação. Nenhuma deve receber antecipadamente o resultado da seguinte apenas porque a tarifa de saída é favorável.

Essa distinção evita dois erros opostos. O primeiro é vender a compatibilidade como independência pronta. O segundo é tratar qualquer trabalho de adaptação como prova de aprisionamento abusivo. Integração pode ter valor legítimo, e uma escolha voluntária pode continuar economicamente atraente mesmo quando abandoná-la exige trabalho. O ponto é tornar esse trabalho visível antes que uma urgência o torne inegociável.

O teste que falta é de serviço, não apenas de transferência

Uma verificação representativa deveria começar por um escopo declarado: quais dados, funções e exigências de continuidade estão em avaliação. O recorte precisa ser suficiente para testar as dependências relevantes, mas não deve se apresentar como demonstração de toda a operação se cobre somente uma parte. O sucesso de um objeto copiado não estabelece o sucesso de uma base inteira.

Em seguida, o ensaio precisaria registrar tempo de execução, solicitações, recuperação faturável, eventuais repetições e gastos no destino. A validação deveria verificar o resultado exigido pela aplicação, e não apenas o término do comando. Esses são critérios propostos para obter evidência; esta análise não realizou o ensaio e não atribui a cliente algum um resultado positivo ou negativo.

O teste mais informativo vai além da existência de uma segunda cópia. Pergunta se o serviço substituto consegue atender às funções necessárias depois da mudança, sem dependências inesperadas do fornecedor original. Também pergunta como a equipe saberia que deve interromper a mudança, o que preservaria durante a verificação e quais condições autorizariam desativar a configuração anterior.

Uma empresa pode concluir, legitimamente, que permanecer no R2 é a melhor decisão. O valor do teste não depende de uma migração imediata. Ele transforma uma possibilidade abstrata em conhecimento sobre prazo, custo e limitações. Se o procedimento falhar ou exigir trabalho adicional, isso delimita o problema a resolver; não prova, isoladamente, uma conduta indevida do fornecedor.

A vantagem comercial é real; o efeito concorrencial ainda é condicional

Um preço de saída zerado pode tornar mais atraente uma arquitetura que precisa retirar dados do armazenamento. A condição é que esse componente seja relevante para o caso analisado. A tabela permite identificar o incentivo, mas não medir quantos clientes mudaram de comportamento por causa dele, quanto economizaram ou como os concorrentes reagiram.

Da mesma forma, não é possível deduzir a rentabilidade do R2, um subsídio cruzado ou a intenção interna da Cloudflare apenas observando a tarifa. Para a análise empresarial, a conclusão defensável está no mecanismo: o preço de transferência não adiciona custo por GB de saída, enquanto o uso do armazenamento e o trabalho de substituição continuam sujeitos a outras condições.

O R2 reúne duas evidências relevantes: uma tarifa sem cobrança de egress e um procedimento documentado para copiar objetos para fora. A próxima evidência decisiva seria uma transferência representativa, contabilizada e validada, seguida da demonstração de que a aplicação funciona no substituto. Até lá, há uma vantagem tarifária e uma possibilidade operacional. Não há prova de custo total zero nem de independência já conquistada.