Skip to main content
Pinecone BYOC (Bring Your Own Cloud) is designed for organizations with strict requirements around data sovereignty, network isolation, and data residency. With BYOC, you deploy the Pinecone data plane in your own cloud account (AWS, GCP, or Azure), and you get the benefits of a managed service — upgrades, scaling, and maintenance — without giving up control of your data or infrastructure. Pinecone never has direct access to your cloud account. Your vectors, metadata, and queries never leave your environment, and no inbound network access is required. An agent in your cluster pulls operations from Pinecone and executes them locally.

​
Architecture

BYOC architecture in which the Pinecone data plane, Kubernetes cluster, FoundationDB, object storage, and DNS run in a VPC in your AWS, GCP, or Azure account. The cluster pulls operations from the Pinecone-managed control plane, and only metrics and traces leave the cluster. BYOC architecture in which the Pinecone data plane, Kubernetes cluster, FoundationDB, object storage, and DNS run in a VPC in your AWS, GCP, or Azure account. The cluster pulls operations from the Pinecone-managed control plane, and only metrics and traces leave the cluster. BYOC uses a split architecture:
  • The data plane runs entirely in your cloud account within a dedicated VPC, storing and processing your vectors, executing queries, and managing index data in object storage (S3 on AWS, GCS on GCP, or Azure Blob Storage on Azure). Cluster metadata lives in FoundationDB, which runs inside your Kubernetes cluster, so there’s no managed database to operate.
  • The control plane is managed by Pinecone globally and handles index lifecycle management, authentication, billing, and user management, but never stores or processes your vectors.
For maintenance, the agent authenticates with Pinecone’s control plane, pulls pending operations (upgrades, scaling, etc.), and executes them locally. All operations are stored as Kubernetes CRDs, providing a complete audit trail. Only operational metrics (CPU, memory, latency) and traces are transmitted to Pinecone for monitoring; customer data is filtered out before transmission.

​
Encryption and customer-managed keys

In the standard Pinecone service, customer-managed encryption keys (CMEK) are how you connect Pinecone-managed storage to your AWS KMS keys through the Pinecone console. In BYOC, that console CMEK flow doesn’t apply. Your vectors and index data are stored in your cloud account (for example, object storage and block storage), so you apply your cloud provider’s KMS to those resources using the same native controls you use for other workloads (key policies, rotation, and compliance programs such as PCI or ISO 27001). When you deploy with pulumi-pinecone-byoc, you can supply your KMS key where the template supports it. For the current options, see the pulumi-pinecone-byoc README.

​
Limitations

Some features available in the standard Pinecone service aren’t yet supported or have constraints in BYOC:
  • Each organization can have up to 2 BYOC environments. To request an increase, contact Pinecone support.
  • Integrated embedding and inference, which relies on models hosted by Pinecone outside your cloud account.
  • Reading and writing data from the index browser in the Pinecone console.
  • Pinecone CLI data plane operations (queries, upserts, fetches). Control plane operations (create, list, delete indexes) work as expected.
  • Imports from private cloud storage buckets, unless the bucket is in the same cloud account as your BYOC deployment.
  • On-demand indexes. BYOC supports dedicated read nodes indexes only.
To monitor with Prometheus, you must configure Prometheus within your VPC.

​
Pricing

Your Pinecone bill for a BYOC environment has two parts: a flat platform fee and a rate for each dedicated read node you run. Separately, you pay your cloud provider directly for the underlying infrastructure (Kubernetes nodes, object storage, block storage, networking, etc.).
If an environment runs both b1 and t1 nodes, calculate the node cost for each type and add the results. Unlike dedicated read nodes in the standard service, BYOC has no separate Pinecone charges for storage or writes. That data lives in your own cloud account, so you pay your cloud provider for it instead of Pinecone.
For current rates and help sizing your BYOC environment, contact us.
Example: An environment with one index using two shards and two replicas runs four b1 nodes, so its monthly bill is the platform fee plus four times the b1 node rate, plus what you pay your cloud provider. The Pinecone BYOC agent running in your cluster measures node usage, periodically reporting which nodes are provisioned. Billing follows the agent heartbeat connection to Pinecone’s control plane:
  • When Pinecone receives heartbeats, you’re billed for the nodes the agent reports, even if the cluster is unhealthy.
  • Short heartbeat interruptions (under 60 minutes) are treated as a grace period.
  • If heartbeats are missing for more than 60 minutes, billing stops and the deployment is marked disconnected.
Pinecone bills for provisioned nodes, not query volume. You’re billed for nodes running in your cluster whether they’re idle, actively processing queries, or experiencing errors.

​
FAQs

Answers to common questions about BYOC:
No. BYOC is designed so Pinecone never needs direct access to your infrastructure. Specifically:
  • Pinecone does not need SSH, VPN, or inbound access to your cluster.
  • You control cloud account boundaries, networking, and Kubernetes access.
  • Operational changes run through explicit, software-mediated workflows.
  • You don’t open inbound firewall ports for Pinecone operations.
Operations are executed via a pull-based model where your cluster retrieves and runs operations locally. All communication is outbound from your cluster.
Does not leave your cloud account:
  • Vectors, metadata, and index contents
  • Query and upsert payloads
  • Customer data
Can leave your cloud account:
  • Operational metrics and traces (for example, CPU, memory, latency)
  • Cluster health and operation status
Customer data is filtered out before transmission and never leaves your cloud account.
In the standard service, Pinecone manages all cloud resources and includes their cost in the service fee. In BYOC, you provision and pay for cloud resources directly through your own cloud account, providing greater control, data sovereignty, and access to available cloud credits or discounts. For a cost breakdown, see Pricing.
You use API keys from the Pinecone console, just like with the standard Pinecone service. Authentication is handled by Pinecone’s global control plane, and your data plane caches API keys locally. This means you manage users and API keys through the console as usual.
Data is stored and processed exclusively within your cloud account, with encryption at rest and in transit. You control at-rest encryption for the underlying resources (including KMS keys in your account) the same way you do for other infrastructure. Communication between the data plane and control plane is encrypted using TLS. Private connectivity (AWS PrivateLink, GCP Private Service Connect, or Azure Private Link) can be used for additional network isolation. For how this relates to hosted CMEK, see Encryption and customer-managed keys.
BYOC is available on AWS, GCP, and Azure.
Indexes cannot be properly terminated if the cluster is destroyed first. Always delete indexes via the Pinecone API or console before running pulumi destroy.
Deploying a BYOC environment creates an internal project named __SLI__ in your organization. This is used by Pinecone to enforce SLAs for your BYOC environment. Do not modify or delete this project.

​
Next steps