Kubernetes on Alibaba Cloud: ACK vs. Self-Managed, and When to Choose Which

Every cloud provider now has a managed Kubernetes offering, and the honest answer to "which one is better" is almost always "run the managed version unless you have a specific reason not to." Alibaba Cloud's Container Service for Kubernetes (ACK) is a solid managed option — but there are still real decisions to make about which flavor of ACK, and when self-managing still makes sense.

The three ACK flavors

For a typical service with steady baseline traffic, ACK Managed is the right default. You keep control over node pools, instance types, and autoscaling policy, without operating etcd or the API server yourself.

Provisioning a managed cluster

aliyun cs CreateCluster --body '{
  "name": "prod-cluster",
  "cluster_type": "ManagedKubernetes",
  "region_id": "ap-southeast-1",
  "kubernetes_version": "1.28.3-aliyun.1",
  "vpcid": "vpc-xxxxxxxxxxxx",
  "vswitch_ids": ["vsw-xxxxxxxxxxxx"],
  "num_of_nodes": 3,
  "worker_instance_types": ["ecs.g7.xlarge"],
  "worker_system_disk_category": "cloud_essd",
  "cloud_monitor_flags": true
}'

cloud_monitor_flags: true wires the Cloud Monitor agent into every node automatically — worth enabling from the first cluster rather than retrofitting it once something's already on fire.

Where ACK differs from EKS/AKS in practice

If you've run Amazon EKS or Azure AKS, most of the Kubernetes-native tooling — Helm, kubectl, ArgoCD, Prometheus — works identically. The differences that actually change how you operate:

• Autoscaling uses Alibaba Cloud's own Cluster Autoscaler fork, tuned for ECS instance types and spot instance (called "Preemptible Instances" here) pricing. The YAML is nearly identical to the upstream autoscaler, but the annotations for instance-type fallback lists use Alibaba's own scaling group IDs.
• Load balancer provisioning through a Service of type LoadBalancer creates an SLB instance automatically, same as EKS creates an ELB — but the annotations for SLB-specific features (like specifying a particular SLB spec tier) use the service.beta.kubernetes.io/alibaba-cloud-loadbalancer-* prefix instead of AWS's service.beta.kubernetes.io/aws-load-balancer-*. Easy to forget mid-migration.
• CSI driver for persistent volumes backs onto Alibaba Cloud Disk (cloud_essd, cloud_efficiency tiers) rather than EBS — the StorageClass names and performance tiers need to be remapped, not assumed to carry over.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: essd-retain
provisioner: diskplugin.csi.alibabacloud.com
parameters:
  type: cloud_essd
  fsType: ext4
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

When self-managed still wins

I've reached for self-managed Kubernetes on Alibaba Cloud (ECS instances + kubeadm) exactly twice, both for the same reason: a compliance requirement mandated air-gapped control plane access with no managed-service data path to Alibaba Cloud's control systems at all. If you don't have that constraint, the operational cost of running your own control plane — etcd backups, API server certificate rotation, version upgrades — isn't worth what you get back.

Cost shape to expect

ACK Managed doesn't charge for the control plane on the Basic tier; you pay for the underlying ECS nodes, SLB instances, and storage exactly as you would if you'd provisioned them standalone. The Professional tier control plane has a flat hourly fee in exchange for an SLA and larger node-count ceiling — worth it once a cluster is genuinely load-bearing for production traffic, not necessary for staging or internal tooling clusters.

If cost visibility across clusters (or across clouds) is the next problem you're solving, that's exactly what I cover in multi-cloud cost optimization.