VPC Peering

Hi, I'm Justin Lee with Confluent. In this module we're going to be looking at the ins and outs of Virtual Private Cloud peering, better known as VPC peering. The first private networking option for Confluent Cloud is a peering connection. All of the public cloud providers, AWS, Google, and Azure allow you to create peer connections between VPCs or VNets. The way it works in Confluent Cloud is this. On the Confluent side you provision a Confluent peering network through the Confluent Cloud Console, API, or Terraform. You peer this Confluent network with your VPC or VNet. This is a standard cloud peering connection between us and you and it supports bidirectional connectivity, which means clients running in the peered VPC or VNet can access Confluent Cloud and fully managed connectors running in Confluent Cloud can access data sources and data sinks in your network. Peering connectivity is a common pattern in cloud networking. It sets up a direct network connection between your network and the Confluent Cloud network. You tell us what CIDR or range you want us to use, it has to be a /16, and we'll provision the network. In the Confluent network, you can provision one or more Confluent clusters, which can all be accessed over the peering connection. There are three main requirements in order for Confluent Cloud peering to work. The first is that this is a bidirectional connection. Your network or InfoSec team must be okay with the fact that we can access your network. We will never reach out to your infrastructure unless you configure a managed connector to access a data source or data sink running in your environment. A second requirement is that in order to provision the Confluent network, we require a /16 CIDR range for use by the Confluent network. This /16 CIDR range should come from one of these three types of IP address ranges. The first is a Private IP Address Range, or RFC 1918 address range. The second option is the shared address space, also known as Carrier Grade NAT. This comes from RFC 6598. The third option is a Benchmark Address Space. That's RFC 2544. There are also a set of address ranges that are explicitly excluded for use. Additionally, in order to resolve Confluent Cloud broker names, you need to allow DNS resolution to the upstream internet. You can't block your DNS infrastructure from accessing the authoritative DNS servers for confluent.cloud, which are hosted by us on the internet. The Confluent Cloud peering network has a number of benefits. It's the most easily understood private networking option and it supports entirely private networking. Traffic never needs to go over the public internet. You can stand up multiple Confluent clusters in the Confluent network. This allows you to allocate a single /16 range for all Confluent clusters in your environment and use it for multiple clusters. Because we have access to your network, we have the ability to access data sinks and data sources that are present in your environment. For example, if you have a database you'd like us to capture change data capture out of, we can potentially run a fully managed connector that can capture changes from your database and publish that to Confluent. There are a number of limitations with a Confluent peering network to be aware of. The first one is more of a limitation of cloud networking in general. In general, cloud networks don't support transitive network connectivity. That is, you can't connect from one network to another through an intermediate network. If you want to access a Confluent network from a VPC or VNet, it generally has to be directly peered to the Confluent network. There are a few exceptions to this, which we'll discuss in a little bit, but generally speaking, you can't transit through one VPC or VNet to get to another one. Additionally, because of the lack of transitive network connectivity in cloud, it's hard to connect on-premise data center hosted services to Confluent Cloud. Specifically, you can't connect from an on-premise network to one of your VPCs in the public cloud and from there to the Confluent Cloud network. VPC peering is really intended to allow private networking between VPCs and VNets and Confluent Cloud within the same region. Both of these scenarios have workarounds, which we'll talk about on the next slide. Without our proxy, managed connectors can only be used for data sources and data sinks that are reachable via an IP address in the VPC directly peered with Confluent Cloud. Unlike AWS VPCs and Azure VNets, which are regional, Google VPCs are global and can span multiple regions. Despite this, even if a GCP Confluent Cloud network is peered to a global GCP VPC, only services in the same region as the cluster can access the Confluent Cloud cluster. An exception to the no transitive connections rule is Google's custom route import and export features. Google Cloud peering offers transitive connectivity for VPN or Google internet connect to on-premises or other cloud provider networks to reach Confluent Cloud using this feature. To enable this feature, select it when creating the peering connection in Confluent Cloud. This option does not work to provide transitive connectivity to Confluent Cloud from one GCP VPC through another Google Cloud VPC. In Azure, Azure provides a capability called Gateway Transit. This allows a VNet to access a VPN or ExpressRoute gateway in a peered VNet. For example, if I have VNet X peered to VNet Y and VNet Y has an express route connected to my data center, Gateway Transit allows VNet X to access the data center through the express route in VNet Y. This capability is not currently supported in Confluent Cloud. Thanks for joining us, we'll see you in the next module.