Segmentación de red y seguridad WireGuard para render farm: una arquitectura Tier-1 + Tier-2

Introducción

Una render farm es un problema de red antes de ser un problema de renderizado. Los frames fluyen entre una máquina de submission, un manager, una flota de workers, una caché de assets y un store de outputs; las credenciales fluyen entre artistas y servidores de licencia; las sesiones remote fluyen entre artistas y la superficie de workstation que están conduciendo. Cuando la red es un switch en una sala, el modelo de seguridad es mayormente perimétrico. Cuando la farm abarca datacenters o continentes, el perímetro ya no es una unidad de análisis útil: cada enlace que cruza una frontera de edificio es un enlace de internet público hasta que se demuestre lo contrario, cada credencial que toca un sistema remoto puede ser interceptada, y cada worker que puede alcanzar a cada otro worker es un worker que puede pivotar si alguna vez se compromete.

Este artículo describe la arquitectura de seguridad que operamos para deployments render farm cross-site y cross-country — un modelo firewall de dos tiers con edge default-deny, firewalls de host por nodo detrás, cifrado WireGuard de extremo a extremo para cada enlace que cruza una frontera de edificio, modelos de acceso de mínimo privilegio para cada rol de operador, y primitivas de aislamiento de cliente que escalan desde infraestructura multi-tenant compartida hasta clusters dedicados de un único cliente. El público objetivo: equipos de seguridad IT evaluando vendors de cloud-rendering, compliance officers y arquitectos de pipeline. Un escrito separado sobre la arquitectura de red — WireGuard hub-and-spoke, BBR, MSS clamping y caché SMB compartida — cubre el transporte; este artículo cubre lo que sucede por encima del cable.

Principios de segmentación de red para render farm

La segmentación significa aquí tres cosas distintas. Primero, ningún nodo puede alcanzar a otro nodo que no necesite alcanzar para su trabajo. Un worker render lee assets desde la caché, tira jobs del manager, escribe outputs de vuelta a una ubicación conocida y envía telemetría heartbeat — y nada más. Un worker comprometido que no puede pivotar a otros workers, alcanzar SSH del operador o el management plane es una falla contenida en lugar de una falla cluster-wide. El movimiento lateral es lo más consecuente que una política de segmentación previene.

Segundo, ningún cliente puede alcanzar a otro cliente. En infraestructura multi-tenant, esto significa que procesos, cuentas de usuario, rutas de sistema de archivos y check-outs de licencia están aislados por cliente a nivel del sistema operativo. En infraestructura dedicated cluster, esto significa fronteras físicas de hardware, hubs WireGuard, stores de credenciales y superficies de gestión operativa separados. La fuerza del aislamiento debe coincidir con la sensibilidad del workload — una freelance renderizando una visualización de producto y un estudio renderizando trabajo entertainment pre-release no necesitan el mismo nivel, pero deben poder elegir el nivel que se adapte a su threat model.

Tercero, ningún cliente puede alcanzar los sistemas internos del operador más allá de la superficie que un trabajo realmente necesita. Una submission render escribe en la cola del manager y lee sus propios outputs; no necesita enumerar a otros clientes, leer la base de datos billing del operador o alcanzar su source control. Esta es la frontera de privilegio que protege a cada cliente de cada otro cliente a través de los propios sistemas del operador.

El modelo tier que operamos refleja estos tres principios. Tier 1 es el perímetro — el edge gateway de cara al internet público que decide qué tráfico entra. Tier 2 es el firewall de host por nodo — cada máquina dentro del perímetro decide independientemente de qué peers acepta conexiones. Por encima de ambos tiers, los controles de acceso a nivel aplicación imponen separación de roles, aislamiento de cliente y la frontera de auditoría que las compliance reviews observan. Cada tier es auditable independientemente; una falla en uno no colapsa los otros.

Edge Tier-1 con ufw y default-deny

El edge del cluster es un único gateway Linux con ufw, el frontend canónico para nftables en Ubuntu LTS. La postura configurada es default deny incoming y default allow outgoing. La única regla entrante en la interfaz pública es allow 51820/udp para WireGuard. Nada más acepta tráfico del lado público — no SSH, no HTTPS, no SMB, no API render manager, no agentes monitoring. Esos servicios bindean a interfaces internas únicamente; alcanzarlos desde fuera del cluster requiere terminar primero un túnel WireGuard.

