VPS ou servidor dedicado: qual realmente serve para a sua carga de trabalho

A máquina parece bem. A carga média é razoável, a memória não está esgotada, o disco tem espaço. A aplicação continua lenta às 9h de todos os dias úteis e ninguém sabe dizer porquê. Ou alguém lhe entregou uma frase em vez de uma métrica: "para isto precisas de hardware dedicado".

A questão VPS ou servidor dedicado decide-se com um punhado de sinais que consegue medir. Na minha experiência, a maioria das cargas de trabalho que chegam aqui não aciona nenhum. Ambas as compras são legítimas, e um servidor dedicado é a resposta certa quando se verificam condições específicas.

A versão curta

• A passagem para hardware dedicado justifica-se quando dispara um sinal concreto, não quando uma máquina apenas parece lenta.
• Importam três sinais operacionais: utilização de CPU sustentada sem folga, steal time de CPU ou IO wait persistentes, e uma carga de trabalho que ultrapassou a maior instância que um fornecedor vende.
• Dois desses três sinais vêm muitas vezes do fornecedor ou do plano, não da virtualização. Teste isso antes de gastar.
• O PCI DSS e a HIPAA Security Rule especificam resultados de isolamento e controlo, não um formato de hardware. Nenhum deles, por si só, exige uma máquina física.
• O hardware dedicado só ganha no custo com utilização sustentada elevada. Abaixo disso, paga um patamar fixo de hardware que não está a usar.

O que difere entre um VPS e um servidor dedicado

Pegue num plano anunciado com 4 vCPU. Num servidor dedicado, quatro núcleos são seus, quer os use quer não. Num VPS, quatro vCPU são uma promessa de escalonamento: o hipervisor apresenta quatro processadores virtuais ao seu kernel e dá-lhes tempo em núcleos físicos conforme a sua política e a carga atual do host.

Em condições normais os dois comportam-se de forma idêntica. Sob contenção, não.

A diferença não é virtual contra físico. É o que lhe é garantido contra o que lhe é atribuído.

O modelo de isolamento segue a mesma divisão. Um VPS é isolado logicamente, pelo hipervisor: kernel próprio, espaço de memória próprio, discos virtuais próprios, impostos por software a correr sobre silício partilhado. VPS contra bare metal é uma diferença em onde se traça essa fronteira, não em se ela existe.

Ambos são isolamento a sério. Falham de maneiras diferentes e são auditados de maneiras diferentes, o que conta na secção de conformidade mais abaixo.

A sobrecarga do hipervisor raramente é já a explicação. Em KVM moderno com extensões de virtualização por hardware e controladores paravirtualizados, nunca encontrei o hipervisor como motivo de uma aplicação estar lenta.

Se um VPS está a render abaixo do esperado, a causa habitual é contenção ou dimensionamento.

A variável interessante vive na contenção, e isso é uma política do fornecedor, não uma propriedade da virtualização. A sobrevenda consiste em vender, entre todos os convidados, mais vCPU, mais IOPS ou mais memória do que o host tem fisicamente, na suposição de que nem todos atingem o pico ao mesmo tempo. Alguns fornecedores mal o fazem. Outros fazem-no de forma agressiva.

A consequência é incómoda para quem compra apenas pela categoria. Um VPS mal sobrevendido e um VPS bem gerido estão mais afastados em comportamento do que um VPS bem gerido e um servidor dedicado.

O alojamento partilhado fica fora desta comparação: sem acesso root e sem garantia de recursos consistente, e o nosso guia explica quando passar do alojamento partilhado para VPS se esse passo vier primeiro no seu caso. A colocation fica fora do âmbito. Compra e é dono do hardware, o que é outro modelo de aquisição, com outros contratos e outra história quando algo falha.

Os sinais de que já ultrapassou um VPS

Estas são verificações contra a sua própria telemetria, não regras práticas sobre o seu setor. Uma condição governa as três: um sinal só conta quando é sustentado.

Uma máquina colada aos 95 % de CPU durante uma janela de backup noturna está a comportar-se corretamente. Uma máquina colada aos 95 % de CPU durante quinze dias está a dizer-lhe alguma coisa.

Utilização de CPU sustentada sem folga

A condição a vigiar é uma média móvel ao longo de dias ou semanas que não deixa espaço para absorver um pico de tráfego, um processo descontrolado ou uma dependência lenta. Não uma leitura de pico. A partir daí os tempos de resposta degradam-se de forma não linear em vez de cederem suavemente, e o incidente seguinte não tem para onde ir.

