ACK Node Pool Deleted, Subscription ECS Charges Remained

The cleanup looked complete

The production migration finished cleanly. The new nodes were Ready.

Argo CD and the applications were running on the stable subscription pool. No Pods were Pending. The Spot application pool and the older system pools were gone from ACK.

From the Kubernetes side, the work looked done. We treated a clean ACK view as the end of the job. That was the mistake.

Deleting an ACK node pool does not, by itself, stop charges for subscription ECS nodes. ACK removal, ECS release, the already-paid subscription term, and auto-renewal are separate controls.

This was a cost and process mistake, not an outage. The cluster stayed healthy. The missed part was the prepaid ECS commitment sitting outside the Kubernetes object model.

The failed assumption

The original production ACK cluster had several node pools. Three small subscription system pools covered one availability zone each. A Spot application pool carried the bursty workload capacity.

We created a new three-zone subscription node pool with stable instance types and a few compatible fallbacks.

Workloads moved onto that pool. Validation passed. Then we drained and removed the Spot pool and the older system pools.

The failed assumption was simple: if ACK no longer showed the old pools, the related infrastructure cost must have ended. That mixes orchestration state with billing state.

ACK can stop managing a node while the ECS instance still exists. Subscription capacity can remain on an already-paid term. Auto-renewal can create another charge later even when the Kubernetes Node object is long gone.

ACK and ECS have separate lifecycles

Kubernetes Nodes, ACK node pools, and ECS instances are related, but they are not the same object. Deleting one layer does not automatically close every layer beneath it.

What deletion actually removes depends on which control plane you are looking at.

Alibaba Cloud’s remove-node guidance is clear about this boundary. Removing a node from ACK can drain pods and detach the node from cluster management. Releasing the ECS instance is a separate option. Only pay-as-you-go instances can be released that way. For subscription instances, the docs say the instance stays until expiration unless you request a refund or change the billing method to pay-as-you-go and then release it.

If the node pool has an Expected Nodes count, ACK can also scale out again after a removal to restore that count. So a careless remove can recreate capacity you thought you had retired.

The same split appears when a whole cluster is deleted. ACK cluster deletion docs state that subscription nodes are not released automatically with the cluster. Someone still has to handle those instances in ECS.

Treat ACK cleanup as necessary. Do not treat it as enough for FinOps closure.

How Alibaba Cloud ACK subscription node cost continues

Subscription ECS is prepaid. You pay for a term such as one month or one year.

During that term, the base compute is already purchased. It does not behave like a pay-as-you-go instance that stops charging the moment you forget about it.

Alibaba Cloud’s subscription billing overview describes this prepaid model and the separate handling for expiration, renewal, and billing-method changes. The current term may already be paid. Setting non-renewal does not refund that term.

Auto-renewal is the risk after a Kubernetes cleanup. If it stays enabled, another charge can appear near expiration even though the node pool is gone from ACK. Auto-renewal guidance and manual renewal settings treat renewal status as an ECS control, not a Kubernetes one.

If auto-renewal stays on, Alibaba Cloud attempts renewal before expiration and can retry afterward when payment fails. That is why a pool that disappeared from ACK weeks earlier can still show up as a charge near the ECS expiry date.

Refund or conversion eligibility is another separate path. Alibaba Cloud documents rules for switching subscription instances to pay-as-you-go and calculating unused-period refunds. Those rules live in the billing path. They are not implied by an ACK delete button.

How we found the remaining commitment

After the migration, the ACK node-pool list looked correct. The Kubernetes Node list looked correct. That was enough for us to treat the change as closed.

The check that should have been next sits outside kubectl: inventory the ECS instances that backed the old pools, then inspect billing method, expiration time, and auto-renewal status. That is where a remaining prepaid commitment becomes visible.

Compare the instances still present in ECS with the nodes ACK no longer lists. If those lists disagree, the Kubernetes cleanup finished and the billing decision did not.

ECS can still hold prepaid objects that need an explicit decision: keep until expiry, disable renewal, convert, or release under documented rules.

A practical CLI family for this inspection is the ECS auto-renewal attribute API. With placeholders only:

aliyun ecs DescribeInstanceAutoRenewAttribute \
  --RegionId <region-id> \
  --InstanceId <instance-id>

Inspect subscription renewal attributes for a specific ECS instance.

The response shows whether auto-renewal is enabled and what renewal status is configured. Keep that answer next to the ACK cleanup evidence. One without the other is incomplete. If you want that trail stored with the change record, tools such as Vigiles can help the next reviewer see both the Kubernetes migration and the ECS billing decision.

The safe consolidation we completed

The technical consolidation itself was sound. The new three-zone subscription pool absorbed the workloads. Labels and zone placement were checked before the old pools were drained.

kubectl get nodes \
  -L workload.example.com/capacity \
  -L workload.example.com/billing \
  -L topology.kubernetes.io/zone

Inspect node labels and zones before draining old capacity.

Useful placement checks before and after the move:

kubectl get pods \
  --all-namespaces \
  -o wide

Review Pod placement across namespaces before drain.

kubectl get pods \
  --all-namespaces \
  --field-selector=status.phase=Pending

Confirm no Pods remain Pending after consolidation.

No Pending Pods remained. That validated the Kubernetes side of the change. The missing step was the ECS closeout for the drained subscription capacity.

If you manage ACK node pools with OpenTofu, keep the same split in code reviews. The Alibaba Cloud ACK OpenTofu reference implementation is useful for node-pool design. It does not replace an ECS renewal and release checklist after a destroy or scale-in.