El razonamiento es mecánico. Cada puerto abierto en internet público se escanea en minutos y se sondea continuamente después. Reducir el número de puertos públicos a exactamente uno, y hacer que ese puerto hable un protocolo que no responde a probes no autenticados (WireGuard no responde nada a un peer que no conoce), reduce la superficie de ataque a la unidad significativa más pequeña. SSH detrás de un túnel WireGuard es un objetivo que el atacante no puede alcanzar sin primero derrotar a WireGuard.

La cadena forward necesita atención explícita. El gateway actúa como router entre la interfaz WireGuard y el subred cluster interno, y la postura forward por defecto de ufw es deny. Establecemos DEFAULT_FORWARD_POLICY="ACCEPT" en /etc/default/ufw, luego restringimos los flujos efectivamente reenviados con reglas FORWARD explícitas que permiten tráfico entre subredes cluster conocidos y deniegan todo lo demás. El resultado es un perímetro auditable que no enruta accidentalmente un paquete a un destino no previsto.

Las reglas salientes merecen la misma disciplina. Los workers tiran de un pequeño conjunto de asset stores upstream, el manager habla con un pequeño conjunto de servidores de licencia, la telemetría va a un pequeño conjunto de endpoints de monitoring, y las actualizaciones OS tiran de un mirror conocido. Bloquear los destinos salientes a ese pequeño conjunto bloquea una clase entera de comportamientos post-compromise: un worker comprometido que quiere exfiltrar datos a un host controlado por el atacante no llega porque el host no está en la allowlist de egress. El filtrado de egress convierte la exfiltración invisible en un intento ruidoso que el monitoring puede marcar.

El logging en el edge Tier-1 registra cada paquete entrante descartado y cada flujo reenviado, enviados a un log host central detrás del mismo túnel WireGuard alcanzable solo desde workstations operador autenticadas. Los logs son la fuente primaria de evidencia de auditoría para compliance reviews.

Firewall de host Tier-2 en cada nodo

El edge Tier-1 es necesario y no suficiente. Un worker alcanzable desde cada otro worker en el subred interno está a un compromise de un pivot cluster-wide, sin importar lo fuerte que sea el edge. Tier 2 es la respuesta: cada máquina dentro del perímetro opera su propio firewall de host, con su propio ruleset, decidiendo independientemente qué peers acepta.

En nodos Linux el firewall de host es ufw, configurado con la misma postura default-deny inbound que el edge pero con reglas internas que permiten solo las conexiones requeridas por el rol del nodo. Un worker render acepta SMB desde la caché, el protocolo render-manager desde el manager, telemetría monitoring desde el host monitoring, y SSH desde el subred bastion operador. Todo lo demás, incluyendo conexiones desde otros workers, se deniega. Un worker comprometido no puede sondear a su vecino porque el vecino no aceptará la conexión — el edge Tier-1 ha sido derrotado en este hipotético, y el firewall de host Tier-2 es la segunda línea que no lo ha sido.

En nodos Windows el firewall de host es Windows Defender Firewall with advanced security, configurado con reglas equivalentes. El RDP entrante está restringido a un subred operador estrecho para soporte de emergencia; el protocolo remote-desktop del cliente (un puerto streaming dedicado para Moonlight o equivalente) está permitido solo desde la dirección peer WireGuard del cliente; todo lo demás se deniega. Para el use case — imponer un pequeño ruleset en una flota de máquinas idénticamente configuradas — Windows Defender Firewall es plenamente adecuado, y la superficie de gestión se integra con Group Policy.

La pertenencia a grupo es la unidad de policy. Los nodos se agrupan por rol y cliente: workers customer-A un grupo, workers customer-B otro, nodos management operador un tercero, caché y almacenamiento un cuarto. Las conexiones cross-grupo requieren una regla explícita y se deniegan por defecto. Un worker customer-A no puede SMB-montar la caché de customer-B, no puede RDP la workstation de customer-B y no puede tirar un job de un manager customer-B — no porque la capa aplicación lo imponga, sino porque el firewall de host no permite que se complete el handshake TCP.

Las reglas firewall de host se gestionan vía configuration management para ser version-controlled, reviewables y consistentes en cada nodo. Un firewall mal configurado en uno de veinte nodos es difícil de detectar por inspección y fácil de atrapar con drift detection.

Cifrado WireGuard de extremo a extremo

