Instaclustr by NetApp Services Specific Terms

March 2024

These Service Specific Terms (“Service Specific Terms”) for NetApp’s Instaclustr Support Service (“Instaclustr Support Service”) and Platform Service (“Instaclustr Platform Service”) are part of the NetApp Cloud Services-Terms of Service (“Terms”). Capitalized terms used, but not defined in these Service Specific Terms, will have the meaning assigned to them in the Terms.

1. Service Level Agreement (Instaclustr Support Services)

   If the Service does not achieve the service levels described in this Service Level Agreement (SLA), then you may be eligible for a service credit.

   We reserve the right to change the terms of this SLA or discontinue the SLA at our discretion. We will honor the SLA in effect at the outset of your subscription for the duration of your initial Subscription Term. However, if you renew your subscription, the version of this SLA that is in effect the time of renewal will apply throughout your renewal term.

   Availability Service Level

   NetApp will use commercially reasonable efforts to make support available 24 hours a day, seven days a week, during any monthly billing cycle.

   Response Time Service Level

   NetApp will use commercially reasonable efforts to respond to support requests no later than 20 minutes from which the support request is received from an authorized customer support contact by NetApp via one of the support channels until acknowledgement by a NetApp Technical Operations Engineer to the Customer and incident resolution commenced according to the defined incident severities.

   Service Credits

   For each breach of the response time SLA beyond the second in any month, 10% of the monthly contract support subscription fees as a service credit to a maximum of 50% of the monthly contracted support subscription. The service credit will apply to future use of the Instaclustr Support Services and will be deducted from your next billing cycle/invoice,

