Why your Alibaba Cloud app slows down: Explaining the ECS, RDS, and OSS failure chain

If you run production workloads on Alibaba Cloud, three services sit at the center of most performance incidents: Elastic Compute Service (ECS) for compute, ApsaraDB RDS for databases, and Object Storage Service (OSS) for object storage. When something degrades, the immediate question is where the problem actually lives: In the instance, the database, the storage layer, or the connections between them?

That last part is the critical one. ECS, RDS, and OSS failures rarely travel alone. A CPU spike on an ECS instance can exhaust the connection pool on a downstream RDS database, which triggers retry logic that hammers OSS with redundant read requests. Three alarms fire. Three dashboards open. One incident.

Per-service dashboards get you to the symptoms. This guide gets you to the cause, and to the point where you can stop reconstructing timelines manually.

ECS high CPU: what's actually happening and how to find it

ECS vCPU saturation is one of the most frequently misdiagnosed issues on Alibaba Cloud. The metric itself is straightforward; the cause is not.

Infrastructure metrics are collected at one-minute granularity from the host without an agent. OS-level metrics, process CPU, memory, and TCP connections, each of these require the CloudMonitor agent and are collected every 15 seconds once installed. For operating system-level detail, process-level CPU breakdown, memory, and TCP connections, you need the agent installed on the instance. Without it, you're working with host-level numbers only: vCPU utilization, disk read/write throughput, and network bandwidth. That's rarely enough to identify the root cause.

Common causes to rule out in order

Runaway application processes

A misconfigured cron job, a memory leak driving constant garbage collection, or an unthrottled background task will each show sustained high CPU with no corresponding traffic spike. On a Linux instance, run top and sort by CPU to identify the offending process. On Windows, use Task Manager's CPU sort.

CPU credit exhaustion on burstable instances

ECS burstable instances (the ecs.t5 and ecs.t6 families) accumulate CPU credits during idle periods and spend them during bursts. Once credits run out, the instance is throttled to its baseline. If you're on a burstable instance type and see CPU capped at a suspiciously round number (10%, 20%, 30%), credit exhaustion is the likely cause. The TotalCredit metric tracks the available CPU credit balance and can be configured as an alert rule in CloudMonitor—set it up proactively, not after the throttling starts.

Noisy neighbors at the availability zone level

Less common, but worth checking during large-scale incidents. In September 2024, a lithium battery fire at Alibaba Cloud's Singapore Availability Zone C data center left ECS, OSS, and ApsaraDB RDS all in an abnormal state for several days—a confirmed multi-service failure triggered by a single infrastructure event. If multiple instances in the same availability zone show simultaneous degradation with no application-level cause, check the Alibaba Cloud Status page before continuing to dig at the instance level.

Legitimate traffic growth without auto-scaling

If your ECS instances don't have auto-scaling configured, a traffic spike saturates existing capacity without any process-level anomaly to point to.

The diagnostic signal is a correlated rise in inbound network bandwidth and vCPU utilization within the same minute window, with no corresponding spike in any single process from the agent's process-level view.

Traffic-driven saturation looks clean at the process level because the load spreads across all application threads. No single process stands out. The signal is bandwidth and CPU rising together with nothing from the agent to explain it. If that's the pattern, add capacity first and stop there.

To diagnose: Check vCPU trend over the past hour. Drill into process-level metrics if the agent is installed. Note the instance type; burstable instances behave differently under load. Then check connection counts, they tend to climb in the same window as CPU saturation on application tiers.

If CPU and process metrics are both clean but the application is still slow, don't keep digging at the instance level. Move to RDS connection counts. Compute saturation is one of the more reliable upstream triggers for a database connection pile-up, and it almost always shows up in RDS first, before any database alert has fired.

ApsaraDB RDS latency: Connection exhaustion, slow queries, and storage pressure

RDS latency on Alibaba Cloud tends to trace back to one of three things: the connection pool is full, slow queries are piling up, or storage pressure is pushing IOPS toward the ceiling.

CPU is the last metric to move. By the time it's consistently elevated, your application has already been taking a hit for several minutes. Start with connection counts.

