BYOC Security
BYOC (Bring Your Own Cloud) warehouses run VeloDB Cloud inside your own cloud resource pool, so data and compute stay in your VPC. This guide covers the security model that follows from that: resource ownership, network placement, safe operation of VeloDB-managed cloud resources, and warehouse deletion.
For the step-by-step provider workflow, keep using Create BYOC Warehouse.
BYOC Deployment Model
In BYOC deployment, data storage and compute resources are retained in your own VPC. The existing security overview describes BYOC as a deployment form where data storage and computing resources stay in your own VPC, and data does not leave your VPC.
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.
Network And Resource Placement
When you create a BYOC warehouse for the first time, the setup flow guides you to select or create the VPC and subnets used by the warehouse. If you already created a BYOC warehouse in a VPC, you can select that VPC and create another warehouse in it.
Provider-specific guides document the preparation steps for VPC or subnet resources:
- Google Cloud: prepare a VPC and subnet before creating the warehouse, unless a suitable VPC and subnet already exist.
- Azure: prepare a VNet and subnet before creating the warehouse, unless a suitable VNet and subnet already exist.
- AWS: choose template mode or wizard mode depending on how you want to create the required cloud resources.
For connection-level network security after the warehouse exists, see Network Security.
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. For the model, see Shared responsibility; for a detailed breakdown across IAM, networking, storage, and key management, contact your VeloDB Cloud account team or use the VeloDB Trust Center.