Alibaba ACA Cloud Operator common mistakes
Alibaba ACA Cloud Operator · Understand the traps and how to avoid them.
Choosing the SLB health-check protocol/port that matches the backend service's application protocol instead of what the health check actually probes, or leaving the default check port when the backend listens elsewhere, then concluding the SLB is broken when all backends show unhealthy.
Candidates conflate 'the service speaks HTTP' with 'the health check must be HTTP on port 80'; they also assume the check inherits the listener port automatically.
What to do instead
For each listener, verify the health-check protocol, port, path, interval, and threshold explicitly; when troubleshooting unhealthy backends, first confirm the check port is open on the ECS instance and the path returns 2xx, and remember Layer 4 (TCP) listeners usually need a TCP check while Layer 7 (HTTP/HTTPS) listeners can use an HTTP check.
Assigning a public IP or EIP to every ECS instance 'just in case', and leaving EIPs unassociated after instance release.
Candidates equate reachability with public addressing and forget that NAT Gateway or an EIP on a shared proxy can provide egress, and that idle EIPs still incur charges.
What to do instead
Design egress through NAT Gateway for private-subnet instances, attach EIPs only to instances that must be inbound-reachable, and audit for unassociated EIPs and idle public IPs as part of cost review.
Treating a Security Group as stateful in the wrong direction or assuming a deny rule can be added; writing an 'allow all' inbound rule to make a connectivity test pass.
Candidates carry over habits from ACL-style firewalls (ordered allow/deny) and from stateless packet filters, and they shortcut troubleshooting by opening everything.
What to do instead
Recall that Security Groups are stateful allow-lists with implicit deny and no explicit deny rules; fix connectivity by adding the narrowest allow rule (specific source CIDR/security group, specific port), and use Network ACLs when explicit deny or subnet-level control is required.
Launching ECS instances without matching the image architecture and instance family (for example, an ARM image on an x86 family) or without checking that the chosen instance type is available in the target zone.
Candidates pick instance type and image independently in the console and assume any combination works and that all types exist in every zone.
What to do instead
Select the instance family first, confirm availability in the intended zone, then choose an image whose architecture matches; when a type is unavailable, change zone or family rather than retrying the same combination.
Stopping an ECS instance and assuming it no longer incurs compute charges, or assuming a stopped instance keeps its public IP.
Candidates map 'stopped' to 'not billed' from laptop intuition; they do not distinguish subscription (prepaid) from pay-as-you-go billing models.
What to do instead
Remember pay-as-you-go instances generally stop incurring compute charges only under the applicable stop policies, and that public IP addresses may be released on stop; for predictable long-running workloads, evaluate subscription or savings plans and release unused resources rather than merely stopping them.
Configuring CloudMonitor alarms on a metric but omitting notification contacts/contact groups, or setting thresholds and periods that never trigger (for example, a 5-minute period with a 1-datapoint threshold on a spiky metric).
Candidates treat alarm creation as the finish line and do not test the notification path; they also misread how period and consecutive-breach counts combine.
What to do instead
After creating an alarm, verify the contact group is attached and send a test notification; set period and consecutive-breach count deliberately (for example, require multiple consecutive breaches to avoid flapping), and confirm the metric namespace/dimensions match the resource being watched.
Storing access credentials in code, user data scripts, or AMI images, and using the primary account AccessKey for routine operations.
Candidates optimize for getting automation to work quickly and are unaware that RAM roles and instance metadata credentials exist.
What to do instead
Create RAM users with least-privilege policies for human/API access, attach RAM roles to ECS instances so applications obtain temporary credentials from instance metadata, rotate and disable unused AccessKeys, and enable MFA on the account.
Taking manual snapshots of system/data disks and calling it a backup strategy, without an automatic snapshot policy, retention rule, or restore test.
Candidates equate 'a snapshot exists' with 'recoverable', and forget that snapshots are incremental and tied to the disk/region.
What to do instead
Configure automatic snapshot policies with retention periods on the relevant disks, document the restore procedure, and periodically test restoring a disk or creating an instance from a snapshot; verify snapshots exist in the region where recovery is needed.
Assuming a VPC spans regions or that a VSwitch can span zones, then placing resources expecting Layer 2 connectivity that does not exist.
Candidates treat VPC as a flat global network and VSwitch as a subnet that can stretch across availability zones.
What to do instead
Remember a VPC is region-scoped and a VSwitch is zone-scoped; place at least one VSwitch per zone you use, and connect across VPCs/regions with the appropriate peering or transit product rather than assuming routability.
Scaling vertically by resizing an instance or adding capacity without first checking whether the workload is CPU-, memory-, disk-IO-, or connection-bound, and ignoring auto scaling for variable load.
Candidates default to 'bigger instance' because it is the most familiar lever and skip the metric review step that the operations domain emphasizes.
What to do instead
Use CloudMonitor metrics to identify the bottleneck, then choose the matching lever (instance family change for CPU/memory, ESS auto scaling for variable demand, bandwidth/disk changes for IO), and re-measure after the change to confirm the bottleneck moved.