Como migrar do S3 para o R2 e reduzir os custos em até 90%

Ao conferir a conta da AWS, encontrei apenas $230 em armazenamento, mas nada menos que $4.500 em transferência de dados. Quando 50 TB começam a circular, o orçamento encolhe depressa. Conversei com amigos que mantêm plataformas de vídeo e serviços de hospedagem de imagens, e todos sentem o peso da saída de dados do S3. Um deles, responsável por um SaaS com 10 TB de tráfego mensal, pagava $891 no S3; o armazenamento custava só $15, e a transferência representava 98% da conta.

E se os dados forem para o Cloudflare R2? Não há cobrança pela saída. Com os mesmos 10 TB de tráfego, o R2 cobra apenas $15 pelo armazenamento. A seguir, comparo custos de cenários reais, mostro o que funciona na API compatível com o S3, explico uma migração de 30 minutos e aponto os problemas que encontrei. Se o aplicativo transfere mais de 500 GB por mês, a economia anual pode chegar a milhares ou dezenas de milhares de dólares.

Por que migrar do S3 para o R2? Os números explicam

A armadilha dos custos ocultos do S3

A estrutura de preços da AWS pode enganar. Os $0,023/GB de armazenamento parecem baratos e, no início, você pensa que fez um bom negócio. Quando o tráfego aumenta, porém, a saída de dados por $0,09/GB passa a dominar a conta.

Veja um exemplo. Imagine uma plataforma de vídeo que armazena 10 TB e transfere 50 TB por mês para visualizações e downloads:

• Armazenamento: 10 TB × $23/TB = $230/mês
• Transferência: 50 TB × $90/TB = $4.500/mês
• Total: $4.730/mês

A transferência representa 95% do total. E esse cálculo usa $0,09/GB; clientes com pouco volume nem sequer recebem descontos.

Um conhecido que mantém um serviço de hospedagem de imagens transfere 20 TB por mês e gastava $20.676 por ano no S3. Segundo ele, o armazenamento custava só $276; todo o restante era transferência de dados. Parecia que trabalhava apenas para pagar a AWS.

Onde está a vantagem de custo do R2

O principal diferencial do Cloudflare R2 é simples: não há cobrança por saída de dados.

Não é um desconto. A tarifa é zero. Você pode transferir 1 TB ou 100 TB e continuará pagando $0 por essa saída. Para aplicativos com tráfego intenso, isso muda completamente a conta.

Os custos se dividem assim:

• Armazenamento: $0,015/GB, ou $15/TB, 35% menos que o S3
• Saída de dados: $0, contra $90/TB no S3
• Operações: $4,50 por milhão de operações Class A e $0,36 por milhão de operações Class B

O R2 também oferece uma franquia gratuita:

• 10 GB de armazenamento
• 1 milhão de operações Class A, como gravações e listagens
• 10 milhões de operações Class B, como leituras

Um blog pessoal ou projeto pequeno pode ficar inteiramente dentro dessa franquia.

Comparação de três casos reais

Organizei três cenários típicos para comparar os custos:

No cenário de SaaS, a mesma carga custa $10.896 a menos por ano no R2. Para uma startup, isso pode equivaler ao salário anual de uma pessoa desenvolvedora em início de carreira.

A plataforma de vídeo economiza ainda mais: $54.960 por ano. Esse valor pode financiar divulgação ou novas contratações.

Quando não vale a pena migrar

Depois de tantas vantagens, também é importante mostrar quando o R2 não é uma boa escolha:

1. Forte dependência do ecossistema AWS: se o aplicativo usa intensamente Lambda, Athena, EMR e outros serviços da AWS, a mudança para o R2 pode exigir muitas alterações e não compensar.
2. Necessidade de recursos avançados de conformidade: o S3 oferece Object Lock e Legal Hold, recursos que podem ser obrigatórios nos setores financeiro e de saúde. O R2 ainda não os oferece.
3. Tráfego muito baixo: se o tráfego mensal for inferior a 100 GB, a economia pode ser pequena. Talvez seja melhor concentrar os esforços no produto.
4. Requisitos rígidos de localização dos dados: o S3 permite escolher entre 33 regiões. O R2 oferece location hint, mas tem menos opções. Se os dados precisam ficar em um país específico, como China ou Rússia, confirme primeiro se o R2 atende ao requisito.