A forma da carga desloca essa linha. Um consumidor de fila constante junto ao seu teto está mais perto de sarilhos do que uma camada web irregular que dispara duas vezes por dia e fica ociosa o resto do tempo. Leia a sua própria curva em vez de um número tirado da página de um fornecedor.

Estar limitado pela CPU não é o mesmo que precisar de hardware dedicado. O primeiro resolve-se muitas vezes dentro da virtualização: uma instância maior, ou uma de relógio mais alto quando a carga é de thread único e sensível à latência.

Confirme qual dos dois tem antes de pedir preço de uma máquina física. Uma aplicação de thread único não fica mais rápida com 32 núcleos.

Steal time e IO wait

O steal time de CPU é a percentagem de tempo em que o seu processador virtual estava pronto a correr e o hipervisor deu o núcleo físico a outra pessoa. É o número que distingue uma carga demasiado grande de um host demasiado cheio.

Não trate uma percentagem específica de steal time como um limiar. Observe a tendência na sua própria máquina. Perto de zero com saltos ocasionais é normal. Consistentemente diferente de zero e a subir significa que o host está em contenção.

Sustentado e alto numa carga sensível à latência significa que está a ser contornado no escalonamento, e é a aplicação que paga.

Dica: execute vmstat 1 30 e observe a coluna st no bloco de CPU; o top mostra o mesmo valor como %st. Faça a leitura nas suas horas de pico reais, não uma vez à meia-noite. Um host saudável tem este aspeto:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 412332  84120 1932144    0    0     0    12  842 1503 21  4 75  0  0
 2  0      0 411980  84120 1932148    0    0     0     0  901 1622 24  5 71  0  0

Um em contenção tem este aspeto, e o tempo em falta está na última coluna:

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0      0 288104  61228 1104996    0    0     8   140 1502 2210 31  6 45  1 17
 5  0      0 287960  61228 1105004    0    0     0     0 1610 2388 29  7 44  2 18

Steal time alto significa que este host está sobrevendido. É uma afirmação sobre o seu fornecedor e o seu plano, não sobre virtualização. A primeira resposta correta é mudar para um host melhor provisionado ou um plano com atribuição de vCPU dedicada. Sair da virtualização vem depois disso, não em vez disso.

Se a sua constatação for o steal time, o diagnóstico de sobrevenda é o primeiro fio a puxar.

Já tirei duas cargas de trabalho de um VPS por este motivo. Nenhuma estava limitada pela CPU. Ambas estavam em hosts vendidos acima da sua capacidade, e a uma delas bastou-lhe outro fornecedor.

O teto de escalabilidade

Bateu no teto quando a maior instância que o fornecedor vende já não chega para a carga, ou quando o último salto vertical deu bastante menos melhoria do que o anterior. O segundo caso passa facilmente despercebido. Se duplicar a instância comprou 20 % de melhoria, o estrangulamento mudou-se para um sítio onde mais vCPU não chegam.

Os gatilhos de armazenamento são os que mais vezes sobrevivem à investigação, e costumam chegar disfarçados de base de dados. A restrição raramente é o motor. É IO aleatório sustentado sobre um pool que partilha com desconhecidos.

Qualquer carga que leia e escreva blocos pequenos de forma contínua (uma base de dados ocupada, uma fila com persistência durável, um serviço com muitos logs) pressiona esse pool com o padrão que ele pior aguenta.

Observe o %wa e os seus próprios percentis de latência durante o pico de carga real. Se a latência varia de formas que a sua própria carga não explica, está em fila atrás de outros inquilinos, e discos que lhe pertençam são a correção fiável.

Dois destes três sinais costumam resolver-se sem sair da virtualização, e testá-lo sai mais barato do que comprar hardware.

Quando a conformidade exige hardware dedicado

Um auditor escreve "o ambiente de dados de titulares de cartão tem de correr em hardware dedicado" e a frase faz duas coisas diferentes conforme quem a lê. Para um profissional de conformidade costuma significar um ambiente isolado de outras cargas e com um âmbito apertado. Para quem compra alojamento parece uma categoria de produto.

É na diferença entre essas duas leituras que se gasta orçamento sem ganho nenhum de controlo.

Tanto o PCI DSS como a HIPAA Security Rule especificam resultados de isolamento e controlo em vez de um formato de hardware. Se o seu requisito é que um conjunto definido de sistemas esteja segmentado, com controlo de acessos, registado e avaliável de forma independente, um ambiente virtual bem segmentado satisfaz isso. Se o seu requisito é que nenhum código de outro inquilino corra no mesmo silício, só o hardware físico satisfaz.

Determine qual das duas frases lhe entregaram antes de pedir preço seja do que for.

