Supported Features for Confluent Cloud

This topic provides the supported features and limitations for Confluent Cloud.

Cluster Types and Features

See Confluent Cloud Cluster Types for details.

Cloud Providers and Regions

Tip

If you don’t see your region listed, contact Confluent. Additional regions can be supported by request.

  • Amazon Web Services (AWS)
    • ap-northeast-1 (Tokyo)
    • ap-south-1 (Mumbai)
    • ap-southeast-1 (Singapore)
    • ap-southeast-2 (Sydney)
    • ca-central-1 (Canada Central)
    • eu-central-1 (Frankfurt)
    • eu-west-1 (Ireland)
    • eu-west-2 (London)
    • sa-east-1 (São Paulo)
    • us-east-1 (N. Virginia)
    • us-east-2 (Ohio)
    • us-west-2 (Oregon)
  • Azure (Microsoft Azure)
    • australiaeast (New South Wales)
    • centralus (Iowa)
    • eastus (Virginia)
    • eastus2 (Virginia)
    • northeurope (Ireland)
    • southeastasia (Singapore)
    • uksouth (London)
    • westus2 (Washington)
    • westeurope (Netherlands)
  • GCP (Google Cloud Platform)
    • asia-east2 (Hong Kong)
    • asia-northeast1 (Tokyo)
    • asia-southeast1 (Singapore)
    • australia-southeast1 (Sydney)
    • europe-north1 (Finland)
    • europe-west1 (Belgium)
    • europe-west2 (London)
    • europe-west3 (Frankfurt)
    • europe-west4 (Netherlands)
    • northamerica-northeast1 (Montreal)
    • us-central1 (Iowa)
    • us-east1 (S. Carolina)
    • us-east4 (N. Virginia)
    • us-west1 (Oregon)
    • us-west2 (Los Angeles)

Compliance for Confluent Cloud

Description Confluent Cloud Dedicated Confluent Cloud Standard & Basic
GDPR readiness Yes Yes
HIPAA Yes No
ISO 27001 Yes No
PCI level 2 Yes Yes
SOC 1, SOC 2, SOC 3 Yes Yes

Upgrade Policy for Confluent Cloud

This section describes how changes to Confluent Cloud are managed for Minor Upgrades for Confluent Cloud, Major Upgrades for Confluent Cloud, and Deprecations for Confluent Cloud.

Minor Upgrades for Confluent Cloud

Any change to Confluent Cloud services that isn’t a major upgrade or deprecation.

Potential customer impact
  • Minimal: standard Kafka state changes that clients handle gracefully, for example leader elections.
  • None: totally transparent, depending on customer usage of the service.
Examples
  • Kafka cluster roll.
  • Upgrading Kafka to a fully backwards-compatible version.
  • Adding new features.
Frequency
Very often, e.g., multiple times per day.
Communication before the change
May include email notifications, in-app messaging, updated documentation and release notes, and/or communication from Sales and customer operations.
Timing of the change for each customer
100% at Confluent’s discretion.

Major Upgrades for Confluent Cloud

Any change to Confluent Cloud services that requires code changes to any customer applications (Kafka clients, API integrations, etc) to continue working as before.

Potential customer impact
  • Large: could prevent use of service without code or configuration changes, or could problematically alter the performance profile.
  • None: totally transparent, depending on customer usage of the service.
Examples
  • Upgrading Kafka to a version that is not fully backwards-compatible with the previous version.
  • Updating a public API from api/v1/foo to api/v2/foo.
  • Security update that materially changes cluster or client throughput.
Frequency
Rare (~1 per year)
Communication before the change
  • Guaranteed: multiple email notifications to all registered Confluent Cloud users, starting at least 180 days before the upgrade date, with details about the change and available options.
  • May also include: in-app messaging; updated documentation and release notes; communication from Sales and customer support.
Timing of the change for each customer
May be coordinated with customers to avoid high-risk times and make the upgrade sooner, but the final date set by Confluent is not negotiable.

Deprecations for Confluent Cloud

Any removal of customer-usable functionality from Confluent Cloud services.

Potential customer impact
  • Large: could prevent use of service if the customer relies on the feature.
  • None: totally transparent, depending on customer usage of the service.
Examples
  • Complete removal of a feature from the UI.
  • Shutting down api/v1/foo.
  • Removing a particular Connector as an option.
Frequency
Rare (~1 per year)
Communication before the change
  • Guaranteed: multiple email notifications to all registered Confluent Cloud users, starting at least 180 days before the deprecation date, with details about the change and available alternatives.
  • May also include: in-app messaging; updated documentation and release notes; communication from Sales and customer support.
Timing of the change for each customer
100% at Confluent’s discretion.
Notes
Deprecations may be part of major upgrades (no guarantee of equivalent functionality in new versions).

Customer Support for Confluent Cloud

See Confluent Cloud support plans for details.

Resource limits for Confluent Cloud

Confluent Cloud limits the number of different resources you can create. To request an increase for a limit, contact support.