Cada enlace que cruza una frontera de edificio está cifrado con WireGuard. Las workstations artistas tunelan WireGuard al gateway cluster. Los enlaces site-to-site tunelan WireGuard entre gateways. Las sesiones SSH operador tunelan WireGuard desde el laptop del operador a la bastion cluster. El LAN cluster interno dentro de un edificio no está cifrado WireGuard — ese tráfico está en un switch en una sala que controlamos — pero todo lo que sale del edificio sí lo está.

El atractivo de WireGuard aquí es una propiedad que no tiene nada que ver con la criptografía per se: no hay fallback plaintext. WireGuard no negocia cipher suites, no selecciona algoritmos en runtime y no tiene una ruta de código de "este peer pidió un cipher más viejo así que vamos a complacer". Cada túnel usa Curve25519 para key exchange, ChaCha20-Poly1305 para el data plane, BLAKE2s para hashing y Poly1305 para message authentication. La elección de cipher está fija a nivel protocolo. Una clase significativa de ataques a protocolos TLS-style negociados — downgrade, weak-cipher selection, broken-cipher legacy fallback — no aplica porque el protocolo no tiene el paso de negociación que esos ataques apuntan.

Las claves por peer son la segunda propiedad. Cada peer tiene su propia clave pública, y el hub permite o deniega explícitamente cada peer basado en su clave y AllowedIPs. No hay secreto compartido. Si la clave privada de una workstation se filtra, el fix del lado hub es remover ese peer y reissue un nuevo keypair para esa única workstation; cada otro peer continúa operando no perturbado. La forward secrecy es la tercera propiedad: WireGuard rota session keys regularmente, y las long-term keys se usan solo para el handshake inicial. Un atacante que graba tráfico y luego compromete una long-term key no puede descifrar el tráfico grabado, porque la session key derivada del intercambio efímero ya no existe.

La implementación a nivel kernel es la cuarta propiedad y determina si la arquitectura es operativamente tolerable a escala. WireGuard está en el kernel Linux mainline desde 5.6. En un gateway Xeon típico, kernel WireGuard sostiene throughput gigabit-class por peer a un costo CPU de un solo dígito. Para un gateway haciendo también routing, firewall y DNS, kernel-vs-userspace crypto es la diferencia entre una caja cómoda y una saturada.

Modelos de acceso de mínimo privilegio

Cada cuenta dentro del cluster tiene los privilegios mínimos para su trabajo, y los roles operador están separados de modo que ningún rol único pueda hacer todo. Cuatro clases de cuenta importan en los deployments que operamos.

Cuentas remote-desktop cliente se loguean en la superficie workstation del cliente con acceso a sus propios datos y entorno DCC. No tienen acceso shell al sistema operativo subyacente. El cliente conduce la DCC vía el protocolo remote-desktop, submitte renders, descarga outputs y nunca toca la capa de administración OS. Una cuenta cliente comprometida no puede alcanzar credenciales OS-level, contraseñas de servidor de licencia o infraestructura cluster compartida.

Cuentas operador DevOps tienen acceso SSH a nodos Linux vía la bastion. El acceso bastion requiere que el operador se autentique primero vía WireGuard, luego a la bastion con una clave hardware-backed, luego al nodo de destino con una clave por cuenta. La autenticación de dos factores se impone en la bastion. Cada sesión SSH se loguea en un audit log central que la propia cuenta del operador no puede modificar o eliminar — hora de inicio, dirección fuente, nodo destino, duración e historial de comandos.

Agentes monitoring en cada nodo tienen una cuenta de servicio dedicada con acceso read-only a las métricas que recopilan. No pueden ejecutar comandos arbitrarios, leer datos de aplicación o escribir a ninguna ubicación persistente además de su propio fichero log. El principio es que la observación no debe requerir derechos de modificación. El acceso almacenamiento se impone por ACLs SMB en la capa caché y NAS: un worker customer-A montando la caché solo ve el árbol customer-A; el servidor SMB lo impone a nivel sistema de archivos en lugar de depender del worker.

La separación de roles más importante es la entre operador y cliente. El operador no tiene acceso remote-desktop a workstations cliente excepto vía una sesión de soporte auditada que el cliente debe autorizar explícitamente. El cliente no tiene acceso OS-level a la infraestructura del operador. Esta frontera — impuesta a la capa WireGuard (configuraciones peer separadas), a la capa firewall de host (reglas de acceso separadas) y a la capa aplicación (realms de autenticación separados) — es la frontera que permite a un cliente confiar en que su workload es solo suyo.

