Oracle 悄改 Always Free 規則，Ampere A1 額度砍半，6 月 15 日超標帳號將被關機或者收費

重點摘要

• Oracle 未發布任何公告，將 Always Free 方案的 Ampere A1 Compute 上限從 4 OCPU / 24 GB 記憶體削減至 2 OCPU / 12 GB，月度運算時數同步減半，降為每月 1,500 OCPU 小時與 9,000 GB 小時，所有指標全面縮水 50%。
• 6 月 15 日為執行截止日：免費帳號超標執行個體將全數停用，30 天後刪除；Pay-As-You-Go 帳號超標部分則直接開始計費，不會強制關機。
• Oracle 官方文件目前存在版本不一致：Always Free Resources 頁面已更新為新上限，但 Free Tier Overview 頁面截至截止日仍顯示舊有的 4 OCPU / 24 GB 數字，可能讓工程師錯誤判斷自身是否合規。

2026 年 6 月 12 日前後，Oracle 悄然更新 Always Free Resources 官方文件，將 VM.Standard.A1.Flex 執行個體的免費配額由 4 OCPU 與 24 GB 記憶體削減至 2 OCPU 與 12 GB 記憶體，月度運算時數亦從每月 3,000 OCPU 小時、18,000 GB 小時縮減為 1,500 OCPU 小時、9,000 GB 小時，所有指標全面減半。根據 Linuxiac 的報導，整個過程沒有任何部落格文章、新聞稿或客戶通知說明此次變更的原因、生效日期，或對現有部署的影響。正在使用免費層 Ampere A1 的開發者與工程師，6 月 15 日是目前可知的唯一操作截止日，而這個日期本身，也只是從文件更新後才得以推算。

「無聲調降」：工程師社群為何比調降本身更在意？

規格縮水是事實。但社群的討論燒起來，燒的是另一件事。

這次爭議的核心，在於 Oracle 跳過任何事前說明就完成變更。社群指引作者 rssnyder 在 GitHub Gist 留言中標記了這個問題。他直接寫道：「Oracle 已悄悄將免費層的上限改為 2 核心 / 12 GB 記憶體。」這句話幾乎成為這波討論的引言縮影，也準確標示了工程師社群最根本的不滿：對雲端資源的依賴，建立在「規則異動會提前說明」的隱性假設上，而 Oracle 這次打破了這個假設。

Ampere A1 的 Always Free 配額對自架服務的工程師有特定吸引力。原本 4 OCPU / 24 GB 的配置讓使用者有充裕空間部署各式服務，降至 2 OCPU / 12 GB 後，現有的執行個體若未在截止日前完成整改，就會觸發停用機制。Oracle 沒有任何預警的變更方式，把規格調降轉成了信任問題。

Linuxiac 的報導指出，沒有任何公開說明能解釋縮減的原因、生效日期，以及對現有部署的衝擊。使用者只能自行比對不同版本的文件才能發現這次變更，無法透過電子郵件或服務儀表板收到通知。Oracle 是否曾向現有帳號持有者寄送任何直接通知，目前無公開資料可以確認。這個問題未必有答案，卻正是工程師社群無法繼續假裝信任的原因。

6 月 15 日的兩種結局：停機還是帳單？

截止日期對兩類帳號設計了不同的懲罰邏輯，後果各有不同，但整改期限相同。

純粹的 Always Free 帳號超出新配額，後果比多數人預期的更全面。Oracle 官方 Free Tier 文件明確說明：若租戶的 A1 執行個體總量超過免費配額，「所有現有的 OCI Ampere A1 執行個體都將立即停用」，並於 30 天後刪除，除非帳號在此期間升級為付費方案。「全有或全無」：只要有一台執行個體超標，帳號下所有 A1 資源都會停用，不只是超標的那台。工程師若在同一租戶下同時跑多個 A1 執行個體，尤其需要注意這個整體計算的方式。

Pay-As-You-Go 帳號的處理方式不同，但風險同樣具體。Viren070 的指引整理指出，PAYG 帳號超出新免費上限的部分，將從 6 月 15 日起直接計費，不會強制關機。習慣把 Oracle 免費層當作「不需要設費用警示」的工程師，可能在月底帳單上看到意料之外的費用。

針對這兩種情形，Viren070 建議幾個具體步驟：將 A1 執行個體縮減到 2 OCPU 與 12 GB 以內，同時啟用成本分析預測功能，並設置從 1 美元起跳的預算警示。1 美元門檻的設計邏輯在於，一旦帳號出現任何計費行為，警示就能在費用累積之前發出訊號，讓使用者有機會及早介入，而不是等到月結帳單出來才發現問題。

閒置回收與文件矛盾：兩個容易忽略的額外風險

6 月 15 日的截止日期把注意力集中在規格調降，但 Always Free Resources 文件也提醒了另一個長期存在的機制：閒置執行個體回收。若 A1 執行個體在連續 7 天的滾動窗口內，CPU 使用率（第 95 百分位）、網路使用率與記憶體使用率全部低於 20%，Oracle 有權回收該執行個體。

這個機制對那些「只是備著、不常跑」的執行個體影響最為直接。若工程師在免費層維護一台測試環境或偶爾才需要啟動的服務，這種低負載的使用模式恰好符合回收觸發條件，執行個體可能在工程師未作任何操作時就消失。規格調降加上閒置回收，免費層使用者需要同時在兩個維度確認執行個體狀態：一是規格是否符合新上限，二是使用率是否落入觸發回收的門檻。這兩個條件各自獨立，缺一不可。

與此同時，文件的版本不一致進一步增加了判斷難度。截至 6 月 15 日，Free Tier Overview 頁面（freetier.htm）仍顯示舊有的 4 OCPU / 24 GB 數字，而 Always Free Resources 頁面（freetier_topic-Always_Free_Resources.htm）已更新為 2 OCPU / 12 GB 的新上限，並列出每月 1,500 OCPU 小時與 9,000 GB 小時的月度配額。兩頁同屬 Oracle 官方文件，卻記載不同的數字。第一次查詢的工程師若只找到 Overview 頁面，可能錯誤判斷自己仍在合規範圍，進而錯過整改截止日。

Viren070 的指引標注，文件大約在 6 月 12 日前後完成部分更新，但 Oracle 並未說明何時或是否會完成兩頁內容的同步。這種不一致本身就說明了這次調降的推進方式：內部決定在先，文件更新隨後跟進，對外說明至今仍不完整。這三件事依序發生，卻沒有任何一個環節伴隨正式的使用者溝通。

這次事件給使用 Oracle 免費層的工程師留下幾個實務教訓：第一，免費方案的規格本質上不受合約保護，可以隨時調整，且不一定伴隨提前通知。第二，雲端帳號即使使用的是免費方案，也應該設置費用警示，從低門檻開始，才能在帳號狀態發生意外變化時儘早察覺。第三，查閱官方文件時，若同一平台的不同頁面顯示矛盾資訊，應以限制更嚴格的那頁為準，而不是以對使用者最有利的那頁為判斷依據。

截至本文完稿，Oracle 仍未就此次變更提供任何公開解釋，也沒有資料顯示現有使用者能獲得規格豁免或緩衝期。2026 年 6 月 12 日，Oracle 悄然更新了一頁文件，改了幾個數字。6 月 15 日，這幾個數字決定哪些執行個體繼續運行，哪些從帳號裡消失。