In part 1 of this series, we explored the benefits of running workloads in NetApp-owned accounts, where Instaclustr manages the entire infrastructure stack. In this blog, we’ll examine the alternative deployment model: running Instaclustr workloads in customer-owned accounts. This approach offers organizations greater control over their infrastructure, while still leveraging Instaclustr’s expertise in managing open source technologies.
What are customer-owned accounts?
In the customer-owned account model, the underlying cloud infrastructure (compute, storage, and networking) is provisioned within the customer’s own cloud provider accounts. NetApp then deploys and manages the open source technologies on this customer-owned infrastructure.
Key components of the customer-owned infrastructure model
1. Infrastructure ownership
Unlike the NetApp-owned account model, with customer-owned accounts you retain full ownership and control of the cloud account running your cloud resources. Your organization maintains the cloud provider relationship, including billing and resource allocation, while NetApp focuses on the infrastructure and application layers of the deployed open source technology.
2. Deployment architecture
When running in customer-owned accounts, NetApp typically deploys:
- Core cluster components: The primary open source technologies (OpenSearch®, ClickHouse, Cassandra®, Kafka®, Cadence®, Valkey™, and PostgreSQL®) running on your infrastructure
- Client networking components: The cloud resources required to allow you to connect to your application. These could include load balancers, NAT gateways, internet gateways, VPC Peering connections, or PrivateLink endpoints
- Gateway instances: Secure access points that facilitate management of the cluster by Instaclustr teams
- Monitoring agents: Small agents on the application nodes that collect and transmit operational metrics back to Instaclustr’s central monitoring systems
3. Network configuration
When deploying NetApp-managed workloads into your account you can choose whether to use private-networks (meaning the workloads are deployed into private subnets with a NAT gateway for egress traffic) or public networks (workloads receive public IP’s and are placed in public subnets).
If you choose the private networking, you will see the following take effect:
- By default, a new VPC or VNet is created with each workload deployment, however when operating in your account you do have the option of reusing an existing VPC for additional workloads (contact support to enable same-vpc capabilities on your account)
- Application nodes are allocated only private IP addresses within your VPC
- Inter-node communication occurs entirely within your private network
- A bastion SSH host is deployed into the public subnet with extremely limited access for Instaclustr management tasks
Benefits of the customer-owned account model
1. Cost optimization through existing cloud agreements
A significant financial advantage of the customer-owned model is the ability to leverage your organization’s existing cloud provider relationships:
- Enterprise discounts: Apply your negotiated pricing agreements and volume discounts with cloud providers
- Reserved instance benefits: Utilize your existing reserved instance or savings plan investments to reduce the cost of workloads compared to NetApp-owned deployments.
- Consolidated billing: Simplify accounting by keeping all cloud resources on a single bill, often unlocking additional volume-based discounts
- Budget controls: Apply your existing cost management tools and budget controls to Instaclustr workloads
2. Seamless integration with existing environments
Customer-owned deployments offer superior integration capabilities:
- On AWS deployments into NetApp-owned accounts, there are a few ways customers can connect to their workloads: VPC Peering and PrivateLink. Customer-owned deployments can take advantage of both VPC Peering and PrivateLink, as well as Direct Connect (if the other workload is on-prem, routing through AWS), and VPC Endpoints
- On Azure deployments into both NetApp-owned accounts and customer-owned accounts, customers can connect to their workloads through VNet peering. PostgreSQL can also deploy with Azure Private Link
- Consistent infrastructure policies: Keep your organization’s standard infrastructure level policies, monitoring, and security controls on your workloads
3. Enhanced control and compliance
The most significant advantage of this model is maintaining control over your infrastructure:
- Data sovereignty: Your data resides entirely within your own accounts, simplifying compliance with regulations or industry-specific requirements
- Security policies: Apply your own security frameworks, access controls, and compliance processes as long as NetApp can perform their management tasks
- Audit capabilities: Maintain direct visibility of all infrastructure, logs, and monitoring for auditing purposes
Just like in NetApp-owned accounts, we provide GDPR, SOC 2, and HIPAA compliance, and PCI Compliance Mode can be enabled on clusters deployed into your customer-owned accounts.
Implementation considerations
Before deploying workloads in your account, you will need to configure several prerequisite tasks provided to you by the Instaclustr team. These include creating an Instaclustr provisioning role with permissions to perform the associated management and operations tasks in your account. You will also need to determine what your VPC network subnets will be for these workloads to not overlap with other VPCs that may communicate with these workloads.
Operational responsibilities
Deploying into a customer account requires the use of the Shared Responsibility Framework, similar to that of other hyperscalers in that NetApp’s responsibilities include the management of deployed technology, monitoring, optimization, updates, backups, security, compliance, and troubleshooting; while the customer is responsible for triggering the initial deployment (via Instaclustr APIs, Terraform recipe, or the Instaclustr console), and overall cloud account management.
When to choose customer-owned accounts
The customer-owned account model can be a preferred deployment for organizations with specific regulatory or technical requirements. While the compliance and auditing are identical to that of NetApp-owned accounts, some organizations prefer this deployment model to maintain direct control over their data, keeping it in their own accounts. This deployment model does not change how NetApp Instaclustr achieves compliance with industry-specific regulations and internal security policies, but rather changes which account the infrastructure is running in.
Companies with mature cloud operations and existing infrastructure investments also find significant value in customer-owned deployments. These organizations can verify compliance with their established cloud practices and cloud monitoring systems while still harnessing Instaclustr’s unified platform approach that streamlines deployment, management, and monitoring of their Instaclustr workloads.
Conclusion
The customer-owned account model offers organizations the ability to see the deployed infrastructure in their own cloud accounts, apply any infrastructure pricing discounts they have, choose additional network connectivity options (depending on the cloud and technology deployed), and have the ability to see cloud level logs and monitoring capabilities of these resources.
When deciding between NetApp-owned and customer-owned models, consider your organization’s priorities regarding operational control, integration requirements, compliance needs, and cost structure. For many organizations, the customer-owned model represents an ideal balance between management simplicity and infrastructure control.
In the final part of this series, we’ll examine a third deployment model: running NetApp Instaclustr workloads entirely on-premises in your own data center.
