Amazon MSK Connect Can Now Pause and Resume Connectors
AWS now lets you pause and resume MSK Connect connectors in place, keeping config, capacity and committed offsets. Here is what changes and what to do this week.
6 min read
Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.
The announcement
On October 22, 2026, AWS announced that Amazon MSK Connect now supports pausing and resuming connectors. You can stop a running connector from processing records, then resume it later in place, without tearing anything down.
Until now, the only way to pause a connector on MSK Connect was to delete it and create it again. AWS's own announcement calls that "a more disruptive operation, adding risk and operational overhead." The new option costs nothing extra and works through the MSK Console, AWS CLI, AWS SDK and AWS CDK, in every AWS Region where MSK Connect is available.
Key takeaways
- You can now pause and resume an MSK Connect connector instead of deleting and recreating it.
- A paused connector keeps three things: its configuration, its capacity settings and its committed offsets.
- On resume, tasks continue from the offsets they last committed.
- It is available at no additional cost.
- It works in 4 places: the MSK Console, AWS CLI, AWS SDK and AWS CDK, in all Regions where MSK Connect runs.
What is Amazon MSK Connect, in one paragraph?
Amazon MSK Connect is the managed version of Apache Kafka Connect that sits next to Amazon MSK, AWS's managed Kafka. In AWS's words, it is "a fully managed service that allows you to deploy, monitor, and scale Apache Kafka Connect connectors." Connectors are the pieces that move data in and out of Kafka. A source connector pulls from something like a database and writes to a topic. A sink connector reads from a topic and writes to a target.
If you run data pipelines on AWS and you use Kafka, there is a good chance a few of these are running right now, quietly copying rows from one place to another.
Why does pausing a connector matter to a developer?
Because the thing a connector talks to is never up 100 percent of the time.
Your source database needs a patch. Your sink target is getting a schema change. Something upstream starts sending garbage and you want to stop the bleeding while you look. Those are exactly the kinds of cases AWS lists: maintenance on a source database or a sink target, or investigating an upstream or downstream issue.
In every one of those moments, you want the same thing. Stop the data flow now. Start it again later, from the same spot, with nothing else changed.
On MSK Connect, that used to mean deleting the connector. Then, when you were ready, creating it again. I want to be honest about what that feels like at 2am during an incident. You are rebuilding a connector definition while also trying to fix the real problem. Every field you have to rebuild is a field you can get wrong.
AWS describes the old path as adding "risk and operational overhead." That is the polite version.
What does a paused connector actually keep?
This is the part of the announcement worth reading twice. Here is everything AWS says survives a pause:
| What | On pause | On resume |
|---|---|---|
| Configuration | Kept | Same configuration |
| Capacity settings | Kept | Same capacity |
| Committed offsets | Kept | Tasks continue from the offsets they last committed |
| Extra cost | None | None |
| Where you can do it | Console, CLI, SDK, CDK | Console, CLI, SDK, CDK |
Three things stay put: configuration, capacity and offsets. That is the whole connector, minus the act of processing records. The resume happens in place, so you are working with the same connector, not a new one built to look like the old one.
What changes in practice?
Here is the before and after for the two scenarios AWS calls out.
Planned maintenance on a source or sink.
- Before: delete the connector, do the maintenance, recreate the connector with the same settings, and check it picked up where it should.
- Now: pause the connector, do the maintenance, resume it.
Investigating an upstream or downstream problem.
- Before: either let data keep flowing while you investigate, or delete the connector and accept the rebuild later.
- Now: pause it the moment something looks wrong, investigate with the flow stopped, resume when you are confident.
That second one is the bigger shift in my view. When stopping a pipeline is expensive, people hesitate. They let it run "for a few more minutes" while they figure out what is going on. When stopping is cheap and reversible, you can pause first and think second. That is a better default during an incident.
Two things I would keep in mind. These come from reading the announcement closely, not from anything extra AWS has said:
- The word is "committed." AWS says tasks continue from the offsets they last committed. Committed is not the same as "the last record I saw go through." If your sink cannot handle seeing a record twice, test a pause and resume before you rely on it in production.
- Paused does not mean the world stops. The rest of your system keeps running. Whatever piles up while a connector is paused is waiting for it when you resume, so plan maintenance windows with that catch-up in mind.
Neither of these is a reason to avoid the feature. They are reasons to try it on a quiet day first.
Where can you pause and resume a connector?
AWS lists four ways in:
- Amazon MSK Console, for the click-through version.
- AWS CLI, for scripts and runbooks.
- AWS SDK, for building it into your own tooling.
- AWS CDK, for teams that define infrastructure as code.
The announcement does not include command names or code samples, so I am not going to guess them here. The Amazon MSK Connect documentation, linked from the announcement, is where you get the exact calls.
It is available in all AWS Regions where MSK Connect is available, at no additional cost.
What should you do this week?
Here is a short, practical list. None of it takes long.
- Find your delete-and-recreate runbooks. Search your wiki, scripts and incident notes for anywhere a connector gets deleted just to stop data flow. Those are the places this feature replaces.
- Try one pause and resume on a non-critical connector. Pick a dev or staging connector. Pause it, wait a few minutes, resume it, and watch what the tasks do. You want to see this once before you need it.
- Check how your sink handles a repeat record. Because resume works from the last committed offsets, confirm your target is fine if it sees the same record again.
- Rewrite the maintenance runbook. Replace "delete connector" and "recreate connector" with "pause" and "resume." Shorter runbooks get followed. Longer ones get skipped.
- Add pause to your incident playbook. Make "pause the connector" an early step when something upstream or downstream looks wrong, not a last resort.
- If you use CDK or SDK tooling, look up the new calls in the docs. Wire them into whatever you already use so the next person does not reach for the console under pressure.
If you only do one thing, do number 2. A feature you have never tried is not a feature you will trust at 2am.
FAQ
Can I pause an Amazon MSK Connect connector now?
Yes. AWS announced on October 22, 2026 that MSK Connect supports pausing and resuming connectors. You can temporarily stop a connector from processing records and resume it in place later.
Does a paused MSK Connect connector lose its offsets or settings?
No. According to AWS, a paused connector keeps its configuration, capacity settings and committed offsets. When you resume, its tasks continue from the offsets they last committed.
How much does pausing and resuming connectors cost?
Nothing extra. AWS says the capability is available at no additional cost, in all AWS Regions where Amazon MSK Connect is available.
How did you pause an MSK Connect connector before this?
You had to delete the connector and recreate it. AWS describes that as a more disruptive operation that added risk and operational overhead, which is the problem this launch removes.
Go pause one staging connector this week and write down what you see, then browse the free tools on Art of Code for the small jobs around your pipeline work. If you are looking for your next data engineering role, check the latest openings on Art of Code jobs.
Written by Adithya Guttha, Founder of Art of Code.
Sign in to like and save posts.
Keep reading
Discussion
Comments (0)
Want to join the conversation?
Sign in to commentNo comments yet. Be the first to comment!