阿里云ECS規格選型與彈性伸縮降本實戰指南

Flexera 2024年云成本報告里有一個刺眼的數據：企業上云后的平均資源浪費率仍高達32%。這相當于每三臺運行的云服務器中，就有一臺的錢是白花的。當“上云即省錢”的敘事紅利消退后，阿里云ECS規格選型與彈性伸縮降本正在從運維課題上升為企業財務紀律的硬指標——它不是要你少用云，而是要你把每一分錢花在真實的負載上。

一、阿里云ECS成本優化為何成企業剛需

多數技術團隊對上云成本的感知停留在“月賬單沒超標就行”，但拉出七天的資源利用率曲線圖，CPU常年趴在15%-25%的實例比比皆是。問題不在于團隊不關心成本，而在于缺乏業務畫像后本能地按峰值配置——這是一種安全冗余思維，卻成了成本泄漏的最大敞口。當單條業務線的月消耗從五位數滑向六位數時，規格選型就不再是技術偏好問題，而是一個需要被量化治理的財務問題。彈性伸縮和精準選型，本質上是同一件事的兩面：讓資源供給曲線盡可能貼合業務負載曲線，而非始終準備著那場永遠不會同時到來的流量洪峰。

1.  云資源浪費三大源頭

云資源浪費并非來自某個單一決策失誤，而是三重慣性疊加的結果。第一重是按峰值靜態配置——團隊為應對每年可能只出現兩次的流量尖峰，讓實例全年運行在頂配規格上，日常利用率不足30%。第二重是業務波動響應滯后，促銷結束三天后實例才縮容，甚至忘記縮容，導致按量付費的資源持續空轉。第三重是跨團隊資源孤島，不同業務線各自申請實例卻無統一標簽和分賬機制，沒人能說清哪臺機器還在用、哪臺早已閑置。三重慣性環環相扣，單靠人工巡檢根本破不了局。

2.  彈性伸縮的降本價值

彈性伸縮的降本邏輯不是“少買機器”，而是把固定成本轉化為可變成本。以一個日均CPU利用率從25%提升至65%的無狀態應用集群為例，通過設置基于平均CPU使用率的伸縮規則，高峰時段自動擴容、低谷自動縮容，可將原本按峰值常駐的實例數量壓縮至原來的三分之一到二分之一。配合負載均衡的會話保持和優雅下線機制，縮容不會造成業務中斷。彈性伸縮的冷卻時間和步長設置才是真正考驗功力的地方——過短引發抖動，過長則浪費，這個參數的調優決定了伸縮策略是降本工具還是故障觸發器。

3.  選型失誤的隱性成本

選型失誤的代價通常不會出現在任何一張賬單報表上，但它實實在在地侵蝕著性能底線和成本結構。用通用型g7實例跑高IO的數據庫場景，為彌補云盤性能短板不得不掛載更高規格的ESSD PL3云盤，最終月成本反而高于直接選用本地SSD的i4實例。另一個更普遍的誤區發生在輕量級場景：開發測試環境、微服務網關這類大部分時間低負載、偶有突發的業務，使用標準實例全額付費，而實際上T6突發性能實例在滿足基準性能的前提下，利用CPU積分應對峰值，可將這部分的支出壓降40%到60%。選型的本質不是挑配置，是匹配工作負載特征——算錯這一步，后續所有優化都是在錯誤基線上修補。

二、ECS實例規格選型的核心方法

云上資源浪費已是公開的秘密，Flexera 近幾年的報告持續指向一個數字：企業平均有 30%–45% 的云支出被閑置資源吞噬。根因很少出在“買少了”，而在于“選錯了”——用計算優化型實例跑純內存緩存，或者給偶發低負載的測試環境配置標準規格，這類錯配導致的隱性成本遠高于單價本身。真正有效的規格選型，不是對比配置表上的 vCPU 數量和內存數字，而是把工作負載的特征翻譯成實例規格族的參數約束。以下三個維度基本決定了選型是否準確。