Meu critério é simples: se o tráfego mensal supera 500 GB, o retorno da migração tende a compensar. Abaixo disso, a decisão depende da sensibilidade do negócio a custos.

Compatibilidade entre as APIs do R2 e do S3: o que funciona e onde ter cuidado

Até que ponto o R2 é compatível

Esta é a principal dúvida: migrar para o R2 pode derrubar o aplicativo? Quanto código precisa mudar?

Nos meus testes, a conclusão foi esta: o R2 implementa de 80% a 90% dos principais recursos da API do S3, cobrindo praticamente todas as operações comuns.

A estratégia da Cloudflare foi implementar as partes mais usadas da API do S3, incluindo:

• Operações básicas: PutObject, GetObject, DeleteObject e ListObjects, que representam 99% dos casos de uso
• Recursos avançados: Multipart Upload, Presigned URLs e configuração de CORS
• Gerenciamento de permissões: Bucket policies e IAM-style access keys

O melhor é que normalmente basta alterar a URL do endpoint e as credentials. Quase todo o código permanece igual.

Em um projeto que usava o AWS SDK for JavaScript, troquei apenas três linhas para migrar ao R2:

// Configuração original do S3
const s3 = new AWS.S3({
  region: 'us-east-1'
});
// Migração para o R2: altere apenas endpoint e credentials
const r2 = new AWS.S3({
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  accessKeyId: R2_ACCESS_KEY_ID,
  secretAccessKey: R2_SECRET_ACCESS_KEY,
  signatureVersion: 'v4',
});

O restante do código de upload, download e exclusão continuou igual. Testei a configuração por duas semanas e não encontrei problemas de compatibilidade.

Recursos sem suporte

O R2 não substitui o S3 em todos os casos. Alguns recursos realmente não são compatíveis, e você deve confirmar se o aplicativo depende deles antes de migrar.

1. S3 Select, para consultas SQL em objetos

O R2 não oferece S3 Select. Se você executa consultas SQL diretamente sobre objetos no S3, terá de baixar os dados antes de consultar ou adotar outra solução.

2. Object Lock e Legal Hold, para retenção de conformidade

Esses recursos são comuns nos setores financeiro e de saúde para atender a requisitos WORM, ou Write Once Read Many. O R2 ainda não os oferece. Se a auditoria de conformidade os exige, não migre.

3. Versioning, para controle de versões

O suporte do R2 ao versionamento do S3 é limitado. Aplicativos que dependem muito da restauração de versões precisam de testes cuidadosos.

4. Alguns recursos avançados de consulta e análise

S3 Inventory e S3 Object Lambda, por exemplo, não são compatíveis com o R2.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Minha recomendação é direta: antes de migrar, liste todos os recursos do S3 usados pelo aplicativo e compare-os com a documentação oficial de compatibilidade da Cloudflare. A maioria dos aplicativos utiliza apenas as operações básicas e não terá problemas.

Compatibilidade das ferramentas nos testes

Testei algumas ferramentas comuns, e quase todas puderam ser trocadas sem dificuldade:

O único cuidado é usar o rclone 1.59 ou mais recente. Versões antigas apresentam problemas de autenticação.

Um problema que encontrei

Em uma das migrações, o aplicativo usava a API ListObjectsV2 do S3 com o parâmetro StartAfter para paginação. Depois da troca para o R2, a paginação se comportou de maneira um pouco diferente e alguns dados deixaram de aparecer.

Ao investigar, confirmei que a paginação do R2 não era idêntica à do S3. Troquei o parâmetro por ContinuationToken, e o problema desapareceu.

A lição é simples: teste bastante depois da migração. Não valide apenas o fluxo normal; cubra também os casos de limite.

Três estratégias de migração: escolha a mais adequada

A Cloudflare oferece duas ferramentas oficiais, Super Slurper e Sippy, e a comunidade mantém opções de código aberto como o rclone. A escolha depende do cenário.

Opção 1: Super Slurper para uma migração pontual

O Super Slurper é a ferramenta oficial da Cloudflare para uma migração única. Ele serve para quem quer transferir todos os dados de uma vez.

Vantagens:

• Operação simples: preencha alguns formulários e inicie a migração
• Preserva todos os metadados, incluindo metadata e content-type
• Não exclui os dados de origem, reduzindo o risco
• É gratuito; você paga apenas as operações Class A do R2, que custam pouco
• Depois da atualização de 2024, ficou cinco vezes mais rápido