Connection pool exhaustion is the most common RDS incident pattern in high-traffic APAC applications. ApsaraDB RDS enforces a maximum connection limit by instance class. When application connection pools are configured too generously or when a deployment creates duplicate pools without closing old ones, the limit is hit quickly. The signal surfaces in application logs before any infrastructure alert fires: "Too many connections" appears in your logs while metrics still look unremarkable, because polling intervals don't catch burst events that resolve and recur within the same window.

To diagnose, check ConnectionUsage (connections in use as a percentage of the maximum). Above 80% warrants immediate investigation. Enable Performance Insight for MySQL and PostgreSQL before your next incident, not during it. It gives a per-session and per-query breakdown that standard dashboards don't provide.

Slow query accumulation are the easiest patterns to miss. One unindexed query on a large table holds a lock, everything behind it stacks up, and all your application sees is a latency spike with no infrastructure metric to explain it. Pull the RDS slow query log through Database Autonomy Service (DAS). It flags queries past a configurable threshold and tells you what to fix per statement.

Storage pressure is the most predictable pattern of the three because it builds slowly. Disk fills up and writes slow down, then they fail. Set a DiskUsagePercent alert at 75%. By the time you hit 90% you're already dealing with an incident, not heading toward one. Enable storage autoscaling on every production RDS instance; there's no good reason not to.

If connection usage and query times both look fine but OSS 5xx rates are climbing in the same window, don't spend time in RDS. The retry loop has already started. Code that can't write to the database doesn't wait. It retries, and those retries pile onto OSS.

OSS errors: 5xx rates, E2E latency, and request distribution failures

OSS errors fall into two categories: request errors (4xx and 5xx status codes) and latency anomalies. They require different diagnostic approaches.

OSS exposes two latency metrics that are frequently confused. E2E latency covers the full round trip. It includes network latency on both sides. Server latency covers only the time OSS spends processing the request internally. A large gap between the two means the problem is network-side, not storage-side. High server latency with a small gap points to OSS itself under pressure: storage node saturation or a hot bucket pattern.

Metrics are reported at one-minute intervals for sums, maximums, and averages. A burst of 5xx errors lasting 45 seconds may appear as a single elevated average in one-minute data. The peak severity is masked, which matters when you're trying to reconstruct the sequence of a cross-service incident.

ServerErrorCount (5xx) spikes usually indicate service-side issues: bucket region saturation, throttling from burst request rates exceeding OSS throughput, or network connectivity problems between availability zones. Check request distribution first, errors concentrated on a single bucket point to a hot bucket or regional issue; errors spread across all buckets point to an account-level or network-level event.

RequestCount anomalies are worth monitoring alongside error rates. A sudden drop in RequestCount without a corresponding drop in application traffic means requests aren't reaching OSS, check VPC endpoints and ECS-to-OSS network connectivity. An unexpected spike in RequestCount often signals a misconfigured retry loop amplifying an upstream error, which is exactly the pattern that forms when RDS latency triggers application retries that land on OSS.

4xx errors are almost always your own code: a bad object key, expired credentials, an ACL mismatch, or a request hitting an object that a lifecycle policy already deleted. To find the specific cause, go to the OSS access log in Simple Log Service (SLS). The ErrorCode field tells you exactly what happened: NoSuchKey for missing objects, InvalidAccessKeyId for credential failures, or AccessDenied for ACL mismatches. One thing worth doing now: SLS log delivery isn't on by default and needs to be configured per bucket. Don't wait until you're in an incident to set it up.

Always look at 4xx and 5xx together. A 4xx surge usually comes first; the 5xx escalation follows as downstream systems start retrying.

A RequestCount spike with no deployment, no traffic change, and nothing on the application side go upstream. Check RDS connection usage first, then ECS CPU. The amplification started above OSS, not in it.

The failure chain no per-service dashboard shows you

Three services. Three dashboards. One incident you're piecing together while it's still happening.

The sequence is usually the same: ECS saturates, the RDS connection pool hits its limit, then retry logic floods OSS with redundant requests. It starts in one place and fans out across your stack in minutes. CloudMonitor sees three separate events with no thread between them. The timeline exists. But you just have to rebuild it yourself, under pressure, across three screens.

What alternative does OpManager Nexus offer?