1.  vCPU 與內存配比：從業務畫像出發，而非憑峰值估算

很多團隊不敢縮減資源規模，根源在于缺乏業務畫像，只能按照想象中的峰值配置。結果一批實例的 CPU 和內存使用率常年徘徊在 30% 以下，即使偶爾沖到 50%，也遠未觸及瓶頸。更危險的做法是盲目追隨“一線配置”：用通用型實例去承載高并發計算任務，或者把數據庫這種內存敏感型應用塞進計算優化型實例里，導致性能不達預期后又被迫升配，花了兩份錢。

正確的姿勢是以 7–15 天的資源利用率數據作為選型基線。從云監控中拉取 CPU、內存、網絡和磁盤 I/O 的時間序列，區分穩態均值和真實峰值，而不是憑經驗下判斷。計算密集型應用（如批量處理、視頻轉碼）通常需要更高的 vCPU 配比，內存與 vCPU 的比例可以低至 1:2 甚至更低；而內存密集型場景（如 Redis、JVM 堆大的 Java 應用）則應挑選內存與 vCPU 比例達到 1:8 甚至更高的規格。通用型實例只適用于沒有明顯資源偏好的均衡負載，強行用一個規格族覆蓋所有場景，意味著至少有一半的工作負載在持續浪費資源。主流云平臺提供的資源優化建議工具也可以快速定位閑置或過量配置的實例，但最終的判斷仍需工程團隊結合業務特點做出，工具只是縮短了數據收集的時間。

2.  網絡與存儲性能影響：規格族差異并非只體現在 CPU 和內存上

不少人選型時只盯著 vCPU 和內存，卻忽略了實例規格對網絡帶寬、存儲吞吐和 IOPS 的隱含限制。這在高 I/O 和網絡轉發密集的場景中幾乎必然踩坑。一個典型的案例是關系型數據庫：如果使用通用型實例掛載云盤，數據庫的高并發隨機讀寫很快就會壓滿云盤的 IOPS 上限，而改用帶有本地 NVMe SSD 的存儲優化型實例（如 i 系列），不僅能獲得更高的 IOPS 和更低的延遲，單 IOPS 成本反而更低。同樣，對于用于流量轉發、網關或高頻消息收發的服務，網絡增強型實例的包轉發率和帶寬上限遠高于通用型，用后者去承載等于人為制造瓶頸，再靠水平擴展去彌補，算下來總成本往往更高。

因此，在選型階段就需要明確應用的 I/O 和網絡傾向。磁盤 I/O 密集應用應優先考慮存儲增強或本地 SSD 實例，而非通過疊加高性能云盤來拼湊性能；網絡密集型應用則需要關注實例規格族標稱的網絡帶寬和收發包能力，避免在負載升高后出現帶寬削峰。如果已經上線的業務因存儲或網絡性能不足而頻繁抖動，第一步不應是盲目升配，而是檢查當前規格族是否與 I/O 模式匹配——更換為正確的規格族，有時不需要增加多少預算，就能讓延遲指標大幅改善。

3.  突發性能實例：輕量波動的低成本解，但不是免費午餐

突發性能實例（如 t5、t6 系列）利用 CPU 積分機制，在基準性能之上可以短時間爆發，特別適合平時低負載、偶有峰值的輕量級場景，比如開發測試環境、微服務容器集群中的低流量節點、輕量 Web 服務器等。在滿足基線性能的前提下，這類實例相比同 vCPU 的標準實例可以節省 40%–60% 的成本，是很多團隊容易忽略的降本杠桿。