2. Service Level Agreement (Instaclustr Platform Services)

   If the Service does not achieve the service levels described in this Service Level Agreement (SLA), then you may be eligible for a service credit.

   We reserve the right to change the terms of this SLA or discontinue the SLA at our discretion. We will honor the SLA in effect at the outset of your subscription for the duration of your initial Subscription Term. However, if you renew your subscription, the version of this SLA that is in effect the time of renewal will apply throughout your renewal term.

   The SLA is tiered based on the technology, size, number and/or class of the cluster that the Customer is running. The tiers recognize that larger clusters can support more consistent levels of performance and availability and is as follows:

   Instaclustr Platform Services supporting Apache Cassandra^®

   Tier1	Service Standards2	Customer Requirements
   Starter (Developer nodes)	No guaranteed availability4 (99.9% target) No latency3 SLAs	Minimum replication of 2 on all topics Add capacity or adjust retention settings when requested by the Instaclustr product team to maintain disk usage in normal operations as less than 80% Comply with reasonable requests from Instaclustr to modify application for best practice Cassandra usage
   Small (5 or less production nodes)	99.95% availability for LOCAL_QUORUM No latency SLAs 20% monthly fees at risk in total; 10% credit for each breach	Minimum replication factor of 3 on all keyspaces (please ensure that cluster is initially configured with target RF of 3) Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify the application for best practice Cassandra usage
   Enterprise (6+ production nodes)	99.99% availability for LOCAL_QUORUM consistency operations 99% of read/write transactions to Instaclustr-maintained table in the cluster within specified latency threshold3 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA	Minimum replication factor of 3 on all keyspaces (please ensure that cluster is initially configured with target RF of 3) Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify the application for best practice Cassandra usage
   Critical (12+ production nodes)	100% availability for LOCAL_QUORUM consistency operations Custom latency SLA negotiable (or use medium SLA)3 100% of monthly fees at risk in total; 30% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA	Minimum replication factor of 5 on all keyspaces (please ensure that cluster is initially configured with target RF of 5) Separate testing and production clusters Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application for best practice alignment and actions finding from that review. Instaclustr review prior to deploying changes that may impact latency SLA Add capacity or remove data when requested by the Instaclustr product team to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify the application for best practice Cassandra usage

   **For Enterprise and Critical level Cassandra clusters, we also provide Recovery Point Objective SLA: The native replication of data in Cassandra means restoration of data from backups is rarely required. However, we will maintain backups to allow restoration of data with less than 24 hours data loss for standard backups and less than 5 minutes data loss for our Continuous Back-ups option. Should we fail to meet this recovery point objective, you will be eligible for SLA credits at 100% of monthly fees for the relevant cluster. If you have undertaken to restore testing of your cluster in the last 6 months (using our automated restore functionality) and can demonstrate that data loss during an emergency restore is outside target RPO and your verification testing, then you will be eligible for SLA credits at 500% of monthly fees.

   Instaclustr Platform Services supporting Debezium^® Change Data Capture Services

   Tier1	Service Standards2	Customer Requirements
   Starter (Developer nodes)	No guaranteed availability4 (99.9% target) No latency3 SLAs	Add capacity when requested by Instaclustr to maintain disk usage in normal operations as less than 70% Comply with reasonable requests from Instaclustr to modify the application for best practice Debezium usage
   Enterprise (3+ production nodes)	99.95% availability for get data into Kafka within <5 minutes 10% monthly fees at risk in total; 5% credit for each breach	Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify the application for best practice Debezium usage

   **Service Level Objective is for delivery of at least 1 replica to Debezium. Duplicate writes may be delivered.

   Instaclustr Platform Services supporting Apache Kafka^® Services

   Tier1	Service Standards2	Customer Requirements
   Starter11,18 (Developer nodes)	No guaranteed availability4 (99.9% target) No latency3 SLAs	Minimum replication of 2 on all topics Add capacity or adjust retention settings when requested by the Instaclustr product team to maintain disk usage in normal operations as less than 80% Comply with reasonable requests to modify application for best practice Kafka usage
   Small17 (5 or less production nodes)	99.95% availability for writes with 2 replica consistency requirement and all reads No latency SLAs 20% monthly fees at risk in total; 10% credit for each breach PrivateLink availability of 99.99%	Minimum replication of 3 on all topics Add capacity or adjust retention settings when requested by Instaclustr m to maintain disk usage in normal operations as less than 80% Comply with reasonable requests to modify application for best practice Kafka usage
   Enterprise17 (6+ production nodes)	99.99% availability for writes with 2 replica consistency requirement and all reads Availability SLA is increased to 99.999% when dedicated ZooKeeper/KRaft nodes are used 99% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA PrivateLink availability of 99.99%	Minimum replication factor of 3 on all topics Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 80% Comply with reasonable requests to modify the application for best practice Kafka usage
   Critical17 (12+ production nodes)	99.999% availability for writes with 2 replica consistency requirement and all reads 99% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3 100% of monthly fees at risk in total; 30% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA PrivateLink availability of 99.99%	Minimum replication factor of 3 on all topics Separate testing and production clusters Must use dedicated ZooKeeper/KRaft nodes for production Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application for best practice alignment and actions findings from that review Instaclustr review prior to deploying changes that may impact latency SLA Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 80% Comply with reasonable requests to modify application for best practice Kafka usage

   Instaclustr Platform Services supporting Kafka^® Connect Services

   Tier1	Service Standards2	Customer Requirements
   Starter11 (Developer nodes)	No guaranteed availability8 (99.9% target)	Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests to modify the application for best practice Kafka Connect usage
   Production Nodes	99.99% availability8 to Instaclustr maintained synthetic transaction connector 20% monthly fees at risk in total; 10% credit for each breach	Minimum of 3 nodes Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests to modify the application for best practice Kafka Connect usage

   Instaclustr Platform Services supporting Redis^™ Services

   Tier1	Service Standards2	Customer Requirements
   Starter (Developer nodes)	No guaranteed availability (99.9% target) No latency3 SLAs	Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests to modify the application for best practice Redis usage
   Enterprise (6+ production nodes)	99.99% availability9 to Instaclustr maintained synthetic transaction 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA	The number of Redis Replica Nodes is greater than or equal to the number of Redis Master Nodes Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests to modify the application for best practice Redis usage

   Instaclustr Platform Services supporting Apache ZooKeeper^™ Services

   Tier1	Service Standards2	Customer Requirements
   Starter (Developer nodes)	No guaranteed availability (99.9% target) No latency3 SLAs	Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests to modify the application for best practice ZooKeeper usage
   Enterprise (3+ production nodes)	99.99% availability10 No latency3 SLAs 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA	Add capacity as reasonably requested by the Instaclustr product team to manage operational loads. Comply with reasonable to modify the application for best practice ZooKeeper usage

   Instaclustr Platform Services supporting PostgreSQL^® Services

   Tier	Service Standards	Customer Requirements
   Starter (Developer nodes)	No guaranteed availability (targeting 99.95%12) No latency SLAs	Add capacity as reasonably requested by Instaclustr to manage operational loads. Configure cluster replication and query settings which are appropriate for their data loss tolerance13 Comply with reasonable requests from the Instaclustr product team to modify the application for best practice PostgreSQL usage Add capacity or remove data when requested to maintain disk usage in normal operations at less than 70%
   Enterprise (2+ production nodes, or 3+ if utilizing synchronous mode strict)	99.99%12 availability for read and write operations 99.9%3 of read/write transactions to Instaclustr-maintained table in the cluster within specified latency threshold 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA	Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests from the Instaclustr product team to modify the application for best practice PostgreSQL usage Configure cluster replication and query settings which are appropriate for their data loss tolerance13 Add capacity or remove data when requested to maintain disk usage in normal operations at less than 70%

   **Availability uptime is not inclusive of one 60-minute scheduled maintenance window per month. During the maintenance window database connectivity may be interrupted for short periods during switchover to secondary nodes. Customers will be notified of scheduled maintenance at least 7 days in advance.

   Instaclustr Platform Services supporting OpenSearch Services¹⁴

   Tier1	Service Standards2	Customer Requirements
   Starter (Developer nodes)	No guaranteed availability (99.9% target) No latency3 SLAs	Minimum of one replica shard on all indices Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify application and index settings for best practice OpenSearch usage
   Small (5 or less production nodes)	99.95% availability15 for search and index operations, where wait_for_active_shards is 2 or less. No latency SLAs 20% monthly fees at risk in total; 10% credit for each breach	Minimum of 2 replica shards on all indices Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify the application and index settings for best practice OpenSearch usage
   Enterprise (6+ production nodes)	99.99% availability15 for search and index operations, where wait_for_active_shards is 2 or less 95% of index/search operations to Instaclustr-maintained Index in the cluster within specified latency threshold3 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA	Minimum of 2 replica shards on all indices Use dedicated masters Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify the application and index settings for best practice OpenSearch usage
   Critical (12+ production nodes)	99.999% availability15 for search and index operations, where wait_for_active_shards is 2 or less 99% of index/search operations to Instaclustr-maintained index in the cluster within specified latency threshold3 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing a breach of latency SLA	Minimum of 2 replica shards on all indices Use dedicated masters Separate testing and production clusters Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application and index settings for best practice alignment and actions findings from that review Instaclustr product team review prior to deploying changes that may impact latency SLA Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70% Comply with reasonable requests to modify the application for best practice OpenSearch usage

   Instaclustr Platform Services supporting Cadence Services

   Tier	Service Standards	Customer Requirements
   Starter (Developer Size Nodes)	No guaranteed availability (99.9% target) No latency SLAs	Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests to modify the application for best practice Cadence usage. Comply with requirements for Starter level SLAs for dependency services (Cassandra, Kafka, OpenSearch)
   Production (3+ Production size nodes for each of Cadence and its dependency service clusters)	99.95% availability as measured by NetApp Instaclustr synthetic transaction monitoring 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing a breach of latency SLA	Add capacity as reasonably requested by Instaclustr to manage operational loads Comply with reasonable requests to modify the application for best practice Cadence usage Comply with requirements for at least Small level SLAs for dependency services (Cassandra, Kafka, OpenSearch)

   Claims Process

   If at any time during your Subscription Term, you determine that you are not receiving the Availability Service Level, contact support@instaclustr.com and include the following information in your email:

   • Calculated Downtime
   • Description in incident of issue
   • Cluster ID of impacted cluster(s)

   ¹SLA tier is per-cluster and based on the number of nodes in the cluster. Customer credits are calculated based on the fees payable for the cluster or clusters impacted by the incident. SLAs credits apply to production clusters only.

   ²Service levels are measured on a monthly basis based on Instaclustr by NetApp’s monitoring systems. All service levels exclude outages caused by non-availability of service at the underlying cloud provide region level or availability zone level in regions which only support two availability zones.

   ³Latency is measured at a minimum rate of one read/write pair per node per 20 second period. Latency SLA excludes incidents where the cause is determined to be changes to a customer’s application or unusually high loads on the cluster.

   ⁴Availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read/write pair per node per 20 second period. A cluster is considered to be unavailable where read/write operations fail for a majority of nodes in the cluster in a given check-in period.

   ⁵Where a customer meets requirements for a tier based on cluster size but does not meet other requirements for a tier, the highest level of SLA where all requirements are met will apply.

   ⁶All SLAs exclude issues caused by customer actions including but not limited to attempting to operate a cluster beyond available processing or storage capacity.

   ⁷SLA credits must be claimed by customers within 14 days of the end of the relevant calendar month.

   ⁸For Kafka Connect, availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one Connector read or write operation per cluster per 20 second period. Excludes issues caused by BYO Kafka Connect Connectors due to the potential impact of user code on the availability of these environments.

   ⁹For Redis, availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read or write operation per cluster per 20 second period. Excludes latency issues caused by the use of integrated Lua scripting (EVAL and EVALSHA). Excludes issues caused by customers executing commands marked as “dangerous” by the Redis project (turning on authentication will restrict access to these commands). Details of these commands can be found here.

   ¹⁰For ZooKeeper, availability is measured by establishing a connection with the ZooKeeper server on each node using a local ZooKeeper client, on a per node per 20 second basis.

   ¹¹For preview versions of Kafka and Kafka Connect, only their respective “Starter” tier SLAs are valid. Production usage may be brought under an agreed SLA for the GA version after joint testing. Please contact us if you wish to discuss this option.

   ¹²PostgreSQL availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read/write pair per node per 20 second period. A cluster is considered to be unavailable where read/write operations fail for all nodes in the cluster in a given check-in period. PostgreSQL SLAs exclude issues caused by customer actions including but not limited to; attempting to operate a cluster beyond available processing or storage capacity, modifications to application configuration, or customer initiated reloads or resizes. PostgreSQL uptime is not inclusive of one 30-minute scheduled maintenance window per month. Customers will be notified of scheduled maintenance at least 7 days in advance, and the Instaclustr product team will make all reasonable attempts to minimize the impact to your availability.

   ¹³Client PostgreSQL applications should be configured in order to maintain high availability and reestablish connections in the event of a master replica failure. For more information see Replication and High Availability

   ¹⁴OpenSearch SLAs also apply to legacy OpenDistro for Elasticsearch clusters.

   ¹⁵The KNN plugin will use additional off heap memory. The default cache and selected node size may be inappropriate depending on the specific use of the plugin combined with other OpenSearch activities. This may result in cluster instability and customers need to be aware this could impact high availability of the cluster.

   ¹⁶Clusters created as “Bundled Use Only” are covered by SLAs only when used purely as a supporting service for another Instaclustr by NetApp offering (i.e., no direct access).

   ¹⁷Enterprise Add-ons for Kafka (Schema Registry, REST Proxy, Karapace Schema Registry and Karapace REST Proxy) are excluded from availability and latency SLAs.

   ¹⁸For preview versions of Enterprise Features for Kafka, only the “Starter” tier SLAs are valid. Production usage may be brought under an agreed SLA for the GA version after joint testing. Please contact us if you wish to discuss this option.

