BYOC Security Overview
BYOC (Bring Your Own Cloud) warehouses are deployed in your own cloud environment. This guide explains the security model for that deployment model, including resource ownership, safe operation of VeloDB-managed cloud resources, and warehouse deletion. For network placement and connectivity controls, see BYOC Network Security.
This deployment model does not imply that all control-plane metadata, operational telemetry, logs, support records, diagnostics, access evidence, or other operational data are stored in the customer environment.
For the step-by-step provider workflow, keep using Create BYOC Warehouse.
BYOC Deployment Model
In a BYOC deployment, warehouse compute and customer warehouse storage are deployed in your cloud environment.
BYOC creation is supported through provider-specific workflows:
| Cloud platform | BYOC setup page | Supporting preparation page |
|---|---|---|
| AWS | Template mode, Wizard mode | Provider setup is included in the AWS warehouse creation pages. |
| Google Cloud | How to create BYOC Warehouse on GCP | GCP operations guide |
| Azure | How to create BYOC Warehouse on Azure | Azure operations guide |
Cloud Resource Precautions
Most warehouse resources run within your cloud environment. Avoid operating cloud resources created by VeloDB Cloud directly from the cloud-provider console unless the relevant documentation instructs you to do so.
Cloud resources created by VeloDB Cloud use tags such as:
| Tag | Value |
|---|---|
resource-created-by | velodb |
cloud-resource-profile | online |
resource-used-by-app | BYOC, MetaService, or a specific warehouse ID |
sdb-cluster-id | Specific cluster ID |
You can use these tags to filter resources created by VeloDB Cloud in the cloud-provider console.
The BYOC creation documentation warns that the following actions may make the warehouse unavailable:
- Modify or delete the permissions of the IAM user created by VeloDB Cloud.
- Modify or delete virtual machines or storage buckets created by VeloDB Cloud.
- Modify or delete security groups or private endpoints created by VeloDB Cloud.
Warehouse unavailability caused by direct cloud-console operations may be irrecoverable.
Delete BYOC Warehouses And Infrastructure
BYOC deletion has two parts: deleting the current warehouse and, when applicable, destroying the BYOC infrastructure.
If the current BYOC warehouse is the last warehouse in the VPC, deleting it also destroys the BYOC infrastructure. The Warehouse Settings page documents the provider-specific follow-up steps:
- AWS: delete the current warehouse, then enter AWS CloudFormation to delete the resource stack. Empty the related bucket before deleting the stack.
- Google Cloud: delete the current warehouse, then run the generated CloudShell command to delete the resource stack.
- Azure: delete the current warehouse, then enter Azure Deployment Stacks and delete the stack.
Shared Responsibility
Responsibility is shared between the cloud provider, VeloDB Cloud, and you. See Shared responsibility for the model. For a detailed breakdown across IAM, networking, storage, and key management, contact your VeloDB Cloud account team. You can also use the VeloDB Trust Center.