Limitações:

• Faz apenas uma migração pontual, sem sincronização incremental
• Se usuários enviarem novos arquivos ao S3 durante a migração, eles não serão sincronizados automaticamente com o R2
• É mais adequado quando cada objeto tem menos de 50 GB; arquivos muito grandes podem causar problemas

Para quem serve:

• Volumes inferiores a 10 TB
• Projetos que aceitam uma breve indisponibilidade ou ainda não estão em produção
• Aplicativos que deixarão completamente o S3 depois da migração

Usei o Super Slurper no meu primeiro projeto migrado. Foram cerca de 30 minutos para transferir 100 GB. Reservei uma janela de manutenção às 3h, e os usuários praticamente não perceberam.

Opção 2: Sippy para migração gradual sem indisponibilidade

O Sippy é a solução de migração inteligente da Cloudflare. Sua principal característica é não exigir uma parada do serviço.

Como funciona:

Você aponta o aplicativo para o R2. Quando alguém solicita um arquivo:

1. O R2 procura o arquivo no próprio armazenamento
2. Se encontrar, retorna imediatamente
3. Se não encontrar, busca o arquivo no S3, entrega a resposta e salva uma cópia no R2 para a próxima solicitação

Assim, os dados são migrados sob demanda. Os arquivos mais acessados passam primeiro, enquanto os dados frios são transferidos aos poucos.

Vantagens:

• Não exige indisponibilidade e é transparente para o usuário
• Reduz a transferência no S3 à medida que os dados mais acessados passam para o R2
• Permite acompanhar a migração e voltar ao S3 caso o resultado não seja satisfatório

Limitações:

• O primeiro acesso a um arquivo é mais lento, pois o R2 precisa buscá-lo no S3
• A configuração é mais complexa e exige mudanças no aplicativo
• Funciona melhor quando há uma separação clara entre dados quentes e frios

Para quem serve:

• Ambientes de produção que não podem parar
• Volumes muito grandes, acima de 10 TB, cuja migração pontual demoraria demais
• Equipes que querem testar a estabilidade do R2 antes da troca completa

Um amigo que mantém um serviço de aceleração por CDN usou o Sippy para migrar 50 TB. O serviço continuou atendendo usuários enquanto os dados eram transferidos em segundo plano. A migração completa levou dois meses, mas não afetou a operação.

Opção 3: rclone para quem quer controle total

O rclone é uma ferramenta de código aberto para sincronização entre serviços de armazenamento. É a opção mais completa, mas exige o uso da linha de comando.

Vantagens:

• É totalmente gratuito e de código aberto
• Permite retomar transferências interrompidas
• Aceita sincronização agendada, como atualizações incrementais durante a madrugada
• Verifica a integridade dos dados com MD5 ou SHA256
• Permite limitar a velocidade para não ocupar toda a largura de banda

Limitações:

• Exige familiaridade com a linha de comando
• Você precisa criar scripts para gerenciar o andamento da migração
• A transferência gera custos de saída no S3, embora a AWS tenha deixado de cobrar por dados migrados para fora desde março de 2024

Para quem serve:

• Equipes técnicas que querem controlar todo o processo
• Projetos que precisam de sincronização contínua, como um período com gravação simultânea no S3 e no R2
• Cenários com requisitos rigorosos de integridade dos dados

Eu prefiro o rclone porque posso automatizar tudo com scripts e acompanhar logs detalhados. Este foi um dos comandos que usei:

rclone copy s3:my-bucket r2:my-bucket \
  --progress \
  --checksum \
  --transfers 32 \
  --s3-chunk-size 64M

O parâmetro --checksum verifica o MD5 de cada arquivo para confirmar a integridade. Já --transfers 32 abre 32 transferências simultâneas e aumenta bastante a velocidade.

Decisão rápida: qual opção escolher?

Use esta árvore de decisão:

É possível parar o serviço?
├─ Sim → Há menos de 10 TB?
│        ├─ Sim → Super Slurper, a opção mais simples
│        └─ Não → rclone, rápido e controlável
└─ Não → Sippy, sem indisponibilidade
Conhecimento técnico + necessidade de controle total → rclone