但關鍵誤區在于把“突發”當成“常態”。CPU 積分一旦耗盡，實例性能會被嚴格限制在基準線附近，任何超出基準的計算需求都會變得極度緩慢。因此，突發性能實例不應承載存在持續高負載的服務，也不適合作核心數據庫或延遲敏感的在線業務。更值得警惕的操作是把競價實例當作穩定承載來用——雖然競價實例折扣可達 90%，但其隨時可能被回收的特性決定了它只適合無狀態、容錯性高的批量任務或 CI/CD 流水線，如果把它當作持久化應用的常駐節點，穩定性風險會完全對沖掉成本收益。正確的做法是，將穩定長線的基礎負載交給預留實例或節省計劃覆蓋，將彈性波動的部分交給伸縮組的突發實例和按量實例混合承擔，這樣既能享受高折扣，又不會因為實例回收而導致業務中斷。

三、彈性伸縮策略設計與關鍵配置

彈性伸縮不是簡單的“加機器、減機器”，而是一套需要精心調校的自動化運維體系。根據 Flexera 2023 年的云成本報告，企業平均有 32% 的云支出被浪費，其中伸縮策略配置不當是第二大貢獻因子——僅次于資源規格超標。問題通常不在伸縮本身，而在規則設計上過于粗糙：要么閾值設置不合理導致反復抖動，要么冷卻時間欠缺讓擴容變成“應激反應”。

1.  規則配置：定義什么是“真的忙”

指標選擇和閾值設定直接決定伸縮質量。CPU 平均使用率是最常見的觸發指標，但它在不同場景下的意義完全不同。對于計算密集型應用（如視頻轉碼），CPU 超過 70% 確實意味著算力吃緊；但對于 IO 密集型應用（如消息隊列），CPU 可能還在 40%，磁盤 IOPS 已經打滿。正確的做法是基于應用畫像選擇指標組合——至少接入兩種指標做“與”或“或”的判斷。一個實際案例是，某電商平臺的訂單服務伸縮策略從單一 CPU 閾值改為“CPU>65% 且 QPS>5000”后，無效擴容次數下降了 70%，因為過濾掉了數據庫慢查詢導致的 CPU 假性飆高。

阿里云的伸縮規則支持定時、指標、混合三種模式，推薦采用“指標打底、定時修正”的策略。指標規則確保日常彈性響應，定時規則處理已知的業務高峰期（如每晚 8 點促銷、每周一晨會流量高峰），避免指標規則的滯后性——因為從監控觸發到實例就緒通常有 2-3 分鐘延遲，對于瞬間涌入的流量沖擊，這個窗口足以讓服務雪崩。

2.  最大實例數的隱性風險

“最大實例數設高點，反正用不上也不會收費”是常見的認知陷阱。實際上，設上限不只是成本控制，更是安全閥。2022 年某 SaaS 公司因代碼缺陷導致死循環，每個請求都新建線程并占用內存，監控系統判定“負載升高”觸發擴容，從 10 臺一路擴到 200 臺——最大實例數設了 1000 且沒有告警。三小時后運維發現時，賬單已增加 4 萬元。正確的做法是：最小實例數由基礎可用性決定（至少 2 臺跨可用區），最大實例數按預算上限換算（比如月度預算 ÷ 單實例小時單價 ÷ 30×24），并設置擴縮容通知推送到企業微信或釘釘。

冷卻時間同樣是“省錢細節”。過短的冷卻時間（如 120 秒）會導致“擴-縮-擴”的乒乓效應，不僅增加按量實例的計費時長（最短 1 小時起算），頻繁創建銷毀還可能在系統內部產生臟數據。建議默認冷卻時間設置為 300-600 秒，讓新實例有足夠時間完成應用啟動、預熱和流量接入，也讓監控數據積累至少兩個采樣周期后再判斷是否繼續擴縮。對于 Java 類重啟動應用，這個值可以拉長到 900 秒。

四、基于實際負載的規格降本技巧

Flexera 2024年的云成本報告再次印證了那個尷尬的現實——大多數企業的云資源浪費率依然穩定在30%上下。根本原因不是企業不想省，而是不敢動。運維團隊往往抱著“寧濫勿缺”的心態，用峰值負載做常配，導致大量ECS實例的CPU和內存利用率常年低于30%。真正的降本，不是簡單關掉幾臺機器，而是從理解負載的底層特征開始。

