Toda software house brasileira chega num momento em que precisa decidir: onde rodar o sistema dos clientes? E essa decisão tem peso comercial, técnico e jurídico que muita gente subestima até o primeiro reajuste do dólar ou a primeira pergunta da contabilidade do cliente sobre nota fiscal de hospedagem.
Esse guia foi escrito para CTO, head de infra e sócio técnico de software house brasileira que vende sistema para outras empresas. Não é tutorial de "criar uma instância EC2". É um framework de decisão sobre arquitetura, fornecedor e modelo comercial — com custos reais em 2026, considerações de LGPD e os trade-offs que ninguém te conta na hora de escolher.
Vamos cobrir os 4 modelos arquiteturais que funcionam pra software house, como decidir entre VPS, dedicado e bare metal, a conta real entre AWS e cloud brasileira (com IOF e câmbio embutidos), backup em ambiente multi-cliente e quando NÃO faz sentido migrar do exterior. No final, um playbook prático de migração sem quebrar operação.
O que muda quando você hospeda pro seu cliente, não pra você
Software house que roda só os próprios sistemas internos tem uma decisão simples. Software house que hospeda o sistema do cliente assume três responsabilidades a mais — e isso muda toda a equação:
1. Você vira Operadora de dados pessoais (LGPD art. 5º, VII)
Quando você processa dados pessoais por conta do cliente final (que é Controlador), a Lei Geral de Proteção de Dados te coloca na figura de Operadora. Isso significa que o seu fornecedor de cloud é Sub-Operadora. E aqui mora o detalhe: se a Sub-Operadora tá nos EUA, você precisa contrato com cláusulas-padrão de transferência internacional (art. 33-36 LGPD), avaliação de adequação do país, base legal específica. Se tá no Brasil, é uma linha no contrato.
Quando o cliente final faz auditoria de LGPD (e cada vez mais fazem), ele pede a documentação. Cliente em saúde, jurídico ou financeiro vai exigir dados em território nacional pra evitar a complicação toda. Sua software house é quem responde por isso.
2. SLA do cliente final passa pelo seu provedor
Você assina contrato com o cliente garantindo, digamos, 99,5% de uptime. Se a infra cai 4 horas, é seu SLA descumprido. Mas a queda foi do provedor — e a maioria dos provedores cloud só dá crédito proporcional, não cobre o prejuízo do cliente final. Você fica no meio.
Isso muda a forma como você escolhe fornecedor: precisa de transparência operacional, suporte que responde rápido em incidente e canal direto com engenharia. Não dá pra ficar dependendo de fila de ticket gringa enquanto seu cliente liga te cobrando.
3. Custo da infra vira margem (ou prejuízo)
Você cobra do cliente uma mensalidade que inclui infra. Se o seu custo de infra sobe 15% por causa do dólar, sua margem some — porque o contrato com o cliente é em Real, fixo. Variação cambial vira problema seu. E se você tenta repassar, perde o cliente pra concorrente que controlou melhor.
Software house que paga em dólar pra hospedar e cobra em Real do cliente está num arbitragem cambial reverso, com risco unilateral.
Os 4 modelos arquiteturais que funcionam
Cada modelo tem seus trade-offs. Não existe "o melhor" — existe o que faz sentido pro tamanho dos seus clientes, perfil do produto e maturidade da operação.
Modelo 1 — Servidor por cliente (isolamento físico)
Cada cliente final tem o próprio servidor virtual ou dedicado. Você gerencia. Cliente pode ter acesso de leitura ou de admin (depende do modelo comercial).
Quando faz sentido: ERP, sistema de gestão, qualquer caso onde os dados do cliente A não podem em hipótese alguma vazar pro cliente B. Setores regulados (saúde, jurídico, financeiro). Clientes com necessidades muito diferentes de recursos (alguns com 10 usuários, outros com 500).
Vantagens: isolamento total, escalonamento independente, blast radius mínimo (se cai um, os outros estão de pé), facilidade de migrar cliente para outro provedor ou repassar gestão.
Desvantagens: custo unitário mais alto, gestão multiplicada por N clientes, atualização da aplicação tem que ser orquestrada (CI/CD bem feito ajuda).
Modelo 2 — Multi-tenant em servidor compartilhado
Sua aplicação é multi-tenant na lógica (separação por tenant_id ou schema no banco). Roda em servidor único, possivelmente com banco único. Cliente novo é uma row na tabela de tenants.
Quando faz sentido: SaaS B2B com produto único e cliente final relativamente homogêneo (mesmas funcionalidades, dados em escala parecida). Crescimento previsível.
Vantagens: custo por cliente despenca, gestão centralizada, deploy é uma vez só pra todos, observabilidade unificada.
Desvantagens: problema num tenant pode afetar todos (noisy neighbor). LGPD exige cuidado redobrado com queries cross-tenant. Cliente que cresce muito pode estourar a infra. Migrar um cliente específico pra outro provedor é difícil.
Modelo 3 — Bare metal pra workload pesado
Servidor dedicado físico real (não VM grande). Você roda banco grande, ETL pesado, processamento de imagem/vídeo, ou sistema legado com requisitos de I/O agressivos.
Quando faz sentido: banco com dezenas de milhões de registros, processamento batch noturno, integrações ETL com volume, sistema legado que não foi feito pra rodar virtualizado.
Vantagens: performance previsível e máxima, sem overhead de hipervisor, custo por workload pesado fica menor que múltiplas VMs grandes.
Desvantagens: menos elasticidade, provisionar leva mais tempo, escalonamento é vertical.
Modelo 4 — Híbrido (combinação dos anteriores)
O modelo mais comum em software house madura. Cliente pequeno e médio em multi-tenant. Cliente enterprise em servidor dedicado próprio. Banco principal em bare metal. Object Storage compartilhado.
Quando faz sentido: base diversificada de clientes, alguns crescendo, alguns pedindo isolamento por contrato. Quase toda software house chega aqui depois de 2-3 anos.
Vantagens: flexibilidade comercial, otimização de custo por perfil de cliente, possibilidade de upsell ("seu cliente cresceu? vamos pra dedicado").
Desvantagens: complexidade operacional. Time precisa entender múltiplos modelos. Faturamento e contábil precisam acompanhar.
VPS, Dedicado ou Bare Metal: como decidir
Heurística simples baseada no tamanho do cliente final e no perfil de uso:
| Perfil do cliente | Recomendação | Por quê |
|---|---|---|
| 1-30 usuários, sistema padrão | VPS compartilhado entre clientes | Custo baixo, gestão simples, isolamento lógico suficiente |
| 30-150 usuários, dados sensíveis | VPS dedicado por cliente | Isolamento físico, custo ainda controlado |
| 150-500 usuários, produção 24/7 | Servidor dedicado pequeno | Performance previsível, sem noisy neighbor |
| 500+ usuários ou banco gigante | Bare metal + storage dedicado | Latência mínima, I/O direto, escala vertical |
Esses números são referência. Sistema pesado (BI, integração contínua com terceiros, vídeo) muda tudo. Diagnóstico gratuito ajuda a calibrar pra realidade do seu produto.
Brasil ou exterior? A conta com IOF e câmbio
Esse é o cálculo que mais software house faz mal. Comparar AWS com cloud brasileira só pelo "preço de etiqueta" esconde 4 custos:
- IOF de 6,38% em todo pagamento internacional via cartão (Lei nº 8.894/1994 atualizada). Já em 2026.
- Variação cambial que sobe entre orçamento e fatura. Só nos últimos 12 meses, o dólar variou ~14%.
- Egress (saída de dados) — AWS cobra US$ 0,09/GB pra retirar dados. Cloud brasileira normalmente não cobra ou cobra muito menos.
- Suporte em plano separado — AWS Business Support começa em US$ 100/mês. Audaks inclui.
Exemplo prático: VPS de 8 vCPU, 16GB RAM, 200GB SSD.
| Item | AWS (us-east-1) | Audaks (SP) |
|---|---|---|
| Instância equivalente | ~US$ 95/mês (m6i.2xlarge) | R$ 380/mês |
| Storage 200GB SSD | ~US$ 24/mês (gp3) | Incluso |
| Egress 500GB/mês | ~US$ 45/mês | Incluso |
| Suporte Business | US$ 100/mês | Incluso |
| Subtotal USD | US$ 264 | — |
| Câmbio R$ 5,80 | R$ 1.531 | — |
| + IOF 6,38% | R$ 1.629 | — |
| Total mensal | R$ 1.629 | R$ 380 |
Diferença 4,3x no exemplo acima. Multiplica por 20-50 clientes que sua software house hospeda e a conta no fim do ano vira pesada. Pra um SaaS B2B com margem apertada, é a diferença entre lucro e prejuízo.
Vale dizer: a comparação muda se você usar serviços muito específicos da AWS (Lambda, DynamoDB, SageMaker, Aurora). Aí o lock-in é maior e a migração é mais complexa. Cobrimos isso adiante.
Backup e disaster recovery em ambiente multi-cliente
Ambiente com vários clientes precisa de estratégia de backup pensada — não dá pra "esperar acontecer". Os pontos críticos:
Estratégia 3-2-1 ainda vale
3 cópias dos dados, em 2 mídias diferentes, 1 fora do site. Em cloud, isso vira: backup principal no provedor, snapshot em region diferente, e cópia em Object Storage isolada (preferencialmente imutável, contra ransomware).
Backup por cliente ou unificado?
Modelo "servidor por cliente" facilita: snapshot por instância, restauração granular. Modelo multi-tenant exige mais cuidado: backup do banco completo + estratégia de restauração só de um tenant (mais complexo, exige scripts customizados).
LGPD: eliminação de dados
Quando cliente cancela contrato, art. 16 da LGPD exige eliminação dos dados pessoais. Isso inclui backups antigos. Mantém política de retenção clara (ex.: backup máximo 90 dias) e processo de eliminação documentado. Cliente vai pedir comprovante.
Custos reais: o que repassar pro cliente
Existem 3 modelos comerciais comuns:
- Tudo embutido na mensalidade SaaS: cliente paga R$ X/mês, infra é seu custo. Margem maior se infra é otimizada, prejuízo se cliente cresce muito sem aumentar plano. Mais simples comercialmente.
- Mensalidade + hospedagem separada: cliente vê linha "hospedagem" na fatura. Margem mais clara, cliente entende o que paga. Pode espantar comprador price-sensitive.
- Setup + mensal + variável: setup cobre migração inicial e configuração, mensal é fixo, variável cobra excedentes (storage, egress, processamento). Modelo mais complexo, melhor pra clientes grandes.
Independente do modelo, nunca trabalhe sem reajuste anual previsto em contrato. IPCA + cláusula de gatilho pra variação extrema. Software house que entrou na pandemia sem cláusula de gatilho cambial sofreu.
Migração: saindo da AWS sem quebrar operação
Quando faz sentido migrar, o medo é "vou parar o sistema do cliente". Não precisa ser assim. Playbook que funciona:
- Mapeamento — todo recurso AWS atual: instâncias, RDS, S3, IAM, SGs, NAT, ELBs, lambdas. Versão dos sistemas operacionais. Volume de dados em cada storage. Tráfego de rede mensal.
- Equivalência — cada recurso AWS mapeado pra equivalente no Audaks (ou outra cloud BR). Engineer faz isso em 1-2 dias pra ambiente médio.
- Provisão paralela — sobe ambiente novo, completo, em paralelo. Sem virar pra produção ainda.
- Sync inicial — copia dados (rsync, snapshot, dump). Pra bancos grandes, faz dump + replicação contínua.
- Janela de virada — combinada com cliente. Em horário de menor uso. Para o sync incremental, valida diff zero, vira DNS, monitora.
- Rollback plan — DNS antigo apontando pro AWS fica vivo por 7 dias. Se algo crítico explode, reverte.
- Validação 7 dias — equipe acompanha, cliente reporta, ajustes finos. Depois desliga AWS.
Janela de downtime efetivo pra ambiente padrão (web app + banco) costuma ser 15-45 minutos. Pra banco gigante ou sistema crítico 24/7, dá pra fazer com replicação Master-Slave e virada DNS sem downtime ("blue-green").
Quando NÃO migrar pro Brasil (honestidade radical)
Pra ser honesto: nem toda situação justifica migração. Casos onde AWS, GCP ou Azure ainda fazem mais sentido:
- Lock-in muito profundo em serviços proprietários — sistema usa Lambda + DynamoDB + Step Functions intensamente. Migração custa mais que os 5 anos seguintes na AWS.
- Cliente final é fora do Brasil — se 70%+ dos seus usuários estão na Europa ou EUA, latência piora muito vindo de SP.
- Necessidade de regiões específicas — alguns workloads de ML usam só GPU H100 que fica disponível em regions específicas.
- Empresa do cliente final exige cloud específica em contrato — acontece com órgãos público gringos ou multinacional. Não tem como.
Pra todo o resto — software house brasileira atendendo cliente brasileiro com sistemas convencionais — cloud nacional faz mais sentido em 2026. Quem fala que "tem que ser AWS" na maioria dos casos tá repetindo cargo cult, não fazendo conta.
Próximos passos
Se você é CTO ou sócio técnico de software house e chegou até aqui, aqui está o que fazer essa semana:
- Lista os clientes que você hospeda hoje. Quantos, qual sistema, qual modelo arquitetural cada um, qual o custo total de infra mensal por cliente.
- Calcula o custo real do dólar nos últimos 12 meses. Quanto a infra subiu sem aumento de receita. Esse número costuma surpreender.
- Mapeia os 2-3 maiores clientes e verifica se são bons candidatos pra migração inicial (menor risco, maior economia).
- Conversa com 1-2 fornecedores brasileiros de cloud B2B (Audaks, opções nacionais) e pede diagnóstico honesto. Engineer no telefone, não vendedor com slide.
A Audaks tem um time que conversa com software house todo dia. Conheça o programa específico para software house. Ou se preferir, marca uma conversa de 30 minutos com um dos nossos engenheiros — a gente entende sua arquitetura, mapeia equivalência e mostra o número final em Real, sem rodeio.
Perguntas frequentes
Vale migrar uma software house pequena (3-5 clientes hospedados) pra cloud brasileira?
Vale, especialmente se a soma de custos mensais já passou de R$ 1.500-2.000. Quanto menor o volume, mais rápido a economia compensa o esforço de migração (que é proporcional ao tamanho do ambiente).
E se meu cliente final exigir AWS especificamente em contrato?
Acontece, especialmente em compliance setoriais. Nesses casos, mantém esse cliente na AWS e migra os outros. Software house que opera em modelo híbrido (parte AWS, parte cloud BR) é normal. Audaks aceita ser provedor de parte do portfolio sem exigir migração total.
Como cobrar do cliente final pela hospedagem se eu mudo de provedor?
Se a hospedagem está embutida no SaaS, o cliente nem precisa saber — você só fica com mais margem. Se é cobrada separada, comunica como redução de custo a partir do mês X. Cliente normalmente gosta porque o preço fica estável (sem repasse de dólar).
Backup multi-cliente em cloud brasileira é mais caro que AWS?
Geralmente é mais barato, principalmente porque Object Storage brasileiro não cobra egress (saída de dados), enquanto S3 cobra US$ 0,09/GB. Pra software house que faz restore frequente, isso pesa muito.
Vocês ajudam na migração ou eu preciso ter equipe DevOps interna?
Ajudamos. Engineer da Audaks faz o desenho da equivalência, sugere ferramentas (rsync, AWS DMS pra dados, Terraform pra infra), acompanha a janela de virada. Time da software house executa, com suporte direto. Pra ambientes complexos, fazemos serviço dedicado de migração assistida.