Skip to main content

Deploying Kafka on Cloud Platforms

1. Using Amazon MSK

Feature Description Notes
Amazon MSK Managed Kafka service on AWS Supports Kafka 3.5+ with automatic upgrades
Deployment Types Provisioned (Dedicated) Managed by AWS, includes auto-scaling
Security Encryption at rest and in transit Supports IAM, TLS, and ACLs

Example: Creating MSK Cluster via CLI

aws kafka create-cluster \
  --cluster-name my-kafka-cluster \
  --kafka-version 3.5.1 \
  --broker-node-group-info \
    "ClientSubnets=[us-east-1a,us-east-1b],InstanceType=kafka.m5.large" \
  --encryption-info \
    "EncryptionAtRestEnabled=true"
Note: Ensure VPC and subnet configurations align with your security requirements.

MSK vs Self-Managed Kafka

  • MSK: Managed, scalable, secure, but less customizable
  • Self-Managed: Full control over configuration, but requires more ops

2. Deploying on Confluent Cloud

Example: Creating a Kafka Cluster on Confluent Cloud

confluent kafka cluster create my-cluster \
  --cloud gcp \
  --region us-central1 \
  --type dedicated \
  --key my-api-key \
  --secret my-api-secret
Property Description Values Notes
cluster.name Name of the Kafka cluster my-cluster Must be unique within the organization
cloud.provider Cloud provider for the cluster aws, gcp, azure Must match the region
region Region where the cluster is deployed us-central1, eu-west-1 Must be supported by the cloud provider
cluster.type Type of cluster to create dedicated, serverless Dedicated clusters offer more control and performance
Note: Serverless clusters are ideal for low-volume, bursty workloads and provide automatic scaling.

Example: Configuring Security with Confluent Cloud

confluent security iam role-binding create \
  --principal User:my-user \
  --role DeveloperReadAll \
  --resource-prefix my-cluster

Comparison: Dedicated vs Serverless Clusters

  • Dedicated: Full control over resources, better for predictable workloads
  • Serverless: Automatic scaling, no resource management needed, suitable for bursty workloads

3. Using Azure Event Hubs

Azure Event Hubs is a fully managed, scalable event streaming platform that can be used as an alternative to Kafka. It provides similar capabilities for real-time data ingestion and processing.

Feature Description Notes
Event Hubs Namespace Logical grouping of Event Hubs within a region Similar to Kafka cluster
Event Hub Individual stream of events within a namespace Similar to Kafka topic
Partition Ordered sequence of events within an Event Hub Similar to Kafka partition
Consumer Group Logical view of an Event Hub for processing events Similar to Kafka consumer group

Example: Sending Events to Event Hubs

const { EventHubClient } = require("@azure/event-hubs");

async function sendEvent() {
  const client = EventHubClient.createFromConnectionString(
    "Endpoint=sb://<namespace>.servicebus.windows.net/;SharedAccessKeyName=<key-name>;SharedAccessKey=<key>;EntityPath=<event-hub-name>"
  );

  const eventData = {
    body: JSON.stringify({ message: "Hello from Event Hubs!" }),
    properties: { source: "kafka-migration" }
  };

  await client.send(eventData);
  console.log("Event sent successfully");
}

sendEvent().catch(console.error);

Example: Reading Events from Event Hubs

const { EventHubClient } = require("@azure/event-hubs");

async function readEvents() {
  const client = EventHubClient.createFromConnectionString(
    "Endpoint=sb://<namespace>.servicebus.windows.net/;SharedAccessKeyName=<key-name>;SharedAccessKey=<key>;EntityPath=<event-hub-name>"
  );

  const consumer = client.createConsumer(
    "$Default",
    "0",
    EventHubClient.GetPartitionInfo("0")
  );

  const events = await consumer.receiveBatch(10, 5000);
  console.log("Received events:", events);
}

readEvents().catch(console.error);

Key Differences from Kafka

  • Managed Service: Azure Event Hubs is a managed service, reducing operational overhead
  • Scalability: Auto-scaling capabilities for handling variable loads
  • Integration: Seamless integration with other Azure services like Functions, Logic Apps
  • Security: Built-in support for Azure Active Directory and Shared Access Signatures
Note: Event Hubs supports both AMQP and HTTP protocols, with AMQP being preferred for better performance.
Warning: Event Hubs has a maximum message size of 1 MB, which is smaller than Kafka's default limit.

4. Deploying on Google Cloud

Example: Creating a Kafka Cluster on Google Cloud

gcloud beta kafka clusters create my-kafka-cluster \
    --project=my-project \
    --location=us-central1 \
    --zone=us-central1-a \
    --cluster-config=projects/my-project/locations/us-central1/clusters/my-kafka-cluster/config \
    --network=default \
    --subnetwork=default \
    --min-broker-count=3 \
    --max-broker-count=10
