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 block | Choice | Why |
|---|---|---|
| Compute | EC2 or EKS in the brokers' VPC | Private network reads, IAM role credentials |
| Cluster auth | SASL/SCRAM (port 9096) or mutual TLS (port 9094) | The two auth paths MSK exposes and the tool supports |
| S3 access | Instance profile or IRSA | No access_key/secret_key in config |
| Bucket layout | One bucket, per-cluster prefixes | Clean IAM scoping and lifecycle rules |
| Retention | S3 lifecycle to STANDARD_IA, then GLACIER | Old backups get cheap without a second system |
| DR copy | S3 cross-region replication | Bucket-level replica in a second region |
- backup.yaml
- IAM policy
- Run it
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
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": ["s3:ListBucket", "s3:GetBucketLocation"],
"Resource": "arn:aws:s3:::my-kafka-backups"
},
{
"Sid": "ObjectOperations",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::my-kafka-backups/*"
}
]
}
kafka-backup backup --config backup.yaml
kafka-backup list --path s3://my-kafka-backups/msk/production
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.