Scope Resource Limit
Organization Environments 10
Organization Kafka clusters 50
Organization Dedicated Kafka cluster provisioning requests per hour 5
Organization Control plane requests per second 5
Organization User accounts (active + invited) 100
Organization Service accounts 100
Organization Kafka API keys (includes keys owned by user accounts and by service accounts) 100
Organization Cloud API keys (includes keys owned by user accounts and by service accounts) 20
Organization Dedicated Kafka clusters in expanding state 5
Organization Connectors 50
Organization ksqlDB apps 50
Environment Kafka clusters 20
Environment Dedicated Kafka clusters in provisioning state 3
Environment Kafka cluster CKUs 50
Environment Schema Registry 1
Environment Connectors 20
Environment Connect tasks 100
Environment ksqlDB apps 20
Environment ksqlDB CSUs 100
Dedicated Kafka cluster Kafka API keys (includes keys owned by user accounts and by service accounts) 500
Dedicated Kafka cluster CKUs 24
Dedicated Kafka cluster VPC peering connections 5
Dedicated Kafka cluster Expansion requests per hour 5
Standard or Basic Kafka cluster Kafka API keys (includes keys owned by user accounts and by service accounts) 20
Any Kafka cluster Connectors 10
Any Kafka cluster ksqlDB apps 10
ksqlDB app CSUs 12
ksqlDB app Expansion requests per hour 5
Connector Tasks 100
Connector Expansion requests per hour 5
User account Control plane requests per second 1
User account Concurrent control plane request limit 10
User account Kafka API keys 10
User account Cloud API keys 2
Service account Control plane requests per second 1
Service account Concurrent control plane request limit 10
Service account Kafka API keys 10
Service account Cloud API keys 2

Confluent Cloud Schema Registry

Schema Management is fully supported on Confluent Cloud with Schema Registry. Details are listed below.

Supported Features for Confluent Cloud Schema Registry

  • A single Schema Registry is available per Environment.
  • Access Control to Schema Registry is based on API key and secret.
  • Each Environment must have at least one Apache Kafka® cluster to enable Schema Registry.
  • Your VPC must be able to communicate with the Confluent Cloud Schema Registry public internet endpoint. For more information, see Using Confluent Cloud Schema Registry in a VPC Peered Environment.
  • Available in cloud provider regions located in the US, Europe, and APAC.

Learn More About Confluent Cloud Schema Registry

Confluent Cloud Connect Preview

Certain Confluent Cloud connectors are available as preview features. A preview feature is a component of Confluent Platform that is being introduced to gain early feedback from developers. These features can be used for evaluation and non-production testing purposes or to provide feedback to Confluent. Comments, questions, and suggestions related to preview features are encouraged and can be submitted to ccloud-connect-preview@confluent.io.

Refer to Confluent Cloud connector limitations for details.

Confluent Cloud Data Flow Preview

Confluent Cloud Data Flow is currently available as a preview feature. A preview feature is a component of Confluent Platform that is being introduced to gain early feedback from developers. These features can be used for evaluation and non-production testing purposes or to provide feedback to Confluent. Comments, questions, and suggestions related to preview features are encouraged and can be submitted to ccloud-dataflow-preview@confluent.io.

For more information, see Data Flow.

Confluent Cloud ksqlDB

You can provision ksqlDB applications by using the Confluent Cloud UI or the ccloud CLI.

For more information, see Create streaming queries in Confluent Cloud ksqlDB.

Supported Features for ksqlDB in Confluent Cloud

  • Web interface for managing your ksqlDB cloud environment directly from your browser that exposes all critical ksqlDB information.
  • SQL editor to write, develop, and execute SQL queries with auto completion directly from the Web interface.
  • Integration with Confluent Cloud Schema Registry to leverage your existing schemas to use within your SQL queries.
  • Available in AWS, GCP, and Azure in all regions.

New Features for ksqlDB in Confluent Cloud

  • New built-in functions:

    • COUNT_DISTINCT(v) - aggregate function, computes the number of distinct values of v.
    • CUBE_EXPLODE(a) - tabular function, outputs a row for each unique combination of elements in array a.

  • Expression support for joins:

    SELECT * FROM s1 JOIN s2 ON s1.str = SUBSTRING(s2.str, 3) EMIT CHANGES;

  • Native Map and Array constructors:

    SELECT ARRAY[1, 2] FROM s1 EMIT CHANGES;
SELECT MAP(k1:=v1, k2:=v1*2) FROM s1 EMIT CHANGES;

  • Expression support for PARTITION BY:

    SELECT col0, col2, col3 FROM s1 PARTITION BY SUBSTRING(col2, 1, 4) EMIT CHANGES;

  • Improved error messages: ACL-related errors link to relevant ACL documentation.

Limitations for ksqlDB in Confluent Cloud

  • Currently, user-defined functions (UDFs, UDAFs, and UDTFs) aren’t supported.
  • You can have a maximum of 20 continuous queries per application.
  • You can have a maximum of three ksqlDB applications.
  • Pull queries aren’t supported.
  • Connect integration isn’t supported.
  • ccloud CLI version 0.198.0 or higher is required to create ksqlDB API keys for Confluent Cloud.

Pricing for ksqlDB in Confluent Cloud

The unit of pricing in Confluent Cloud ksqlDB is the Confluent Streaming Unit (CSU). A CSU is an abstract unit that represents the linearity of performance. For example, if a workload gets a certain level of throughput with four CSUs, you can expect about three times the throughput with 12 CSUs.

Confluent charges you in CSUs per hour.

You select the number of CSUs for your application at provisioning time. You can configure CSUs in blocks of four.

  • 4 CSUs is the minimum.
  • 12 CSUs is the initial maximum.
  • Your application can have 4, 8, or 12 CSUs.

Note

CSU pricing varies slightly depending on cloud provider and region. Pricing is shown in the web interface as part of ksqlDB provisioning so that you can see exact pricing for your cloud and region of choice.

Scaling CSUs for ksqlDB in Confluent Cloud

Scaling your application’s CSUs after initial provisioning is not supported. If you determine that your application requires more CSUs, you must provision a new application with the desired number of CSUs, and migrate to your new one.

Sizing guidelines for ksqlDB in Confluent Cloud

Four CSUs are sufficient for many workloads. In general, start with four CSUs and scale out if more capacity is needed. To identify when more CSUs are needed, check ksqlDB consumer lag.

After your ksqlDB application is provisioned, you can only change the CSU allocation by migrating to a new one one with the desired number of CSUs.