Aislamiento de cliente: multi-tenant versus dedicated cluster

El aislamiento de cliente tiene dos implementaciones prácticas. La infraestructura SaaS multi-tenant opera los trabajos de muchos clientes en una flota compartida, aislándolos a nivel OS — cuentas de usuario, rutas de sistema de archivos, grupos de procesos y scopes de check-out de licencia separados. La infraestructura dedicated cluster opera los trabajos de un cliente en hardware asignado a ese único cliente durante la duración del engagement, sin que ningún proceso, cuenta o dato de otro cliente toque las mismas máquinas.

El aislamiento multi-tenant es el default, y para la mayoría de workloads es la elección correcta — la economía es mejor, y el aislamiento a nivel proceso combinado con ACLs sistema de archivos y las reglas firewall de host de arriba previene los patterns de acceso cross-customer que importan en práctica. El aislamiento dedicated cluster es la elección correcta cuando el valor del workload, el entorno regulatorio o las obligaciones contractuales exigen una frontera más fuerte. El threat model motivante es: ¿y si el aislamiento OS-level tiene una vulnerabilidad que aún no conocemos, o si el propio acceso interno del operador es en sí mismo el vector de ataque? En hardware dedicado, las respuestas están acotadas por la física — los datos del cliente viven en los discos del cliente, los procesos corren en las CPUs y GPUs del cliente, el hub WireGuard del cliente sirve solo a sus peers, y el acceso operador puede configurarse para requerir autorización explícita por sesión. Una clase de riesgos se mueve de "confiar en la implementación multi-tenant del operador" a "confiar en la propia frontera de hardware del cliente".

El modelo customer-owned-credentials — BYOC, donde las licencias DCC y credenciales asset-store del cliente las introduce el cliente y nunca las ve el operador — es el emparejamiento natural con dedicated cluster; ver el writeup customer-owned credentials para el modelo completo. Hardware dedicado más customer-owned credentials significa que el operador opera la infraestructura pero no ve material de autenticación, archivos fuente o datos de proyecto. El rol del operador se vuelve "mantener la infraestructura sana" en lugar de "tener acceso a los datos del cliente y elegir no usarlos".

Cuándo elegir dedicated sobre multi-tenant es específico al workload. Vemos a clientes elegir dedicated cuando una de tres condiciones está presente: un umbral de sensibilidad IP fijado por escrito por el equipo legal o compliance del cliente; un marco regulatorio que exige aislamiento de datos por cliente demostrable; o un umbral de escala donde la diferencia de costo se vuelve lo bastante pequeña para que el upside de aislamiento domine. Un artículo separado cubre el framework de decisión SaaS-vs-dedicated-cluster con más profundidad.

Compliance readiness (sin reivindicaciones de certificación)

La divulgación honesta primero: Super Renders Farm actualmente no está certificada SOC 2, actualmente no está certificada ISO 27001 y no tiene ninguna otra certificación formal de seguridad de la información que representaríamos a un compliance reviewer como "tenemos el certificado, puede tomarlo como evidencia". Cualquier cliente cuyo propio programa de compliance exija que sus vendors estén certificados debe saberlo antes de firmar un contrato.

Lo que sí proveemos es un conjunto de bloques técnicos que un auditor reviewando el programa compliance de un cliente puede examinar — los componentes de la arquitectura descrita en este artículo, vistos a través de las familias de controles que SOC 2 y ISO 27001 comparten a la capa técnica.

Cifrado at-rest y in-transit. Los datos en tránsito entre cliente y cluster, y entre nodos cluster que abarcan edificios, están cifrados por WireGuard (Curve25519 + ChaCha20-Poly1305). Los datos at-rest en la capa caché y almacenamiento usan funciones nativas OS de encryption-at-rest donde el cliente las solicita; esto es configurable por engagement porque los tradeoffs varían por workload. SMB3 está configurado para requerir cifrado in-transit en tráfico cross-site.

Capacidad de trazabilidad de auditoría. Los logs de sesión SSH se registran con fuente, destino, duración e historial de comandos en un log host que las cuentas operador no pueden modificar. Los logs de handshake WireGuard registran cada intento de conexión peer. Los logs render-job registran hora de submission, parámetros, estado de completion y uso de recursos por cliente. Estos logs pueden exportarse a petición para el auditor del cliente.

