How Druva uses AWS PrivateLink for Secure Cloud Data Transfers

In this post, we examine how Druva, a SaaS vendor offering cloud data protection and management solutions, implemented AWS PrivateLink to secure data transfers between Druva’s customers using Amazon Web Services (AWS) and Druva virtual private cloud (VPC). PrivateLink establishes private connectivity between VPCs, Amazon hosted services, and on-premises networks using VPC endpoints. This provides a more secure alternative to using public IP addresses, and keeps all traffic on the AWS network—never exposing it to the public internet.

AWS PrivateLink connects resources within one VPC (the consumer) to services within another VPC (the provider) using private IP addresses. When deploying PrivateLink, a VPC endpoint is created within the consumer VPC. Traffic from this endpoint is directed to an endpoint service deployed within the provider VPC. The traffic between the VPC endpoint and the endpoint service remains on the AWS network and is not exposed to the public internet. This creates a private connection for secure data transfer, making it well-suited to backup scenarios. For Druva, it facilitates the secure movement of data between Druva’s customer VPCs and Druva VPCs.

High-level architecture 

Druva’s enterprise backup service includes a control plane (CP) and a data plane (DP). The control plane is set up in two AWS Regions (Region-1 & Region-2), while the data plane is in multiple AWS Regions. The control plane and data plane VPCs are peered together, allowing for traffic movement between the control plane and the data plane.

Within Druva’s network, the endpoint services of the control plane and the data plane are connected to Network Load Balancers. Network Load Balancers are pass-through, and they are not configured for SSL termination. Requests to the backends of the control plane and the data plane, respectively, are routed using HAProxy. HAProxy, which stands for High Availability Proxy, is a popular open source software TCP/HTTP Load Balancer and proxying solution. At this time, AWS PrivateLink only supports Network Load Balancer, and Druva’s clients connect to backends with L7 routing. Since this is not possible with Network Load Balancer, HAProxy is required between the backends and the Network Load Balancer.

The architecture of this solution is outlined in Figure 1.

Figure 1: Secure access between consumer’s private subnets and Druva’s enterprise workloads using AWS PrivateLink.

• There are two Druva control plane regions: Region-1 and Region-2
• Druva has control plane backends and data plane backends in Region-1 and Region-2
• Other regions have only data plane backends
• Two types of VPC endpoint services are created in each AWS region:  Data plane VPC endpoint service for communication to the data plane backend in the same region (VPC endpoint services 2 & 4) and  Control plane VPC endpoint service for communication with the control plane backend in Region-1 or Region-2 (VPC endpoint services 1 & 3)
• In regions without a control plane backend, the communication between the control plane VPC endpoint service and control plane backend is routed via VPC peering
• Druva’s customers’ data is backed up in Amazon Simple Storage Service (Amazon S3) buckets in Druva’s data plane in the same region

Data security

• A Network Load Balancer is launched in a private subnet, allowing traffic only over a secure port (443).
• The Amazon S3 buckets have default encryption enabled, and the data is encrypted using server-side encryption with Amazon S3 managed keys (SSE-S3).
• The data is also encrypted using a customer-specific custom key using Druva’s envelope encryption utility.
• The data in transit is secured using TLS protocol, enabling TLS versions 1.2 and above.

How to configure the service provider’s VPC and other solution components

When an endpoint service is created, as Druva’s customer your AWS accounts must be allowlisted in it. One Network Load Balancer is needed for each VPC endpoint service. The access to Druva’s control plane and data plane backends that use VPC endpoint service can be restricted. The access can be restricted to specific resources, to traffic originating from a specific VPC or to traffic originating from a specific VPC endpoint.

Druva uses Terraform scripts to perform the preceding steps in each account and region. A sample script is mentioned in the next section.

Code snippet

####Configurable parameters whose values are passed on at the time of deployment
#### Variables
variable "customer_aws_accounts" {
  default = ["*"]
}

variable "private_aws_subnets" {
  default = [""]
}

variable "aws_vpc_id" {
  default = ""
}

variable "proxy_instance_id" {
  default = ""
}