1.  從歷史監控數據重構實例選型邏輯

憑經驗估算配置的時代該終結了。一個被反復驗證的操作路徑是：導出云監控中至少7到15天的CPU、內存、網絡吞吐和磁盤IO數據，畫出負載曲線，區分出真實峰值、平均水位和波動脈沖。這三條線能告訴你完全不同的答案。

多數人只看峰值，結果就是為每天可能只出現20分鐘的尖峰配置了24小時的高規格實例。一個典型的例子是跑數據庫的實例，如果平均IOPS穩定在3000以下但峰值能沖到12000，用本地SSD實例（如i3系列）疊加云盤，性能比通用型g7強制掛載ESSD PL3更穩定，單實例月成本反而能降25%以上。原因在于存儲I/O密集型負載對實例的底層帶寬和隊列深度有硬要求，通用型實例的虛擬化開銷在持續高IO下反而會成為瓶頸。這里的關鍵認知是：升配不一定解決問題，錯配才是成本的根因。

對于輕量級Web服務器、微服務或開發測試環境，T5/T6這類突發性能實例的降本效果被嚴重低估了。這類實例通過CPU積分機制運行，只要基線性能能滿足日常負載，偶發的請求尖峰由積分消化，實際成本可比同等配置的標準實例低40%到60%。但這里有一個硬約束——積分耗盡后CPU會被限流，所以不適用于持續高負載的場景。判斷標準很直接：如果監控顯示CPU平均利用率持續高于基線性能，說明該用標準型了；如果只是間歇性脈沖，突發實例就是最優解。

2.  用混合計費模型搭建穩態與彈性分離的架構

實例選型解決的是單點資源利用率問題，但規模化降本的核心在于將工作負載按“穩態”和“彈性”拆開處理。這是一個被Gartner反復驗證的成本優化范式：7×24小時運行的穩定基礎負載，最適合被預留實例或節省計劃覆蓋，一年期或三年期的承諾折扣可以把這部分成本壓到底；而促銷流量、定時任務、批處理這類可預判的彈性負載，交給按量實例或競價實例處理。

實操中最常見的錯誤是拿競價實例跑持久化應用。競價實例折扣高達90%不假，但它的釋放機制是隨時隨地的，只適合無狀態、可重試、容錯性高的任務——CI/CD流水線、無狀態API網關、批量數據處理。一個合理的混合比例是：底層30%預留實例覆蓋基本水位，30%按量實例應對正常波動，剩余40%用競價實例承接彈性部分。這個配比在保證服務可用性的前提下，能將整體計算成本壓縮到純按量部署的50%到60%。

伸縮策略本身也需要成本治理。不設最大實例數上限的伸縮組，遭遇應用死循環或外部攻擊時可能觸達賬戶配額上限，這個賬單對財務團隊的沖擊遠超運維的預期。冷卻時間過短則會導致頻繁擴縮，每次伸縮活動本身有開銷，抖動帶來的業務影響更是隱性成本。一個成熟的實踐是：最小實例數錨定基本可用性，最大實例數嚴格參照預算上限和賬戶配額設定，同時對競價實例中斷設置SNS或云監控告警，在釋放前30秒的預警窗口內完成流量摘除，避免異常蔓延到用戶側。

五、構建持續優化的成本治理閉環

將規格選型與彈性伸縮真正轉化為成本競爭力，不能靠一次性調整，而需要建立起一套持續發現、調整、驗證的治理閉環。多家調研機構的數據指向同一個事實——企業云資源浪費率長期在 30%–45% 區間徘徊，其中規格不匹配與缺乏動態調整機制是最大的成本泄漏點。正因為如此，優化不會止于一次“削峰填谷”，而必須嵌入日常運維流程。

1.  關鍵監控指標與告警

