A slow-loading app rarely comes down to bad code alone. More often, it's an instance type that no longer fits the workload, a disk that's hit its IOPS ceiling, or a network path that's quietly throttling throughput.
Elastic Compute Service (ECS) gives you a lot of levers to pull — most teams just never pull them until something breaks.
This guide walks through ten practical ways to get more performance out of your ECS instances, from picking the right instance family to tuning storage, network, and OS-level settings. Each one is something you can act on today.
The single biggest performance lever is also the most overlooked: running the wrong instance family for the job.
A CPU-bound batch job on a memory-optimized instance wastes money and still runs slow. A database on a general-purpose instance without enough memory headroom will thrash.
Alibaba Cloud groups ECS instances into families based on their CPU-to-memory ratio and intended use case:
Before picking anything, it's worth reading the overview of ECS instance families, which explains how instance types are named and grouped, and links out to a selection guide.
Newer generations in the same family typically deliver more compute and I/O performance per vCPU than older ones at a similar price point, so if you provisioned instances more than a generation or two ago, a like-for-like upgrade is often free performance.
It's tempting to add more instances when performance degrades, but scaling out an under-specified instance type just multiplies the inefficiency.
Start by checking actual utilization. If CPU utilization sits low while memory is maxed (or vice versa), the CPU-to-memory ratio of your current instance family is wrong for the workload — switching families, not adding instances, is the fix.
A practical example: if monitoring shows healthy memory usage but persistently low CPU utilization, reducing the CPU-to-memory ratio (moving to a family with less memory per vCPU) can raise utilization efficiency without touching the application.
This kind of analysis is covered in Alibaba Cloud's resource usage optimization best practices, part of the Well-Architected Framework.
If your application is disk-bound — a database, a search index, anything with heavy random reads and writes — the disk type matters more than the instance type.
Alibaba Cloud's Enhanced SSDs use 25 Gigabit Ethernet and RDMA to deliver up to 1,000,000 random read/write IOPS per disk with 100–200 µs latency, according to the ESSD specifications and performance guide.
ESSDs come in four performance levels (PL0 through PL3), and the right level depends on your capacity and IOPS requirements — a PL0 disk scales its maximum IOPS with capacity, while PL3 can hit the full 1,000,000 IOPS ceiling regardless of size.
If your workload has unpredictable spikes rather than a steady baseline, ESSD AutoPL disks decouple capacity from performance entirely: you provision IOPS and throughput independently of disk size, with performance bursts available on top.
The ESSD AutoPL disks guide covers baseline, provisioned, and burst performance in detail.
For a side-by-side comparison of IOPS and throughput ceilings across disk types, the Block Storage performance metrics reference is the fastest way to see what you're leaving on the table with standard SSDs or ultra disks.
Don't assume a disk is hitting its rated IOPS — verify it. Alibaba Cloud documents a repeatable method using the fio benchmarking tool to test raw ESSD performance, including recommended instance types (such as ecs.g7se.32xlarge), image versions, and test parameters, in Test the IOPS performance of an ESSD.
Two details matter here. First, storage I/O performance scales with instance size within storage-enhanced families — a larger instance type in the same family delivers higher IOPS and throughput, not just more vCPUs.
Second, results vary by OS image; Alibaba Cloud Linux 3 is the recommended baseline for consistent benchmark numbers. If you're chasing a specific IOPS target, always benchmark on a raw partition (after snapshotting) rather than trusting theoretical maximums.
You can't optimize what you don't measure, and ECS gives you two distinct layers of visibility. Infrastructure monitoring is agentless and collects host-level metrics like vCPU utilization, network traffic, and disk I/O once per minute — no setup required, as described in viewing ECS instance monitoring information.
Operating system monitoring goes deeper via the CloudMonitor agent, sampling every 15 seconds and exposing OS-level detail like per-process CPU time and TCP connection states — see the infrastructure vs. OS monitoring overview.
For a unified view across CPU, memory, disk, and network on one chart — which makes it much easier to spot whether a slowdown is CPU-bound, I/O-bound, or network-bound — use CloudMonitor dashboards.
Set alert thresholds with headroom in mind: a common pattern is alerting at 70% CPU utilization after three consecutive breaches, which catches sustained pressure without triggering on normal spikes.
Network performance on ECS is a function of instance type, not just bandwidth purchased.
Larger instance types within a family generally deliver higher packet-forwarding rates and throughput, and some families — like g7ne — are specifically built for high concurrent-connection and packet-forwarding workloads, per the general-purpose instance families specifications.
A subtlety worth knowing: ECS console monitoring only tracks public bandwidth, while CloudMonitor tracks both public and internal bandwidth.
If your app talks heavily to other services inside the VPC, internal bandwidth exhaustion won't show up unless you're checking CloudMonitor — a gap that's easy to miss during a performance investigation, as noted in the ECS monitoring information guide.
No single instance size handles both your average load and your peak load efficiently — provision for peak and you overpay at baseline; provision for baseline and you degrade at peak.
Auto Scaling (also called Elastic Scaling Service, or ESS) solves this by automatically adding instances when demand rises and removing them when it falls, based on policies you define. It's a free service — you only pay for the ECS instances it creates, per the what is Auto Scaling overview.
It's worth understanding what Auto Scaling does not do: it changes instance count, not instance specifications.
If your bottleneck is CPU or memory on a single instance, Auto Scaling won't help — you need to resize or change the instance family first, then let Auto Scaling handle count.
The how Auto Scaling works guide walks through the full scale-out sequence, including the cooldown period that prevents rapid, repeated scaling from noisy metrics.
For multi-zone resilience during scale-out, you can attach up to five vSwitches across different zones to one scaling group — if the highest-priority zone runs out of capacity, Auto Scaling automatically retries in the next.
The operating system image isn't a neutral choice — it directly affects the performance you get out of the underlying hardware.
Alibaba Cloud's own ESSD benchmarking documentation notes that specific Linux distributions may not reach expected IOPS performance on certain images, and recommends Alibaba Cloud Linux 3 as the baseline for predictable storage performance.
Beyond storage, match the image to the instance family: some newer instance families have compatibility requirements (for example, specific families don't support older FreeBSD releases), which are documented per family in the ECS instance families overview.
Using a minimal, up-to-date, Alibaba Cloud-optimized image also reduces background OS overhead competing with your application for CPU and I/O.
It's easy to assume "if it isn't broken, don't touch the instance type." But Alibaba Cloud's cost optimization guidance makes a point worth internalizing: newer instance generations frequently deliver more performance at the same or lower specification and price than the generation before.
Their documented comparison between g5.2xlarge and g6.2xlarge shows how a straightforward generational upgrade — without changing vCPU or memory counts — improved performance and cut costs by at least 15%, detailed in best practices for cost optimization.
This means a periodic instance-generation review is worth adding to your maintenance calendar, not just your budget review. Designing applications to run across different instance types (rather than hardcoding assumptions about a specific type) makes these upgrades painless when a new generation ships.
A common mistake is buying more disk capacity to "get more IOPS," when what's actually needed is provisioned performance.
With ESSD AutoPL disks, IOPS and throughput are configured independently of capacity — you can provision additional IOPS on a disk without resizing it, and each provisioned IOPS unit includes a fixed amount of throughput (16 KB), per the ESSD AutoPL performance configuration guide.
This matters for cost control as much as performance: instead of over-provisioning capacity to chase an IOPS number, you provision exactly the performance the workload needs, and can adjust it later — enabling or disabling the performance-provision and performance-burst features as demand changes — without touching disk size.
Most ECS performance problems trace back to a mismatch somewhere: the wrong instance family for the CPU-to-memory profile, a disk that's capacity-optimized rather than performance-optimized, or a monitoring gap that hides where the bottleneck actually is.
Start by measuring — infrastructure monitoring and CloudMonitor dashboards will tell you whether you're CPU-bound, I/O-bound, or network-bound — and then apply the fix that matches: right-size the instance family, upgrade to ESSDs or AutoPL for I/O, move to the current instance generation, and let Auto Scaling handle demand variability rather than over-provisioning for peak.
None of these changes require a rebuild. They're configuration and provisioning decisions, which is exactly why they're worth revisiting on a regular cadence rather than only when something slows down.
How to Improve Core Web Vitals Using Alibaba Cloud CDN and ECS
23 posts | 4 followers
FollowAlibaba Cloud ECS - January 8, 2020
Alibaba Clouder - February 12, 2019
Wenson - August 4, 2020
Alibaba Clouder - November 19, 2019
Kalpesh Parmar - May 22, 2026
yzq1989 - April 10, 2020
23 posts | 4 followers
Follow
Intelligent Robot
A dialogue platform that enables smart dialog (based on natural language processing) through a range of dialogue-enabling clients
Learn More
Storage Capacity Unit
Plan and optimize your storage budget with flexible storage services
Learn More
Simple Log Service
An all-in-one service for log-type data
Learn More
Edge Node Service
An all-in-one service that provides elastic, stable, and widely distributed computing, network, and storage resources to help you deploy businesses on the edge nodes of Internet Service Providers (ISPs).
Learn MoreMore Posts by Kalpesh Parmar
