FullAgenticStack: eBPF “de verdade” em VPS vs Bare Metal

Esse artigo é uma explicação mais detalhada de um conceito que citei nesse artigo: https://dev.to/fullagenticstack/fullagenticstack-minha-arquitetura-basica-ainda-sem-ia-4gbi

Por que o UbiQEdgeWall precisa ser bare metal para XDP nativo, AF_XDP e rota direta da placa de rede para o socket do agente

Resumo: VPS pode rodar eBPF. VPS pode até rodar XDP genérico. Mas a versão realmente forte da arquitetura — o UbiQEdgeWall recebendo pacote cedo, filtrando antes do stack de rede, usando XDP nativo/offload e encaminhando por AF_XDP para um socket de agente — exige bare metal ou uma instância “metal” onde você tenha controle real do kernel, driver e interface de rede.

Este artigo separa o que dá para fazer em VPS, o que exige servidor físico dedicado, quais provedores fazem sentido para testar, e quais preços públicos eu encontrei para os provedores citados.

Os preços mudam por região, estoque, contrato, imposto, setup fee e câmbio. Use este documento como mapa técnico e comparativo inicial, não como orçamento final.

---

1. A confusão principal: eBPF não é a mesma coisa que XDP nativo

A pergunta correta não é apenas:

“A VPS deixa usar eBPF?”

A pergunta correta é:

“A VPS deixa usar o tipo de eBPF/XDP que minha arquitetura precisa?”

Existem níveis diferentes:

1. eBPF para observabilidade, tracing, socket, cgroup e TC
   
   Geralmente pode funcionar em VPS Linux, desde que o kernel tenha suporte, as permissões existam e o provedor não bloqueie recursos necessários.

2. XDP genérico
   
   Pode funcionar em praticamente qualquer interface, inclusive virtual, mas roda mais tarde no caminho do pacote. Ele é útil para MVP, mas não representa o melhor caso de performance.

3. XDP nativo / driver mode
   
   O programa roda no ponto mais cedo possível do recebimento do pacote no driver da interface. Isso exige suporte do driver e acesso real à interface. É aqui que VPS normalmente falha.

4. XDP offload
   
   O programa roda na própria placa de rede. Isso exige hardware específico e suporte do driver/NIC. Em VPS comum, praticamente não é o cenário esperado.

5. AF_XDP / XDP Socket
   
   Permite que um programa XDP redirecione pacotes para sockets otimizados em userspace. Para a ideia do UbiQUIC/UbiQEdgeWall de levar o pacote do plano de rede para o socket do agente clone com o mínimo de overhead, AF_XDP é a peça correta — mas o ganho real depende de driver, NIC, filas, zero-copy e configuração fina.

A documentação de eBPF descreve que programas XDP podem ser anexados a dispositivos de rede e são chamados para pacotes de entrada, podendo dropar, redirecionar, manipular ou permitir o pacote. A grande vantagem de XDP vem do fato de ele atuar antes de partes caras do stack de rede, especialmente antes do caminho tradicional com alocação de sk_buff.¹

A documentação da Red Hat separa os modos de XDP em native/driver, generic e offloaded. Ela também deixa claro que o modo nativo depende do suporte do driver da interface, enquanto o modo genérico funciona de forma mais ampla, mas com overhead maior. O modo offloaded exige hardware específico.²

---

2. O que uma VPS normalmente permite

Uma VPS comum pode ser suficiente para:

• observabilidade com eBPF;
• tracing de syscalls, processos, TCP, disco e rede;
• filtros em tc ingress/egress;
• cgroup eBPF;
• socket filters;
• nftables, iptables, tc, clsact e políticas de rate-limit;
• XDP genérico em alguns cenários;
• protótipo de EdgeFilter.

Então a versão barata da arquitetura pode usar uma VPS como:

EdgeFilter VPS

Essa camada já ajuda muito. Ela reduz ruído, aplica filtros, coleta métricas e corta tráfego local antes da aplicação.

Mas ela não deve ser vendida conceitualmente como “eBPF direto da placa de rede”.