Control de acceso y segregación. El modelo firewall Tier-1 + Tier-2 es el control de segregación. La separación de roles operador-vs-cliente es el control de acceso basado en roles. Las pertenencias a grupos firewall por cliente en el modelo dedicated cluster son el control de aislamiento de cliente. Cada uno es auditable independientemente como texto. La destrucción de datos al final del engagement sigue un procedimiento documentado — eliminación a nivel de archivo, sobrescritura de espacio libre y una carta de atestación firmada por el operador registrando qué se destruyó, cuándo y por quién. La atestación es el artefacto que el programa compliance del cliente archiva como evidencia.

Monitoring de red. El cluster opera flow logging en el gateway y monitoring a nivel host en cada nodo. La intrusion detection de red continua al nivel que un objetivo SOC-2 "continuous monitoring" exigiría está en la roadmap interna pero no actualmente desplegada.

El encuadre que importa: la infraestructura del operador es un componente del programa compliance del cliente, no el programa en sí. Un cliente persiguiendo SOC 2 o ISO 27001 es evaluado en la totalidad de sus controles, de los cuales el vendor de rendering es un input. Nuestro trabajo es proveer bloques en los que el programa del cliente pueda confiar, y ser honestos sobre qué controles son maduros, parciales o todavía no están en scope.

Threat model

Los documentos de arquitectura sin threat model tienden a implicar que la arquitectura defiende contra todo, lo cual nunca es cierto. El scope de lo que esta arquitectura aborda está acotado; las fallas que no aborda son reales y vale la pena nombrarlas.

Contra qué defiende la arquitectura. Scanning y probing externos: la postura default-deny Tier-1 y el comportamiento authenticate-before-accept de WireGuard significan que la única respuesta del cluster a un scan no autenticado es silencio — sin banner para fingerprintear, sin string de versión para atacar, sin prompt de auth para brute-forcear. Movimiento lateral tras un compromise single-node: el firewall de host Tier-2 significa que un worker comprometido no puede escanear o pivotar a sus vecinos, alcanzar el management plane o la bastion operador. El blast radius es un nodo más lo que el nodo tenía acceso legítimo a — significativo, pero no cluster-wide. Robo de credenciales operador usadas contra el cliente: en el dedicated cluster con customer-owned credentials, el operador no tiene licencias, credenciales asset-store o claves de descifrado de proyecto del cliente, así que un compromise del store de credenciales operador no expone material de auth del cliente. Exfiltración de datos por personal operador, significativa pero no absolutamente: el acceso SSH operador requiere sesiones bastion auditadas, claves hardware-backed y autorización por sesión, elevando sustancialmente el costo de un escenario insider malicioso sin reducirlo a cero.

Contra qué no defiende plenamente la arquitectura. Ataques supply-chain: sistemas operativos, DCCs, plugins, render engines y el propio kernel son software escrito por partes distintas al operador; podemos mitigar (gestión de parches, host hardening, segmentación que limita lo que un binario comprometido puede alcanzar) pero no eliminar. El riesgo supply-chain es una categoría que compartimos con toda la industria en lugar de una que hayamos resuelto. Amenazas internas con acceso admin: un operador con acceso bastion, acceso audit-log e intención sostenida de mal-usar esos privilegios está restringido por audit logs, autenticación de dos factores, separación de roles y la frontera dedicated cluster por cliente — pero no eliminado. La contratación de operadores, background checks y visibilidad audit-trail que los clientes pueden reviewar son los controles que abordan esto. Higiene de credenciales del cliente: si la clave privada WireGuard de un cliente se filtra porque la workstation está comprometida, el atacante tiene el mismo acceso que el cliente; el operador puede detectar patterns anómalos y desactivar el peer, pero no puede prevenir la filtración.

La arquitectura remueve grandes categorías de riesgo y reduce otras a niveles manejables; no remueve cada categoría, y cualquier representación de vendor que sugiera lo contrario debe examinarse con escepticismo.

Preguntas frecuentes

