FAQ for Confluent Cloud
This topic provides answers to general Confluent Cloud questions.
Tip
If you don’t see your region listed, contact Confluent. Additional regions can be supported by request.
- Amazon Web Services (AWS)
- af-south-1 (Cape Town)
- ap-northeast-1 (Tokyo)
- ap-northeast-2 (Seoul)
- ap-south-1 (Mumbai)
- ap-southeast-1 (Singapore)
- ap-southeast-2 (Sydney)
- ca-central-1 (Canada Central)
- eu-central-1 (Frankfurt)
- eu-north-1 (Stockholm)
- eu-west-1 (Ireland)
- eu-west-2 (London)
- eu-west-3 (Paris)
- me-south-1 (Bahrain)
- sa-east-1 (São Paulo)
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-1 (N. California) (Only supports Single-Zone (SZ) dedicated clusters with PrivateLink/VPC peering/Transit Gateway.)
- us-west-2 (Oregon)
- Azure (Microsoft Azure)
- australiaeast (New South Wales)
- canadacentral (Canada)
- centralus (Iowa)
- eastus (Virginia)
- eastus2 (Virginia)
- francecentral (France)
- northeurope (Ireland)
- southeastasia (Singapore)
- uksouth (London)
- westus2 (Washington)
- westeurope (Netherlands)
- GCP (Google Cloud Platform)
- asia-east1 (Taiwan)
- asia-east2 (Hong Kong)
- asia-northeast1 (Tokyo)
- asia-south1 (Mumbai)
- asia-southeast1 (Singapore)
- asia-southeast2 (Jakarta)
- australia-southeast1 (Sydney)
- europe-north1 (Finland)
- europe-west1 (Belgium)
- europe-west2 (London)
- europe-west3 (Frankfurt)
- europe-west4 (Netherlands)
- europe-west6 (Zurich)
- northamerica-northeast1 (Montreal)
- southamerica-east1 (São Paulo)
- us-central1 (Iowa)
- us-east1 (S. Carolina)
- us-east4 (N. Virginia)
- us-west1 (Oregon)
- us-west2 (Los Angeles)
- us-west4 (Las Vegas)
Confluent Cloud runs the latest version of Confluent Platform, including all released and to-be-released updates.
- After a new version of Kafka is released, there is an expected lag before all Confluent Cloud clusters are updated with the latest.
- Not all current Confluent Platform features are available in Confluent Cloud.
Since Kafka version 0.10.0.0, clients and brokers provide backward compatibility so that they can
fall back to older request types or throw appropriate errors if functionality is not available. This
means that upgrades to Kafka clients do not require corresponding broker upgrades and upgrades to the
Kafka version running in Confluent Cloud do not require corresponding version upgrades on the client side.
However, it is strongly recommended that you keep all of your clients running on the latest version
so that you get the best performance and can use the latest features. For more information, see
Confluent Platform and Apache Kafka Compatibility.
- Confluent Cloud follows the Confluent Platform client version support policy.
- Compatible clients must support and implement TLS/SSL encryption and SASL_PLAIN authentication. This is required to connect to Confluent Cloud.
- All client features since 0.10.0.0 are supported, including exactly-once delivery semantics.
Yes. You can set retention per topic in Confluent Cloud, including unlimited retention with log compaction. You are only limited
by the amount of total storage for your cluster.
Yes, these are described in Confluent Cloud Cluster Types. If you try to create more partitions than you are allowed, you will see
this error:
"You may not create more than the maximum number of partitions"
You can manage your support plan by clicking the lifesaver icon in the upper-right
corner of the Confluent Cloud window. From the menu that appears, click Support Plans.
The Support Plans page shows which plan you have currently. You can also choose
a different plan from this page by clicking Select in the description of the
plan. The next window that opens shows the pricing details for that plan and asks
you to confirm your support plan upgrade. Click Confirm upgrade to upgrade,
or click Close to cancel.
Important
Downgrade restrictions apply to support plan purchases. Your current support level
will stay in effect until the end of the current calendar month. However, if you
downgrade within the month of purchase, your current support plan level is
maintained until the end of the next full calendar month.
- All traffic over the wire requires TLS/SSL encryption and SASL_PLAIN authentication.
- All data is encrypted at rest on encrypted volumes. Confluent Cloud ensures encryption
on customer data stored at rest through the native encryption services offered by our cloud providers.
- BYOK encryption is supported for data at rest on AWS dedicated clusters.
- You control the API keys and secrets specific to your cluster which you can revoke or reissue if necessary.
- All data is stored on secure infrastructure, with access controls that are restricted to Confluent engineers,
inside a Confluent controlled VPC.
- Confluent Cloud Dedicated clusters provide dedicated compute and storage resources.
- VPC Peering (optional) provides network-level security for customers with
Dedicated Clusters in Confluent Cloud.
- Single sign-on (SSO) using your existing SAML-based identity provider (IdP).
Confluent Cloud SSO provides access control for multiple independent software systems.
For more information, see the Confluent Cloud Security Addendum
and the Confluent Cloud Security Controls
whitepaper.
TLS version 1.2 is supported.
Important
Effective March 15, 2020, connections made by using TLS 1.0 and 1.1 are no
longer supported. TLS 1.0 and 1.1 are legacy cryptographic protocols that do not support modern
cryptographic algorithms. They contain security vulnerabilities that can be exploited by attackers.
The Internet Engineering Task Force is planning to officially
deprecate both protocols.
The majority of encrypted internet traffic is now over TLS 1.2. TLS 1.2 has been the recommended
version for IETF protocols since 2008.
Kerberos authentication is not supported.
No. Because the cloud infrastructure that is used by Confluent Cloud does not guarantee static IPs across cluster changes, DNS is used to provide a consistent address. The underlying IPs may be stable for some period of time, but are subject to change at any time, so they should not be relied upon for any use.
However, DNS for each cluster follows a predictable pattern. If your cluster bootstrap URL is pkc-12345.<region>.<cloud>.<tld>, all broker endpoints will be of the format:
b0-pkc-12345.<region>.<cloud>.<tld>, b1-pkc-12345.<region>.<cloud>.<tld>, b2-pkc-12345.<region>.<cloud>.<tld>...
Here are the recommended JVM producer settings.
- JVM Security configuration
java.security.Security.setProperty(“networkaddress.cache.ttl” , “30");
java.security.Security.setProperty(“networkaddress.cache.negative.ttl” , “0");
- Kafka Producer and Consumer configuration
consumer.client.dns.lookup="use_all_dns_ips"
producer.client.dns.lookup="use_all_dns_ips"
You can upgrade Basic clusters to Standard clusters. No other changes to cluster
type (including downgrading a Standard cluster to Basic) are supported. For more
information on cluster types, see Confluent Cloud Cluster Types.
No, an email account can only be in one organization at a time. If you are changing
organizations, Confluent support can move your user account to a different organization.
If your email provider supports tagging with a plus sign (+), then you can register
a new account using your existing email address with a different tag.
For example, if you have an existing Confluent Cloud user account using myemail@gmail.com then you could register a
separate user account with this syntax: myemail+org2@gmail.com.
In the Confluent Cloud web UI, you may see the same bootstrap server for different clusters.
This is working as designed; it occurs because Confluent Cloud clusters are multi-tenant.