Property Description Values Notes
cluster.name Name of the Kafka cluster my-kafka-cluster Must be unique within the project
location Region where the cluster is deployed us-central1 Must support Kafka
zone Zone within the region us-central1-a Must support Kafka
network Network to use for the cluster default Must be a valid VPC network
subnetwork Subnetwork to use for the cluster default Must be a valid subnetwork within the network
min.broker.count Minimum number of brokers in the cluster 3 Minimum value is 1, recommended is 3 or more
max.broker.count Maximum number of brokers in the cluster 10 Must be greater than or equal to min.broker.count
Note: Ensure that the project has the Kafka API enabled and the appropriate IAM permissions to create and manage Kafka clusters.
Warning: The cluster will be created in the specified region and zone. Make sure to select appropriate zones for high availability.

Deployment Summary

  • Create a Kafka cluster using the Google Cloud Console or CLI.
  • Specify the project, region, zone, and network configuration.
  • Set minimum and maximum broker counts for scaling.
  • Ensure proper IAM permissions are in place.

5. Configuring Cloud-Specific Settings

Setting Description Cloud Provider Notes
cloud.provider Specifies the cloud provider for Kafka deployment AWS, GCP, Azure Must be set to configure cloud-specific settings
region Region where Kafka cluster is deployed AWS, GCP, Azure Must match the region where resources are located
instance.type Instance type for Kafka brokers AWS, GCP, Azure Choose based on performance and cost requirements
storage.type Storage type for Kafka logs AWS, GCP, Azure Options include EBS, SSD, or managed storage
network.type Network configuration for Kafka cluster AWS, GCP, Azure Can be VPC, Virtual Network, or Private Link

Example: AWS Configuration

cloud:
  provider: aws
  region: us-west-2
instance:
  type: m5.large
storage:
  type: ebs
network:
  type: vpc

Example: GCP Configuration

cloud:
  provider: gcp
  region: us-central1
instance:
  type: n1-standard-2
storage:
  type: ssd
network:
  type: vpc

Example: Azure Configuration

cloud:
  provider: azure
  region: eastus
instance:
  type: Standard_D2s_v3
storage:
  type: managed
network:
  type: virtual_network
Note: Ensure that the cloud provider's IAM roles and policies are correctly configured to allow Kafka to access necessary resources.

6. Managing Cloud Kafka Security

Security Aspect Description Implementation
Authentication Ensures only authorized clients can access Kafka SCRAM-SHA-256 or OAuth-Bearer mechanisms
Authorization Controls what actions users can perform on topics and resources ACLs (Access Control Lists) or RBAC (Role-Based Access Control)
Encryption in Transit Secures data transmission between clients and brokers TLS/SSL with encryption.protocol
Encryption at Rest Protects data stored on disk from unauthorized access server.ssl.keystore.location and ssl.truststore.location

Example: Configuring TLS for Kafka

# Enable TLS for Kafka
listeners=SSL://localhost:9093
ssl.keystore.location=/path/to/keystore.jks
ssl.keystore.password=changeit
ssl.key.password=changeit
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=changeit
Note: Ensure that all certificates are valid and issued by a trusted CA for production environments.

Key Security Practices

  • Use strong authentication methods like SCRAM or OAuth-Bearer
  • Implement fine-grained authorization using ACLs or RBAC
  • Enable TLS for all communication channels
  • Regularly rotate keys and certificates
  • Monitor access logs for suspicious activity

7. Scaling Cloud Kafka Clusters

Scaling Type Description Implementation Notes
Vertical Scaling Increasing resources (CPU, RAM, Storage) of existing brokers Adjust instance type in cloud console (e.g., from m5.large to m5.xlarge) May cause temporary downtime during resize
Horizontal Scaling Adding more brokers to the cluster to increase throughput and capacity Use cloud provider's auto-scaling or manual broker addition Requires rebalancing partitions across new brokers

Example: Adding a New Broker to AWS MSK Cluster

aws kafka update-broker-count \
    --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/abc123 \
    --current-broker-count 3 \
    --target-broker-count 4
Note: Horizontal scaling in managed Kafka services like AWS MSK or Azure Event Hubs typically involves updating the cluster configuration rather than manually adding brokers.
Cloud Provider Scaling Mechanism Auto-Scaling Support Notes
AWS MSK Update broker count via API or console NEW Auto Scaling Groups (beta) Supports vertical scaling via instance type changes
Azure Event Hubs Scale throughput units (TPU) via portal or CLI Yes, through TPU adjustment Partitions are managed automatically
GCP Pub/Sub Adjust message throughput limits via quotas No direct broker scaling Uses topic/subscription model instead of brokers