成本治理的起點是全面且準確的監控，而非事后的賬單驚訝。CPU 利用率、內存使用率、網絡吞吐量及磁盤 IOPS 四個維度的長周期數據，是判斷規格是否匹配的核心依據。大量團隊習慣于只看 CPU，卻忽視內存或 IO 瓶頸——例如將數據庫跑在通用型實例上，CPU 尚可但云盤 IOPS 打滿，導致響應延遲上升，被迫升配，實則換成本地 SSD 實例性能更優、成本更低。因此，監控至少要以 7 天為最小窗口，采集峰值、平均值與 P99 延遲等分位數，才能有效定位真實資源畫像。

更重要的是，監控必須與告警聯動。突發性能實例在 CPU 積分耗盡后，性能會被限制在基線以下，若缺乏積分余量告警，輕量 Web 或開發環境就可能突發降級，影響業務。伸縮活動同樣需要獨立告警：伸縮失敗、達到最大實例數上限、競價實例被提前釋放等事件，都應在幾分鐘內推送到運維群組。沒有這類實時告警，彈性伸縮反而可能成為“靜默故障源”——實例擴不出來，服務靠存量硬撐，待發現時已經上演流量事故。實踐中，我們建議至少設置三層告警：資源水位告警（如 CPU 持續高于 70% 觸發擴容評估）、容量邊界告警（最大實例數觸碰預警）、以及特定實例類型風險告警（競價實例中斷通知），將成本優化約束在安全邊界之內。

2.  定期優化流程與工具

閉環的核心在于將監控數據轉化為具體動作，并以固定節奏執行。每兩周或每月進行一次“資源瘦身”迭代，是被驗證行之有效的方法。借助云平臺提供的資源優化建議，可以快速篩出長期低負載實例——比如 CPU 和內存連續 14 天低于 30% 的機器，列為降配或釋放候選。但要注意，直接看平均值容易漏掉周期性的短時高峰，因此優化建議必須結合業務“生物鐘”：若一個實例每天凌晨 2 點有 5 分鐘的 100% CPU 批處理，平時幾乎空閑，降配可能致任務超時。此時更優解是將其遷入突發性能實例，或歸并入彈性伸縮組，以定時任務觸發臨時擴容，而非保留過量規格。

工具層面，云監控導出的性能數據可以直接導入自建的選型分析表，對不同業務線建立“資源效能比”模型。例如，每單位 CPU 核數支撐的并發請求量、每 GB 內存承載的緩存命中率等，當效能指標出現 15% 以上偏離，就觸發規格重選評估。此外，定期拉取未使用資源報告——未掛載的云盤、閑置公網 IP、未釋放的彈性網卡等附帶資源，是極易被忽視的成本長尾，處置這些“僵尸資源”能帶來立竿見影的賬單下降。這種周期性的清理動作，應作為固定議題納入團隊雙周運維復盤。

3.  跨團隊成本治理實踐

多云賬號、多業務線場景下，成本治理的最大障礙往往不是技術，而是責權不清。沒有嚴格的標簽規范與分賬機制，優化就找不到對象——賬單上一條數千元的支出，不知道對應哪條業務線，沒人認領，也就沒人負責優化。因此，資源強制打標是治理閉環的第一道硬性門檻。標簽維度至少應覆蓋“團隊-業務-環境”，例如“數據平臺-實時推薦-prd”，并利用云平臺的標簽策略禁止創建無標簽資源。

在此基礎上，每兩周按標簽維度導出賬單，計算各業務線的單位運營成本——例如每千次 API 請求的實例成本、每 TB 緩存數據的資源開支。數據公開透明后，成本意識才會從運維擴散到產品和研發團隊。我們發現，當研發團隊看到自己名下開發環境一個月花費數千元，且 70% 時間處于閑置時，會自發推動資源降配或引入突發實例，而非一味要求“規格不變”。更進一步，可設立成本優化專項預算，將節省金額的一定比例用于團隊激勵，驅動由下而上的治理文化。最終，監控、優化、復盤三個齒輪咬合運轉，規格選型與彈性伸縮才能在動態業務中持續兌現降本承諾，而不是淪為一次性的紙上方案。