No PCI DSS, o conceito operativo é o âmbito. A própria orientação do Security Standards Council sobre âmbito e segmentação de rede estabelece como posição por omissão que tudo está no âmbito até se verificar o contrário. Descreve a segmentação como um método que pode reduzir o número de componentes de sistema no âmbito. Esse suplemento não nomeia qualquer formato de hardware em ponto algum do seu texto.

Um ambiente virtual mal segmentado ainda pode arrastar para o âmbito muito mais da sua stack do que tinha orçamentado. Esse é o custo de o fazer mal, não um argumento contra fazê-lo.

A HIPAA é mais explícita quanto a assentar em controlos. O texto da disposição de flexibilidade de abordagem da HIPAA Security Rule, publicado pela Cornell Law School, refere que as entidades abrangidas e os seus parceiros de negócio podem usar quaisquer medidas de segurança que lhes permitam implementar as normas de forma razoável e adequada. A escolha é avaliada face à dimensão da organização, à infraestrutura técnica, ao custo e ao risco. É um teste de adequação, não uma especificação de equipamento.

Numa implementação alojada, o requisito operativo é normalmente contratual. O texto do 45 CFR § 164.308(b)(1) publicado pela Cornell Law School refere que uma entidade abrangida só pode deixar um parceiro de negócio tratar informação de saúde protegida em formato eletrónico depois de obter garantias satisfatórias de que será devidamente salvaguardada. Um fornecedor que não assine um acordo de parceiro de negócio desqualifica-se sozinho, tenha o hardware que tiver.

Alguns casos só se resolvem com dedicado. Um contrato com um cliente que estipula por escrito o isolamento físico é um deles.

Outro é um controlo que não consegue implementar sem acesso ao hardware: cifra integral do disco com uma chave que guarda num TPM que controla, arranque seguro verificado, ou uma linha de base de firmware que atesta você mesmo. Nesses casos, compre o hardware e pare de avaliar.

Dica: antes de aceitar "hardware dedicado" como requisito, pergunte a quem o escreveu que controlo isso implementa e a que sistemas se aplica. Muitas vezes a resposta é um ambiente isolado, delimitado ao ambiente de dados de titulares de cartão, e não um produto chamado servidor dedicado. Os preços são muito diferentes.

Os resultados de conformidade dependem do seu avaliador e do seu âmbito específico. Isto dá-lhe a pergunta certa para lhe fazer, não uma decisão que possa invocar contra ele.

Onde as curvas de custo se cruzam

Dedicated hardware looks cheap per core, and at sufficient scale it is. Across providers publishing public bare metal pricing, entry configurations in the 6-core, 32 GB class typically start from around $150 to $200 per month, while 24-core, 256 GB machines with multi-terabyte NVMe commonly start from $450 and up.

Those are typical list-price ranges as of August 2026, not a market average. Price your own shortlist.

Olhe para a forma em vez dos números absolutos. O preço de um VPS é quase linear face aos recursos atribuídos e praticamente não tem patamar mínimo, por isso uma instância de 1 GB custa uns dólares. O preço do dedicado começa no que custa uma máquina física inteira e depois sobe devagar, porque o custo marginal de mais núcleos dentro de um chassis que já aluga é baixo.

Duas retas com declives diferentes e ordenadas na origem diferentes cruzam-se num ponto.

É a utilização que decide de que lado desse cruzamento está. A reta do dedicado é fixa: paga por 24 núcleos quer use 24 quer use 4.

Uma máquina dedicada a 20 % de utilização custa mais por unidade de trabalho entregue do que um VPS bem dimensionado, mesmo quando a fatura é menor por núcleo. O denominador é o que consumiu, não o que lhe venderam.

O ponto de cruzamento não é "acima de N núcleos". É "acima de N núcleos que mantém ocupados".

Três custos não aparecem em nenhuma das faturas e pertencem à comparação:

• Tempo de aprovisionamento. Um VPS fica disponível em minutos. O hardware físico encomenda-se, monta-se em rack e entrega-se em horas ou dias. Essa latência é uma restrição de planeamento de capacidade, não um incómodo pontual.
• Sem redução de escala. Depois de um pico de tráfego pode encolher um VPS de novo. Um servidor dedicado é um compromisso mensal no seu tamanho máximo até acabar o prazo do contrato.
• Falha de hardware. Quando um host falha debaixo de si num VPS, o fornecedor migra-o ou restaura-o. Quando um disco ou uma fonte falha na sua máquina dedicada, o caminho de recuperação é um pedido de suporte e um restauro a partir de backup, com a indisponibilidade a contar no seu próprio SLA.