OpManager Nexus puts ECS vCPU utilization, RDS ConnectionUsage , and OSS ServerErrorCount on a shared timeline. If CPU saturation on your application tier preceded a connection count climb on RDS by 90 seconds, you see that sequence directly rather than piecing it together after the incident closes. Auto-discovery picks up your ECS instances, RDS databases, and OSS buckets before anything breaks, so the relationships are already there when you need them. For teams running Alibaba Cloud alongside AWS or Azure, all three are monitored from the same console .

Start a 30-day free trial of OpManager Nexus or request a demo to see how Alibaba Cloud monitoring looks alongside the rest of your infrastructure.

Things to remember

ECS CPU diagnosis requires process-level agent data, host-level metrics alone rarely identify root cause. Check burstable instance credit exhaustion before assuming an application problem.

RDS latency is most reliably caught by monitoring ConnectionUsage and enabling DAS slow query logs before incidents, not after. CPU is a lagging indicator for database performance.

The OSS E2E vs server latency gap is the fastest way to determine whether an OSS issue is network-side or storage-side. Monitor both independently.

Incidents spanning ECS, RDS, and OSS simultaneously are faster to triage when all three services are visible in a single console, switching between dashboards under pressure costs time your SLA may not have.

Unified observability reduces mean time to resolution (MTTR) by removing the manual work of cross-service incident reconstruction.

FAQs

1. Why does an ECS CPU spike cause ApsaraDB RDS latency to increase?

An ECS application tier that's CPU-saturated can't process responses fast enough to release database connections back to the pool. Connections stay open, accumulate, and eventually hit the RDS instance class limit. From that point, new connection requests queue or fail. Your application sees latency. No database alert has fired yet. The CPU spike happened upstream; RDS is just where the pain shows up.

2. What is the difference between E2E latency and server latency in Alibaba Cloud OSS?

E2E latency measures the full round trip from the client sending a request to receiving a response, including network transit on both sides. Server latency measures only the time OSS spends processing the request internally. If E2E latency is high but server latency is low, the bottleneck is network-side, not the storage layer. If both are high, OSS itself is under pressure, typically from storage node saturation or a hot bucket pattern.

3. How do I tell if my Alibaba Cloud ECS instance is being throttled due to CPU credit exhaustion?

Check the instance type first. CPU credit exhaustion only affects burstable instance families (ecs.t5 and ecs.t6). If you are on one of these and CPU utilization appears capped at a round number such as 10%, 20%, or 30% regardless of load, credit exhaustion is the likely cause. Monitor the TotalCredit metric in CloudMonitor, which tracks the available credit balance in real time. Configure an alert on TotalCredit before exhaustion occurs, not after throttling starts.

4. What is the maximum connection limit for ApsaraDB RDS?

There is no single figure. The maximum connection count on ApsaraDB RDS scales with the instance class, so a smaller instance class carries a significantly lower ceiling than a high-memory production instance. The practical diagnostic threshold is ConnectionUsage : when connections in use exceed 80% of the instance maximum, investigate immediately. For the exact limit on your instance class, refer to the ApsaraDB RDS instance specification table in Alibaba Cloud documentation.

5. How does OpManager Nexus monitor Alibaba Cloud compared to AWS and Azure?

OpManager Nexus applies the same monitoring model across all three providers. ECS instances, ApsaraDB RDS databases, and OSS buckets are monitored alongside AWS and Azure resources from the same console, with auto-discovery identifying resources across providers without manual configuration. Metrics, alerts, and timelines are consistent across clouds, so a cross-provider incident does not require switching between provider-native dashboards to reconstruct the sequence of events.

6. What should I check first when multiple Alibaba Cloud services fail simultaneously?

Start with ECS. In multi-tier Alibaba Cloud applications, compute saturation is the most common upstream trigger for cross-service failures. Check vCPU utilization and, if the CloudMonitor agent is installed, process-level metrics. If ECS looks clean, move to RDS ConnectionUsage , then OSS ServerErrorCount and RequestCount . A simultaneous rise across all three services with no application-level change usually points to an infrastructure event at the availability zone level; check the Alibaba Cloud Status page before continuing to dig at the service level.