六、企業降本典型場景與案例解析

把云資源成本單純歸咎于“用了太多機器”是一種偷懶。在一線實操中，真正的主因往往是兩個錯配：實例規格與實際負載的錯配、資源供給與業務節奏的錯配。下游的賬單只是結果。以下三個典型場景，分別對應周期性爆發、實時波動和長期穩態下的資源治理，它們共同證明一件事——正確的規格選型與彈性伸縮設計，可以把浪費的那30%–45%云支出找回來，且不犧牲服務等級。

1.  電商大促彈性應對：從“為峰值買單”到“為真實負載編程”

一家年GMV超十億的垂直電商，常年在300多臺ECS上跑著微服務化后的商城主站、訂單、商品和推薦鏈路。過去為了扛住雙11和618，技術團隊按預計峰值流量的1.3倍進行預留，大促結束后的兩周內再手動縮容。這種做法造成了兩個慢性病：日常CPU平均利用率僅17%–23%，但無人敢把整體規模壓下去；突發大流量時，手工擴容的速度跟不上流量爬升的斜率，某年大促前10分鐘因擴容延遲曾導致短暫限流。

他們把優化拆成兩件事：穩態基線重塑和峰值彈性解耦。

首先基于連續14天的云監控數據（CPU、內存、網絡吞吐及磁盤IOPS），將24小時常駐的服務群體做了規格重匹配。商品和推薦這類計算密集型服務從原先的通用型g5遷移到計算型c6，利用更高主頻和計算優化，單實例QPS吞吐提升了約26%，反而可以減少28%的常駐實例數。訂單、支付等邏輯復雜但計算密度不高的服務，則保留了通用型，改為一年期預留實例加節省計劃，階段性折扣把固定開銷削掉約35%。一個常被忽視的點是：大量非核心的輕量Web前端、管理后臺以及預熱緩存，被遷移到了突發性能T6實例上，依靠CPU積分應對偶爾的管理并發，該項變動使得該部分年成本下降了約52%。

彈性的部分，用上了“定時+指標”雙模伸縮。大促前1小時，按照預定計劃將伸縮組的最小實例數拉高到穩態的3倍，同時配置基于平均CPU利用率（閾值75%）的追蹤策略，一旦定時擴容未能完全覆蓋秒級流量尖峰，指標伸縮立即補位。伸縮組內混合配置了c6和c6a兩個實例規格族，防止單一規格庫存不足導致擴容失敗，這一做法在當年雙11零點自動擴容成功率保持在99.7%以上。冷卻時間設在300秒，避免了頻繁抖動；縮容策略則使用“先停止、再終止”，給連接優雅關斷留出15分鐘窗口。

最終效果很直觀：全年總計算成本同比下降41%，大促零限流、零緊急人工干預，日常CPU利用率抬升到45%左右，不再為“一年只跑72小時的峰值”支付全部賬單。

2.  游戲服動態擴容：把競價實例用在正確的地方

一個主打MOBA玩法的游戲工作室，各區服采用“戰斗服+大廳服”的經典架構。波峰波谷極不規則——晚間和周末在線人數是凌晨的4～8倍，且新賽季開始的第一周會出現難以預測的超高峰。先前一律采用固定的高配通用實例，單戰斗服承載上限鎖定，擴容依賴運維批量跑腳本，縮容靠人工判斷，很容易漏掉凌晨低負載的閑置資源。一次賽季更新當天，因擴容跟不上涌入的玩家，多個戰斗服排隊嚴重，流失慘重，而服務器賬單里，凌晨CPU不足10%的實例占了很大一部分。

改造的核心思路是：把延遲敏感的常駐會話與可中斷的非關鍵任務拆開，用不同實例類型與計費模式匹配。

