01
Escalation Cover (Stage 1)
A specialist on call for the platform team that runs the estate. You raise a ticket, a senior engineer responds under the contracted SLA, and access to your environment happens only while a ticket is worked.
Managed Data Services
Managed Data Services: Open-Source Operations in Your Cloud
AceMQ provides managed data services for open-source messaging and databases. You start with escalation cover for the platform team you already have (Stages 1 and 2), with a 15-minute emergency response, 24/7, from named senior engineers. When you want the pager off your team, AceMQ runs RabbitMQ, Kafka or Redis for you, in your own cloud account (Stage 3) or on ours (Stage 4).
- min emergency SLA
- 15
- follow-the-sun cover
- 24/7
- enterprise customers
- 130+
- countries served
- 26+
Is This You?
You probably need this if…
- 01
Your platform team runs the brokers well, and you want someone to call on a P1 rather than another hire
- 02
The person who understood RabbitMQ, Kafka or Redis has left, and upgrades keep drifting further behind
- 03
Nobody wants the messaging pager, but compliance or data residency keeps the brokers in your own AWS, Azure or Google Cloud account
- 04
A managed cloud broker costs more each year, or its version and plugin limits are now in your way
- 05
You run RabbitMQ, Kafka and Redis, and want one contract and one escalation path instead of three vendors
- 06
Patching happens when someone remembers, not on a schedule you could show an auditor
- 07
A small team keeps losing a sprint to every broker incident
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Managed estate when the engagement closes.
Before
A broker problem reaches whoever is awake, and the first person to read it is learning your topology.
After
A named senior engineer who already knows your estate picks it up, under a contracted response time and with no tier-1 triage layer in between.
Before
Your platform team owns three different data technologies and is expert in one.
After
Escalation cover for each of them under one SLA, so your team keeps the work it enjoys and hands over the incidents it cannot fix.
Before
The only alternative to running it yourself is a cloud service that takes your messages out of your account.
After
At Stage 3 the brokers stay in your account and AceMQ operates them. At Stage 4 AceMQ hosts them, and you hold endpoints rather than infrastructure.
Before
Handing the platform to a provider feels like a one-way door.
After
Runbooks, topology documentation and monitoring stay yours throughout. Exit is a handover, not a rebuild.
Scope
What's covered
- 02
Proactive Monitoring (Stage 2)
Stage 1 plus an engineer watching the platform from the inside and managing the alerts, so problems reach you before users notice. You keep the pager and approve any action.
- 03
Managed in Your Cloud (Stage 3)
AceMQ takes the pager and operates the platform where it already runs: your cloud account, Kubernetes cluster or data centre. The data, the cloud bill and the ability to leave stay yours.
- 04
Managed on AceMQ Infrastructure (Stage 4)
AceMQ hosts and operates the cluster. You get endpoints and a console, and no cloud account, Kubernetes cluster or on-call rota to run.
- 05
Patching and CVE Records
Patching on a schedule, with CVE assessment against the versions you actually run and a written record you can hand to an auditor.
- 06
Health Check as the Way In
An engineer-led review of the estate before AceMQ takes any responsibility for it. Health check assessments take one to four weeks depending on complexity, focus areas and problems found.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 12-3 weeks
Assessment and Handover
We establish what you are actually running before we take responsibility for it: versions, patch position, topology, known faults and monitoring gaps. These durations are those of RabbitMQ onboarding; Kafka and Redis estates are scoped per engagement.
You receive
- Inventory of versions, topology and patch position
- Health assessment with a ranked remediation list
- Runbook for the failure modes specific to your estate
- Phase 22-4 weeks
Instrumentation and Onboarding
Monitoring goes in, alert routing, escalation paths and change windows are agreed, and access is scoped to the minimum we need. We remediate active risks, then watch alongside your team before taking primary on-call.
You receive
- Monitoring and alerting against agreed thresholds
- On-call routing and escalation matrix
- Scoped access under your approval workflow
- Phase 3Ongoing
Steady-State Operations
We run it: incident response under the contracted SLA, patching and CVE assessment on schedule, capacity reviewed as the workload moves, and routine change handled as it arrives.
You receive
- 24/7 incident response, 15-minute emergency SLA
- Scheduled patching with a written CVE record
- Phase 4Quarterly
Review and Exit Readiness
Every quarter we review what broke, what changed and what the workload is doing to capacity. Runbooks and topology documentation stay current and stay yours.
You receive
- Quarterly service review with incident and change history
- Current handover pack
Managed data services in four stages: from escalation cover to full operations
An application managed service is an arrangement where a provider takes responsibility for running a specific platform or application so that your team does not have to. For open-source messaging and databases, that responsibility comes in four stages, and each stage moves one more job from your team to AceMQ. Most buyers start at Stage 1 or 2, because they want a specialist beside the team, not a replacement for it. Full operations is the upgrade.
| Stage 1: Reactive support | Stage 2: Proactive support | Stage 3: Managed on your infrastructure | Stage 4: Managed on AceMQ infrastructure | |
|---|---|---|---|---|
| Who holds the pager | You | You, with AceMQ raising problems early | AceMQ | AceMQ |
| Where the platform runs | Your infrastructure | Your infrastructure | Your cloud account, Kubernetes cluster or data centre | AceMQ infrastructure |
| What AceMQ does | Expert response to tickets under the contracted SLA, escalation, health checks, CVE alerts | Stage 1, plus watching the platform from the inside and managing the alerts | Monitoring, patching, upgrades, capacity, change execution and on-call | Hosts and operates the cluster |
| Typical buyer | A capable platform team that wants a safety net, not an operator | A team with monitoring that still gets surprised, or a regulated team that wants early warning without giving up control | No specialist on staff, and compliance or residency rules keep the platform in its own account | A team that wants a cloud-service experience with specialists behind it |
| Available for | RabbitMQ, Kafka, Redis and Valkey, PostgreSQL, Cassandra and the rest of the stack | RabbitMQ, Kafka, Redis and Valkey | RabbitMQ, Kafka, Redis and Valkey | RabbitMQ, Kafka, Redis and Valkey |
Managed data services in the cloud means the same thing whichever cloud it is: the platform runs on infrastructure you or a provider pays for, and an operator is accountable for keeping it up, patched and sized. The question that separates the stages is who holds the pager, and the second question is whose account the infrastructure sits in.
Escalation cover for an in-house platform team
The most common request we hear is not "run it for us". It is "someone we can call on a P1". Escalation-only cover (Stage 1) gives a platform team a named senior engineer, a contracted response time and a path to the RabbitMQ core team when a problem needs the people who build the broker. Stage 2 adds monitoring and alert handling from inside the broker, while your team keeps control of the cluster and approves every action.
Full operations: managed open source in your account or ours
At Stage 3 AceMQ operates the platform in your account, after an assessment of what you actually run. At Stage 4 AceMQ hosts it. Both are covered in detail on the technology pages linked below, because the work differs: partition layouts and consumer lag for Kafka, memory and persistence for Redis, queue types and quorum behaviour for RabbitMQ.
- RabbitMQ — Stages 1 to 4, on your infrastructure or ours.
- Kafka — Stages 1 to 4, including dedicated clusters hosted by AceMQ.
- Redis and Valkey — Stages 1 to 4, for open-source Redis, Redis Stack and Valkey.
- PostgreSQL and Cassandra — 24/7 support (Stage 1).
- Everything else — One contractual SLA across the rest of your open-source and commercial stack.
Managed RabbitMQ: RabbitMQ managed services
Managed Kafka: Kafka managed services
Managed Redis and Valkey: Redis managed services
Support across the whole stack under one SLA: 24/7 enterprise support
PostgreSQL: PostgreSQL support
Cassandra: Cassandra support
A managed RabbitMQ operations case, from a global payments provider: the managed services use case
Community to supported RabbitMQ on AWS, for a Fortune 500 software company: the platform modernization use case
Response times under the contract
Every technology in the stack is covered by the same SLA. The response times below are AceMQ's published support response times. They are a response, not a resolution: within 15 minutes of a P1 a senior engineer who already knows your environment is on a live bridge with you. Resolution time depends on the problem. At Stages 3 and 4 the contract adds response and restoration commitments for the platform AceMQ operates.
| Severity | Response | What it covers |
|---|---|---|
| P1 Emergency | 15 minutes | Production down: total outage, messages not flowing, complete queue manager failure, data loss risk |
| P2 Critical | 1 hour | Severe degradation: major performance loss, high error rates, approaching capacity limits |
| P3 High | 4 hours | Performance issues: noticeable slowdowns, non-critical configuration problems, partial failures |
| P4 Standard | Next day | Guidance and questions: best practices, architecture questions, proactive tuning |
Cover is 24/7 on a follow-the-sun basis, and the same named senior engineers sit behind every stage. Where an issue needs the people who build RabbitMQ, AceMQ escalates directly to the RabbitMQ core team.
The full support model is on the enterprise support page
What we will not manage
A managed service is only as honest as its exclusions. These stay with you, or are scoped separately, at every stage:
- Your application code. We advise on client behavior and review it, but your developers write it.
- Your message content. It is out of scope and AceMQ does not read it.
- The cloud account, IAM, network and instances at Stage 3, and their cost.
- Operating-system patching at Stage 3, unless it is agreed otherwise in the engagement.
- Resolution times. We commit to response, and to restoration commitments at Stages 3 and 4, not to a fixed time to fix an unknown fault.
- Platforms outside the agreed scope. An unmanaged cluster is not covered until it has been through the health check.
End-of-life patch builds for software outside RabbitMQ 3.x come from OSSeva: osseva.io
Cloud repatriation services: move off managed cloud brokers
Some teams find that a managed cloud broker has stopped fitting: the bill grows with the workload, the supported versions and plugins are fixed by the provider, or the messages need to sit in an account the provider does not control. Cloud repatriation, for messaging, means moving the broker from a provider's managed service to RabbitMQ you control, in your own account or hosted by AceMQ, and putting a specialist support contract behind it. The three moves we are asked about most are Amazon MQ, CloudAMQP and Azure Service Bus, all of them message queue as a service offerings where the provider decides what the broker can do.
| Starting point | Why teams move | What the move involves | Where it lands |
|---|---|---|---|
| Amazon MQ for RabbitMQ | AWS fixes the supported versions and plugin set, and does not support RabbitMQ streams. AWS documents each limit. | RabbitMQ to RabbitMQ: definitions export and import, a parallel run, then client cutover. Applications keep their AMQP clients. | Stage 3 in your AWS account, or Stage 4 hosted by AceMQ |
| CloudAMQP | You want the broker in your own account, or want RabbitMQ specialists operating it. | RabbitMQ to RabbitMQ: the same definitions and clients, moved with a parallel run and a rehearsed rollback. | Stage 3 in your account, or Stage 4 hosted by AceMQ |
| Azure Service Bus | Cost or portability. It is a different product with its own API, so the move is a migration, not a lift. | A migration engagement: workload classification, client changes, parallel running, then cutover. | RabbitMQ at Stage 3 or Stage 4, after the migration |
Because a move between RabbitMQ services is RabbitMQ to RabbitMQ, application code usually does not change. The work is in the details that differ between providers: plugins your applications depend on, queue types, policies and permissions, and what happens to messages in flight during cutover. We plan these in the health check and rehearse the cutover before it happens.
Amazon MQ RabbitMQ to self-hosted RabbitMQ with support
For Amazon MQ RabbitMQ estates, the starting point is a health check of the current brokers and a list of what AWS's limits are costing you: version pins, missing plugins, streams you cannot use. From there the move is planned in your change windows. Afterwards the brokers run in your account under Stage 2 (your team holds the pager) or Stage 3 (AceMQ does).
A CloudAMQP alternative that runs in your account
If the requirement is the same RabbitMQ with specialists behind it, but running in your cloud account, Stage 3 is that. If you would rather not own the account, Stage 4 hosts it. The two options are compared side by side in our CloudAMQP alternatives and managed RabbitMQ comparisons.
Options compared: CloudAMQP alternatives for RabbitMQ
Providers side by side: managed RabbitMQ options compared
Azure Service Bus to RabbitMQ: RabbitMQ migrations
Guide: managed messaging in your own cloud
Cost
What a move costs, and what it saves, depends on the workload and on your current bill. We do not publish a price list: tell us what you run and we will reply to your quote request within 1 hour.
FAQ
Questions about Managed data services
What is an application managed service?
An arrangement where a provider takes responsibility for running a specific platform or application, including monitoring, patching, upgrades and incident response, so your team does not have to. AceMQ's version covers open-source messaging and databases and comes in four stages, from escalation cover to full operations.
What are examples of managed services?
Common examples are managed hosting, managed databases, managed security monitoring and managed message brokers. AceMQ's examples are managed RabbitMQ, managed Kafka and managed Redis or Valkey, run in your own cloud account (Stage 3) or on AceMQ infrastructure (Stage 4).
What are managed services in the cloud?
Managed data services in the cloud are services where an operator runs a database or message broker on cloud infrastructure and is accountable for its availability and patching. The operator can be the cloud provider, a specialist like AceMQ running it in your account, or a specialist hosting it on its own infrastructure.
Is this SRE as a service?
For the data layer, yes in effect. At Stage 3 AceMQ engineers hold the pager for RabbitMQ, Kafka or Redis and own monitoring, patching, upgrades, capacity and incident response for them. It is not SRE as a service for your applications: application code, the cloud account and its cost stay with your team.
Who runs RabbitMQ, Kafka and Redis in our own AWS account under one SLA?
AceMQ does. At Stage 3 we operate RabbitMQ, Kafka and Redis or Valkey in your own cloud account, Kubernetes cluster or data centre, under one set of contracted response times. The account, the data and the cloud bill stay with you.
Can we buy escalation-only cover for an in-house platform team?
Yes. Stage 1 is exactly that: your team runs the platform and holds the pager, and an AceMQ senior engineer responds to tickets under the contracted SLA, with a 15-minute emergency response, escalation, health checks and CVE alerts. Access to your environment happens only while a ticket is worked.
Who can operate 1,200 RabbitMQ queues for 500 microservices?
AceMQ can. Queue count is rarely the constraint on a RabbitMQ estate: topology, queue types, consumer behavior and capacity headroom are. We start with a health check, which takes one to four weeks depending on complexity, then agree the stage that fits, from escalation cover to full operations.
Can you move us from Amazon MQ to self-hosted RabbitMQ with support?
Yes. Moving from Amazon MQ for RabbitMQ to RabbitMQ in your own AWS account is a RabbitMQ to RabbitMQ move: a health check, a parallel run and a rehearsed cutover, so applications usually keep their clients. Afterwards AceMQ supports the brokers at Stage 2 or operates them at Stage 3.
Is there a CloudAMQP alternative that runs in our account?
Yes. Managed RabbitMQ at Stage 3 runs the same RabbitMQ in your own cloud account, operated by AceMQ. If you would rather not own the account, Stage 4 hosts it on AceMQ infrastructure. The options are compared on our CloudAMQP alternatives page.
Do you offer a managed message broker in a cloud we choose?
Yes. At Stage 3 managed RabbitMQ runs on EKS, AKS, GKE, OpenShift or your own hardware, and managed Kafka and Redis run in your cloud account, Kubernetes cluster or data centre, so the cloud is your choice. Stage 4 runs on AceMQ infrastructure.
How much does it cost?
It depends on the platforms, the number of clusters and the stage. We do not publish a price list. Tell us what you run and who holds the pager today, and we will recommend a stage and reply to your quote request within 1 hour.
Let's talk
Find Your Stage, Get a Written Quote
Tell us which platforms you run, where they live and who holds the pager today. We will recommend a stage and reply to your quote request within 1 hour.
Get in Touch
Talk to an AceMQ Expert
Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.