What deletion does and does not mean

Use this comparison when someone claims the cleanup is complete:

Action	Kubernetes result	ECS result	Billing result
Delete Node object	Node disappears from Kubernetes	Instance may still run	Cost normally remains
Remove node from ACK	Node leaves cluster management	Depends on removal options and billing model	Must be checked
Delete ACK node pool	Pool disappears from ACK	Subscription instances may require separate handling	Existing term and renewal remain separate
Disable auto-renewal	No Kubernetes change	Instance remains through current term	Prevents a future automatic renewal
Release eligible ECS instance	No Kubernetes object remains	Instance is released	Refund rules or conversion rules may apply

Checked against Alibaba Cloud ACK and ECS documentation on September 25, 2026.

Official remove-node docs also warn against removing or releasing worker ECS instances only from the ECS console or with raw kubectl delete shortcuts. Use the ACK removal path for cluster-managed nodes, then complete the billing decision in ECS when subscription rules require it.

During the change review, name the controls separately: delete the Kubernetes Node object, remove the node from ACK, delete the ACK node pool, release the ECS instance if eligible, end or prevent renewal, and request a refund or conversion only when the billing rules allow it. Each step has a different owner and a different proof.

What we should have checked first

Before deleting the old pools, the checklist should have included billing identity as well as Kubernetes readiness.

Which pools are subscription, Spot, or pay-as-you-go?
Which ECS instances back each pool?
What is the current expiration date for each subscription instance?
Is auto-renewal enabled?
Is refund or subscription-to-pay-as-you-go conversion eligible and approved?
Who owns the billing decision if the Kubernetes migration finishes first?

We validated Pods, Ready nodes, and application health. Those checks were necessary. They were incomplete for prepaid capacity.

Ownership matters as much as the technical check. If platform engineering owns the ACK change and FinOps owns the subscription decision, write that handoff into the change record. Otherwise one team closes a green migration while another team finds the renewal later on the bill.

The corrected removal process

The next time a subscription pool is retired, the process should look like this:

Safe subscription-node removal ends with ECS and billing confirmation, not only ACK deletion.

Inventory node pools, instance IDs, zones, and billing models.
Cordon the old nodes after replacement capacity is Ready.
Drain workloads with PDB awareness.
Validate that replacement nodes hold the workloads and that Pending counts stay at zero.
Remove the nodes and pool through ACK or the OpenTofu workflow that owns them.
Inspect the ECS instances that previously backed the pool.
Disable auto-renewal or set non-renewal when the capacity should not return.
Confirm the next bill and any refund or conversion ticket before closing the change.

If a subscription instance must be released before natural expiration, follow the documented path: check refund rules, convert to pay-as-you-go when required, then release. Do not invent a shortcut from the ACK delete dialog.

Keep the evidence together. Save the node inventory, drain completion, ACK removal confirmation, ECS renewal status, and billing follow-up in one place. The next engineer should not have to rebuild the story from chat history.

Lessons for Kubernetes and FinOps teams

Kubernetes success metrics can hide unfinished cloud-billing work. Ready nodes and empty Pending queues answer the service question. They do not answer the prepaid-capacity question.

Give FinOps and platform engineering a shared closeout gate for ACK changes that touch subscription ECS. Require evidence of renewal status and of the release or retention decision.

Prefer clear labels for capacity and billing intent on nodes and pools. When Spot, subscription, and pay-as-you-go capacity share one cluster, operators need that distinction during drain and during cost review.

Multi-zone pools improve resilience. They also multiply the number of subscription objects you must account for after a consolidation.

Related reading on this site: FinOps decisions that keep reliability intact covers cost cuts that quietly raise operational risk. Cut MTTR without adding more alerts is a reminder that recovery and ownership problems also need explicit checks, not only console cleanup. Human error is not a root cause fits when a cleanup misses a control that the process never asked anyone to verify.

Final checklist

Subscription node removal checklist

0 of 10 checks completed

Before drain

Replacement capacity is Ready
Workload placement is understood
Billing type is recorded

During ACK removal

Nodes are cordoned and drained
No Pods remain Pending
Old pools are removed after checks

After Kubernetes cleanup

Old ECS instances are inventoried
Renewal status is confirmed
Exit options are checked
The next bill is reviewed

If ACK is clean but the ECS renewal status is unclear, the cleanup is not finished.

Questions engineers usually ask

Does deleting an ACK node pool delete its ECS instances?

Not automatically for subscription ECS. ACK deletion removes cluster management of the pool. Subscription instances often need separate ECS handling before release.

Does deleting the node pool stop subscription charges?

Not necessarily. The already-paid term can remain in force, and auto-renewal can create a later charge if it stays enabled.

What happens when auto-renewal is disabled?

The instance normally continues through the current prepaid term, but Alibaba Cloud should not automatically renew it for another term. Disabling auto-renewal does not refund the current term.

Can a subscription ECS instance be refunded?

Sometimes, under documented conversion and refund rules. Eligibility must be checked in the billing path and is not granted by ACK node-pool deletion alone.

Should production Kubernetes nodes use subscription or Spot billing?

Use subscription or other stable capacity for critical production baselines, and use Spot only where interruption is acceptable and replacement capacity is planned.

What should be checked before deleting an ACK node pool?

Check replacement capacity, Pending Pods, ECS instance inventory, billing model, expiration dates, auto-renewal status, and any refund or conversion decision owners.

We Deleted the ACK Node Pool, but the Subscription Charges Remained

What you will learn