Skip to main content
Solution: Full backup architecture on AWS

Kafka backup on AWS, built from parts you already run

MSK keeps brokers healthy; it does not keep yesterday's data. Wire one backup path — cluster to compute to S3 — with IAM roles instead of static keys, and every topic becomes restorable to a millisecond.

The Kafka backup on AWS architecture

Kafka backup on AWS is three decisions, not thirty: where the backup process runs, how it authenticates to the cluster, and how the S3 bucket is laid out. The pattern below works for Amazon MSK and for self-managed Kafka on EC2 alike.

Run the backup on EC2 or EKS inside the same VPC as the brokers. Reads stay on the private network, and the process picks up credentials from the instance profile or IRSA service account — no static AWS keys to rotate or leak. Backups land in an S3 bucket in the same region, outside the cluster's failure domain.

Building blockChoiceWhy
ComputeEC2 or EKS in the brokers' VPCPrivate network reads, IAM role credentials
Cluster authSASL/SCRAM (port 9096) or mutual TLS (port 9094)The two auth paths MSK exposes and the tool supports
S3 accessInstance profile or IRSANo access_key/secret_key in config
Bucket layoutOne bucket, per-cluster prefixesClean IAM scoping and lifecycle rules
RetentionS3 lifecycle to STANDARD_IA, then GLACIEROld backups get cheap without a second system
DR copyS3 cross-region replicationBucket-level replica in a second region
MSK over SASL/SCRAM, S3 via IAM role
mode: backup
backup_id: "msk-prod-aws"

source:
bootstrap_servers:
- b-1.mymsk.abcd12.c2.kafka.us-east-1.amazonaws.com:9096
- b-2.mymsk.abcd12.c2.kafka.us-east-1.amazonaws.com:9096
security:
security_protocol: SASL_SSL
sasl_mechanism: SCRAM-SHA512
sasl_username: ${MSK_SCRAM_USER}
sasl_password: ${MSK_SCRAM_PASSWORD}
# Recommended for cloud Kafka services
connection:
tcp_keepalive: true
keepalive_time_secs: 60
keepalive_interval_secs: 20
topics:
include:
- "*"
exclude:
- "__consumer_offsets"

storage:
backend: s3
bucket: my-kafka-backups
region: us-east-1
prefix: msk/production
# No access_key/secret_key — instance profile or IRSA supplies credentials

backup:
compression: zstd
include_offset_headers: true
consumer_group_snapshot: true

Why replication inside AWS is not the backup

MSK replicates every partition across brokers, and MSK Replicator can mirror whole clusters between regions. Both copy faithfully — including the topic a bad deploy just corrupted or the one someone deleted. Point-in-time backup is the layer that remembers the state from before the incident; the MSK Replicator comparison walks the distinction.

The backup captures records with timestamps and headers, consumer group offsets, and topic configuration, compressed with Zstd. Restores target the original cluster or a new one — another region or another account — and stop at a precise millisecond. For durability past the first month, S3 lifecycle rules tier old backups to STANDARD_IA and GLACIER, and cross-region replication keeps a second-region copy without any extra backup infrastructure. The AWS S3 setup guide has the exact bucket, lifecycle, and replication commands.

Frequently asked questions

What does a Kafka backup architecture on AWS look like?

A backup process on EC2 or EKS in the same VPC as the cluster, reading topics over MSK’s SASL/SCRAM or mutual TLS listeners, and writing compressed backups to an S3 bucket in the same region. IAM roles supply the S3 credentials, lifecycle policies handle retention tiering, and S3 cross-region replication provides the DR copy.

Do I need static AWS access keys to back up Kafka to S3?

No. On EC2 the tool uses the instance profile; on EKS it uses IAM Roles for Service Accounts (IRSA). Leave access_key and secret_key out of the storage config entirely. The only secrets left are the Kafka credentials, which can come from environment variables.

How does the backup authenticate to Amazon MSK?

As a standard Kafka client, using whichever listener your cluster exposes: SASL_SSL with the SCRAM-SHA512 mechanism on port 9096, or mutual TLS with a client certificate on port 9094. Credentials typically live in AWS Secrets Manager and reach the config through environment variables.

Does this work for self-managed Kafka on EC2, not just MSK?

Yes. The architecture is identical — only the bootstrap servers and the security block change to match your listeners. Self-managed clusters can also use PLAIN or SCRAM-SHA256 SASL mechanisms if that is how they are configured.

How do I get a multi-region Kafka backup on AWS?

Enable S3 cross-region replication on the backup bucket. The backup itself stays a single in-region job; S3 maintains the second-region copy asynchronously. In a regional failover, restore from the replica bucket to a new cluster and reposition consumer groups from the backed-up offsets.

Ready to protect your Kafka data?

Take your first backup in minutes with the open source CLI, or talk to us about Enterprise features like encryption, RBAC, and audit logging.