Q: ¿Es WireGuard production-grade para uso render farm enterprise? A: WireGuard está en el kernel Linux mainline desde la versión 5.6 (marzo de 2020), se usa en producción por grandes operadores de infraestructura y su protocolo ha sido verificado formalmente con el Tamarin prover. Las primitivas criptográficas (Curve25519, ChaCha20-Poly1305, BLAKE2s, Poly1305) son elecciones modernas peer-reviewed usadas en muchos sistemas sensibles a la seguridad. Para transporte render farm — túneles de larga duración, grandes flujos, pequeña superficie operativa — es la elección de producción que hemos operado durante años sin incidentes a nivel protocolo.

Q: Si nuestro vendor render farm es comprometido, ¿están expuestos mis datos? A: En un modelo multi-tenant, un compromise de la infraestructura operador podría exponer datos a los que los sistemas operador tienen acceso, acotados por los controles de aislamiento de cliente de arriba. En el dedicated cluster con customer-owned credentials, el operador no tiene el material de autenticación del cliente y los datos del cliente viven en hardware asignado al cliente — un compromise de la infraestructura compartida del operador no expone automáticamente datos dedicated-cluster porque el dedicated cluster es una frontera separada. Dedicated-plus-BYOC es la respuesta práctica más fuerte para workloads de alta sensibilidad IP.

Q: ¿Pueden proveer audit logs para una compliance review? A: Sí. Los logs de sesión SSH, handshake WireGuard, render-job y flujo firewall pueden exportarse a petición para el auditor del cliente, sujeto al período de retención definido en el contrato. El formato de export es el que el auditor necesita (lo más común CSV o JSON). No proveemos acceso read-write al log host en sí; el modelo de export preserva la integridad del audit trail mientras da al cliente la evidencia que necesita.

Q: ¿Cómo se verifica la destrucción de datos al final del engagement? A: La eliminación a nivel archivo es seguida de una sobrescritura de espacio libre en los dispositivos de almacenamiento relevantes, luego una carta de atestación firmada por el operador registrando los dispositivos en scope, fecha y hora, procedimiento y personal involucrado. Para engagements que lo requieren, la destrucción puede ser presenciada por el representante del cliente. La atestación es el artefacto que el programa compliance del cliente archiva como evidencia.

Q: ¿Qué hay de amenazas insider de su propio personal? A: La amenaza insider se mitiga por separación de roles, autenticación de dos factores en la bastion, audit logs que las cuentas operador no pueden modificar y la frontera dedicated cluster por cliente. No se reduce a cero, y lo decimos honestamente. La revisión propia del cliente de los audit logs, a petición, es uno de los controles más efectivos contra el mal uso insider — pone al cliente en el bucle sobre lo que el personal operador ha hecho realmente.

Q: ¿Soportan integración SAML o single sign-on? A: El SSO del lado cliente está en la roadmap interna y no es una característica generalmente disponible hoy. Los clientes que necesitan SSO por sus propias razones de compliance deben plantearlo en el scoping del engagement; algunas integraciones se han hecho por engagement donde el proveedor de identidad del cliente puede ser puenteado a la capa de auth del cluster vía un camino documentado.

Q: ¿Puede mi auditor SOC 2 o ISO 27001 reviewar su arquitectura? A: Sí. Como se divulgó, no estamos certificados nosotros mismos, pero respondemos a cuestionarios de vendor-review y a solicitudes de review de arquitectura de auditores cliente. Los bloques técnicos descritos en este artículo son los mismos que el auditor verá en nuestras respuestas escritas; las configuraciones son auditables como texto. Lo que no podemos proveer es un documento de certificación propio, porque actualmente no tenemos uno.

Q: ¿Cuál es su cobertura intrusion detection? A: El flow logging en el edge Tier-1 y el monitoring a nivel host en cada nodo están desplegados hoy. La intrusion detection de red continua al nivel que un objetivo SOC-2 "continuous monitoring" exigiría está en la roadmap interna pero no actualmente en producción. Los clientes cuyo propio programa compliance exija un control continuous-IDS deben evaluar la brecha contra su propia tolerancia al riesgo.

Para la arquitectura de red sobre la que este modelo de seguridad se apoya, ver nuestro deep-dive arquitectura render farm cross-country. Para el modelo customer-owned-credentials que se empareja con dedicated cluster, ver el writeup BYOC. Para el deployment operativo, ver nuestra guía render farm 20 nodos GPU dedicada. Para el framework de decisión de compra, ver la comparación SaaS versus dedicated cluster y la landing dedicated GPU cluster rental.