Numa VPS, a interface que você vê normalmente é virtualizada. Você enxerga algo como eth0, ens3, virtio_net, ena, gve ou outra interface exposta pela camada de virtualização do provedor. A placa física real, as filas da NIC, parte dos offloads e o hypervisor ficam fora do seu controle.

Por isso, a frase correta é:

VPS serve para EdgeFilter eBPF operacional.

Bare metal serve para UbiQEdgeWall real.

---

3. O que o UbiQEdgeWall real precisa

O UbiQEdgeWall real é o servidor de borda que faz sentido para a arquitetura final.

Ele precisa controlar:

• kernel Linux;
• versão do kernel;
• driver da NIC;
• suporte a XDP nativo;
• suporte a AF_XDP;
• múltiplas filas RX/TX;
• RSS/RPS/XPS;
• IRQ affinity;
• ethtool;
• offloads da NIC;
• MTU;
• pinning por core;
• NUMA;
• bpftool;
• libxdp;
• xdp-tools;
• modo zero-copy quando disponível.

O caminho ideal é:

NIC física
  -> driver com XDP native
  -> programa XDP
  -> decisão: drop / pass / redirect
  -> AF_XDP socket
  -> UbiQEdgeWall userspace
  -> UbiQUIC / UbiQ
  -> socket do Agent clone

Esse desenho é o que permite falar, tecnicamente, em algo próximo de:

replicação e encaminhamento operacional em tempo real do plano de rede para o socket do agente clone.

Sem bare metal, você ainda pode simular o fluxo e validar o runtime. Mas a parte “direto da placa de rede” fica conceitualmente enfraquecida.

---

4. Teste prático: como saber se o servidor presta para UbiQEdgeWall

Depois de contratar o servidor, o teste mínimo é:

uname -r
sudo bpftool feature probe kernel
sudo bpftool feature probe dev eth0
ethtool -i eth0
ethtool -k eth0
ip -details link show eth0

O bpftool feature probe é a forma prática de inspecionar recursos eBPF disponíveis no kernel, tipos de programa, tipos de mapa e helpers.³

Teste XDP nativo:

sudo ip link set dev eth0 xdp obj xdp_pass.o sec xdp

Teste XDP genérico:

sudo ip link set dev eth0 xdpgeneric obj xdp_pass.o sec xdp

Teste XDP offload, se a NIC suportar:

sudo ip link set dev eth0 xdpoffload obj xdp_pass.o sec xdp

Se só xdpgeneric funcionar, o servidor pode servir para MVP, mas não para o UbiQEdgeWall final.

Se xdp nativo funcionar, aí começa a ficar interessante.

Se AF_XDP com zero-copy funcionar, aí começa a ficar realmente forte para o desenho do UbiQUIC/UbiQEdgeWall.

A documentação do kernel define AF_XDP como uma família de sockets otimizada para processamento de pacotes de alta performance.⁴

---

5. Dois nomes para não confundir a arquitetura

Eu usaria dois nomes diferentes:

EdgeFilter VPS

Versão barata.

Roda:

• eBPF possível na VM;
• TC ingress/egress;
• nftables;
• XDP genérico quando disponível;
• observabilidade;
• rate-limit;
• filtros simples;
• descarte antes da aplicação.

Serve para MVP, validação, custo baixo e proteção inicial.

UbiQEdgeWall Bare Metal

Versão correta.

Roda:

• XDP nativo;
• AF_XDP;
• controle de driver/NIC;
• controle de filas;
• IRQ affinity;
• RSS/RPS/XPS;
• tuning de kernel;
• roteamento UbiQUIC;
• encaminhamento para socket do agente clone;
• política Zero Trust de admissão antes da aplicação.

Serve para produção séria, baixa latência, alto volume, descarte agressivo e arquitetura realmente State-of-the-Art.

---

6. Provedores citados: preços e especificações públicas