#### Resources
##Druva VPC Endpoint, default value of allowed_principals is “*” else it will be Customer’s AWS Account Ids
##Customer will link up multiple VPC Endpoints with this VPC Endpoint of Druva
resource "aws_vpc_endpoint_service" "vpce" {
  acceptance_required        = false
  network_load_balancer_arns = [aws_lb.nlb.arn]
  allowed_principals         = var.customer_aws_accounts

  tags = {
    Name = "service_vpce"
  }
}
##Network Load Balancer to be created in private subnet
resource "aws_lb" "nlb" {
  name               = "service-nlb"
  internal           = true
  load_balancer_type = "network"
  subnets            = var.private_aws_subnets
  
  enable_deletion_protection = true
  enable_cross_zone_load_balancing = true

  tags = {
    Name = "service_nlb"
  }
}

##Network Load Balancer listener rule allowing traffic only on secure 443 port
resource "aws_lb_listener" "listener_rule" {
  load_balancer_arn = aws_lb.nlb.arn
  port              = "443"
  protocol          = "TCP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.tg.arn
  }
}

resource "aws_lb_target_group" "tg" {
  name     = "service-tg"
  port     = "443"
  protocol = "TCP"
  vpc_id   = var.aws_vpc_id

  health_check {
    interval            = "30"
    port                = 443
    protocol            = "TCP"
    healthy_threshold   = "2"
    unhealthy_threshold = "2"
  }
}

resource "aws_lb_target_group_attachment" "tg_attachment" {
  target_group_arn = aws_lb_target_group.tg.arn
  target_id        = var.proxy_instance_id
  port             = 443
}

output "service_name" {
  value = aws_vpc_endpoint_service.vpce.service_name
}

output "private_dns_name" {
  value = aws_vpc_endpoint_service.vpce.private_dns_name
}

How to configure the consumer VPC and other solution components

As Druva’s customer you need to deploy an AWS CloudFormation template to complete the following configuration steps on your side of the network:

• Create a VPC endpoint for each endpoint service in Druva’s (the service provider’s) VPC to facilitate communication over a private network.
• Create an Amazon Route 53 private hosted zone in your VPC. This will have CNAME entries pointing to the VPC endpoint, which are needed for private communication. This is needed to route traffic to VPC endpoints using Druva’s own domain name (druva.com).

Business and technical benefits
The key business and technical benefits of Druva’s enterprise backup cloud platform, which uses AWS Private link for secure data transfer are:

• Augmenting backup strategy with a software as a service (SaaS)-based solution for critical workloads.
• Augmenting backup solutions with SaaS-based solutions for workloads where mandated by regulatory and compliance requirements.
• Dynamically scaling VPC endpoint services based on data backup requirement for optimum utilization.
• Reusing VPC endpoint services to set up multiple private connections
• Automating deployment using Terraform and CloudFormation templates without needing manual intervention.
• Optimizing cost by backing up data in the same Region as the customer, reducing data transfer cost.
• Making the data secure in transit because it never leaves the private network.
• Controlling network access by using fine-grained access control to specific resources in Druva’s VPC instead of all resources by default, following principle of least privilege.

Other use cases of this approach

AWS PrivateLink provides a secure and scalable mechanism that allows common services, such as security services, logging, monitoring, DevOps, authentication, and authorization, in the shared services VPC to be exposed as an endpoint service and consumed by workloads in separate VPCs.

For customers who have a hybrid ecosystem that combines the AWS Cloud and on-premises infrastructure, AWS PrivateLink could allow them to extend resource targets for the AWS PrivateLink endpoint service to resources in an on-premises data center. This would enable seamless communication between resources deployed in AWS or hosted on-premises.

Conclusion

In this post, we explained why and how Druva uses AWS PrivateLink to establish private connectivity between resources in their AWS accounts and their customers’ AWS accounts in the same Region. The solution uses VPC peering for cross-Region communication between resources. This architecture ensures that data upload and data download from the VPC in the same AWS Region (using AWS PrivateLink) or different AWS Regions (using VPC peering in Druva’s network or their customers’ network), uses the AWS internal network and does not take place over the public internet.

Refer to the Amazon Virtual Private Cloud Documentation to explore AWS PrivateLink further and read about other related services. Learn more at www.druva.com and join the conversation at twitter.com/druvainc.

About the authors