Skip to main content

Secure Private Access

Use CaseSecurityZilla Plus
★Zilla Plus This use case is implemented by Zilla Plus, Aklivity's commercial edition of Kafka Gateway.

The Problem

Internal services in other VPCs, or in other AWS accounts entirely, need authenticated access to a Kafka cluster, but the cluster shouldn't be reachable from the public internet, and manually whitelisting every broker endpoint across account and VPC boundaries doesn't scale.

How Zilla Solves It

Zilla Plus for Amazon MSK deploys an auto-scaling, stateless proxy layer in a private VPC that handles authentication and routing of Kafka requests, giving Kafka clients in other VPCs and accounts a single, private, unified domain name to connect through. The Kafka cluster itself needs no configuration changes.

Secure Private Access Overview
Secure Private Access Overview

Key Features

  • Seamless Amazon MSK Serverless connectivity across cross-account VPCs.
  • No configuration changes required to the MSK cluster.
  • Custom wildcard DNS with Route 53 hosted zone integration.
  • A unified domain name for Kafka clients, regardless of which VPC or account they connect from.
  • Eliminates the need to manually whitelist each bootstrap endpoint.
  • End-to-end TLS handshake, with auto-scaling proxy instances behind a network load balancer.
  • Integrates with AWS Nitro Enclaves for automated certificate renewal.
  • Supports access from on-premises or remote devices via AWS Client VPN.

Architecture

Many-to-One Private Access

Multiple Kafka clients from different cross-account VPCs connect securely to a single Amazon MSK Serverless cluster, simplifying multi-tenant access with a unified, private connectivity model.

Many to One Private Access Overview
Many to One Private Access Overview

  • Choose a wildcard DNS pattern to use for intranet access to the Kafka brokers. These wildcard DNS names must resolve to the IP address of the VPC Endpoint in the client VPC, which then routes traffic via the VPC Endpoint Service to the Zilla Plus Network Load Balancer (NLB).

  • The Zilla Plus proxy must also be configured with a TLS server certificate representing the same wildcard DNS pattern.

One-to-Many Private Access

Kafka clients securely access multiple Amazon MSK Serverless clusters deployed across different VPCs through the same proxy layer.

One to Many Private Access Overview
One to Many Private Access Overview

  • Choose a wildcard DNS pattern to use for intranet access to the Kafka brokers. These wildcard DNS names must resolve to the IP address of the VPC Endpoint in the client VPC, which then routes traffic via the VPC Endpoint Service to the Zilla Plus Network Load Balancer (NLB).

  • The Zilla Plus proxy must also be configured with a TLS server certificate representing the same wildcard DNS pattern.

Connecting via AWS Client VPN

Zilla Plus also supports secure private access to Amazon MSK Serverless over a custom domain using AWS Client VPN, letting on-premises users securely connect to MSK Serverless clusters from outside the VPC without exposing the clusters to the public internet.

Secure Private Access via AWS Client VPN
Secure Private Access via AWS Client VPN

  • Choose a wildcard DNS pattern to use for intranet access to the Kafka brokers. These wildcard DNS names must resolve to the IP address of the VPC Endpoint in the client VPC, which then routes traffic via the VPC Endpoint Service to the Zilla Plus Network Load Balancer (NLB).

  • The Zilla Plus proxy must also be configured with a TLS server certificate representing the same wildcard DNS pattern.

After deployment, an AWS Client VPN endpoint attached to the client VPC lets on-premises clients connect and access the MSK Serverless clusters.

Deploy