3. Open-Source Software

   In the event NetApp distributes or otherwise provides for Customer any software for which the original source code is made freely available to the public under a designated open source license which permits users to use, change, and improve the software, and to redistribute it in modified or unmodified form (“Open Source Software”) to Customer in furtherance of the delivery of the services associated with this Order Form, then such Open Source Software is subject to the terms of the applicable open source license. To the extent there is a conflict between the terms and conditions of this Order Form and the terms and conditions of the applicable open-source licensee, the terms and conditions of the open-source license will prevail.

   Bug fixes, patches and features developed for Open-Source Software (Open-Source Contribution), because of the services associated with this Order Form, may be released by NetApp to the Apache Software Foundation project or other relevant open-source project at any time (a “Open-Source Software Contribution”). The parties agree that, despite any other provision in the Order Form, neither NetApp nor Customer has any right (including IP Rights), title or interest in the Open-Source Contribution.

4. Service Use for Processing Personal Information

   If personal information has not been specified in the Order Form, Customer will not use the Services for the storage and processing of personal information without NetApp’s consent.

   If personal information has been specified in the Order Form. NetApp acknowledges that Customer will use of the Services for the storage and processing of personal information. Where personal information is stored in the Services NetApp recommends:

   • Using application encryption (as appropriate) for all personal information before storage in the Services;
   • Enabling Customer to Server encryption when provisioning clusters;
   • For clusters running in AWS, enabling EBS encryption within the Services when provisioning clusters;
   • Meeting NetApp’s published baseline security control requirements for Instaclustr services applicable to Customers;
   • Meeting all Customer security responsibilities as described in the Agreement; and
   • Implementing any additional security controls as are reasonably recommended by NetApp.

   Customer must provide NetApp, at reasonable periods, information regarding the total number of personal records stored within the Services to enable NetApp to meet its security, insurance, and other compliance requirements.

   NetApp will manage Customer’s clusters and information as stated in NetApp’s SOC-2 accreditation. NetApp will not be liable to Customer for any data breach arising from Customer’s failure to implement any of the above recommendations.