Managed Messaging in Your Own Cloud: Who Operates What

Vendors use "managed", "BYOC" (bring your own cloud) and "fully managed" for different things. The useful split is two questions: who holds the pager and whose account do the brokers run in.

• DIY with support (Stages 1 and 2). Your team runs the brokers and holds the pager. A specialist responds to tickets (Stage 1) and, at Stage 2, also manages monitoring and alerts while you approve any action.
• Operated in your own cloud (Stage 3). The specialist takes the pager and runs the brokers where they already live: your AWS account, Azure subscription, Google Cloud project, Kubernetes cluster or data centre. The market often calls this placement BYOC when it describes a vendor's platform; here the operator is a team working on the broker you already run.
• Hosted (Stage 4). The provider runs the cluster in its account and gives you endpoints and a management console, the model usually sold as message queue as a service. You own no cloud account, Kubernetes cluster or on-call rota for it.

Neither of the last two is better in general. Residency rules and an existing cloud commitment usually decide it.

At AceMQ, Stages 3 and 4 cover RabbitMQ, Kafka and Redis or Valkey. IBM MQ and ActiveMQ estates are covered by 24/7 support (Stage 1) rather than by the managed stages.

The first security question is how the operator gets in. The pattern on AWS is a role in your account that the operator's account is trusted to assume. Credentials are temporary, every action lands in your CloudTrail, and you can delete the role to end access in one step. Azure and Google Cloud have equivalents.

Two details matter. First, a third party that serves many customers must use an external ID in the trust policy. AWS documents this as the defence against the confused deputy problem, where one customer tricks the provider into acting on another customer's account. The provider generates the ID, unique per customer, and you add it as a condition:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::<operator-account-id>:root" },
  "Action": "sts:AssumeRole",
  "Condition": { "StringEquals": { "sts:ExternalId": "<id-issued-by-operator>" } }
}

Second, scope the role to the job. A read-only monitoring role can exist permanently; a change role should be assumed only against an approved change, and limited to the tagged resources of the messaging estate rather than the whole account. A permission boundary or service control policy stops a mistaken grant reaching other workloads. On Kubernetes the equivalent is namespace-scoped RBAC rather than cluster-admin; on premises it is a controlled jump host with named accounts.

Ask any provider for no shared human accounts, session names that tie each action to a named engineer, and the exact policy documents for each role.

At Stage 3 the brokers stay in your private subnets, so applications keep their internal addresses and the operator works through the assumed role. A hosted service needs a private path to someone else's network. Two AWS constructs cover it, and they are not interchangeable.

• AWS PrivateLink exposes a specific service to your VPC through an endpoint, without an internet gateway, NAT device or public IP. You control which services are reachable, and no route exists between the two networks.
• VPC peering connects two whole networks. The CIDR blocks cannot overlap, routing is not transitive, and both owners must add routes. It fits two networks you control; it is a poor fit for a provider serving many customers.

Then check the broker's own rules, because each system breaks in its own way behind a load balancer or endpoint:

• Kafka clients connect to a bootstrap address, then to each broker at the address it advertises. Kafka's own documentation says advertised.listeners are the addresses published to clients and other brokers, and that they can differ from the bind addresses. A single load-balanced hostname without per-broker mapping fails after the first metadata response.
• RabbitMQ uses 5672 and 5671 for AMQP, 15672 and 15671 for the management API, and 25672 plus 4369 for inter-node communication. RabbitMQ's documentation says inter-node ports should only be reachable from the hosts that run other cluster nodes or CLI tools, never the public internet.
• Redis Cluster needs two open ports per node: the client port, usually 6379, and the cluster bus port, by default the client port plus 10000. Clients must not use the bus port, but both must be open between nodes.

Disks and snapshots: encrypt volumes with a customer managed key in your account. AWS KMS documents that for a customer managed key the key policy is exclusively controlled by you, and you can disable the key or schedule it for deletion. That gives you a revocation lever the operator cannot touch. Transport: TLS certificates and their private keys should come from your CA or certificate manager, with rotation in the runbook. Credentials: broker users and secrets belong in your secrets store. Message content: in a well-scoped Stage 3 contract the operator does not read payloads, and the contract should say so.

