Comece pelo seu workload, não por um plano de hospedagem
Liste as jornadas que geram valor ou risco: primeira visita, busca, login, detalhe do produto, envio de formulário, checkout, atualização no editor ou chamada de API. Para cada uma, registre picos de requisições ou usuários concorrentes, payload, personalização, dependências e regiões de visitante. Inclua trabalhos agendados e administrativos, pois consomem os mesmos recursos.
Transforme a lista em medidas de aceitação. Largest Contentful Paint, ou LCP, mede carregamento do conteúdo principal; Interaction to Next Paint, ou INP, mede responsividade; e Cumulative Layout Shift, ou CLS, movimentos inesperados. O Google descreve bons alvos como LCP dentro de 2,5 segundos, INP abaixo de 200 milissegundos e CLS abaixo de 0,1. Adicione conclusão de rota, tempo de resposta do servidor e metas de taxa de erro.
Não deixe uma página cacheada e rápida substituir uma transação autenticada ou com suporte a banco de dados.
Defina período de pico, crescimento esperado, picos de campanha e trabalho em lote que pode se sobrepor.
Marque se o host, sua equipe ou um terceiro controla cada gargalo provável.
Compare capacidade, limites e comportamento de escalonamento
Peça os limites por trás da oferta: compute e memória, desempenho de armazenamento, conexões de banco de dados, limites de workers, cobrança de rede, controles de requisição e restrições por vizinho compartilhado. “Largura de banda ilimitada” não mostra se a aplicação consegue executar trabalho não cacheado suficiente em um pico. Pergunte quais métricas são visíveis e por quanto tempo ficam disponíveis.
Escalonamento importa apenas quando seu gatilho, atraso, teto e preço são conhecidos. Confirme se é automático, se sessões e jobs permanecem seguros e o que acontece ao atingir o teto. Prefira um teste no pico esperado e além dele a uma alegação teórica de capacidade. Headroom é uma decisão de negócio, não uma porcentagem universal.
Compare tempo de resposta p95 ou p99, não apenas uma média.
Colete tempos de banco de dados, fila e APIs upstream durante o teste.
Estime custos de escala, entrega, backup e segunda região antes de se comprometer.
Posicione a origem deliberadamente e valide a entrega
Escolha uma região de origem usando localização da audiência, dependências da aplicação, necessidades de localização de dados e acesso operacional. Teste a partir de geograficas e condições de rede representativas. Uma content delivery network, ou CDN, é um cache distribuído que pode servir ativos elegíveis mais próximos dos visitantes e reduzir o trabalho na origem; ela não substitui uma origem, banco de dados ou aplicação saudáveis.
Inspecione cabeçalhos e comportamento, não apenas uma configuração no dashboard. Assets estáticos versionados geralmente podem ter lifetimes mais longos porque uma atualização tem uma nova URL. Respostas dinâmicas e personalizadas precisam de regras explícitas. HTTP distingue caches compartilhados de privados; detalhes de conta não devem se tornar reutilizáveis por outro cliente. Ensaie uma purga de cache e rollback.
Capture uma primeira visita e uma visita de retorno porque os estados de cache diferem.
Verifique Cache-Control e chaves de cache para páginas, assets, cookies, parâmetros e locale.
Documente como staff autorizado desativa uma regra ruim sem expor conteúdo sensível.
Trate evidência de recuperação como um requisito de desempenho
Pergunte o que é copiado, onde as cópias vivem, retenção, autoridade de restauração e se os backups cobrem bancos de dados, uploads, código, configuração e infraestrutura. Defina recovery point objective, ou RPO, como perda de dados aceitável em tempo, e recovery time objective, ou RTO, como tempo de restauração aceitável. Defina ambos a partir das consequências de negócio, não do padrão do pacote.
Um backup bem-sucedido não é prova de recuperação. A CISA recomenda testes de recuperação agendados, e a AWS diz que recuperação de desastres deve ser avaliada e testada. Restaure uma cópia recente em isolamento, verifique registros e mídias importantes, use a sequência documentada e registre o tempo decorrido. Uma região alternativa pode reduzir alguns riscos, mas adiciona custo e complexidade.
Recupere um arquivo ou registro sem sobrescrever dados atuais.
Restrinja acesso à restauração e mantenha credenciais e runbooks de recuperação disponíveis para respondedores autorizados.
Um snapshot de banco de dados pode não recriar configurações, versões de aplicação ou regras de entrega.
Avalie suporte e responsabilidade compartilhada antes de precisar deles
Compare escopo de suporte, horários, canais, escalonamento e a diferença entre incidentes de plataforma e troubleshooting de aplicação. Obtenha responsabilidade escrita por patches, bancos gerenciados, TLS, regras de firewall, backups e restauração. Uma promessa de suporte é útil quando nomeia o responsável e a próxima ação em um cenário realista.
Revise papéis de acesso, autenticação multifator, logs de auditoria, manipulação de segredos e isolamento de contas. Para cartões de pagamento ou dados regulados sensíveis, recursos de hospedagem sozinhos não estabelecem conformidade. Use essa comparação como input técnico e obtenha revisão qualificada de segurança, jurídica ou de compliance sobre a arquitetura de pagamento e obrigações aplicáveis.
Pergunte como o provedor lida com uma restauração falha, banco saturado ou regra de cache prejudicial.
Verifique quem pode alterar produção, ler backups, ver logs e criar credenciais.
Créditos de serviço e cobertura gerenciada podem ter condições materiais.
Execute testes comparativos realistas e seguros e mantenha a ficha
Use o mesmo release, intenção de configuração e script de teste para cada candidato. Execute um baseline, pico esperado, spike curto, período sustentado e um exercício seguro de recuperação ou deploy. A AWS recomenda ambientes parecidos com produção, cenários definidos, monitoramento em toda a arquitetura, dados sanitizados ou sintéticos, e retestes regulares. Obtenha aprovação do provedor e siga a política de testes dele.
Combine testes de laboratório controlados com dados de campo pós-lançamento. Testes de laboratório são repetíveis para debugging; dados de campo refletem dispositivos reais, redes, geografia, estado de cache e comportamento. Reavalie a ficha após releases significativos ou mudanças de dependência. SIU pode transformar achados em endurecimento pré-lançamento, remediação atribuída a proprietários e melhorias prontas para rollback.
Mantenha locais, concorrência, estado de cache e payloads consistentes.
Salve timings de rotas, erros, métricas de recursos, versões, custos e observações.
Selecione a opção que atende às necessidades documentadas a um custo operacional sustentável.