If you’re just getting started with Confluent Cloud, you’re probably going to start with a cluster that is accessed over a secure public endpoint.
In fact, it’s quite possible that this is the only network connectivity you’ll ever need—this is a secure production-grade solution that greatly simplifies your architecture.
At a very high level—with a secure public endpoint, you can access your Confluent Cloud cluster from anywhere, in a secure fashion.
All communication from clients—whether that’s Kafka applications and services, Kafka Connect integrations, stream processing, or even just exploring Kafka with the UI or CLI—is encrypted, using industry-standard TLS encryption. This is the same encryption used when you access your bank account or make a credit card payment online—everything is secured in transit.
Additionally, everything in Confluent Cloud requires authentication—in order to talk to Kafka you have to prove your identity, using an API key and secret, in order to access any data. We can also use your identity to validate that you should have access to a specific set of data.
So unless you have a specific infosec requirement, where you need more complex or advanced network connectivity, using a secure public endpoint may actually be both the best and easiest way to use Confluent Cloud.
With a secure public endpoint, we’re standing up a Kafka cluster that can be accessed from anywhere.
Let’s expand on this a little bit more. With a secure public endpoint, your Confluent cluster is exposed on a set of public endpoints, securely. You can access it from anywhere you need, whether from a cloud provider network, or from your on-premises network.
Secure public endpoints allow clients to connect to Confluent Cloud. But there are also situations in which Confluent Cloud may need to connect back to your network. For example, fully managed connectors.
When you’re using a secure public endpoint, managed connectors run in the Confluent Cloud network. Because managed connectors are going to access your data sources and data sinks, your data sources and data sinks need to be accessible over the internet, just like Confluent Cloud is accessible via secure public endpoints. This can be done in one of two ways:
Also, all of this applies to all Confluent Cloud network architectures. If your data sources and sinks can be exposed on internet endpoints, you can use fully managed connectors, regardless of whether you’re using public endpoints, or one of the other options we discuss later in this course, such as a peering configuration, or a Private Link network.
If you can’t expose your data sources and sinks to the internet, another option is self-managed connectors. In this architecture, you’ll run a connector in your on-premises network. This is a data integration which lives in your environment.
In the case of a self-managed source connector, you’ll run a data integration in your environment that reads from your data source and pushes (or produces) it up to Confluent Cloud using the Confluent Cloud secure public endpoint.
In the case of a self-managed sink connector, you’ll again run a data integration in your environment, this time one that consumes (or reads) from Confluent Cloud using the Confluent Cloud secure public endpoint and writes to your data sink.
Because these self-managed connectors are running in your environment, this architecture actually works regardless of your network architecture—you can do this with secure public endpoints, peered networks, or even Private Link.
Here are a few reasons why you wouldn’t be able to use secure public endpoints:
We will only share developer content and updates, including notifications when new content is added. We will never send you sales emails. 🙂 By subscribing, you understand we will process your personal information in accordance with our Privacy Statement.