Vendor lock-in occurs when proprietary features, integrations, or switching costs make migration away from a Kafka provider difficult or impractical. Managed Kafka reduces operational burden, but may limit broker configuration, upgrade control, and portability. section 9.2.1
Assess lock-in through the dependencies and costs attached to a deployment:
- Proprietary capabilities, such as RBAC, enforced schema constraints, or advanced topic mirroring, may not transfer cleanly between providers. section 9.2.1
- Tight integrations with services such as IAM, Kinesis, and CloudWatch can bind workloads to a wider cloud ecosystem. section 9.2.1
- Large replicated datasets can make egress fees alone enough to render a provider change impractical. section 9.2.1
- Hybrid deployments using MirrorMaker or Kafka Connect preserve migration and recovery options, but add latency, synchronization overhead, complexity, and cost. section 9.5
Choosing managed Kafka intentionally
A company may accept Confluent Cloud, Amazon MSK, or Aiven lock-in when seamless integrations, lower operational burden, and vendor service-level agreements matter more than near-term portability. It should document exit costs, avoid proprietary features on critical paths, and retain a minimal migration route through standard serializers and APIs. section 9.2.1