戰斗服和游戲邏輯對網絡時延和穩定性要求極高，保留7x24小時運行的預留實例，規格從通用型改為網絡增強型實例g6e，充分利用高網絡包收發能力來降低玩家指令的尾部延遲。大廳、匹配、聊天等無狀態且有明顯波動的服務，接入彈性伸縮組，基于“平均網絡連接數”這種更貼近游戲在線的指標來自動擴縮。夜間最低保留實例數設為白天的1/4，冷卻時間配合游戲房間生命周期設置為600秒，避免縮容過快導致正在對戰的房間被銷毀。

真正的點睛之筆是引入了競價實例，用于處理批量計算任務——賽季結算、離線排名計算、回放數據分析。這些任務允許中斷和重試，本身就適合搶占式資源。工作室將此類任務打包成容器化作業，放進混合伸縮組，底層60%為按量實例保底、40%為競價實例，一旦競價實例被回收，任務調度器自動轉移到新的競價實例上重新執行。這個組合使這部分算力的成本降至原先的不到1/3。

整個改造后，月度計算成本下降57%，擴容響應從原先的平均15分鐘縮短到不到90秒，縮容不再依賴人工，閑置資源被控制在極低水平。唯一的代價是需要工程團隊接受“競價實例隨時可能消失”的事實，并在代碼層面做好檢查點和斷點續算——這筆一次性投入在長期成本面前基本可以忽略。

3.  SaaS平臺資源優化：標簽治出來的35%空間

一家服務逾千家企業客戶的B2B SaaS平臺，在同一阿里云賬號下同時維護著生產、預發、測試三套環境，多條業務線（CRM、協同、數據分析）共享底層資源。財務一直反映云成本年增長30%以上，但技術側卻說不清每一條業務線具體花了多少錢，只能粗略平攤。翻開資源清單，數百臺ECS實例里，運行I/O密集型數據庫和搜索服務的竟有相當比例是通用型g5，磁盤延遲高、抖動頻繁，為了彌補性能被動升配，內存和vCPU大量閑置；開發測試環境24小時開著標準實例，周末和夜間幾乎零負載，卻在持續計費。

治理分三步走。

第一步，強制標簽與分賬。所有資源按“業務線-環境-負責人”三級標簽打標，利用分賬賬單將每條業務線的計算、存儲、網絡成本暴露在各自的負責人面前。透明本身就是一種壓力。

第二步，規格重映射。數據分析業務的ClickHouse和Elasticsearch集群，對磁盤吞吐和IOPS極其敏感，之前用通用型疊加ESSD云盤，性能瓶頸在云盤的帶寬上限。將這些節點遷移到搭載本地NVMe SSD的i3實例后，查詢延遲下降了40%，并且因為性能釋放，集群總節點數從24個減少到16個，直接省下1/3的硬件成本。CRM業務的大量無狀態應用，從標準規格遷移到同代計算優化型c6，實例數不變但資源利用率更健康。

第三步，用彈性解決環境與時段浪費。測試環境和預發環境全面改用突發性能T6實例，基線和積分機制剛好覆蓋白天的低頻率訪問，夜間的低頻負載幾乎不消耗積分，無需額外付費。同時針對測試環境設置定時伸縮：工作日23:00至次日7:00將最小和期望實例數收縮為0，僅保留必要的數據卷和快照；早晨再自動恢復，每月為此節約的非生產環境費用達原有水平的62%。生產環境中，那些按固定周期跑批的任務（每日凌晨2點運行的報表計算），通過一次性伸縮組觸發一批競價實例執行，結束后自動釋放，保證功能不缺失的同時不占用穩態資源。

三個階段走完，年度云成本增速由30%回落到個位數，絕對金額降低35%，更重要的副產品是：每條業務線的單位服務成本（Cost per Tenant）第一次被精確量化，為后續的定價和資源投入決策提供了清晰依據。這件事說明，當技術架構與財務治理并行時，降本才真正可復現、可持續。