A tabela abaixo resume os provedores citados e o que eu encontrei de preço/especificação em páginas públicas. Em todos os casos, é necessário validar o driver/NIC real depois da contratação, porque preço e CPU não garantem XDP nativo nem AF_XDP zero-copy.

Provedor	Tipo	Exemplo público encontrado	Preço público encontrado	Especificações encontradas	Link de preço/spec	Leitura arquitetural
Hetzner	Dedicated root server	EX44	a partir de €44/mês na página pública de Dedicated Root Server / EX-Line	Intel Core i5-13500, 64 GB DDR4, 2 × 512 GB NVMe, porta 1 Gbit/s, tráfego ilimitado	https://www.hetzner.com/dedicated-rootserver/ex44/	Excelente candidato barato para primeiro UbiQEdgeWall bare metal europeu. Precisa validar NIC/driver/XDP nativo no servidor entregue.
OVHcloud	Dedicated / Bare Metal	Advance-3 / Advance-4 / Scale	Advance-3 2026: a partir de US$236/mês; Scale-a2/linhas superiores: a partir de US$484/mês em exemplos públicos	Advance-3: AMD EPYC 4465P, 12c/24t, 64–256 GB, NVMe, private 25 Gbps, public 1–5 Gbps. Scale/linha superior: até 50 Gbps private e public até 25 Gbps em planos maiores	https://www.ovhcloud.com/en/bare-metal/prices/	Muito bom para edge com rede forte e mitigação de DDoS. Custo maior que Hetzner/Scaleway, mas melhor perfil de rede.
Vultr	Bare Metal	AMD EPYC 9255 / 9354P	Página pública mostra AMD EPYC 9255 a US$1.481/hora e AMD EPYC 9354P a US$2.158/hora; homepage também anuncia Bare Metal a partir de US$120/mês	EPYC moderno, SSD/NVMe, bare metal automatizado; detalhes variam por região/plano	https://www.vultr.com/products/bare-metal/	Bom para multi-região e provisionamento simples. Para UbiQEdgeWall, validar NIC e se XDP/AF_XDP funciona no hardware entregue.
Scaleway	Elastic Metal / Dedibox	EM-B220E-NVMe / EM-I120E-NVMe / Dedibox Start	EM-B220E-NVMe: €119.99/mês; EM-I120E-NVMe: €129.99/mês; Dedibox Start a partir de €4.74/mês com compromisso anual	EM-B220E: AMD EPYC 7232P, 8c/16t, 64 GB, 2 × 1.02 TB NVMe, 1 Gbps até 10 Gbps. EM-I120E: AMD EPYC 8024P, 8c/16t, 64 GB, 2 × 960 GB NVMe, 1 Gbps até 25 Gbps	https://www.scaleway.com/en/pricing/elastic-metal/ e https://www.scaleway.com/en/dedibox/	Um dos melhores candidatos custo/controle na Europa para começar. Linha Elastic Metal é mais coerente para edge do que Dedibox ultra-barato.
Leaseweb	Dedicated servers	HP DL120 G9 / Dell R730XD / High bandwidth	Página pública lista exemplos como €71.80/mês para HP DL120 G9 e promo de Dell R730XD €164.14/mês; há opções high-bandwidth > €1.149/mês	Exemplo: HP DL120 G9, Xeon E5-1620v3, 32 GB, 2 × 480 GB SSD, 30 TB traffic, entrega em 1 hora. Várias regiões: Holanda, EUA, Alemanha, Canadá, Reino Unido, Singapura, Hong Kong, Austrália, Japão	https://www.leaseweb.com/en/c/dedicated-server	Forte por presença global e variedade. Bom para edge geográfico. Precisa validar NIC/driver no modelo exato.
IBM Cloud	Bare Metal Servers	VPC / Classic bare metal	Página oficial descreve preço flexível hourly, monthly e reserved, mas o preço exato depende do configurador	Classic: mais de 11 milhões de combinações e 20 TB de bandwidth incluído; VPC: perfis preset e deployment em regiões multizona	https://www.ibm.com/products/bare-metal-servers/pricing	Bom para ambiente enterprise, compliance e contrato. Para arquitetura barata, provavelmente caro ou burocrático. Para UbiQEdgeWall, validar acesso real a NIC/driver.
AWS	EC2 Metal	m7i.metal-24xl / m7i.metal-48xl	m7i.metal-24xl aparece em agregador de preço como US$4.8384/hora; m7i.metal-48xl como US$9.6768/hora. AWS publica pricing por região no Price List API	AWS docs: m7i.metal-24xl e m7i.metal-48xl são tamanhos bare metal; m7i.metal-24xl tem perfil de 96 vCPUs, 384 GiB RAM e rede alta	Specs: https://aws.amazon.com/ec2/instance-types/m7i/ e https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html. Pricing/API: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-the-aws-price-list-bulk-api-fetching-price-list-files-manually.html. Agregador usado para número rápido: https://instances.vantage.sh/aws/ec2/m7i.metal-24xl	Excelente tecnicamente, caro para seu MVP. Pode ser útil se o UbiQEdgeWall precisar estar dentro da AWS. Validar ENA/XDP/AF_XDP no AMI/kernel.
Oracle Cloud Infrastructure	Bare Metal	BM.Standard.E6 / E6 Ax	Oracle Price List mostra Compute - Standard - E6 Ax - OCPU: US$0.0138/OCPU-hora; blog oficial de E6 Standard informa US$0.03/OCPU-hora + US$0.002/GB-hora de memória	Compute Shapes: BM.Standard.E6 / E6 Ax usam AMD EPYC 9J45, base 2.7 GHz, boost 4.1 GHz; shapes bare metal podem ter muitos OCPUs e RAM	Price list: https://www.oracle.com/cloud/price-list/. Shapes: https://docs.oracle.com/iaas/Content/Compute/References/computeshapes.htm. Blog E6: https://blogs.oracle.com/cloud-infrastructure/oci-launches-e6-standard-compute-powered-by-amd	Forte para bare metal grande, mas provavelmente overkill para edge barato. Bom se precisar de muita CPU/RAM e integração OCI.