Minha recomendação é que o Super Slurper basta para a maioria dos casos. A simplicidade costuma valer mais do que a flexibilidade das outras opções, exceto quando o serviço não pode parar nem por um instante ou o volume é muito grande, acima de 50 TB.

Migração prática em 30 minutos com o Super Slurper

Com a teoria resolvida, vamos à configuração. Usarei o Super Slurper como exemplo. A preparação leva cerca de 30 minutos; o tempo de transferência dos dados vem depois.

Etapa 1: preparação em 5 minutos

1. Crie uma conta na Cloudflare e ative o R2

Acesse o painel da Cloudflare, crie uma conta e encontre “R2 Object Storage” na barra lateral para ativar o serviço.

O R2 exige um cartão de crédito, mas oferece uma franquia gratuita. Um projeto pequeno pode não pagar nada.

2. Crie um bucket no R2

Clique em “Create bucket” e preencha:

• Bucket name, de preferência igual ao bucket no S3 para facilitar o gerenciamento
• Location hint; escolha EU se houver um requisito de conformidade, ou Automatic nos demais casos

⚠️ Importante: location hint e jurisdictional restrictions não podem ser alterados depois da escolha. Avalie com cuidado. Automatic é suficiente na maioria dos casos.

3. Crie um usuário IAM somente leitura na AWS

Esta etapa é importante. Não use as chaves da conta principal, pois o risco de segurança é alto.

No console do AWS IAM, siga Users → Add User:

• Nome de usuário: r2-migration-readonly
• Access type: Programmatic access
• Permissions: Attach existing policies directly → selecione “AmazonS3ReadOnlyAccess”

Outra opção é usar uma política personalizada, mais segura por limitar a permissão ao bucket necessário:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

Depois da criação, a AWS exibirá o Access Key ID e o Secret Access Key. Copie e salve ambos, porque eles aparecem apenas uma vez.

4. Gere um R2 API Token

Volte ao R2 e siga Manage R2 API Tokens → Create API Token:

• Nome do token: migration-token
• Permissions: Object Read & Write
• Selecione o bucket criado anteriormente

O R2 também mostrará um Access Key ID e um Secret Access Key. Salve-os.

Etapa 2: configuração da migração em 15 minutos

1. Abra a área Data Migration

No painel do R2, clique em “Data Migration” → “Migrate Files”, no canto superior direito.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

2. Selecione Super Slurper

Você verá Super Slurper e Sippy. Selecione Super Slurper para fazer uma migração pontual.

3. Preencha os dados do bucket de origem no S3

• Provider: Amazon S3
• Bucket name: o nome do bucket no S3, como my-images
• Bucket region: a região do S3, como us-east-1, disponível no console do S3
• Access Key ID: a chave do usuário IAM criado anteriormente
• Secret Access Key: o Secret Key correspondente

Clique em “Verify Connection”. Uma marca verde aparecerá se a conexão funcionar.

4. Preencha os dados do bucket de destino no R2

• Bucket name: o nome do bucket criado no R2
• R2 Access Key ID: o Access Key do R2 API Token
• R2 Secret Access Key: o Secret correspondente

5. Configure as opções de migração

• Overwrite existing objects: define se arquivos existentes serão substituídos; recomendo marcar
• Path prefix, opcional: informe um prefixo, como images/, se quiser migrar apenas uma pasta do S3

6. Revise e inicie a migração

Confira toda a configuração e clique em “Start Migration”.

7. Aguarde o término da transferência

O painel mostrará:

• Velocidade de transferência
• Quantidade de arquivos migrados
• Tempo restante estimado

Estimativas de tempo:

• 100 GB → cerca de 30 minutos
• 1 TB → cerca de 4 a 6 horas
• 10 TB → cerca de 2 a 3 dias

Você pode fechar a página; a migração continuará em segundo plano. Volte a qualquer momento para acompanhar o andamento.

Etapa 3: validação em 10 minutos

Quando a migração terminar, não exclua imediatamente os dados do S3. Valide tudo primeiro.

1. Confira a quantidade de objetos

Abra o bucket no painel do R2 e compare:

• Quantidade de objetos no S3: X
• Quantidade de objetos no R2: X

Os números devem ser iguais. Se não forem, consulte os logs para identificar falhas de migração.

2. Verifique a integridade de alguns arquivos

Baixe alguns arquivos aleatórios e compare o MD5:

# MD5 do arquivo no S3
aws s3api head-object --bucket my-bucket --key test.jpg --query 'ETag' --output text
# MD5 do arquivo no R2, usando rclone ou baixando para comparar
rclone md5sum r2:my-bucket/test.jpg

Se os ETags forem iguais, o arquivo está íntegro.

3. Teste o acesso aos arquivos

Abra alguns arquivos pela Public URL ou pela API do R2 e confirme que o download funciona.

4. Confira os metadados

Verifique se os campos metadata personalizados foram preservados:

aws s3api head-object --bucket my-bucket --key test.jpg
# Compare com os metadados no R2

Etapa 4: troca do aplicativo para o R2

Depois da validação, você pode começar a apontar o aplicativo para o R2. Faça uma liberação gradual em vez de trocar todo o tráfego de uma vez.

1. Altere a configuração do aplicativo

Imagine que o aplicativo configure o S3 por variáveis de ambiente:

# Configuração original do S3
S3_ENDPOINT=https://s3.amazonaws.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=xxx
S3_SECRET_KEY=xxx
S3_REGION=us-east-1
# Configuração do R2
S3_ENDPOINT=https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=R2_xxx
S3_SECRET_KEY=R2_xxx
S3_REGION=auto  # Use auto no R2

2. Faça uma liberação gradual

Comece com 10% do tráfego e procure erros:

• Confira os logs do aplicativo
• Monitore a taxa de erros
• Acompanhe o retorno dos usuários

Se tudo estiver estável, aumente gradualmente: 10% → 50% → 100%.

3. Monitore os principais indicadores

Depois da migração, acompanhe de perto:

• Taxa de erros da API
• Tempo de resposta
• Custos de transferência, que devem cair bastante

4. Mantenha um backup no S3

Recomendo manter os dados no S3 por 30 dias e excluí-los apenas depois de confirmar a estabilidade do R2. Desde março de 2024, a AWS não cobra pela transferência de dados migrados para fora, portanto essa saída não tem custo.

Você pode configurar uma regra de ciclo de vida no S3 para fazer a limpeza automática:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Expiration": {
        "Days": 30
      }
    }
  ]
}

Todos os objetos serão excluídos automaticamente depois de 30 dias.

Como otimizar e monitorar o R2 depois da migração

A migração não encerra o trabalho. Ela abre espaço para melhorar desempenho e custo.

Otimização de desempenho

1. Ative a CDN da Cloudflare

O R2 já usa a rede global da Cloudflare, mas funciona ainda melhor com a CDN:

• Abra as configurações do bucket no R2 → Public Access → Connect Domain
• Vincule seu domínio, que precisa estar gerenciado pela Cloudflare
• O cache da CDN será ativado automaticamente

Assim, o conteúdo será entregue pelo ponto da CDN mais próximo do usuário.

2. Configure um Cache-Control adequado

Defina o header Cache-Control ao enviar um arquivo para informar por quanto tempo a CDN deve mantê-lo em cache:

// Recursos estáticos, como imagens e vídeos, ficam em cache por um ano
s3.upload({
  Bucket: 'my-bucket',
  Key: 'image.jpg',
  Body: fileBuffer,
  CacheControl: 'public, max-age=31536000, immutable'
});
// Conteúdo atualizado com frequência fica em cache por uma hora
s3.upload({
  // ...
  CacheControl: 'public, max-age=3600'
});

3. Use um domínio personalizado no R2

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

A URL padrão do R2 não é amigável: https://xxx.r2.cloudflarestorage.com/file.jpg.

Com um domínio personalizado, ela pode ficar assim: https://cdn.yoursite.com/file.jpg.

Além de ser mais legível, a URL personalizada pode oferecer melhor desempenho com a CDN.

Otimização de custos

1. Use a classe Infrequent Access para dados frios

O R2 oferece a classe de armazenamento Infrequent Access, ou IA, para dados acessados com pouca frequência:

• O armazenamento é mais barato: $0,01/GB, contra $0,015/GB na classe Standard
• Cada leitura tem uma cobrança adicional de $0,01/GB

Ela é indicada para arquivos históricos, backups e outros dados frios.

2. Ajuste o part size do Multipart Upload

Em uploads grandes, o part size influencia o custo das operações Class A. Cada parte enviada conta como uma operação:

• Part size pequeno demais → mais operações → custo maior
• Part size grande demais → retransmissões mais caras em caso de falha

Minha recomendação:

• Arquivos menores que 100 MB → upload único
• Arquivos de 100 MB a 1 GB → part size de 64 MB
• Arquivos maiores que 1 GB → part size de 128 MB

No rclone, use:

rclone copy s3:bucket r2:bucket --s3-chunk-size 64M

3. Monitore o custo das operações Class A e Class B

A saída de dados é gratuita, mas as operações têm custo:

• Class A, para gravações: $4,50 por milhão
• Class B, para leituras: $0,36 por milhão

O painel do R2 mostra a quantidade mensal de operações. Se houver operações Class A em excesso, procure uploads duplicados ou solicitações desnecessárias.

Monitoramento para detectar problemas rapidamente

1. Cloudflare Analytics

O R2 inclui o Analytics, que mostra:

• Quantidade de solicitações
• Volume de dados
• Taxa de erros
• Arquivos mais acessados

Abra o bucket no R2 e acesse Analytics.

2. Alertas de custo

Defina um limite para receber uma notificação automática:

Cloudflare Dashboard → Notifications → Add → selecione “R2 storage usage”.

Você pode, por exemplo, configurar um e-mail quando o custo mensal superar $50 e evitar surpresas na conta.

3. Monitoramento no aplicativo

Monitore estes indicadores do R2 no aplicativo:

• Taxa de erros da API, com meta inferior a 0,1%
• Tempo médio de resposta, com meta inferior a 100 ms
• Latência P99, com meta inferior a 500 ms

Use ferramentas de APM como Sentry ou Datadog para detectar problemas e reverter rapidamente.

4. Compare periodicamente com o custo do S3

Todo mês, compare:

• A conta do S3 antes da migração
• A conta do R2 depois da migração
• O valor economizado, que pode até pagar um almoço para a equipe 😄

Eu mantenho uma planilha com esses números. Ver a economia acumulada mês a mês dá uma boa sensação de progresso.

Conclusão: vale a pena migrar para o R2?

Minha resposta é: se o aplicativo transfere mais de 500 GB por mês, migrar para o R2 vale muito a pena.

As três principais vantagens são:

1. A economia é real: sem tarifa de saída, a conta de nuvem pode cair de 50% a 90%. Um SaaS pode economizar mais de $10.000 por ano, e uma plataforma de vídeo pode passar de $50.000.
2. A migração é administrável: o Super Slurper leva 30 minutos para configurar, e o R2 oferece de 80% a 90% de compatibilidade com a API. Na maioria dos aplicativos, basta alterar o endpoint. Meus testes mostraram que a mudança é menos complexa do que parece.
3. O risco pode ser controlado: a migração não exclui a origem. Você pode liberar o tráfego gradualmente e voltar atrás se algo der errado. Como a AWS não cobra mais pela saída dos dados migrados, o custo de experimentar é quase zero.

Mas o R2 não resolve todos os casos:

• Se o aplicativo depende muito do ecossistema AWS, como Lambda e Athena, a migração pode sair cara
• Se você precisa de recursos avançados de conformidade do S3, como Object Lock, o R2 ainda não é suficiente
• Se o tráfego é muito baixo, inferior a 100 GB por mês, o retorno da migração é pouco relevante

Minha recomendação é testar primeiro o desempenho e a estabilidade com a franquia gratuita do R2 e só então migrar em grande escala. Para uma transição gradual, o Sippy oferece o menor risco.

Um último caso ajuda a mostrar o impacto. Um amigo mantinha um serviço de hospedagem de imagens e pagava $1.800 por mês no S3. Depois da migração, passou a gastar apenas $18 no R2, referentes ao armazenamento. Ele usou a economia para contratar uma pessoa de design e melhorar o produto. Esse é o valor da otimização de custos: não apenas gastar menos, mas direcionar o dinheiro para o que produz mais resultado.

Próximos passos:

1. Use a calculadora do R2 para estimar sua economia
2. Teste o desempenho do R2 com a franquia gratuita
3. Escolha uma estratégia: Super Slurper, Sippy ou rclone
4. Faça uma migração gradual e valide a estabilidade
5. Transfira todo o tráfego e acompanhe a redução dos custos

Se encontrar algum problema durante a migração, compartilhe nos comentários. Boa migração e uma conta bem menor!