Managed Apache Flink
Last reviewed by Tyler Eastridge
AceMQ runs your Apache Flink applications and clusters for you, so stream processing stays up without your team on call: the Flink Kubernetes Operator, checkpoint and state health, savepoint-based upgrades, scaling and the pager. We work inside your Kubernetes clusters or cloud account (Tier 3), or on infrastructure AceMQ runs (Tier 4). Amazon Managed Service for Apache Flink, Confluent Cloud for Apache Flink and Ververica suit some teams better, and this page says which.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Apache Flink consulting and services.
Customers
Partners
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
We install and operate the operator, then run FlinkDeployment and FlinkSessionJob resources through it: pod templates, high availability settings, ingress, and the operator's own upgrades, which include replacing its custom resource definitions by hand.
Checkpoint duration, size and failure rate watched against your interval, state size growth, and backpressure by operator. A checkpoint that takes longer every week is flagged before it times out, and the pager reaches an engineer who has your job graph in front of them.
Job and Flink upgrades planned as a sequence: operator uids checked, a stop-with-savepoint rehearsed on a copy, the restore verified, then the production change with the savepoint kept as the way back.
Choice between HashMap and RocksDB state against state size, incremental checkpoints where the backend supports them, and a restore drill from checkpoint or savepoint timed against your recovery objective.
Parallelism set against source partitions, task manager slots and memory against observed use, and the operator's autoscaler enabled only for jobs where a rescale is acceptable.
Service accounts and RBAC reviewed, TLS between components, secrets kept out of job configuration, and the images you run tracked against Apache releases. Access to your environment follows your change process and is logged.
Why AceMQ
Run managed Flink in your own clusters (Tier 3) when residency and compliance keep checkpoints and data in your boundary, or have AceMQ host it (Tier 4) when you want job endpoints and no infrastructure to run. The people running it are Flink specialists under an AceMQ contract, not a generic hosting provider.
AceMQ holds the contract, the SLA and escalation, and brings in partner Flink specialists as the jobs need them. A page reaches an engineer who already has your job graph, checkpoint history and runbooks. The 15-minute figure is a response time, not a resolution time.
Many Flink incidents start next to Flink: a Kafka partition that has gone idle, a sink that is not transactional, a storage bucket that throttles checkpoints. We run Flink and also work on what feeds it and what it writes to.
Savepoint, restore and upgrade runbooks, job and cluster documentation and the alert rules live in your repository. Bringing operations back in-house, or moving a job between your clusters and ours, starts from a current handover pack.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Managed Flink compared
Most people who search for managed Flink are comparing cloud services. Those are platforms: the vendor runs the engine and you work inside its rules. AceMQ's managed service is people who run open-source Flink on infrastructure you own or on ours. Each row answers one question.
| Question | AceMQ managed Flink (Tier 3 or 4) | Amazon Managed Service for Apache Flink | Confluent Cloud for Apache Flink | Ververica |
|---|---|---|---|---|
| Who runs it | AceMQ engineers with partner Flink specialists, under a contract with a 15-minute emergency response. | AWS, as a fully managed service for Flink applications. | Confluent, inside Confluent Cloud. | Ververica describes itself as built by the original creators of Apache Flink and sells its own platform. |
| Where it runs | Your Kubernetes clusters or cloud account (Tier 3), or infrastructure AceMQ runs (Tier 4). | AWS. | Confluent Cloud. | Ververica's site lists bring-your-own-cloud and self-managed deployment. |
| Which Flink | Apache Flink as released. The operator supports 1.19, 1.20 and the 2.x line and still accepts 1.15 to 1.18 as deprecated, so a job that has not moved can still be run. | AWS's documentation lists the versions it offers: check it against the version your jobs need. | No runtime version selection: Confluent runs the latest and applies patches and minor upgrades itself. | Its own VERA engine, which Ververica says is compatible with the open-source APIs. |
| What you give up | A people-based price instead of a metered console, and at Tier 3 you pay your own infrastructure bill. | Control of the runtime: you work inside the service's limits and region. | A choice of Flink version, and where the jobs run. | Running the stock Apache Flink runtime. |
| Best when | You already run Kafka and Flink on Kubernetes, need the data inside your boundary, or want one contract across Flink, Kafka and the databases. | You are on AWS, your sources are AWS services, and you want AWS to run the cluster. | Your data is in Confluent Cloud and you want SQL on it without running a cluster. | You want a vendor platform with its own engine and tooling from the Flink founders. |
Sources: aws.amazon.com/managed-service-apache-flink, docs.confluent.io (Flink overview), ververica.com and the Apache Flink Kubernetes Operator 1.16 compatibility page, all read 4 November 2026. Vendor terms change, so check them before you commit.
The Flink Kubernetes Operator
The Apache Flink Kubernetes Operator extends the Kubernetes API with custom resources for Flink applications. It reconciles a declared job toward the running cluster. A managed service starts where its automation stops.
Deploy, suspend, resume, upgrade and delete jobs. Application clusters when a FlinkDeployment has a job, session clusters when it does not, and FlinkSessionJob to submit into one. Standby JobManagers through Flink's Kubernetes HA, and an autoscaler that adjusts parallelism.
Which upgrade mode is safe for this job, whether a checkpoint that takes four minutes is a problem, whether the sink is transactional, which state backend fits, or why a watermark has stopped moving. Those are operating decisions.
The operator's own upgrade replaces the custom resource definitions with kubectl by hand: the docs say this step is not part of the Helm install. A new operator release can also reject a Flink version it no longer supports at validation, so the order of upgrades matters.
The operator 1.16 compatibility page lists Flink 1.19, 1.20 and the 2.x line as supported, 1.15 to 1.18 as deprecated and 1.13 and 1.14 as rejected. We check every flinkVersion in your resources before an operator upgrade, not after.
The operator's FlinkBlueGreenDeployment and FlinkStateSnapshot resources are marked experimental in its 1.16 custom resource documentation, so we use them where you ask for them and say so in the plan.
Upgrades
The operator offers three upgrade modes. Choosing between them is the part of managed Flink that goes wrong quietly, because every mode works until the state does not restore.
Cancel with a savepoint, then restore from it. The job has to be running. This is the mode for planned changes where state must survive exactly, and the savepoint doubles as the rollback point.
Restore from the latest checkpoint or HA metadata. It works on a job that is already failing, which is why it is the recovery mode, but it depends on high availability being on and checkpoints being recent.
Start with empty state. Right for jobs that rebuild from the source, wrong for a job whose state took a week to build.
Explicit operator uids on every stateful operator, because without them a changed job graph cannot map state back. Savepoint compatibility is checked against the Flink docs, which cover the data format and not SQL semantic changes, so SQL jobs get a rehearsal on a copy.
Flink 2.3.0 was released on 25 June 2026. The community policy supports the current and previous minor release with bugfixes, so a plan that stays two minors behind is a plan to run unfixed code. Flink Kubernetes Operator: what it automates and what you still run
On-call
Flink incidents arrive as symptoms in the checkpoint and watermark metrics before they arrive as lost data. These are the ones the pager is for.
Checkpoints that run longer than the interval, then fail. We separate a slow sink or skewed operator from state size growth, and from storage that cannot keep up, before changing the interval or the timeout.
One slow operator stalls everything upstream. We find it by operator, then decide between a parallelism change, a fix to the slow call and a different sink strategy.
An idle source partition holds the watermark back and windows never fire. The fix is an idleness setting or a source change, not a restart.
State that grows without a time to live, and a restore that takes longer than your recovery objective. RocksDB is limited by disk rather than memory and offers incremental checkpoints, which must be turned on.
A 15-minute response is a response time, not a resolution time. Every P1 ends with a written root-cause analysis.
Tier 3 and Tier 4
With support (Tiers 1 and 2) your team carries the Flink pager and AceMQ answers and reviews. With managed services (Tiers 3 and 4) AceMQ carries it. Both managed tiers do the same operational work; they differ in whose Kubernetes the jobs run on and who pays for it.
AceMQ operates Flink in your Kubernetes clusters or cloud account, with system access and your change process. You keep the clusters, the object storage for checkpoints, the data and the infrastructure bill.
AceMQ hosts and operates Flink on infrastructure it runs, with the operator, checkpoint storage and upgrades included. You get job submission and monitoring, not clusters or an on-call rota.
A managed Flink service runs the jobs, not the Kafka cluster behind them or the code in them. AceMQ can run Kafka too, under a separate managed contract.
A common path is a support contract and a review of checkpoints and state, then a job-by-job handover. Tier 3 or 4 does not need a big-bang cutover.
The two support tiers are described on the Flink support page. Apache Flink support: 24/7, 15-minute SLA
Choosing honestly
A cloud service is the right answer for some jobs. These are the differences that decide it.
Your sources and sinks are AWS services, you have no wish to run a cluster, and the Flink version AWS offers is the one your jobs need.
The data already lives in Confluent Cloud and the work is SQL over topics. You accept Confluent choosing the Flink version.
You want a vendor platform with its own engine and tooling, and a supplier whose business is Flink.
You already run Flink or Kafka on Kubernetes, need data and checkpoints inside your own boundary, need a Flink version a cloud service does not offer, or want one contract for Flink, Kafka and the databases beside them.
What none of them removes: the job code, the state design and the sink semantics belong to whoever owns the pipeline.
Price drivers
Managed Flink is quoted, not listed. These are the inputs, and the written quote comes back within 1 hour of your request.
How many jobs and clusters, how much state, how much parallelism, and which are production.
The state backend, the checkpoint interval and the recovery objective, which set the checkpoint, savepoint and restore-drill work.
Business-hours cover, or 24/7 on-call with the 15-minute emergency response.
Tier 3: your cloud bill for the clusters plus AceMQ's fee for operating them. Tier 4: infrastructure included in the AceMQ quote. A Flink minor upgrade that is already due is priced as a scoped item.
Not a fit for
We would rather say so up front.
Managed Flink from AceMQ is a contract with senior engineers behind it. If you want a job running in minutes with no contract, AWS and Confluent sell exactly that.
Stream processing design, event-time semantics and job code are consulting, which sits on the Flink page. They can lead into a managed contract.
Rewriting your own services is out of scope. AceMQ operates Flink and works with the team that owns the pipeline.
A handful of bounded jobs on a schedule need a current version and monitoring, not a managed service.
Running several engines? One contract can also cover Kafka, PostgreSQL and more. Managed Kafka services
Escalation Path
Every tier reaches a senior Apache Flink engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Typical engagements
Typical Apache Flink support, remediation and consulting engagements. Each card links to the full write-up: the streaming jobs, what the engagement covers and what it delivers.
Global Payments Processor
Resolving checkpoint timeouts under backpressure where RocksDB state has grown past what the configured checkpoint interval can absorb.
Apache Flink
Apache KafkaRocksDB
KubernetesConnected Vehicle Telematics Provider
Diagnosing event-time windows that stop firing because a single idle source partition holds the watermark back across the whole job.
Apache FlinkApache KafkaKubernetesSmart Grid Technology Provider
Evaluating whether a proposed streaming workload belongs on Flink, and what the exactly-once, state, and operational requirements will really cost.
Apache FlinkApache KafkaKubernetes
RedpandaData Platform Team
A typical Tier 3 engagement: AceMQ runs Apache Flink jobs on the customer's own Kubernetes clusters with the Flink Kubernetes Operator, owning checkpoint health, savepoint-based upgrades and the pager.
Apache FlinkKubernetesKafkaRocksDBRegional Insurer
What a platform review covers when several teams want streaming and nobody has decided which broker, processor and operating model the company will run.
KafkaApache Flink
DebeziumOnline Fraud Detection Platform
Designing state backend, key partitioning, and rescaling strategy for large-state Flink jobs that must restart without hours of downtime.
Apache FlinkRocksDBApache KafkaKubernetesSupport options
AceMQ offers Apache Flink support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for jobs your team runs, proactive monitoring that catches checkpoint, state and CVE problems first, managed Flink on your own infrastructure, and fully managed Flink on AceMQ infrastructure. Kubernetes, YARN and standalone deployments are covered in all four.
You run it, we back you up
Best for: Teams that run Flink themselves and need senior cover when a job will not stay up.
You run it, we watch it with you
Best for: Job estates where a slow creep in checkpoint time must be caught before it becomes an outage.
We run it in your cloud or data centre
Best for: Regulated estates that must keep streaming state and data inside their own boundary.
We host it and run it, as a service
Best for: Teams that want to run Flink jobs without owning clusters, state storage or a rota.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Apache Flink day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Apache Flink
Support is one part of what AceMQ does for Apache Flink. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Yes. Tier 3 runs in your clusters or cloud account, including on premises and air-gapped sites, using your access controls and change process. AceMQ works with system access, inside that change process and logged. We use the Apache Flink Kubernetes Operator because it is the project's own way to declare, upgrade and recover jobs on Kubernetes. Tier 4 is the alternative when you would rather run no infrastructure.
By choosing the upgrade mode for that job. A planned change uses a savepoint: stop the job with one, upgrade, restore from it, and keep it as the way back. A failing job is recovered from the last checkpoint. Every stateful operator needs an explicit uid first, and SQL jobs are rehearsed on a copy because savepoint compatibility covers the data format, not changes in SQL semantics.
Yes. AceMQ works on Apache Flink in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Managed Apache Flink is quoted per scope, with no list price: the price depends on the number of environments and nodes, the SLA, whether AceMQ runs Apache Flink on your infrastructure (Tier 3) or on ours (Tier 4), and the access and change process you need. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Apache Flink for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email an Apache Flink Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
