AWS é Nutella: escalar no cartão de crédito não é arquitetura, é crédito na praça
Se pra escalar você só depende de passar o cartão, você não tem arquitetura de software. Eu uso nuvem pro pico que eu não consigo prever e data center alugado pro que é previsível. A minha régua pra começar a fazer essa conta: R$ 5.000 por mês de cloud.
🎧 PREFERE OUVIR? · 16 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 16 minutos no canal @josimarjmv em maio de 2026. Assista e leia junto. Aqui embaixo eu conto a mesma coisa por escrito, com mais calma, e ponho o que eu fui conferir depois.
a AWS não é ruim, e eu uso nuvem. O que eu chamo de Nutella é escalar só com cartão de crédito: aumenta instância, liga o autoscale e ninguém pergunta quanto custa. Isso é crédito na praça, não arquitetura. Nuvem faz sentido pro pico imprevisível e pra validar MVP. Quando o uso é previsível e a fatura passa de R$ 5.000 por mês, é hora de pôr o on-premises na conta, com gente de infraestrutura em quem você confia.
Antes que você me xingue
AWS é Nutella. Calma. Eu não estou dizendo que a AWS é ruim. Eu vou explicar o ponto de vista de quem paga a conta, de CEO, de empresa.
Vou dar minha carteirada. Meu nome é Josimar, eu sou CEO de uma empresa de tecnologia de economia real, que contrata pessoas reais, que tem time de dev, de marketing e de venda. Estou na trincheira há mais de 20 anos. Não é papagaio de internet.
Eu tenho uma dor que eu vi se formar no mercado nos últimos anos: o cloud praticamente como religião. Cloud não é religião. É uma das várias opções que a gente tem.
O condicionamento dos cursinhos de pandemia
A galera nova foi treinada em cursinho de pandemia, tudo baseado em AWS, Lambda, S3. Os cursinhos ruins se proliferaram muito rápido e nivelaram muita régua por baixo. Eu já sofri isso na pele.
Tem gente que acha que S3 é só o storage da Amazon. Não é. S3 é um protocolo, e várias tecnologias usam esse protocolo. O Ceph, por exemplo, faz armazenamento baseado em objeto. Na gravação eu prometi contar a minha experiência com ele, e contei: Ceph com S3 gratuito, onde eu pus 100 TB de disco e aproveitei 30.
Fui conferir a frase na fonte em 13 de outubro de 2026. A documentação do Ceph, na página Ceph Object Gateway S3 API, diz que ele suporta uma API RESTful compatível com o modelo básico de acesso a dados da API do Amazon S3. A tradução é minha.
Cartão de crédito não é arquitetura
Quando a sua aplicação escala baseada em cartão de crédito, você não tem arquitetura de software. Você tem crédito na praça.
Se pra escalar só depende de grana, exclusivamente grana, passa o cartão, mete mais instância, significa que você não tem uma arquitetura pensada. Subir uma arquitetura de sistema e escalar em qualquer cloud são coisas completamente diferentes.
É muito fácil apertar o botãozinho do autoscale. Tem curso sério que ensina isso de forma séria, mas tem um monte de gente que acha que é só aumentar a quantidade e está tudo certo. Não é. Essa cilada eu abri em outro texto: autoscale não salva aplicação mal feita.
O dev e a visão do negócio
É muito difícil pegar um dev e colocar ele com a visão do negócio. O sênior, o tech lead, esses já participam mais dessas discussões. Mas o desenvolvedor, em geral, quer olhar o código lindo dele e usar o último hypezinho pra dizer que está usando. Não está preocupado se o cliente dele está pagando a conta.
Não são todos, eu não estou generalizando. Estou trazendo o escopo geral do negócio.
As perguntas que eu faço antes de subir em produção
A gente não pode desenvolver um sistema que começa e termina numa AWS. E isso vale principalmente pros vibe coders, que estão na moda. Pra testar, pra validar o MVP, é barato: você paga lá 20 dólares e está tudo bem. Quando o negócio começa a escalar e vai pra produção, tem reflexão pra fazer.
- O cliente pequeno ou médio sabe quanto vai custar a aplicação rodando pra 100 usuários, de IOPS, de banco de dados, de failover em duas regiões?
- O cliente precisa disso? O cliente aguenta essa conta?
- Qual é a conta da aplicação em 12 meses? E a conta por usuário?
- Quanto vai custar a taxa de egress, a taxa de retirada, quando você tira arquivo da nuvem ou libera tráfego de CDN? Você já contabilizou isso?
Por que essas perguntas entram na hora de arquitetar o software? Porque empresa não é ONG de caridade e não é igreja. A empresa existe pra dar lucro e gerar renda pra todo mundo que trabalha em volta dela, seja sócio, acionista ou colaborador.
Uma região só não é redundância
Não adianta estar na AWS numa região só. Você não tem redundância de fato. A AWS cai. É raro, a estrutura dos caras é fantástica, mas cai. A gente já viu cair algumas vezes. Em setor muito sensível, tem que ter redundância, e depois daqueles problemas houve até um movimento grande pra usar duas nuvens: a principal na AWS e outra no Azure ou no Google Cloud.
O caso mais recente que eu achei documentado pela própria AWS, lendo em 13 de outubro de 2026: o resumo do incidente do DynamoDB na região da Virgínia do Norte, em 19 e 20 de outubro de 2025. Pelo relato deles, um defeito na automação de DNS do DynamoDB apagou os endereços do endpoint regional, e isso arrastou EC2, Lambda, balanceador de carga e outros serviços. Uma região.
O que eu fui conferir: a saída de dados tem franquia, e depois é cobrada
Em novembro de 2021 a AWS publicou a ampliação do nível gratuito de transferência de dados: a saída das regiões pra internet é gratuita até 100 GB por mês, e a do CloudFront até 1 TB por mês, valendo desde 1º de dezembro de 2021. Passou disso, é cobrado por giga. O valor por giga eu não ponho aqui, porque muda por região e por faixa. A conta é sua: pegue o seu tráfego do mês e multiplique.
Pra quem entrega vídeo, como eu, 100 GB não é nada. Uma conta parecida, só que por requisição, eu fiz em VPS ou Vercel: a conta por requisição que eu não pago.
A Netflix e a GPU que ficou ligada no fim de semana
Exemplo prático: a Netflix saiu, não totalmente, mas uma parte grande dela, de cloud. Na gravação eu disse que foi porque o cloud ficou muito caro.
Fui ver o que está publicado, em 13 de outubro de 2026. A parte que ela tirou é a entrega do vídeo. A página do Netflix Open Connect diz que os equipamentos dela estão em mais de 60 data centers no mundo e dentro da rede de mais de mil provedores de internet. O resto continua na nuvem: a página Netflix on AWS diz que a AWS fornece computação, armazenamento e infraestrutura pra Netflix. O motivo de custo é leitura minha, eu não achei essa frase dita por eles.
Repare no desenho: o tráfego pesado e previsível fica em equipamento próprio, e o resto fica na nuvem. É o mesmo raciocínio que eu defendo aqui.
A instância esquecida
Agora um caso meu. Você sobe uma VMzinha pra testar e deixa ligada no fim de semana. Isso já aconteceu na empresa. Esqueceram a aplicação ligada e ela ficou rodando o fim de semana inteiro.
Era uma instância muito grande, com muita GPU, isso anos atrás. Eu não lembro o número exato: 100, 150, 200, 250 dólares, um troço assim. Foi um valor substancial, e ficou ligado à toa, em teste. A gente precisa ter esse tipo de atenção.
Pra quem a nuvem é indicada: o meu transbordo
Vou dar exemplo meu. Eu tenho um negócio que chama transbordo.
Hoje eu tenho 140 giga de link no meu CDN de vídeo. Duas filiais do SBT no interior são clientes nossos. Quando uma emissora dessas pega uma Champions League pra transmitir, a gente sabe o que acontece em transmissão de esporte: o pico é gigantesco. São muitos milhares de pessoas além do que eu consigo suportar. Possivelmente eu não tenho link pra aguentar isso tudo.
Como funciona:
- O meu pipeline monitora como estão os meus links, a minha entrega e a latência de quem está assistindo.
- Num determinado momento, ele cria sozinho endpoints em CDNs de fora, de acordo com o preço de cada região. Estados Unidos é um preço, Europa é outro. Eu não uso um só.
- Eu mando um link pra esse CDN, e ele distribui pro restante da audiência.
É assim que empresa faz transbordo pra não prejudicar quem está assistindo. E aí faz todo sentido eu usar nuvem. A AWS é ruim? Não. Pra isso é ótimo.
O critério é este: é um pico muito grande e inesperado. Não é previsível. Não dá pra eu contabilizar, ir lá e contratar bare metal e servidor pra uma coisa que eu não sei quando vem.
O caso dos 6 milhões de dólares por mês
Não ter equipe de infraestrutura é um gargalo grande, de fato. Equipe de infraestrutura hoje é cara, e eu acredito que vai ser cada vez mais cara. Mas pra muita empresa faz sentido contratar uma consultoria só pra responder: quanto fica isso aqui?
No ano anterior ao da gravação eu estive num evento de DevOps no Google, em São Paulo, sobre inteligência artificial pra infraestrutura. Conversando com o pessoal de lá, ouvi o caso de uma empresa específica, que eu não vou dizer qual é. Ela veio da Azure, com uma consultoria de cloud parceira do Google, e saiu de 6 milhões de dólares de custo pra mais ou menos 4 milhões de dólares por mês.
Primeiro problema: contrato em dólar, e a gente está no Brasil. Segundo: economizou 2 milhões por mês, legal. Mas o que esse cara usa, que gasta 4 milhões de dólares por mês, que não poderia vir pra on-premises?
O que é on-premises: as duas searas
A primeira é in loco, dentro da própria empresa. Com o avanço e a estabilidade dos links de internet e a pulverização de data centers e mini data centers, isso ficou mais fácil. Precisa de expertise e de infraestrutura, lógico.
A segunda é o que eu faço. Eu não tenho data center na empresa nem no escritório. Os meus racks ficam num data center alugado em São Paulo, no mesmo ambiente físico do Google e do Facebook. Eles têm o compliance e a segurança deles separados, lógico. Eu estou num galpão compartilhado, com centenas de outros racks. A história de como eu fui parar lá está em migrei da nuvem pro on-premise e isso salvou a empresa.
A régua dos R$ 5.000 por mês
A esmagadora maioria das empresas, dos clientes, dos SaaS que os vibe coders estão subindo agora é previsível. O Yuri está fazendo aqui um software de gráfica, por exemplo. Um software desses você consegue pôr previsível.
Num determinado momento, uma VPSzinha já não aguenta. Você vai pro cloud, e o cloud começa a te dar R$ 1.000 de gasto por mês. R$ 2.000.
Vou te dar um número. Se você começar a gastar mais do que R$ 5.000 por mês de cloud, é hora de começar a analisar a estrutura on-premises. E é um valor baixíssimo. A gente sabe que R$ 5.000 de cloud vai embora rapidinho.
| Situação | Onde eu poria | Por quê |
|---|---|---|
| MVP, teste, validação | Nuvem | É barato, uns 20 dólares, e está tudo bem. |
| Aplicação pequena e estável | VPS | Aguenta até um determinado momento. |
| Uso previsível, fatura acima de R$ 5.000 por mês | Fazer a conta do on-premises | Previsível dá pra dimensionar e contratar. |
| Pico muito grande e inesperado | Transbordo pra nuvem | Não dá pra contratar servidor pro que não se prevê. |
| Setor muito sensível | Redundância de verdade | Uma região só cai junto. |
O que precisa estar na conta
A partir do momento em que você tem gente de infraestrutura em quem pode confiar, é hora de fazer a conta. Não joga na mão de qualquer pessoa, senão vai dar errado. E a conta não é só máquina:
- Banco de dados: como escala, com backup, log, monitoramento e observabilidade.
- Aplicação: quantos serviços e microsserviços precisam rodar? Ou é um monolito?
- Estado: é stateless ou não? É efêmero, como os contêineres? Você mata tudo e continua rodando?
- O que é local: o login é local? A sessão é local? O storage é local?
A escala não é tão simples assim. A gente tem que entender a arquitetura do sistema antes de discutir onde ele roda.
Quem levanta essa conversa dentro da empresa
A minha tese: se o cliente tem previsibilidade, é hora de você, dev sênior, tech lead, chamar o CTO e o CEO. Talvez o CTO não tenha nem noção disso, porque também foi criado na era da AWS.
A AWS cresceu muito na pandemia, quando o dinheiro parecia ilimitado e todo mundo punha grana. Hoje as empresas estão todas cortando custo. O juro está mais caro pra todo lado, Estados Unidos, Brasil. E o on-premises é um ambiente certeiro pra cortar custo. Depende muito de ter equipe de infraestrutura, mas é hora de olhar pra isso com carinho.
Equipe própria ou consultoria 24x7
Em geral, empresa de infraestrutura que você contrata cuida 24x7 da manutenção, do servidor, da observabilidade. E os devs cuidam da aplicação, igual já é na AWS: dali pra cima, é o dev que cuida. Normalmente elas são contratadas pra monitorar, não ficam alocadas dentro da empresa. Depende da verba, do modelo de negócio e da governança.
É isso que eu ensino presencialmente na Imersão de Infraestrutura. Formato, data e condição são os da página dela, não desta gravação de maio.
O aumento que você pode pedir
Eu acredito que o futuro do dev, do tech lead, de qualquer pessoa da área, é olhar arquitetura. E não só a arquitetura de sistema linda e maravilhosa: a arquitetura que paga a conta.
Imagina que você começa a economizar R$ 100 mil, R$ 200 mil pra empresa em que trabalha. A hora em que você bater na mesa e disser "gente, eu preciso de um aumento", é óbvio que a empresa vai olhar pra você com outros olhos. A não ser que o chefe seja daqueles que não reconhecem ninguém. Tem muito por aí, mas aí já é outra história.
Deixar de ser Nutella
AWS Nutella é uma brincadeira, porque é realmente muito fácil escalar baseado em cartão de crédito. Eu adoraria escalar o meu negócio assim. Não ter que cuidar de data center no Brasil, de data center fora do Brasil, de redundância em tempo real, de backup, de snapshot.
Mas a gente tem que olhar de um ângulo superior, o ângulo de quem paga a conta: em que momento faz diferença pra empresa ter um on-premises e manter uma equipe de infraestrutura dedicada, ou uma consultoria 24x7.
É hora de parar de achar que AWS é religião, ou Google Cloud, ou qualquer outro, e começar a olhar como negócio. A AWS é uma opção. O Google Cloud é outra opção. E o on-premises é outra opção que, na minha opinião, está cada vez mais forte. Soberania, invasão, segurança: tem várias outras questões que entram quando você vai pra esse ambiente. Eu me acho hoje muito mais seguro do que era quando estava tudo em nuvem.
Nota de cronologia
Gravei em maio de 2026, o vídeo foi ao ar em 30 de maio e este texto saiu em 13 de outubro de 2026. Os 140 giga de link, os clientes e a régua dos R$ 5.000 são daquela gravação. O evento de DevOps foi no ano anterior, e os 6 e 4 milhões de dólares são o que eu ouvi lá, numa conversa. Eu não tenho documento disso.
Na gravação eu prometi dois vídeos, um sobre o Ceph e um sobre a cilada do autoscale. Os dois saíram e viraram texto, e estão linkados aqui em cima. Também falei de um teste de IA local em GPU que eu ia fazer na semana seguinte. Esse eu deixo fora deste texto.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
A AWS é ruim?
Não. A estrutura deles é fantástica e eu uso nuvem. AWS Nutella é uma brincadeira, porque é muito fácil escalar baseado em cartão de crédito. O que eu critico é tratar cloud como religião e não fazer a conta de quem paga.
O que é escalar com cartão de crédito?
É quando, pra escalar, você só depende de grana: passa o cartão, aumenta instância, liga o autoscale. Se é só isso, você não tem uma arquitetura pensada, você tem crédito na praça. São coisas completamente diferentes.
Quando vale a pena sair da nuvem pro on-premises?
A minha régua: passou de R$ 5.000 por mês de cloud, é hora de começar a analisar a estrutura on-premises. Isso vale principalmente quando o uso é previsível e quando você tem gente de infraestrutura em quem pode confiar, própria ou contratada.
Pra que a nuvem faz sentido de verdade?
Pro pico que eu não consigo prever. No meu CDN de vídeo eu tenho 140 giga de link. Quando um cliente transmite esporte, o pico passa do que eu suporto, e o meu pipeline cria sozinho um endpoint num CDN de fora pra fazer o transbordo do tráfego. Pra isso a nuvem é ótima. Também faz sentido pra validar um MVP barato.
On-premises é ter servidor dentro da minha empresa?
É uma das duas formas. A outra é o que eu faço: os meus racks ficam num data center alugado em São Paulo, num galpão compartilhado com centenas de outros racks. Eu não tenho data center no escritório.
Preciso de equipe de infraestrutura pra sair da nuvem?
Precisa de gente em quem você pode confiar, e isso é um gargalo de verdade, porque equipe de infraestrutura é cara. Pra muita empresa faz sentido contratar uma consultoria ou uma empresa de infraestrutura que cuida 24x7 de servidor, manutenção e observabilidade, enquanto os devs cuidam da aplicação.
S3 é só da Amazon?
Não. S3 é um protocolo, e várias tecnologias falam esse protocolo. O Ceph é uma delas: a documentação dele diz que o gateway de objetos é compatível com o modelo básico de acesso a dados da API do Amazon S3. Dá pra ter armazenamento em objeto fora da Amazon.
O que eu ganho, como dev, olhando pra conta da nuvem?
Argumento. Se você começa a economizar R$ 100 mil, R$ 200 mil pra empresa em que trabalha, a conversa de aumento muda de figura. Eu acredito que o futuro do dev e do tech lead é olhar a arquitetura que paga a conta, não só a arquitetura linda no diagrama.
Baseado na gravação do canal @josimarjmv publicada em 30/05/2026 (16min25s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: a brincadeira da AWS Nutella e o aviso de que eu não estou dizendo que a AWS é ruim; a carteirada (CEO de empresa de tecnologia de economia real, com time de dev, marketing e venda, mais de 20 anos na trincheira); o cloud como religião e os cursinhos de pandemia; S3 como protocolo e o Ceph como exemplo; a frase do crédito na praça; o dev que não olha o negócio, com a ressalva de que não são todos; o MVP de 20 dólares; as perguntas de custo (100 usuários, IOPS, banco, failover em duas regiões, conta em 12 meses e por usuário, taxa de egress); a empresa que existe pra dar lucro; a AWS que cai e o movimento pra duas nuvens; a Netflix ter saído de parte grande do cloud por custo; a instância com GPU esquecida ligada num fim de semana, anos atrás, com o valor dito de cabeça; os 140 giga de link, as duas filiais do SBT no interior, a transmissão de esporte e o transbordo automático pra CDNs por preço de região; o gargalo de equipe de infraestrutura; o evento de DevOps no Google em São Paulo e a empresa que foi de 6 pra cerca de 4 milhões de dólares por mês; as duas formas de on-premises e os meus racks em data center alugado em São Paulo; o software de gráfica do Yuri; a régua de R$ 5.000 por mês; a lista de banco, serviços, estado e sessão; chamar o CTO e o CEO; o corte de custo e o juro; a consultoria 24x7; a economia de R$ 100 mil, R$ 200 mil e o pedido de aumento; as três opções e eu me achar mais seguro hoje. Falando, eu não disse a moeda do valor da GPU; "dólares" vem da descrição que eu mesmo pus no vídeo, que fala em centenas de dólares.
Apuração minha (13/10/2026): a compatibilidade do gateway de objetos do Ceph com o modelo básico de acesso a dados da API do Amazon S3 está em Ceph Object Gateway S3 API, da documentação do Ceph. As datas, a região e a causa do incidente de outubro de 2025 estão em Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region, da AWS; eu não afirmo que foi esse o episódio que eu tinha na cabeça ao gravar. A franquia de 100 GB por mês de saída das regiões e de 1 TB por mês do CloudFront, valendo desde 01/12/2021, está em AWS Free Tier Data Transfer Expansion, do blog da AWS, de 24/11/2021; não conferi o valor por giga acima da franquia e por isso não cito. Os mais de 60 data centers e os mais de mil provedores com equipamento da Netflix estão em Netflix Open Connect; a frase de que a AWS fornece computação, armazenamento e infraestrutura pra Netflix está em Netflix on AWS, da AWS. Nenhuma das duas páginas diz que a Netflix montou rede própria por causa de preço: isso é leitura minha. As traduções são minhas. O diagrama das três colunas e a tabela de situações são organização minha, feita depois, em cima do que eu disse. O caso dos 6 milhões de dólares, os clientes e os números do meu CDN não foram conferidos fora da gravação. Preço, data e condição da imersão não entram neste texto: valem os da página dela.