---

7. Provedor por papel na sua arquitetura

Para sua arquitetura, eu não escolheria o provedor só por CPU. Eu escolheria por papel.

MVP barato

EdgeFilter VPS: VPS comum com eBPF/TC/nftables/XDP generic
Clones: VPS baratas em provedores diferentes
Crypto workers: VPS mínimas, sem persistência
UbiQ: VPS separada
Persistência: VPS ou servidor com disco melhor

Aqui, o objetivo é validar o runtime, o UbiQ, o QBEQStore, os clones, os workers de crypto e a governança de CPU.

Produção séria

UbiQEdgeWall: bare metal real
Clones: VPS ou bare metal leve, provedores diferentes
Crypto workers: VPS descartáveis ou bare metal barato
UbiQ: VPS forte ou bare metal pequeno
Persistência: servidor separado, idealmente com storage robusto

Aqui, o UbiQEdgeWall precisa ser contratado como servidor físico dedicado ou metal instance.

Produção agressiva

UbiQEdgeWall primário: bare metal com XDP native + AF_XDP
UbiQEdgeWall secundário: outro provedor/continente
Clone A: provedor 1
Clone B: provedor 2
UbiQ: provedor 3
Persistência: provedor 4
Crypto workers: provedores baratos e descartáveis

Aqui, a meta é reduzir blast radius: nenhum provedor, região, rede ou contrato pode derrubar a arquitetura inteira.

---

8. Por que eu não colocaria Google Cloud como hot path do UbiQEdgeWall

Google Cloud tem Bare Metal Solution, mas ela é apresentada como máquinas bare metal em extensões regionais co-localizadas próximas a regiões Google Cloud, não como o caminho mais simples para montar um edge packet-processing barato e portátil.⁵

Além disso, em arquitetura multi-região e multi-cloud, o custo de tráfego precisa ser tratado como parte do desenho. A página oficial de VPC Network Pricing do Google mostra cobrança de transferência entre regiões por GiB, com valores variando conforme origem e destino.⁶

