Most write-ups on Elastic Compute Service (ECS) stop at "click create instance." That's fine for a demo, but it skips the decisions that actually matter once you're running something in production: which region, which instance family, how you handle access, and how the instance fits into the rest of your infrastructure. This is the setup I use as a baseline on every Alibaba Cloud project.

Picking a region and zone

Alibaba Cloud's region list is larger than most engineers expect — over 30 regions, with strong coverage in Asia-Pacific that AWS and Azure don't match as densely. Two things decide the region for me:

  • Latency to your users. If your audience is in Southeast Asia, ap-southeast-1 (Singapore) or ap-southeast-5 (Jakarta) will beat routing through us-west-1 every time.
  • Service parity. Not every service is available in every region. Check the product availability by region before committing — this bites people who provision first and discover a missing managed service second.

Within a region, spread instances across at least two zones. Zones map to physically separate data centers, and Server Load Balancer (SLB) health checks assume you're using that separation for real redundancy.

Choosing an instance family

Alibaba Cloud's naming convention takes a minute to parse but tells you everything:

Family Use case Comparable to
ecs.g7 General purpose, balanced CPU/memory AWS m6i, Azure Dsv5
ecs.c7 Compute-optimized AWS c6i, Azure Fsv2
ecs.r7 Memory-optimized AWS r6i, Azure Esv5
ecs.i4 Local NVMe storage, I/O heavy workloads AWS i4i

For a typical containerized web workload, ecs.g7 covers it. Reach for c7 if you're CPU-bound (build agents, video encoding) and r7 for in-memory caches or databases that outgrow managed offerings.

Hardening access before anything else touches the instance

This is the step most tutorials skip, and it's the one that matters most:

# Disable password auth entirely — key-based only
aliyun ecs ModifyInstanceAttribute \
  --InstanceId i-xxxxxxxxxxxx \
  --Password ""

# Attach a security group that denies all inbound by default
aliyun ecs AuthorizeSecurityGroup \
  --SecurityGroupId sg-xxxxxxxxxxxx \
  --IpProtocol tcp \
  --PortRange 22/22 \
  --SourceCidrIp <your-office-or-vpn-cidr>/32 \
  --Policy accept

Two habits that save real incidents later:

  1. Never open port 22 to 0.0.0.0/0. Use a bastion host or Alibaba Cloud's Cloud Assistant to run commands without exposing SSH publicly at all.
  2. Tag everything on creation. Environment=production, Owner=platform-team, CostCenter=core-infra — retrofitting tags after 40 instances exist is a miserable afternoon.

Wiring it into the rest of the stack

An ECS instance in isolation isn't useful. The pieces I connect immediately:

  • RAM (Resource Access Management) role, not long-lived AccessKey credentials baked into the instance. Alibaba Cloud's RAM role model mirrors AWS IAM instance profiles closely enough that the mental model transfers directly.
  • Cloud Monitor agent, installed via Cloud Assistant, so CPU/memory/disk alarms exist before the first incident, not after.
  • A VPC with private subnets for anything that isn't a load balancer or bastion. Public IPs on application servers are a habit worth breaking early.

What I'd tell someone starting today

Provision through Terraform or ROS (Resource Orchestration Service) from day one, even for a single instance. The moment you have two environments — staging and production — doing this by hand in the console becomes the thing that quietly drifts and causes the incident nobody can explain. I cover the Terraform setup in a follow-up article if you want the IaC version of this same instance.