What is BYOC?

Enterprise database needs vary significantly based on organizational requirements and infrastructure constraints. SingleStore addresses this diversity by offering multiple deployment options for SingleStore Helios®, a fully managed cloud database service. Customers who prefer a hands-off approach can deploy in fully managed; and now in bring-your-own-cloud (BYOC) regions, customers have an option to pay for and manage infrastructure separately.
The BYOC model has gained substantial traction among organizations that value maintaining management of their cloud infrastructure, while simultaneously benefiting from cloud deployment and orchestration. SingleStore Helios BYOC regions were developed in response to this market shift, enabling deployment of a fully managed database service within a customer's AWS Virtual Private Cloud (VPC).
This architecture allows SingleStore to operate directly within your AWS account and VPC. The result is a balanced solution where you retain responsibility for compliance, security and availability, while SingleStore handles the complexities of database operations and maintenance. This hybrid approach effectively combines the control traditionally associated with self-managed deployments and the operational efficiency of cloud services.
Why choose SingleStore BYOC?
Finding the right balance between control, cost and operational simplicity is crucial for today's database solutions. SingleStore Helios BYOC regions offer a new approach to data management on AWS, prioritizing your need for compliance and control. With BYOC regions, your SingleStore instances and data reside securely within your own AWS account — and you decide if and when third-party tools get access.
Here are three key benefits of choosing SingleStore BYOC:
- Meet internal compliance requirements. All services run in your own cloud environment without public IPs. You can leverage features like bring your own VPC,workload identity for temporary credentials issued by trusted hardware, and Role-Based Access Control (RBAC) to easily meet internal compliance requirements.
- Lower operational costs. Manage SingleStore instances via the portal or API without handling infrastructure manually. Leverage your existing AWS pricing benefits to manage your hardware costs separately.
- Uncompromised performance and scalability. BYOC uses the same proven control plane and automation technology as SingleStore’s managed regions, enabling seamless scaling, high availability and auto-healing for production workloads.
How can I get started?
We've streamlined the onboarding process to configure SingleStore BYOC region into three straightforward steps:
- Step 1: Prepare your Virtual Private Cloud (VPC)
- Step 2: Creating and initializing the BYOC region
- Step 3: Complete the BYOC bootstrapping process
Lets look at each of these steps in detail:
Step 1. Prepare your Virtual Private Cloud (VPC)
This first step involves establishing the necessary private subnets, along with NAT Gateways for outbound internet connectivity, to host the BYOC infrastructure. We offer guidelines to ensure a compatible network topology that aligns with the security and connectivity demands of our BYOC offering. For instance, we recommend creating a dedicated VPC to enhance security, simplify configuration and streamline management. Importantly, the SingleStore data plane will not have any public inbound access; all connections will be established through private channels across your VPCs.
Step 2. Creating and initializing the BYOC region
This step involves creating the BYOC region and initiating its core components within your designated AWS account. The initialization and bootstrapping of the region are streamlined through the following actions within the SingleStore portal:
- Navigate to the 'Cells' page. Access the 'Cells' page within the SingleStore portal.
- Initiate cell creation. Click the 'Create Cell' button.
- Provide AWS and VPC details. A form will appear, prompting you to enter your AWS account and VPC information.
- Start initialization. Upon submitting the form a record will appear, indicating that the initialization process has begun.
.png?width=1024&disable=upscale&auto=webp)
Registering your BYOC environment
The final step involves registering your BYOC environment with our control plane. This process generates a specific Docker image tailored to your deployment, which you will execute within your VPC. This image is designed with complete transparency, allowing you to thoroughly verify its operations before execution.
.png?width=1024&disable=upscale&auto=webp)
Step 3. Completion of the BYOC bootstrapping process
Once the bootstrap image has been successfully executed, your BYOC data plane will register with our control plane and you're ready to start using your SingleStore BYOC region!
.png?width=1024&disable=upscale&auto=webp)
You can immediately begin creating and managing Workspace groups through the familiar SingleStore portal. This provides a similar experience to fully Managed regions. Alternatively, for those who prefer programmatic interaction, you can utilize our management APIs to seamlessly integrate SingleStore BYOC regions into your existing tools and workflows. And as always, we provide detailed documentation and dedicated support to guide you through every step of the way.
.png?width=1024&disable=upscale&auto=webp)
Deep dive: How does BYOC work?
Before diving into the architecture of SingleStore BYOC regions, lets look at our five foundational tenets to ensure security, control and a seamless managed experience:
- Ensure customer data sovereignty. All customer data and database instances must reside within the customer's designated AWS account and region, guaranteeing complete control over data location and compliance.
- Prioritize security and isolation. SingleStore must maintain a robust security posture through strict isolation (no public inbound ports), secure communication channels and clear separation of management and data planes.
- Uphold customer-centric access control. Customers retain ultimate authority over access to their environment and infrastructure via AWS IAM roles and permissions, including mandatory approvals for sensitive operational actions.
- Deliver a managed experience via centralized control. Provide a seamless, fully managed database service through a central control plane that securely orchestrates operations like provisioning and upgrades within the customer's account.
- Guarantee unbreakable data plane integrity. Implement critical safeguards — like image signing — to prevent any control plane action from compromising the customer's data plane, ensuring absolute data integrity and protection.
With the preceding tenets as a guide, let's dive deeper into the architecture of our SingleStore BYOC regions. At its heart, SingleStore Helios BYOC regions operate with a distinct separation of duties across two AWS accounts. SingleStore manages the control plane within its own AWS environment, while you own and manage the data plane within your AWS account.