Scaling Considerations

  • Partition distribution must be rebalanced after scaling
  • Use kafka-reassign-partitions.sh for manual rebalancing
  • Monitor consumer lag and broker load post-scaling
  • Ensure sufficient network bandwidth for multi-broker clusters

8. Monitoring Cloud Deployments

Example: Kafka Cloud Monitoring Setup

aws cloudwatch put-metric-alarm \
  --alarm-name "KafkaBrokerHighCPU" \
  --metric-name CPUUtilization \
  --namespace "AWS/EC2" \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-description "Triggers when Kafka broker CPU exceeds 80%" \
  --actions-enabled \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:KafkaAlerts
Monitoring Aspect Description Tools/Services
Broker Metrics Key performance indicators for Kafka brokers AWS CloudWatch, Prometheus, Grafana
Consumer Lag Time delay between message production and consumption Kafka Manager, Confluent Control Center
Topic Throughput Messages per second processed on topics Amazon MSK, Azure Event Hubs

Key Metrics to Monitor

  • Broker CPU Utilization - Ensure it stays under 80% to prevent throttling
  • Consumer Group Lag - Alert if lag exceeds 5 minutes
  • Disk I/O - Monitor for high read/write latency
  • Network Throughput - Track bandwidth usage for scaling decisions
Note: Use confluent control-center for centralized monitoring in Confluent Cloud deployments.
Warning: High consumer lag can indicate system overload or misconfigured consumers.

9. Optimizing Cloud Costs

Cost Factor Description Optimization Strategy
Instance Type Choosing the right EC2 or cloud instance type affects CPU, memory, and I/O performance. Use m5.large or c5.xlarge for Kafka brokers with moderate throughput. Avoid over-provisioning.
Storage Type SSD vs HDD storage impacts latency and throughput. Use gp3 or io2 SSDs for Kafka logs to reduce latency and improve performance.
Replication Factor Higher replication increases durability but also storage and network costs. Use replication.factor=2 for cost-effective redundancy in most cloud environments.
Retention Policy Longer log retention increases storage costs. Set log.retention.hours=168 (7 days) to balance data availability and cost.
Auto-Scaling Dynamic scaling can lead to over-provisioning and unnecessary costs. Use auto.create.topics.enable=true with proper limits to avoid excessive topic creation.

Example: Cost-Optimized Kafka Configuration

broker.id=0
listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://kafka-broker-0.example.com:9092
log.dirs=/var/lib/kafka/data
num.partitions=12
default.replication.factor=2
log.retention.hours=168
auto.create.topics.enable=true
Note: Use aws cloudwatch to monitor Kafka metrics and identify cost-drivers.
Warning: Reducing replication.factor below 2 may increase data loss risk.

Summary of Cost Optimization Tips

  • Choose appropriate instance types for performance and cost balance.
  • Use SSD storage for better I/O performance at a reasonable cost.
  • Set retention policies to prevent unnecessary long-term storage.
  • Control topic creation to avoid over-provisioning resources.

10. Implementing Hybrid Cloud Setup

Example: Kafka Cluster Configuration for Hybrid Cloud

# kafka-config.yaml
listeners: PLAINTEXT://localhost:9092,SSL://:9093
advertised.listeners: PLAINTEXT://kafka-internal.example.com:9092,SSL://kafka-external.example.com:9093
listener.security.protocol.map: PLAINTEXT:PLAINTEXT,SSL:SSL
inter.broker.listener.name: SSL
ssl.truststore.location: /etc/kafka/certs/truststore.jks
ssl.truststore.password: changeit
ssl.keystore.location: /etc/kafka/certs/keystore.jks
ssl.keystore.password: changeit
ssl.key.password: changeit
Configuration Description Values Notes
listeners Network listeners for client connections PLAINTEXT://localhost:9092,SSL://:9093 Supports both internal and external connections
advertised.listeners Address advertised to clients for connecting PLAINTEXT://kafka-internal.example.com:9092,SSL://kafka-external.example.com:9093 Must match the actual network addresses accessible from clients
inter.broker.listener.name Listener used for broker-to-broker communication SSL Ensures secure internal communication
Note: Ensure that the advertised listeners are accessible from both cloud and on-premises clients to support hybrid deployment.

Hybrid Cloud Deployment Considerations

  • Use secure listeners (SSL/TLS) for external access to protect data in transit
  • Configure advertised.listeners to reflect the public network addresses
  • Ensure proper network security groups and firewall rules for both cloud and on-premises access
  • Consider using a load balancer or service mesh for managing traffic between environments

Was this article helpful?