> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ de BYOC

> Preguntas frecuentes sobre ClickHouse Bring Your Own Cloud (BYOC)

<div id="faq">
  ## FAQ
</div>

<div id="onboarding-and-provisioning">
  ### Incorporación y aprovisionamiento
</div>

<Accordion title="¿Cómo empezar con BYOC?">
  Póngase en contacto con ClickHouse mediante el [formulario de contacto](https://clickhouse.com/cloud/bring-your-own-cloud) y el equipo habilitará BYOC para su organización. A continuación, prepare una cuenta en la nube dedicada (una cuenta de AWS, un proyecto de GCP o una suscripción de Azure) y siga la [guía de incorporación estándar](/es/products/bring-your-own-cloud/onboarding/standard). Recomendamos encarecidamente usar una cuenta, un proyecto o una suscripción dedicados exclusivamente a BYOC.
</Accordion>

<Accordion title="¿Cuánto tarda el aprovisionamiento de la infraestructura y cuáles son los motivos habituales por los que se bloquea?">
  Calcule entre 45 y 90 minutos de principio a fin. El intervalo es amplio porque la mayor parte de ese tiempo corresponde al aprovisionamiento de recursos por parte del proveedor de nube —el clúster de Kubernetes, los balanceadores de carga y los componentes de red—, cuya duración varía de una ejecución a otra y está fuera del control de ClickHouse. Cuando el aprovisionamiento se bloquea, las causas más frecuentes se deben a la cuenta:

  * La plantilla de CloudFormation o el módulo de Terraform se modificó antes de aplicarse; por ejemplo, al añadir un `PermissionsBoundary` o renombrar el rol de IAM para cumplir una convención de nomenclatura (en AWS, mantenga el nombre predeterminado `ClickHouseManagementRole`, a menos que ClickHouse haya aprobado explícitamente otro). Aplique los artefactos tal como se proporcionan: las personalizaciones compatibles se exponen como parámetros y cualquier otro cambio requiere la aprobación previa de ClickHouse.
  * Políticas a nivel de organización (SCP de AWS, políticas de organización de GCP como `iam.allowedPolicyMemberDomains` o políticas de Azure que restringen las asignaciones de roles) que bloquean la asunción de roles o las vinculaciones de IAM.
  * Una discrepancia en el ID externo del rol de incorporación (consulte la pregunta sobre el ID externo más abajo).
  * Límites de cuota de la cuenta (por ejemplo, IP elásticas o VPC en AWS).

  El aprovisionamiento se reintenta automáticamente y se recupera una vez corregido el problema subyacente. Si su infraestructura permanece bloqueada durante más de un par de horas, contacte con soporte.
</Accordion>

<Accordion title="¿Qué valor debemos usar para el ID externo en la plantilla de incorporación?">
  La consola de ClickHouse Cloud genera un ID externo para su cuenta de AWS al iniciar la incorporación y lo rellena previamente en el enlace de CloudFormation (el parámetro `ExternalID`); si usa Terraform, pase el mismo valor como `external_id`. Todas las infraestructuras BYOC de la misma cuenta de AWS comparten el mismo ID externo. No elija un valor propio: debe coincidir con el que espera la automatización de ClickHouse; de lo contrario, no se podrá asumir el rol entre cuentas y el aprovisionamiento fallará. Consulte [ID externo de AWS](/es/products/bring-your-own-cloud/onboarding/standard#aws-external-id) para obtener más información.
</Accordion>

<Accordion title="¿Por qué mi ID externo es emptyid?">
  Las infraestructuras BYOC incorporadas antes de que se introdujeran los ID externos usan el valor de marcador de posición `emptyid` para mantener la compatibilidad con versiones anteriores. Cuando añade infraestructura nueva a una cuenta de AWS con una implementación heredada existente, la consola reutiliza este marcador de posición para que todas las infraestructuras de la cuenta mantengan una configuración de confianza coherente. Si desea cambiar a un ID externo único, contacte con soporte de ClickHouse.
</Accordion>

<Accordion title="¿Puede BYOC usar una VPC existente? ¿Y las VPC compartidas?">
  En AWS y GCP, puede desplegar una VPC existente que se encuentre en la **misma** cuenta o proyecto que la infraestructura BYOC. Consulte las guías de personalización para [AWS](/es/products/bring-your-own-cloud/onboarding/customization-aws) y [GCP](/es/products/bring-your-own-cloud/onboarding/customization-gcp). En GCP, también se admite una **VPC compartida** de un proyecto host independiente: el [módulo de incorporación](https://github.com/ClickHouse/terraform-byoc-onboarding/tree/main/modules/gcp) acepta directamente el proyecto host y la subred; consulte su sección "Shared VPC" para conocer la configuración y los requisitos previos. Próximamente podrá usar su propia VNet en Azure.

  En AWS, las subredes compartidas desde otra cuenta mediante AWS RAM no son compatibles; en su lugar, use una cuenta dedicada conectada a su red existente mediante peering de VPC o PrivateLink. Tenga en cuenta que, con una VPC gestionada por el cliente, solo se habilita de forma predeterminada el balanceador de carga privado (consulte la [configuración](/es/products/bring-your-own-cloud/configuration/configurations)).
</Accordion>

<Accordion title="¿Puede instalarse BYOC en un clúster de Kubernetes existente?">
  No. ClickHouse crea y gestiona por completo el clúster de Kubernetes (EKS, GKE o AKS). Esto es necesario para que ClickHouse pueda operar la plataforma de forma fiable y mantenerla actualizada.
</Accordion>

<Accordion title="¿Podemos ejecutar nuestras propias cargas de trabajo en el clúster o la cuenta en la nube de BYOC?">
  En la cuenta en la nube: es posible, pero los recursos ubicados en el mismo entorno siempre quedan, en cierta medida, dentro del ámbito de permisos de ClickHouse. En AWS, la mayoría de los permisos de escritura están restringidos por etiquetas y prefijos (los recursos aprovisionados por ClickHouse llevan `clickhouse-byoc=true`), pero un pequeño conjunto de acciones de EC2 no puede restringirse por etiquetas. En GCP y Azure, las identidades de incorporación tienen permisos con alcance de proyecto o suscripción. Mantenga sus recursos alejados de los aprovisionados por ClickHouse y, en cada nube, utilice preferiblemente una cuenta, un proyecto o una suscripción dedicados; esta sigue siendo la recomendación principal.

  En el clúster de Kubernetes: es posible, con restricciones. Use sus propios grupos de nodos con taints y tolerations, evite los espacios de nombres administrados por ClickHouse y no instale controladores de admisión ni motores de políticas para todo el clúster, ya que pueden bloquear la reconciliación de los componentes de ClickHouse. Describa primero su plan al equipo de soporte para que podamos confirmar que no haya conflictos.
</Accordion>

<div id="compute">
  ### Cómputo y escalado
</div>

<Accordion title="¿Puedo crear varios servicios en una misma infraestructura BYOC?">
  Sí. La infraestructura (incluido el clúster de Kubernetes) solo debe aprovisionarse una vez por cada combinación de cuenta/proyecto/suscripción de Cloud y región, y todos los servicios que cree en esa región la comparten.
</Accordion>

<Accordion title="¿Qué regiones son compatibles con BYOC?">
  Todas las **regiones públicas** incluidas en nuestra documentación de [regiones compatibles](/es/products/cloud/reference/supported-regions) están disponibles para implementaciones BYOC. BYOC se aprovisiona en tres zonas de disponibilidad, por lo que no se admiten las regiones con menos de tres zonas ni las AWS Local Zones. Si la región que necesita no aparece en la lista, póngase en contacto con su representante de ClickHouse para consultar su disponibilidad.
</Accordion>

<Accordion title="¿Hay sobrecarga de recursos? ¿Qué recursos se necesitan para ejecutar servicios aparte de las instancias de ClickHouse?">
  Además de las propias instancias de ClickHouse (servidores de ClickHouse y ClickHouse Keeper), también ejecutamos servicios auxiliares como `clickhouse-operator`, el cluster autoscaler, Istio y la pila de monitorización.

  El consumo de recursos de estos componentes compartidos es relativamente estable y no aumenta linealmente con el número ni el tamaño de sus servicios de ClickHouse. Como orientación general, el grupo de nodos del sistema dedicado a estas cargas de trabajo suma aproximadamente 48 vCPU y 192 GB de memoria; en AWS, por ejemplo, equivale a unas seis instancias `2xlarge`. Además, cada warehouse ejecuta un ensemble de Keeper dedicado de tres nodos, compartido por todos los servicios de ese warehouse. Consulte el [modelo de costes](/es/products/bring-your-own-cloud/reference/cost-model-aws) para obtener más información.
</Accordion>

<Accordion title="¿BYOC admite el autoescalado?">
  El autoescalado vertical a nivel de servicio está en la hoja de ruta. Actualmente están disponibles el escalado vertical y horizontal manual mediante la consola, el escalado programado para patrones de carga previsibles, la inactividad y reactivación automáticas para cargas de trabajo intermitentes, y el escalado automático de los grupos de nodos a nivel de infraestructura; nunca tendrá que gestionar los nodos usted mismo. ClickHouse supervisa y escala ClickHouse Keeper.
</Accordion>

<Accordion title="¿En qué tipos de instancia se ejecuta BYOC? ¿Podemos cambiar la familia de instancias?">
  BYOC se ejecuta en un conjunto seleccionado de grupos de nodos, en lugar de en tipos de instancia arbitrarios. Los grupos de nodos de carga de trabajo (servidores de ClickHouse y Keeper) se ejecutan de forma predeterminada en instancias basadas en ARM y optimizadas para memoria (Graviton en AWS), mientras que el grupo de nodos del sistema suele utilizar instancias x86. Se pueden aprovisionar otras familias de instancias, proporciones de CPU a memoria o arquitecturas previa solicitud a través de soporte; las instancias spot no son compatibles. Consulte la [configuración](/es/products/bring-your-own-cloud/configuration/configurations).
</Accordion>

<Accordion title="¿Podemos ejecutar réplicas muy pequeñas para reducir los costes?">
  Cada réplica se ejecuta como un pod en su propio nodo; el tamaño del nodo se ajusta al de la réplica, los nodos se aprovisionan bajo demanda y nunca se colocan varias réplicas en un mismo nodo. Por tanto, las réplicas muy pequeñas son ineficientes: una mayor proporción del hardware se destina a sobrecarga y el ancho de banda de red y disco escala con el tamaño de la instancia. Los tamaños inferiores a los que ofrece la consola requieren solicitudes personalizadas a través de soporte.
</Accordion>

<Accordion title="¿Podemos separar las cargas de trabajo de ingesta y consulta?">
  Sí. Los warehouses (separación de cómputo-cómputo) son compatibles con BYOC: varios servicios comparten los mismos datos, por lo que puede dedicar unos servicios a la ingestión y otros a las consultas.
</Accordion>

<div id="network-and-security">
  ### Red y seguridad
</div>

<Accordion title="¿Podemos limitar o revocar los permisos concedidos durante la instalación?">
  Puede reducir los permisos desde el principio en AWS y GCP: los artefactos de incorporación están parametrizados, por lo que puede omitir permisos para administrar la topología de red de su VPC al usar su propia VPC (`IncludeVPCWritePermissions` en CloudFormation, `include_vpc_write_permissions` en los módulos de Terraform). En GCP, esto limita únicamente la administración de la topología; ClickHouse conserva acceso de escritura a los recursos de red de su propiedad dentro de la VPC, como la subred NAT de Private Service Connect, el adjunto de servicio y las direcciones de entrada. En AWS, además, en vista previa privada y previa habilitación por parte de soporte, puede administrar usted mismo los roles de IAM (`IncludeIAMWritePermissions=false`, consulte [roles de IAM gestionados por el cliente](/es/products/bring-your-own-cloud/onboarding/customization-aws)); los roles entre cuentas están protegidos mediante un ID externo contra ataques de suplante de identidad. En Azure, el módulo de incorporación concede actualmente un rol fijo con ámbito de suscripción, sin parámetros para limitar su alcance. En todos los proveedores de nube, algunos permisos solo son necesarios para funciones específicas y pueden eliminarse si nunca va a utilizar esas funciones; contacte con soporte si necesita limitar los permisos más allá de lo que permiten los artefactos.

  Después del aprovisionamiento, no elimine unilateralmente los permisos de la identidad de administración: ClickHouse reconcilia continuamente la infraestructura, y la falta de permisos interrumpe el aprovisionamiento, las actualizaciones y el soporte. Para modificar los permisos concedidos o retirar el servicio por completo, coordínese con soporte (consulte la pregunta sobre desmantelamiento más adelante).
</Accordion>

<Accordion title="¿Qué puede hacer exactamente ClickHouse en nuestra cuenta en la nube? ¿Puede nuestro equipo de seguridad revisar los permisos?">
  La [referencia de privilegios](/es/products/bring-your-own-cloud/reference/privilege) ofrece una descripción general de cada rol e identidad y de su propósito en AWS, GCP y Azure. Para la identidad de incorporación (bootstrap), el alcance exacto de las políticas se define en los artefactos publicados: la [plantilla de CloudFormation](https://s3.us-east-2.amazonaws.com/clickhouse-public-resources.clickhouse.cloud/cf-templates/byoc_v2.yaml) y los [módulos de Terraform](https://github.com/ClickHouse/terraform-byoc-onboarding), que su equipo de seguridad puede auditar directamente. Las identidades adicionales que ClickHouse crea después de la incorporación (roles de controlador, cuentas de servicio e identidades administradas) se describen para cada proveedor en la referencia de privilegios y, como residen en su cuenta, puede inspeccionar sus políticas reales en la consola de su proveedor de nube y consultar su creación y uso en CloudTrail o sus equivalentes de GCP/Azure. En AWS, la mayoría de los permisos de escritura del rol de administración están restringidos mediante etiquetas de recursos y prefijos de nombre como `clickhouse-cloud-*`, por lo que, por lo general, no puede modificar recursos que no haya creado (un pequeño número de acciones de EC2 no puede restringirse mediante etiquetas), y **no tiene acceso a nivel de objeto a sus buckets de datos**: el acceso a objetos se limita a identidades dentro del clúster restringidas a las cargas de trabajo de ClickHouse. En GCP y Azure, las identidades de incorporación tienen permisos con ámbito de proyecto o suscripción; este es uno de los motivos por los que se recomienda encarecidamente utilizar un proyecto o una suscripción dedicados. Los permisos de lectura son más amplios porque se requieren para la reconciliación continua.
</Accordion>

<Accordion title="¿Qué acceso tienen los empleados de ClickHouse a nuestro entorno y datos?">
  De forma predeterminada, no tienen acceso a sus datos. Para solucionar problemas, los ingenieros deben pasar por un proceso interno de escalación just-in-time; el acceso tiene una duración limitada, se basa en certificados, está restringido a las tablas `system.*` (sin tablas con datos de clientes), se registra y es auditado por nuestro equipo de seguridad. Cualquier consulta ejecutada por un ingeniero de ClickHouse es visible para usted en su propio `system.query_log`. Para diagnósticos de infraestructura, la misma escalación sujeta a aprobación también puede conceder acceso temporal al servidor de API de Kubernetes y a la pila de monitorización dentro del clúster mediante Tailscale. Consulte [acceso a datos de ClickHouse](/es/products/bring-your-own-cloud/reference/clickhouse-data-access) para conocer el modelo de acceso a datos y [seguridad de red](/es/products/bring-your-own-cloud/reference/network-security) para conocer el modelo de conexión.
</Accordion>

<Accordion title="¿Han considerado futuros controles de seguridad para que los ingenieros de ClickHouse accedan a la infraestructura del cliente para solucionar problemas?">
  Sí. Tenemos en nuestra hoja de ruta implementar un mecanismo controlado por el cliente que permita a los clientes aprobar el acceso de los ingenieros al clúster. Actualmente, los ingenieros deben pasar por nuestro proceso interno de escalación para obtener acceso just-in-time al clúster. Este acceso se registra y es auditado por nuestro equipo de seguridad.
</Accordion>

<Accordion title="¿Qué datos salen de nuestra cuenta?">
  Solo metadatos operativos: eventos sobre el estado del servicio y las copias de seguridad, métricas de uso para facturación y notificaciones de alertas. Sus datos, copias de seguridad, logs y datos de Monitoring permanecen en su cuenta. Consulte [seguridad de red](/es/products/bring-your-own-cloud/reference/network-security) para obtener la lista completa de flujos salientes.
</Accordion>

<Accordion title="¿Cómo accede el plano de control de ClickHouse a la API de Kubernetes de nuestra cuenta? ¿Se requiere Tailscale?">
  De forma predeterminada, el endpoint de la API de Kubernetes es público, pero está restringido a las direcciones IP NAT de ClickHouse. Mientras se utilice esta configuración predeterminada, no elimine las entradas de la lista de permitidos de ClickHouse, ya que el plano de control las necesita para administrar el clúster. Como alternativa, el endpoint puede configurarse para acceso exclusivamente privado, en coordinación con el equipo de ClickHouse: mediante Tailscale (solo saliente, también utilizado para el acceso de resolución de problemas) o, en AWS, mediante VPC Lattice (vista previa privada). Consulte la [configuración](/es/products/bring-your-own-cloud/configuration/configurations). Tenga en cuenta que esto se aplica únicamente a la API de Kubernetes: las llamadas a las API del proveedor de nube (por ejemplo, EKS y EC2 en AWS) se originan en la red de ClickHouse Cloud mediante la asunción de roles entre cuentas y nunca pueden enrutarse a través de Tailscale. Consulte [las API del proveedor de nube frente a la API de Kubernetes](/es/products/bring-your-own-cloud/reference/network-security#cloud-api-vs-kubernetes-api).
</Accordion>

<Accordion title="¿Cómo funciona la comunicación de red entre la red BYOC y el almacenamiento de objetos?">
  En AWS, el tráfico entre su VPC BYOC del cliente y S3 utiliza HTTPS (puerto 443) a través de la API de S3 de AWS para los datos de las tablas, las copias de seguridad y los registros. Este tráfico pasa por un endpoint de gateway de VPC para S3, por lo que permanece dentro de la red de AWS, no atraviesa la internet pública y no genera cargos de gateway NAT. En GCP, el acceso a las API de Google utiliza de forma similar Private Google Access. En Azure, los datos se almacenan en cuentas de Azure Blob Storage dentro de su suscripción.
</Accordion>

<Accordion title="Los datos están en nuestro propio bucket; ¿podemos leerlos o modificarlos directamente?">
  No. Los blobs de datos de las tablas se almacenan en una estructura compartida sin rutas por tabla, por lo que no es posible atribuir los objetos a tablas y cualquier modificación directa puede corromper sus servicios. Nunca modifique directamente el contenido del bucket; si sospecha que hay algún problema, abra un ticket de soporte.
</Accordion>

<Accordion title="¿Qué puertos se utilizan para la comunicación entre el client y el clúster?">
  Las conexiones del client terminan en el balanceador de carga en puertos TLS: **8443** (interfaz HTTPS) y **9440** (protocolo nativo sobre TLS); el puerto 443 también se enruta a la interfaz HTTPS. La interfaz MySQL (puerto 3306) no está expuesta actualmente en BYOC; está prevista en la hoja de ruta (consulte la [descripción general](/es/products/cloud/guides/infrastructure/deployment-options/byoc/overview)).

  Dentro de la red, la comunicación interna del clúster utiliza el protocolo nativo en el puerto 9000, HTTP en el puerto 8123 y comunicación entre servidores en el puerto 9009 para la replicación y las consultas distribuidas. Estos puertos internos y los puertos de ClickHouse Keeper nunca se exponen en ningún balanceador de carga.
</Accordion>

<Accordion title="¿Nuestros endpoints de servicio están expuestos a la internet pública? ¿Podemos usar solo acceso privado?">
  Con una VPC gestionada por ClickHouse, cada servicio dispone de forma predeterminada de un balanceador de carga público protegido por una lista de acceso de IP; además, puede habilitarse en la consola de ClickHouse Cloud un balanceador de carga privado, accesible desde su red y redes emparejadas (consulte [Balanceadores de carga](/es/products/bring-your-own-cloud/configuration/configurations#load-balancers)). Con una VPC gestionada por el cliente, los valores predeterminados se invierten y solo se habilita el balanceador de carga privado. El filtrado de IP se aplica en la capa del proxy de entrada, por lo que los puertos del balanceador de carga pueden parecer abiertos en los análisis, aunque se rechazan las conexiones procedentes de orígenes que no figuran en la lista. El endpoint público puede deshabilitarse por completo cuando ya no dependa de él ningún componente. El [selector de conexión](/es/products/bring-your-own-cloud/configuration/connect#connection-via) de la consola muestra los endpoints de cada ruta de conexión habilitada para su servicio. Consulte la [conectividad](/es/products/bring-your-own-cloud/configuration/connect).
</Accordion>

<Accordion title="¿Podemos usar nuestro propio dominio DNS o aportar nuestros propios certificados TLS?">
  No por el momento. Los endpoints de servicio se aprovisionan bajo `clickhouse-byoc.com` con certificados gestionados por ClickHouse.
</Accordion>

<Accordion title="¿Cómo configuramos AWS PrivateLink, GCP Private Service Connect o Azure Private Link?">
  Siga las guías de configuración de red para [AWS](/es/products/bring-your-own-cloud/onboarding/network-aws), [GCP](/es/products/bring-your-own-cloud/onboarding/network-gcp) y [Azure](/es/products/bring-your-own-cloud/onboarding/network-azure). Hay dos aspectos que suelen pasarse por alto: la lista de permitidos de endpoints es **por servicio**, por lo que los endpoints deben registrarse de nuevo para cada servicio nuevo, y la resolución DNS de los nombres de endpoint privado debe configurarse de su lado si ejecuta su propio DNS. Una vez configurado, use el [selector de conexión](/es/products/bring-your-own-cloud/configuration/connect#connection-via) de la consola para copiar el nombre de host correcto del endpoint privado.
</Accordion>

<Accordion title="¿Podemos conectarnos mediante PrivateLink desde otra región de AWS?">
  Sí, pero el conmutador **Habilitar enlace privado** de la consola solo cubre consumidores de la misma región: AWS deshabilita de forma predeterminada el acceso entre regiones en los servicios de endpoint, y la consola de ClickHouse no lo administra. Como el servicio de endpoint reside en su cuenta de BYOC, debe habilitarlo usted mismo: agregue las regiones consumidoras a la lista de **Regiones compatibles** del servicio de endpoint en la consola de AWS y, después, cree el endpoint con la opción entre regiones en el lado del consumidor. ClickHouse no cambiará ni restablecerá estos valores. Consulte la [guía de configuración de PrivateLink](/es/products/bring-your-own-cloud/onboarding/network-aws#setup-privatelink) para conocer los pasos; se aplican las tarifas de transferencia de datos entre regiones de AWS.
</Accordion>

<Accordion title="¿Existe una lista de endpoints que debemos permitir en nuestro firewall o en las reglas de salida?">
  No existe una única lista publicada de endpoints. El clúster requiere acceso saliente a Internet funcional (directamente o mediante NAT), además de acceso privado a las API del proveedor de nube; consulte los [requisitos de conectividad de red](/es/products/bring-your-own-cloud/onboarding/customization-aws#ensure-network-connectivity). Si su política de red requiere un inventario explícito, contacte con soporte para revisar su configuración.
</Accordion>

<Accordion title="Nuestras herramientas de seguridad marcaron contenedores con privilegios o montajes de host en el clúster de BYOC; ¿es lo esperado?">
  Algunos componentes de la plataforma requieren legítimamente privilegios elevados o acceso al filesystem del host, como el controlador CSI de EBS, los trabajos de configuración de nodos y el exporter de nodos de Prometheus (que lee `/proc` y `/sys`). Si su escáner detecta incidencias, compártalas con soporte; confirmaremos si cada una es intencionada o requiere medidas.
</Accordion>

<Accordion title="¿Admiten claves de cifrado gestionadas por el cliente (CMEK)?">
  Actualmente, no para BYOC. Los datos en reposo se cifran con claves gestionadas por el proveedor de nube. Consulte la [descripción general](/es/products/cloud/guides/infrastructure/deployment-options/byoc/overview) para ver la lista actual de funcionalidades planificadas.
</Accordion>

<div id="upgrades-and-maintenance">
  ### Actualizaciones y mantenimiento
</div>

<Accordion title="¿Cómo funcionan las actualizaciones de versión de ClickHouse? ¿Puedo decidir la frecuencia del mantenimiento?">
  Las actualizaciones funcionan igual que en ClickHouse Cloud: los servicios se adhieren a canales de lanzamiento (rápido, regular o lento) y respetan las ventanas de mantenimiento programadas; contacte con soporte para configurarlas. Espere una programación de actualizaciones de al menos una vez por semana. Las actualizaciones se realizan de forma gradual, réplica por réplica (make-before-break), por lo que no hay tiempo de inactividad de todo el servicio. Consulte [operations](/es/products/bring-your-own-cloud/configuration/operations).
</Accordion>

<Accordion title="¿Quién es responsable de las actualizaciones de Kubernetes y qué impacto cabe esperar?">
  ClickHouse se encarga de realizar proactivamente las actualizaciones de Kubernetes, antes de las fechas de finalización del soporte del proveedor, y coordina la ventana con usted a través de soporte. Las actualizaciones del plano de control son transparentes; las de los grupos de nodos se realizan nodo por nodo con semántica make-before-break, por lo que puede experimentar breves restablecimientos de conexión mientras se reinician los pods, pero sin pérdida de datos. Consulte [operations](/es/products/bring-your-own-cloud/configuration/operations).
</Accordion>

<div id="backups-and-disaster-recovery">
  ### Copias de seguridad y recuperación ante desastres
</div>

<Accordion title="¿Dónde se almacenan las copias de seguridad?">
  En el almacenamiento de objetos de su propia cuenta en la nube; las copias de seguridad nunca salen de su entorno. La programación y la retención de las copias de seguridad se pueden configurar; póngase en contacto con el soporte técnico para ajustarlas.
</Accordion>

<Accordion title="¿Qué incluye una copia de seguridad? ¿Se incluyen las tablas del sistema?">
  Todas las bases de datos, tablas y objetos creados por el usuario, además de las entidades de acceso (usuarios, roles, perfiles de configuración, políticas de fila, cuotas) y las funciones definidas por el usuario. Las tablas de registro del sistema, como `system.query_log`, no se incluyen.
</Accordion>

<Accordion title="¿Por qué se me factura por copias de seguridad anteriores a mi período de retención?">
  Las copias de seguridad forman cadenas: una copia de seguridad completa seguida de copias incrementales que dependen de ella. La copia de seguridad completa base es necesaria para restaurar cualquier copia incremental de su cadena, por lo que se conserva (y almacena) hasta que todas las copias incrementales dependientes hayan superado el período de retención.
</Accordion>

<Accordion title="¿Cómo podemos supervisar nosotros mismos el estado de las copias de seguridad?">
  Hay dos opciones: los endpoints de copias de seguridad de la ClickHouse Cloud API y las métricas de copias de seguridad (contadores de inicio, finalización y errores) expuestas por la pila de monitorización del clúster. Recomendamos configurar alertas para los errores en su propia monitorización. Consulte [observabilidad](/es/products/bring-your-own-cloud/reference/observability-aws).
</Accordion>

<Accordion title="¿Cómo cumplimos los requisitos de recuperación ante desastres (RPO/RTO)?">
  BYOC se despliega en tres zonas de disponibilidad, y las escrituras solo se confirman cuando el almacenamiento de objetos las confirma. La replicación entre regiones no está disponible actualmente, por lo que la recuperación ante desastres regional se basa en copias de seguridad y el RPO alcanzable está limitado por la frecuencia de las copias de seguridad. La frecuencia y el destino de las copias de seguridad se pueden configurar para ajustarse a sus objetivos, incluido realizar copias de seguridad en un bucket de otra región; póngase en contacto con el soporte técnico para configurarlo.
</Accordion>

<div id="observability">
  ### Observabilidad
</div>

<Accordion title="¿Cómo podemos integrar BYOC con nuestra propia monitorización y alertas?">
  La pila de monitorización (Prometheus, Grafana, AlertManager) se ejecuta dentro de su cuenta y puede utilizarla directamente mediante conectividad privada: consultarla a través de la API PromQL, federarla en su propio Prometheus o recopilar métricas del endpoint `/metrics_all` de ClickHouse para cada servicio. Actualmente no existe una integración lista para usar con plataformas de terceros como Datadog; intégrela mediante su ingestión compatible con Prometheus. Consulte [observabilidad](/es/products/bring-your-own-cloud/reference/observability-aws) para conocer los endpoints y la configuración.
</Accordion>

<div id="cost">
  ### Coste
</div>

<Accordion title="¿Qué se paga con BYOC?">
  Dos facturas independientes: ClickHouse Cloud cobra en función de la memoria asignada a tus servicios, y tu proveedor de nube te factura directamente el coste de la infraestructura subyacente, sin recargo. Actualmente, las páginas de referencia detallada sobre costes cubren AWS: consulta el [modelo de costes](/es/products/bring-your-own-cloud/reference/cost-model-aws), los [servicios facturables de AWS](/es/products/bring-your-own-cloud/reference/billable-aws-services) y los [límites de servicio de AWS](/es/products/bring-your-own-cloud/reference/aws-service-limits).
</Accordion>

<div id="availability-and-lifecycle">
  ### Disponibilidad y ciclo de vida
</div>

<Accordion title="¿En qué proveedores de nube está disponible BYOC?">
  AWS, GCP y Azure están disponibles de forma general. Consulte la [descripción general](/es/products/cloud/guides/infrastructure/deployment-options/byoc/overview) para conocer las funcionalidades y regiones compatibles en cada nube.
</Accordion>

<Accordion title="¿Cómo se desmantela un entorno BYOC?">
  Finalice sus servicios y la infraestructura BYOC desde la consola de ClickHouse; no empiece por eliminar recursos ni revocar permisos en la consola de su proveedor de nube, ya que esto interrumpe la conexión con el plano de control durante el proceso y obliga a realizar una limpieza manual. Una vez completada la finalización desde la consola, elimine la pila de incorporación (pila de CloudFormation o módulo de Terraform) y los recursos restantes. En AWS, todos los recursos creados por ClickHouse están etiquetados con `clickhouse-byoc=true`, por lo que puede enumerarlos posteriormente para verificar que no quede nada; en GCP y Azure, el proyecto o la suscripción dedicados que incorporó delimitan lo que debe revisar.
</Accordion>

<div id="uptime-sla">
  ### SLA de disponibilidad
</div>

<Accordion title="¿ClickHouse ofrece un SLA de disponibilidad para BYOC?">
  No, dado que el plano de datos está alojado en el entorno de nube del cliente, la disponibilidad del servicio depende de recursos que no están bajo el control de ClickHouse. Por lo tanto, ClickHouse no ofrece un SLA formal de disponibilidad para las implementaciones de BYOC. Tenga en cuenta que los servicios en ejecución operan de forma independiente del plano de control de ClickHouse: una interrupción del plano de control no detiene los servicios que se ejecutan en su cuenta. Si tiene alguna pregunta adicional, póngase en contacto con [support@clickhouse.com](mailto:support@clickhouse.com).
</Accordion>