Então, para essa arquitetura, eu usaria Google apenas com muito cuidado:

• clone receptor;
• nó passivo;
• ambiente de teste;
• ponto específico quando o tráfego não precisa sair muito;
• integração com algum serviço Google que justifique o custo.

Eu não colocaria Google como centro de fan-out de replicação ou como UbiQEdgeWall principal sem simular custo de egress antes.

---

9. O ponto técnico que precisa ficar claro no artigo

A frase correta é:

VPS roda eBPF.

VPS pode rodar XDP genérico.

VPS raramente é o lugar certo para XDP nativo/offload real.

UbiQEdgeWall final precisa de bare metal.

E a frase operacional é:

Na arquitetura barata, use EdgeFilter VPS.

Na arquitetura State-of-the-Art, use UbiQEdgeWall Bare Metal.

Essa separação evita vender conceito errado.

---

10. Checklist antes de comprar o bare metal

Antes de contratar, eu perguntaria ao provedor ou validaria assim que a máquina subir:

• Qual é a NIC real?
• Qual é o driver Linux?
• O driver suporta XDP native?
• O driver suporta redirect?
• O driver suporta AF_XDP?
• Existe suporte a zero-copy?
• Quantas filas RX/TX existem?
• Consigo alterar IRQ affinity?
• Consigo alterar RSS/RPS/XPS?
• Consigo usar kernel customizado?
• Consigo desabilitar offloads problemáticos?
• Existe DDoS protection antes do meu servidor?
• Existe limite de PPS?
• O provedor limita pacotes UDP?
• O provedor filtra tráfego antes de mim?
• Existe console remoto/IPMI/KVM?
• Existe reinstalação automática?
• Existe rescue mode?
• Existe custo de tráfego saindo?
• Existe cobrança por tráfego interno?
• Existe custo para failover IP?
• Existe custo para private network?

O servidor barato que não responde bem a essas perguntas pode até ser ótimo para clone, UbiQ ou worker de crypto, mas não necessariamente para UbiQEdgeWall.

---

11. Comandos de validação inicial

# Kernel
uname -a
uname -r

# Interface e driver
ip -details link show
ethtool -i eth0
ethtool -k eth0
ethtool -l eth0
ethtool -S eth0 | head

# Recursos BPF do kernel e device
sudo bpftool feature probe kernel
sudo bpftool feature probe dev eth0

# Teste de attach XDP nativo
sudo ip link set dev eth0 xdp obj xdp_pass.o sec xdp

# Remover XDP
sudo ip link set dev eth0 xdp off

# Teste genérico
sudo ip link set dev eth0 xdpgeneric obj xdp_pass.o sec xdp

# Teste offload, se houver hardware
sudo ip link set dev eth0 xdpoffload obj xdp_pass.o sec xdp

Se o attach nativo falhar e só o genérico funcionar, não é o servidor ideal para UbiQEdgeWall final.

---

12. Recomendação prática

Para o seu caso, eu organizaria assim:

Fase 1: validar runtime sem gastar muito

Use VPS para EdgeFilter.

Use:

• nftables;
• tc;
• cgroup eBPF;
• socket filters;
• tracing;
• XDP generic se funcionar;
• logs de queda;
• métricas de PPS;
• rate-limit.

Objetivo: validar arquitetura, não performance máxima.

Fase 2: primeiro UbiQEdgeWall real

Contrate um bare metal barato na Europa.

Candidatos iniciais:

• Hetzner EX44;
• Scaleway Elastic Metal EM-B220E ou EM-I120E;
• Leaseweb entry/mid-range;
• OVH Advance se quiser rede mais forte.

Objetivo: validar XDP native, AF_XDP, tuning de fila, IRQ affinity e encaminhamento para UbiQ/UbiQUIC.

Fase 3: UbiQEdgeWall multi-provedor

Use dois bare metals de provedores diferentes.

Exemplo:

UbiQEdgeWall A: Hetzner ou Scaleway
UbiQEdgeWall B: OVH ou Leaseweb
Clone A: DigitalOcean
Clone B: Oracle Free / Vultr / outro
UbiQ: provedor separado
Persistência: provedor separado
Crypto workers: VPSs baratas e descartáveis

Objetivo: sobreviver a falha de provedor, região, rota, contrato, DDoS, saturação e incidente operacional.

---

13. Conclusão

A intuição estava certa:

“Nenhuma VPS deixa usar eBPF de verdade?”

A resposta precisa ser mais precisa:

• VPS deixa usar algum eBPF.
• VPS pode deixar usar XDP genérico.
• VPS geralmente não entrega controle físico real da placa de rede.
• Para XDP nativo, AF_XDP forte, filas da NIC, tuning de IRQ e caminho de pacote realmente cedo, o caminho correto é bare metal.

Então a arquitetura deve assumir dois níveis:

EdgeFilter VPS = versão barata, operacional, boa para MVP.
UbiQEdgeWall Bare Metal = versão correta, final, State-of-the-Art.

Essa distinção evita erro conceitual e melhora o desenho do sistema.

O UbiQEdgeWall não é só “um servidor com firewall”.

Ele é a borda programável do runtime.

Ele existe para filtrar, classificar, descartar, redirecionar e preparar o pacote antes que ele vire custo de aplicação.

E para isso, quando o objetivo é o máximo controle possível do caminho de rede, o servidor certo é físico.

---

Fontes

Fontes de preço e especificação por provedor

• Hetzner EX44: https://www.hetzner.com/dedicated-rootserver/ex44/
• Hetzner Dedicated Root Server overview: https://www.hetzner.com/dedicated-rootserver
• OVHcloud Bare Metal prices: https://www.ovhcloud.com/en/bare-metal/prices/
• Vultr Bare Metal: https://www.vultr.com/products/bare-metal/
• Vultr pricing overview: https://www.vultr.com/pricing/
• Scaleway Elastic Metal pricing: https://www.scaleway.com/en/pricing/elastic-metal/
• Scaleway Dedibox: https://www.scaleway.com/en/dedibox/
• Leaseweb Dedicated Servers: https://www.leaseweb.com/en/c/dedicated-server
• IBM Cloud Bare Metal pricing: https://www.ibm.com/products/bare-metal-servers/pricing
• IBM Cloud Bare Metal overview: https://www.ibm.com/products/bare-metal-servers
• AWS EC2 M7i instance types: https://aws.amazon.com/ec2/instance-types/m7i/
• AWS EC2 instance specifications: https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html
• AWS Price List Bulk API docs: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-the-aws-price-list-bulk-api-fetching-price-list-files-manually.html
• Vantage AWS m7i.metal-24xl quick pricing mirror: https://instances.vantage.sh/aws/ec2/m7i.metal-24xl
• Vantage AWS m7i.metal-48xl quick pricing mirror: https://instances.vantage.sh/aws/ec2/m7i.metal-48xl
• Oracle Cloud price list: https://www.oracle.com/cloud/price-list/
• Oracle Compute Shapes docs: https://docs.oracle.com/iaas/Content/Compute/References/computeshapes.htm
• Oracle E6 Standard launch/pricing blog: https://blogs.oracle.com/cloud-infrastructure/oci-launches-e6-standard-compute-powered-by-amd

---

1. eBPF Docs — Program Type BPF_PROG_TYPE_XDP: https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_XDP/ ↩

2. Red Hat Documentation — Getting started with XDP and eBPF: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/getting-started-with-xdp-and-ebpf ↩

3. ebpf-go Documentation — Feature Detection / bpftool feature probe: https://ebpf-go.dev/concepts/features/ ↩

4. Linux Kernel Documentation — AF_XDP: https://docs.kernel.org/networking/af_xdp.html ↩

5. Google Cloud Bare Metal Solution docs: https://docs.cloud.google.com/bare-metal/docs ↩

6. Google Cloud VPC network pricing: https://cloud.google.com/vpc/network-pricing ↩