Cost Spike Investigation and Commitment Decision
A SaaS company's monthly Alibaba Cloud bill jumped from about 30,000 to 52,000 CNY in one month with no planned launch. The bill is dominated by ECS (pay-as-you-go), OSS storage and requests, and NAT Gateway. The team has a stable baseline: about 40 ECS instances run 24/7 for the core service, and a variable fleet of 10-30 instances handles daily peaks. OSS holds 200 TB, growing ~5 TB/month, with a large share of objects not accessed in over 180 days. NAT Gateway charges rose sharply. Nobody can explain the increase, and finance wants both an explanation and a plan to prevent recurrence. The team is considering buying a large 1-year all-upfront subscription to 'lock in savings.'
1. How would you investigate the increase before committing to any purchase, and what are the likely culprits given the service mix?
Read the worked answer
Investigate first; committing to a subscription before understanding the spike risks locking in the wrong baseline.
Investigation steps:
- Use cost and billing analysis to break the increase down by product and by time. Identify which product(s) drove the delta and on which days it started.
- For ECS, check whether the variable fleet ran larger or longer than usual, and whether instances were left running (orphaned or non-autoscaled). Check instance family changes.
- For OSS, separate storage cost from request cost. A request-cost spike with flat storage suggests an access pattern change (e.g., a job scanning many small objects, or a misconfigured client). Storage growth of 5 TB/month is expected and does not explain a jump.
- For NAT Gateway, examine data-processing volume and connection counts; a sharp rise often means traffic that used to stay internal now egresses, or a runaway client retry loop.
- Correlate with ActionTrail and change logs to find configuration changes around the spike date.
Likely culprits given the mix: an autoscaling or runaway-fleet issue on ECS; a request-heavy access pattern or lifecycle misconfiguration on OSS; and increased NAT data processing from changed traffic routing or retries. The investigation should produce the specific driver, not just a total.
2. Given the findings, what commitment and storage strategy would you recommend, and why is an all-upfront 1-year subscription for everything unwise?
Read the worked answer
Match commitments to the stable, predictable portion and leave the variable portion flexible.
- ECS: the ~40 always-on instances are a good fit for a subscription/commitment (e.g., a 1-year commitment on that baseline), because they run continuously and the discount is realized. The 10-30 variable peak instances should stay pay-as-you-go or use a flexible mechanism, because committing to peak capacity pays for idle time.
- OSS: enable lifecycle rules to transition objects not accessed in 180+ days to a lower-cost storage class (e.g., infrequent access or archive), and consider a storage package for the predictable baseline. This directly addresses the 200 TB with a large cold share, reducing both storage and, where applicable, request costs.
- NAT Gateway: fix the traffic driver found in the investigation (routing, retries) rather than buying around it.
Why not all-upfront everything: it commits the company to the current peak and to today's architecture, removes flexibility if the spike cause was a misconfiguration that gets fixed, and pays upfront for variable capacity that may shrink. Commit to the stable baseline, optimize storage with lifecycle policies, and fix the traffic issue; then re-baseline and consider further commitments.