Supported Features for Confluent Cloud

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

Features in Confluent Cloud

The following limits and features apply to all Confluent Cloud cluster types:

Description Supported
ACLs Yes. For details, see Access Control Lists (ACLs) for Confluent Cloud.
Auto topic creation No
Consumer lag UI Yes. For details, see Configuring Access to the UI Dashboard.
Encryption at rest Yes (encrypted volumes)
Encryption in motion Yes (SSL/TLS)
Exactly Once Semantics Yes
Key based compacted storage Yes
Multi-zone high availability Yes
Service accounts Yes. For details, see Service Accounts for Confluent Cloud.
Support Yes. For details, see Compliance for Confluent Cloud.
Topic management UI Yes. For details, see Managing Topics in Confluent Cloud.
Max topics Depends on provisioned storage capacity and total cluster size.
Schema Registry Yes. For details, see Supported Features for Confluent Cloud Schema Registry.

The following limits and features apply to specific Confluent Cloud cluster types (where applicable, limits are pre-replication):

Description Basic Standard Dedicated
Cluster throughput
  • Write: Up to 100 MB/s
  • Read: Up to 100 MB/s
  • Write: Up to 100 MB/s
  • Read: Up to 100 MB/s
  • Write: Up to 50 MB/s per CKU
  • Read: Up to 150 MB/s per CKU
Max partitions per cluster 2,048 2,048 4,500 per CKU up to 33,000 total
Max storage per partition 100 GB 100 GB 100 GB
Data retention per cluster Up to 5 TB Up to 5 TB 10 TB per CKU
Max message size 2 MB 2 MB 2 MB default, but can be increased to 8 MB
Max simultaneous connected clients 100 100 1,000 per CKU
Max connection attempts per second 10 10 80 per CKU
Max requests per second 1,500 1,500 15,000 per CKU
Network peering options Not available Not available VPC Peering, Transit Gateway on AWS
Uptime SLA Not available 99.95% 99.95%
Multi-zone high availability Not available Available Available
Confluent Cloud Schema Registry schema versions 1,000 1,000 1,000
Max tasks per connector 1 Unlimited Unlimited

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) [1]
    • 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)
    • us-central1 (Iowa)
    • us-east1 (S. Carolina)
    • us-east4 (N. Virginia)
    • us-west1 (Oregon)
    • us-west2 (Los Angeles)
[1]Region only supports single zone Basic and Standard cluster types. Multi-zone Dedicated clusters are available.

Compliance for Confluent Cloud

Description Confluent Cloud Enterprise Confluent Cloud
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, Minor 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 net 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 Confluent Cloud Enterprise 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

Description Confluent Cloud Enterprise Confluent Cloud
Support

Business (included):

  • 24 x 7 coverage
  • P1 issue response within 60 minutes

Premier (add-on):

  • 24 x 7 coverage
  • P1 issues response within 30 minutes
  • Assigned TAM, quarterly business and technical reviews

Basic

Developer

  • Business hours support
  • 24 x 7 access to support portal

Business

  • 24 x 7 coverage
  • 60 minutes response SLA

For more information, see How do I change support plans?

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

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 KSQL

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

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

Supported Features for KSQL in Confluent Cloud

  • Web interface for managing your KSQL cloud environment directly from your browser that exposes all critical KSQL 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 KSQL 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 KSQL 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 KSQL 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

The unit of pricing in Confluent Cloud KSQL 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 KSQL provisioning so that you can see exact pricing for your cloud and region of choice.

Scaling CSUs

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 your old application to your new one.

Sizing guidelines

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 KSQL consumer lag.

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