Looking at the architecture diagram, you can see this separation clearly. On the right side, we have the SingleStore control plane, handling all the orchestration, configuration, monitoring and backup tasks. These services live securely within SingleStore's VPC, ensuring no direct access to your sensitive data.
In the center within your customer tenant's AWS account, you'll find your data plane VPC — where your SingleStore instances run. This data plane hosts your workspaces, monitoring, cell-agent and BYOC-gateway-client.
A key security feature, as illustrated in the diagram with the note "No public address, no open ports in data plane," is that none of the components within your data plane expose public ports, load balancers or IP addresses. So, how does the SingleStore control plane manage your data plane without direct access? The answer lies in a secure reverse-proxy tunnel.
As you can see in the diagram, the services within your data plane region (specifically the gateway-client) initiate outbound connections to the gateway service in our control plane. This outbound-only communication establishes a secure tunnel. Through the secure tunnel, SingleStore can manage and monitor the BYOC infrastructure.
Finally, when it comes to connecting your internal applications to your SingleStore instances, SingleStore BYOC regions prioritize security and privacy. As shown in the diagram with the dotted lines representing communication from "Customer apps" to the "Workspaces," we don't rely on public endpoints. Instead, we empower you to establish private connectivity using options like AWS PrivateLink or AWS Transit Gateways. This ensures your applications — whether hosted in your corporate network or other VPCs — can securely and privately access your SingleStore deployments within your data plane.
Managed Kubernetes experience
SingleStore manages the upgrades of the infrastructure components in your BYOC environment. Our aim is to make this process smooth and with as little disruption as possible. Let’s start by looking at what gets updated in your BYOC environment:
- Service executables and runtimes. These are core services in your BYOC data plane, and managing and updating them makes sure security vulnerabilities (CVEs) are automatically addressed.
- Kubernetes runtime version (EKS). We manage upgrades to your Amazon EKS cluster's Kubernetes version for compatibility, stability and access to new Kubernetes features.
- Node pools for EC2 instances. We update the EC2 instances that power your EKS cluster's worker nodes and the Kubernetes control plane nodes, ensuring they are supported and performant.
- SingleStore engine versions. Finally, we manage the upgrade process for your SingleStore instances to the latest stable versions, providing new features and performance improvements.
The update process in general is designed to give you greater flexibility while minimizing service interruptions. In general, the process is initiated from SingleStore's control plane, which securely communicates with a component (cell agent) within your BYOC region to schedule and execute the necessary updates within your Kubernetes cluster. For more involved updates, like those to the Kubernetes runtime and underlying node pools, we follow a carefully orchestrated approach. This involves first preparing new nodes, then seamlessly transitioning your SingleStore instances and other services to these updated nodes before safely removing the older infrastructure — all designed to minimize any potential disruption to your operations.
This structured approach not only enables safe, controlled and scalable Kubernetes upgrades but also provides control and transparency to the workflow. So a few key takeaways from this managed update experience are:
- Configurable scheduled update windows. All infrastructure updates occur during pre-defined update windows. You can configure or change these windows to fit your operational needs, providing control and minimizing potential impact.
- Reliable and safe updates. Our automation for BYOC infrastructure updates is idempotent. This means updates can be run multiple times without causing unintended changes or disruptions in the AWS EKS cluster, ensuring a reliable process.
- Security is a priority. We prioritize security during updates. All update packages are digitally signed and undergo a strict review to prevent introduction of new permissions or security vulnerabilities in your BYOC data plane cluster.
Here is the matrix of responsibilities between SingleStore and our BYOC customers:
.png?width=1024&disable=upscale&auto=webp)
Data isolation during monitoring and troubleshooting
You maintain sovereignty over your data within your AWS account while benefiting from SingleStore's expertise in managing the underlying infrastructure. In our BYOC offering, we maintain a strict separation between the control plane (managed by SingleStore) and the data plane (within your AWS account) to ensure complete data isolation. All customer data remains strictly private and hosted exclusively within your AWS account. Within your BYOC data plane, we deploy dedicated monitoring to collect metrics and logs, ensuring that initial data capture happens within your controlled environment.
These metrics captured are categorized into two groups:
- Those related to your deployed SingleStore instances (workspaces)
- Those associated with Kubernetes custom resources (nodes, pods, deployments, etc.)
To ensure the stability and reliability of SingleStore services, we securely process these metrics and logs in the SingleStore cloud portal, allowing us to set alerts and visualize them through our Grafana instance. Before being transmitted to the SingleStore cloud portal, these metrics undergo normalization within your BYOC data plane. To secure the transmission, we also utilize an outbound-only reverse-proxy tunnel to further enhance your security. Additionally, when collecting logs from your SingleStore instances, we automatically redact sensitive information including credentials, Personally Identifiable Information (PII) and the content of SQL queries.
Break-glass access: Controlled escalation for critical issues
While our standard operational model heavily relies on automation and secure remote management, we recognize that rare, critical situations might necessitate direct, temporary access to your BYOC data plane to resolve a severe problem. This is precisely where our break-glass access mechanism comes into play.
Think of break glass as a highly controlled emergency access mechanism that requires your explicit authorization. It allows designated SingleStore engineers to temporarily access your AWS environment to resolve critical issues at the infrastructure level. It's important to understand that this is not a standard operating procedure and requires your explicit consent every time it's needed.
These situations are typically limited to foundational infrastructure problems that prevent normal operation, including:
- Issues with the underlying Kubernetes cluster itself
- Failures in accessing or utilizing storage volumes
- Severe network connectivity problems affecting the BYOC environment
Our controlled escalation process for these scenarios works as follows:
- A designated SingleStore support engineer will reach out to you, clearly explaining the critical nature of the issue and why break-glass access is essential, so you can grant temporary access to this specific break-glass role.
- Internally, the SingleStore engineers who will be working on the issue must go through an internal approval process before assuming this SingleStore break-glass role.
- Once approved and the role is assumed, SingleStore employees can initiate the break-glass process and gain access to your BYOC environment to triage and fix the issue.
- Once the issue is resolved, access to the break-glass role is immediately revoked.
For complete transparency and security, all operations performed within your BYOC environment are meticulously logged via AWS CloudTrail. This provides you with a comprehensive audit trail of every action taken during the emergency intervention.
Get started now
It's been an incredible journey building SingleStore Helios BYOC regions on AWS. The value BYOC regions have already delivered to customers has been remarkable, and we're excited to see this adoption continue to grow. Witnessing organizations gain control over their data and cloud infrastructure while benefiting from our fully managed expertise has been truly rewarding.
We've invested significant resources in addressing the complexities of security, cost optimization and operational overhead to ensure a seamless and secure deployment experience. Features like robust data isolation, private networking and our managed Kubernetes offering allow you to maintain data sovereignty while we handle core service, runtime and SingleStore upgrades seamlessly.
Ultimately, SingleStore BYOC empowers you with the flexibility and scalability you need, allowing your organization to focus on what matters most — your data and applications — while we manage the database intricacies. We believe this solution is a game-changer for the industry, and we can't wait to see what innovative solutions our customers will build with it.
If SingleStore BYOC on AWS is the right fit for your needs, contact us to get started.