Quando um VPS continua a ser a resposta certa

Nenhum sinal disparou. A utilização tem folga, o steal time está plano, o teto de tamanho da instância está longe, nenhum contrato exige isolamento físico e o seu consumo não está nem perto do cruzamento de custos. Fique virtualizado.

Isso é capacidade, não prémio de consolação. Os snapshots tornam uma atualização reversível e uma migração arriscada testável. Instâncias pequenas separadas dão-lhe separação de ambientes a um preço que faz valer a pena ter staging.

E a avaria de hardware às 3 da manhã é de outra pessoa, o que para uma equipa pequena vale mais do que uma diferença de benchmark.

A distância encurtou, e isso é uma mudança na tecnologia, não um argumento de venda. Planos com vCPU dedicada, NVMe por omissão e controladores paravirtualizados já maduros retiraram quase toda a distância prática de desempenho para cargas típicas.

A longevidade do fornecedor pertence à lista curta ao lado das especificações. Um plano VPS que pode abandonar numa tarde traz menos risco de fornecedor do que um contrato de hardware de doze meses. Isso só se mantém se o fornecedor ainda existir e ainda responder a pedidos no nono mês. Verifique há quanto tempo opera, como publica o histórico de incidentes e como o suporte responde antes de uma falha, e não durante.

Também existe alojamento dedicado gerido, que troca controlo do hardware por menos carga operacional, o que está no mesmo eixo que a decisão entre gerido e não gerido um nível abaixo.

Ficar num VPS é uma decisão ativa, com o seu próprio caminho de escalada, não a opção por omissão em que se cai por não escolher.

Se o seu diagnóstico foi contenção e não capacidade, a compra em causa é um VPS, não um chassis. O que quer dele é a liberdade de voltar a reduzir depois do acontecimento que o trouxe até aqui. É precisamente para esse caso que construímos: o nosso Linux VPS corre sobre armazenamento NVMe com um SLA de disponibilidade de 99,95 % e faturação à hora. Testar uma instância maior ou de relógio mais alto custa-lhe uma tarde em vez de um contrato. Dimensione-a face aos limiares acima, passe-lhe o seu próprio pico e volte a ver o steal time.

Perguntas frequentes

Quanto mais rápido é um servidor dedicado do que um VPS?

Depende do recurso pelo qual está a competir. Com virtualização moderna, a diferença de CPU num host bem provisionado é pequena, porque a sobrecarga do hipervisor é mínima com extensões de virtualização por hardware. As diferenças fiáveis são a ausência de contenção de IO e de rede, e notam-se como consistência de latência mais do que como velocidade bruta. Se a sua carga nunca disputa disco ou rede no pico, conte com uma diferença pequena de mais para decidir a compra.

Um VPS chega para uma base de dados em produção?

Para a maioria das bases de dados em produção, sim. A restrição determinante costuma ser IO aleatório sustentado sobre armazenamento partilhado, não o motor da base de dados. Uma base que lê e escreve blocos pequenos continuamente atinge o limite de um pool partilhado muito antes do limite do motor. Discos dedicados removem esse limite; uma instância maior não.

O PCI DSS exige um servidor dedicado?

Não, não como regra geral. O PCI DSS especifica requisitos de isolamento e controlo delimitados ao ambiente de dados de titulares de cartão, e não um formato de hardware. A orientação de âmbito do Security Standards Council trata tudo como dentro do âmbito até se verificar o contrário e descreve a segmentação de rede como método para reduzir os sistemas no âmbito. Um ambiente virtual bem segmentado pode satisfazer isto; um mal segmentado puxa muito mais da sua stack para dentro do âmbito.

Como sei se o meu VPS tem um problema de vizinho barulhento?

O sintoma é desempenho inconstante no pico numa máquina que de resto não está ocupada: tempos de resposta que oscilam enquanto a sua carga, memória e uso de disco se mantêm planos e sem nada de especial. As horas calmas parecem normais, e é por isso que o problema sobrevive tanto tempo sem diagnóstico. A causa está no host físico que partilha, por isso a correção é um plano melhor provisionado ou outro fornecedor, não reescrever a sua aplicação.

Quando devo passar de um VPS para um servidor dedicado?

Upgrade when at least one of these holds: CPU utilization sits at a rolling-average level that leaves no headroom for a traffic event; steal time or IO wait stays high after you have already tried a better-provisioned plan; the workload has outgrown the largest instance your provider sells; a contract or a control genuinely requires physical isolation; or sustained utilization is high enough that a fixed hardware cost beats per-resource pricing.