Confluent Cloud takes up a full /16 subnet in an Azure VNET?

Confluent Cloud
1

Considering most enterprises have IP exhaustion of their RFC 1918 from poor allocation practices over many year, its INSANE that Confluent Cloud requires a /16 to do a VNET deployment. What customer will need to spin up 65k nodes in a Kafka cluster???

If your trying to do Kafka Connect with Confluent Cloud and need to reach back to an on-premises databases there are no good options. Either gobble up a /16 of valued Private IP space or you have to punch a hole in your firewall to let traffic through (really???). Not to mention that renders ExpressRoute useless.

What about conecting to Service Endpoints / Private Link to Storage accounts or databases in Azure? Without a VNET you are stuck opening the firewall on them. Private Link to Confluent Cloud is just about giving a unidirectional private IP towards cloud but does NOTHING for connecting to external things that aren’t on the internet.

The other option of running Confluent Platform in your on premise data center and paying its exorbinant 3x licensing costs compared to Confluent Cloud along with having to run a bunch of hardware and storage isn’t really a great option either.

Is there any way to lower that VNET size manually?

2

Hello @dalehypereon and welcome to the Confluent Community Forum!

Currently, the /16 CIDR is a hard requirement to set up VNet peeting on Azure. This may change in the future though.

For connecting (via Kafka Connect) to Private Link endpoints for Azure storage / databases, there’s a hybrid solution where you run the connector in your VNet. Many Confluent Cloud customers take this approach. Note that there isn’t a license cost for Confluent Commercial Connectors with this setup. From here:

Self-managed connectors have no billing mechanism themselves. However, note that using self-managed connectors may incur ingress, egress, and storage charges for your Kafka clusters running in Confluent Cloud.