An ApsaraMQ for Kafka instance moves through a series of states from deployment to release. The lifecycle depends on the billing model: subscription, pay-as-you-go (hourly), or serverless. Understanding each state, how transitions occur, and when automatic release happens helps you avoid unintended data loss.
Instance states
Every instance exists in one of the following states. The Actions column in the ApsaraMQ for Kafka console indicates which operations are available:
Highlighted -- the operation is available.
Grayed out -- the operation is not available in the current state.
Not displayed -- the operation does not apply to this instance type.
| State | Meaning | Available actions | Data impact |
|---|---|---|---|
| Not Deployed | Purchased but not set up. No resources are provisioned. | Deploy | None -- no data exists yet |
| Running | Active and serving traffic. | Stop (pay-as-you-go and serverless only), Renew (subscription only) | All topics, consumer groups, and configurations are accessible |
| Expired | Subscription not renewed, or pay-as-you-go instance with insufficient account balance. | Renew or add funds, Forcibly delete | -- |
| Stopped | Pay-as-you-go or serverless instance manually stopped. | Enable, Forcibly delete | Topics, consumer groups, and components are preserved |
| Released | Resources permanently reclaimed. | Delete (remove from the list) | All data is permanently deleted |
Once an instance reaches the Released state, it cannot be restored. All data -- including topics, consumer groups, and configurations -- is permanently deleted. Back up any data you need before the release window closes.
Auto-release deadlines
The following table summarizes when instances are automatically released if no action is taken:
| Billing model | Trigger state | Auto-release deadline |
|---|---|---|
| Subscription | Expired | 7 days after expiration |
| Pay-as-you-go / Serverless | Stopped | 8:00 two days after entering the Stopped state |
| Pay-as-you-go / Serverless | Expired | 7 days after expiration |
Subscription instances
Lifecycle overview
Deploy an instance (Not Deployed -> Running)
A newly purchased instance starts in the Not Deployed state. Deploy it in the ApsaraMQ for Kafka console to provision resources. After deployment, the instance transitions to Running.
Expiration (Running -> Expired)
An instance moves from Running to Expired in either of the following situations:
The subscription period ends and the instance is not renewed.
You unsubscribe from the instance by submitting a ticket.
Release an instance (Expired -> Released)
An expired instance can be released proactively or passively:
Proactive release: Forcibly delete the instance in the console. The system schedules an asynchronous task that runs when the instance status becomes Expired. Track the task on the Tasks Pending for Scheduling tab of the Instance Details page.
Passive release: If the instance is not renewed within 7 days of entering the Expired state, it is automatically released. The status changes to Released. Delete the released instance from the console to remove it from the instance list.
Releasing an instance permanently deletes all associated resources, including topics, consumer groups, and stored messages. Back up any data you need before the release window closes.
Restore an instance (Expired -> Running)
Renew an expired subscription instance within 7 days of expiration to restore it to the Running state. After 7 days, the instance is automatically released and cannot be restored.
Pay-as-you-go (hourly) and serverless instances
Lifecycle overview
Deploy an instance (Not Deployed -> Running)
Deploy the instance in the ApsaraMQ for Kafka console to transition it from Not Deployed to Running. The deployment process is the same as for subscription instances.
Stop or expire an instance (Running -> Stopped / Expired)
An instance leaves the Running state in either of the following situations:
Manual stop: Stop the instance in the console. The status changes to Stopped.
Insufficient balance: If your account balance is insufficient, the status changes to Expired.
Before you stop an instance, you do not need to delete the topics, groups, or components on the instance. However, you must stop your business because services are interrupted after you stop the instance.
Release an instance (Stopped or Expired -> Released)
A stopped or expired instance can be released proactively or passively.
Proactive release
Forcibly delete the instance in the console. The system schedules an asynchronous task that runs when the instance status becomes Stopped or Expired. After the final bill is generated, the instance is deleted automatically. Track the task on the Tasks Pending for Scheduling tab of the Instance Details page.
A forcibly deleted instance cannot be restored. Do not add funds to your account while a force deletion is in progress -- the instance is still deleted even if funds are added.
Passive release
| Pre-release state | Auto-release deadline | Example |
|---|---|---|
| Stopped | 8:00 two days after entering the Stopped state | Instance stopped at 14:00 on October 13, 2023 -> released at 8:00 on October 15, 2023 |
| Expired | 7 days after entering the Expired state | -- |
After release, the status changes to Released. Delete the released instance from the console to remove it from the instance list.
Releasing an instance permanently deletes all associated resources, including topics, consumer groups, and stored messages. This action cannot be undone.
Restore an instance (Stopped or Expired -> Running)
The restoration method depends on the current state:
| Current state | How to restore | Deadline |
|---|---|---|
| Stopped | Enable the instance in the console | Before 8:00 on the third day after entering the Stopped state |
| Expired | Add funds to your account | Within 7 days of entering the Expired state |
After restoration, the instance returns to Running. If the deadline passes without action, the instance is released and cannot be restored.