Qbox clients have the advantage of Virtual Public Cloud peering. With this
networking connection, password protection or IP whitelisting becomes fail-safe against the unlikely scenario where AWS has a glitch in the
configuration of a network. VPC peering promises data “sovereignty,” assuring any data in the Qbox cluster is only sent to the requesting VMs owned
by the customer.
In this article, we give a brief overview of this connection, its basics, and the process to enable it.
Nodes on Qbox are each assigned both a public IP address and a private IP address. They both point to the same VM (Virtual Machine or “server”) which hosts the node, but there is a difference. Requests sent to the public IP are routed through the public internet, allowing the nodes (running on VMs) to be reached from somewhere outside the datacenter the VM resides in — for example, from your local computer in a coffee shop.
Requests sent to the private IP of a node from that coffee shop would fail, however. That is because these private IP addresses are only “addressable” inside the datacenter. It is only within the datacenter that these addresses are recognized. That means that any server inside the datacenter can use the private IP to reach the respective VM (like computers on a shared local network).
There are 2 main benefits to using private IPs:
- Security. There are fewer chances for a “middle man” to intercept data on an insecure public network.
- Performance. This is a huge benefit. It can shave 50-300ms off a request when using private instead of public IP addresses. When Elasticsearch is responding in under 10ms, 300ms is a major hit.
Regarding VPC peering
On AWS (only this provider specifically), VMs can be launched into special private networks called VPCs (virtual private clouds). By default, VMs on AWS are launched into a big, open private network (shared with all other VMs in the network in the same region) called “EC2 Classic”.
Thus, while private networks are more secure than public, there is still the concern of unauthorized access to a private IP from another server within “EC2 Classic”.
In a VPC, private IPs assigned to each node are only addressable within that VPC itself. This is the most secure form of inter-VM networking within the datacenter.
Qbox normally recommends password-protection or IP whitelisting on clusters, but with VPC peering, both become merely failsafes against the unlikely scenario where AWS has a glitch in the configuration of a network, causing a vulnerability. This is all not to mention that, if a customer is using a VPC on their account, VPC peering must be used in order for private IPs to be available for the cluster at all. VPC VMs cannot communicate with non-VPC VMs.
That means that any customer using a VPC for their application servers, whether or not they care about secure communication with their Qbox cluster, must consider VPC peering if they care about the performance boost offered by private IPs.
For larger, stricter deployments (“Enterprise”), security requirements are tighter. VPC peering promises data “sovereignty”, assuring any data in the Qbox cluster is ONLY sent to the requesting VMs owned by the customer.
How VPC peering works
Currently, VPC peering cannot be setup by a customer through the dashboard — this should be coming soon.
However, it is still simple enough for a support engineer to enable.
What is needed from the customer: for each VPC they want peering with the Qbox cluster VPC, they must provide:
- AWS account ID
- VPC ID
- VPC CIDR block
Multiple VPCs can peer with a single Qbox cluster. By default, Qbox will auto-generate a CIDR for the Qbox cluster’s VPC (this is different from the VPC CIDR of the customer’s VPCs).Optionally, a customer can provide a set CIDR for Qbox to use for a cluster’s VPC. This is useful when the customer predicts ongoing allocation of addresses in their private deployment, and Qbox’s dynamically-generated CIDR may reserve the wrong, or too large of a, CIDR block.
VPC peering is a way to connect 2 or more VPCs, so that VMs in each can communicate. Also, once a support engineer has configured and launched a cluster with VPC peering enabled, there are 2 more steps required of the customer:
- They must accept the VPC peering request.
- They must add a route to the route table of their VPC that points the Qbox VPC CIDR to the peering connection ID. (This process is easier than it sounds)