With a hosted service the keys sit in the provider's account by default. If you need customer-controlled keys there, make it an explicit requirement and get it written into the contract.

"Managed" hides the most disputes here. Write down, per layer, who patches, who approves the window and who tests the client side:

• Broker and runtime patches (for example RabbitMQ with Erlang, Kafka, Redis or Valkey): the operator, on a defined cadence, with a written CVE assessment for the versions you actually run.
• Major upgrades: the operator plans and executes, but they change client behaviour, so your application owners test. Typical examples are the classic-to-quorum queue migration in RabbitMQ and the ZooKeeper-to-KRaft migration that Kafka 4.x requires.
• Operating system and Kubernetes node patches: normally yours at Stage 3 unless the engagement says otherwise, which means a node reboot can land on a broker the operator thinks is stable. Agree who tells whom.
• Versions the community no longer patches: a managed contract on an old release only helps if it covers backported fixes. Ask for the coverage window before you sign.

A hosted service patches on the provider's schedule, which suits you until a frozen change window cannot take the change.

The operator needs signals; you need the same ones. Metrics and logs should land in a system you can open, such as your Prometheus, your cloud's monitoring service or your log platform. Alert thresholds and routing should be documented, so you know what pages a human and who that is. The operator's dashboards should not be a private copy you lose on exit.

At Stage 2, AceMQ adds monitoring and alerting through its observability setup and a named engineer manages the alerts. For RabbitMQ that is an in-broker plugin that watches the cluster from the inside, and no message payloads or credentials leave your cluster. At Stage 3 monitoring is deployed into your environment during onboarding, with alert routing and escalation agreed in the runbook. A hosted provider will show you its own console, so ask which metrics it exposes and whether you can export them.

At Stage 3 you pay two bills: the cloud bill for compute, storage, network and keys, and the operator's service fee. At Stage 4 the infrastructure is folded into one fee. Neither is automatically cheaper. List the drivers whoever runs the cluster: broker count and instance size, storage set by retention and replication, traffic between zones and regions, snapshot storage, private connectivity charges and the engineering time removed. For Kafka, model inter-zone traffic explicitly, because replication generates it.

Ask the provider what the fee includes (on-call, patching, upgrades, capacity reviews, change requests), what is billed separately, and to size the cloud spend you will carry yourself. Prices depend on the estate and the commitments, so this guide quotes none.

Lock-in in managed messaging comes from missing documentation, not contract terms. The test: could you take the platform back on Monday? At Stage 3 that means topology documents, runbooks and monitoring configuration are maintained as yours throughout, a current handover pack exists at any point, and ending the engagement is revoking the role, rotating secrets and handing over the pager. The brokers never moved.

At Stage 4 the data does have to move. Plan the tooling before you need it: Shovel or Federation for RabbitMQ, MirrorMaker 2 for Kafka, and replica or snapshot moves for Redis and Valkey. Ask whether the provider exports definitions, users and policies, and what the notice period is.

1. Can your team carry the pager? If yes and you want a specialist behind you, that is Stage 1. Add Stage 2 if you want early warning from inside the broker.
2. Must messages stay in your account, VPC or data centre? If yes, and you want someone else to hold the pager, that is Stage 3.
3. Do you want to own no infrastructure for messaging at all? Then Stage 4, hosted.

An estate that is already running is taken over as it is, after an assessment; moving to a hosted platform is never a precondition. The stage can also change later, because the operating work is the same.

Each technology has a managed services page with the stages in detail: RabbitMQ, Kafka and Redis and Valkey. The compare pages set hosted platforms side by side on the same criteria. Stage 3 starts with an assessment, and a written quote comes back within 24 hours.

Sources: AWS on the confused deputy problem and external IDs, PrivateLink, VPC peering limitations and AWS KMS keys; Kafka broker configuration, RabbitMQ networking and Redis Cluster ports.