Skip to main content
Qovery creates it in the AWS account of the environment’s cluster, as a Blueprint service in one of your environments.
New to this? You don’t need to know Kubernetes or Terraform. Qovery sets up Amazon MSK in your cloud account and manages it for you: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment.

Create it

  1. Open the environment, then New service › Blueprint.
  2. Find Amazon MSK in the catalog and pick the major version.
  3. Fill in the variables. Required ones are marked; the others use their defaults.
  4. Create the service, and deploy it now or later.
You don’t add any file to your repository. Qovery creates the Blueprint from the Console or the API.

Variables and outputs

Generated from qbm.yml at AWS/msk/default/1.0.8, the manifest the Console form is built from.
Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint’s name; see Aliases Qovery creates for outputs for the naming rules and the cases where no alias is created.

Reference

From the Blueprint’s README. Provisions an Amazon MSK Serverless cluster (aws_msk_serverless_cluster) — managed Apache Kafka with no broker sizing — via hashicorp/aws (~> 5.0).

Credentials & networking

Uses the Qovery cluster’s AWS credentials (credentials.default: cluster). By default the cluster attaches to the Qovery cluster network: the cluster VPC subnets and workers security group are auto-discovered via the ClusterId tag (like the managed RDS blueprints), so in-cluster apps can reach it. Override with subnet_ids / security_group_ids on clusters where the tag lookup doesn’t resolve (user-provided VPC).

Variables

Required

Network overrides

Outputs

Notes

  • Auth is SASL/IAM only (MSK Serverless requirement): clients authenticate with their AWS IAM identity — no static passwords. The consuming workload’s IAM role needs kafka-cluster:* permissions scoped to the cluster ARN/UUID, and its security group must be allowed by the cluster SG on the Kafka ports.
  • MSK Serverless does not create networking; it attaches to existing subnets/SG (auto-discovered here).
  • Billed per-throughput + storage (no idle broker-hour cost, unlike provisioned MSK).

Required AWS IAM permissions (to deploy)