模組是橫切的：任何一階實作時都可能需要先在某一家開帳號。內容的歸屬規則是：成熟度階梯的模組放 vendor 中立的概念，正文的範例以 AWS 為參考實作，但不收某一家的完整實作篇；這個模組的根目錄放跨業者、在主控台與帳號層操作的內容（建立主機的選項、主控台的管理領域、免費額度比較）；某一家的實作與實測紀錄放在業者子資料夾，例如管理通道在 GCP 上的 IAP 實作、帳單停損在 GCP 上的建置。概念文章連到業者子資料夾，業者子資料夾的每一篇連回它實作的那個概念。

章節文章

子資料夾

依 weight 排列（list.html 先列子資料夾、再列文章，所以兩篇根目錄文章在列表頁排在子資料夾之後）：

• 建立雲端虛擬機的選項：vendor 中立，依功能分類一類一篇（位置、機型與映像檔、網路、登入、磁碟、代理程式與維護、安全開機）
• Oracle Cloud：主控台導覽、帳號結構與 home region、CLI 登入、建立主機的實測紀錄
• Google Cloud：IAP 管理通道、MIG 與 GKE 的管理存取、帳單停損開關，三個主題各有一篇概念文章與一篇實測紀錄

新增一家業者時開一個子資料夾，在收費比較那篇補上那一家的欄位，再用下面這條掃一次，把寫死成目前業者組合的句子、並列句與對照表一起更新。掃描對象不寫死業者數，所以加過一家之後下一次照樣有效：

1rg -n "[一二三四五六七八九]家|其他兩家|另兩家|Google Cloud 與 AWS|AWS 與 Google Cloud|Oracle Cloud .*Google Cloud .*AWS" \
2  content/devops/infra/cloud-providers/ content/devops/infra/knowledge-cards/availability-zone.md \
3  content/devops/infra/knowledge-cards/fault-domain.md content/devops/infra/knowledge-cards/instance-metadata-service.md

跟其他模組的關係

• → 模組三：網路地基：管理通道的三層模型，各家實作的實測對照它
• → 模組八：成本管理：成本監控與計費模型；不分業者的預算門檻、信用卡額度、配額當費用上限與停損層級的推算在 租用雲端主機之前的費用規劃：費用訊號的延遲、停止之前的最大超支、扣款的信用卡額度、配額與預算門檻的計算，以及停損停到哪一層；要不要建停損，依據是各家試用結束後會不會自動開始計費
• → 接手維運：用主控台建好的資源要收進 IaC 時的匯入流程
• → 主機形態光譜：選 IaaS 之前先決定要管多少

Backlog

頂端列

登入後畫面最上面那一列，由左到右是：

• ☰（導覽選單）：所有服務的入口，內容見〈導覽選單的分類〉。選單上方有一個搜尋框，打服務名稱就列出它所在的分類，例如打 Bastion 會列出「Bastion · Identity & Security」。
• 搜尋（放大鏡）：搜尋資源與服務，也能用資源名稱找到某一台主機或某一個 VCN。
• 區域選擇器：目前選定的區域，例如「Indonesia North (Batam)」。清單頁只顯示這個區域的資源。
• Developer tools：兩個項目，Cloud Shell（瀏覽器裡的終端機，已經裝好 OCI CLI 並以目前登入的身分驗證，不必在本機安裝 CLI 或設定金鑰）與 Code Editor。
• 通知（鈴鐺）：Oracle 的公告，包括排定的硬體維護。
• 說明（問號）：文件與支援的入口。
• 人像選單：從上到下是目前的使用者名稱、identity domain（tenancy 裡存放使用者與群組的分區，新帳號只有 Default 一個）、tenancy 名稱（tenancy 是 Oracle Cloud 的帳號，一個客戶一個）、介面語言、User settings（個人的密碼、多因素驗證、API 簽章金鑰與其他憑證）、Console settings、Sign out。點 tenancy 名稱進入 Tenancy Details 頁，那裡看得到 home region 與 tenancy 的 OCID（Oracle Cloud ID：Oracle Cloud 給每個資源的唯一識別碼，以 ocid1. 開頭，CLI 與 API 用它指定要操作的對象）。

Free Tier 帳號在試用期間，頂端列上方另有一條「Free Tier account」的橫幅，說明試用結束後只剩 Always Free 資源，並附 Upgrade 連結。

導覽選單的分類

選單左欄是分類，點一個分類，右側展開它底下的服務與頁面。實測的分類依序是：Home、Compute、Storage、Networking、Oracle AI Database、Databases、Analytics & AI、Developer Services、Identity & Security、Observability & Management、Hybrid & Multicloud、Migration & Recovery、Billing & Cost Management、Governance & Administration、Marketplace。管理一台主機會用到的是下面這幾類：

Compute：Overview、Instances、Instance Maintenance、Dedicated Virtual Machine Hosts、Instance Configurations、Instance Pools、Cluster Networks、Autoscaling Configurations、Capacity Reservations、Custom Images。建立與管理主機都從 Instances 進去。

Storage：Block Storage（Block Volumes、Block Volume Backups、Block Volume Replicas、Volume Groups 與它們的備份與複本、Backup Policies）、File Storage（File Systems、Mount Targets）、Object Storage & Archive Storage（Buckets、Private Endpoints）。開機磁碟不列在導覽選單上：進入任一個 Block Storage 頁面（例如 Block Volumes）之後，頁面頂端的「Storage」那一列可以展開，子選單裡有 Boot Volumes、Boot Volume Backups 等項目，刪除主機後留下的開機磁碟從這裡找。進入服務頁面之後，頁面頂端都有這樣一列可以展開的服務子選單，在同一個服務的各頁面之間切換用它比回導覽選單快。

Networking：Overview、Virtual cloud networks、Load balancers（Load balancer、Network load balancer）、DNS management（Public zones、Private zones 等）、IP management（Reserved public IPs、BYOIP、Public IP pools 等）、Network Command Center（Network visualizer、Network Path Analyzer 等）。VCN、subnet、security list、NSG、閘道都從 Virtual cloud networks 進入某一個 VCN 之後設定。

Identity & Security：Identity（Overview、Domains、Network Sources、Policies、Compartments）、Cloud Guard、Security Zones、Security Advisor、Certificates、Scanning（Vulnerability Reports 等）、Key Management（Vault 等）、Secret Management、Zero Trust Packet Routing，以及 Bastion。使用者與群組在 Domains 裡的 Default domain 底下管理。

Observability & Management：Application Performance Monitoring、Logging（Logs、Audit 等）、Monitoring（Metrics Explorer、Alarm Definitions 等）、Log Analytics、Events Service、Management Agent 等。主機的 CPU 與記憶體圖表在主機頁面上就看得到；跨主機的指標與告警從 Monitoring 進去。

Billing & Cost Management：Billing（Subscriptions、Invoices、Usage Statements、Payment History、Upgrade and Manage Payment）、Cost Management（Overview、Cost Analysis、Cost and Usage Reports、Budgets、Scheduled Reports、Cost Anomaly Detection 等）。

Governance & Administration：Account Management（Tenancy Details、Announcements、Region Management）、Cloud Advisor、Resource Scheduler、Tenancy Management（Resource Explorer、Tenancy Explorer、Quota policies、Limits, quotas and usage、Tag Namespaces）、Organization Management。

右側每個項目滑過時會出現「Press P to pin link」，釘選的項目出現在 Home 分類與首頁的 Pinned 區，常用的頁面釘起來就不必每次翻選單。

清單頁的 compartment 篩選器

Compartment 是 tenancy 底下用來分組資源與套用權限政策的容器，tenancy 本身是最上層的 root compartment，每個資源都建在某一個 compartment 裡。Instances、Virtual cloud networks、Block Volumes 這類清單頁的表格上方有一行「Applied filters」，其中的 Compartment 那一項篩選條件就是 compartment 篩選器，清單只列出選定 compartment 裡的資源。實測新帳號的預設是 root compartment，這一項篩選條件顯示為「<tenancy 名稱> (root)」。資源建在另一個 compartment 時，清單看起來是空的，要把篩選器切過去。建立頁上的下拉選單也一樣：VCN、subnet 的選單只列出「所在 compartment」那一欄選定的 compartment 裡的資源。

常用頁面的路徑

試用與 Free Tier 帳號只能有一個訂閱區域（就是 home region），升級成 Pay As You Go 之後還要先在 Limits, quotas and usage 申請提高 Subscribed region count，才能在 Region Management 訂閱第二個區域。

選單路徑對不上時（改版、介面語言不同），在導覽選單的搜尋框打表格裡的頁面名稱。

延伸閱讀：各頁面背後的概念

這些分類各自管什麼、Google Cloud 與 AWS 的對應名稱，見 雲端主控台的管理領域；從 Compute → Instances 進去之後建立頁每個分頁的取值，見 Oracle Cloud 建立主機的實測紀錄；Tenancy Details 頁上 home region 的意義與它對 Always Free 額度的限制，見 Oracle Cloud 的帳號結構與 home region。

區域（region）：主機在哪個城市

區域是一個地理位置上的資料中心群。Oracle Cloud 的區域識別碼帶城市（ap-tokyo-1），Google Cloud 與 AWS 用洲別、方位加編號（asia-east1 在台灣、ap-northeast-1 在東京），城市要查各家的區域對照表。區域決定主機的下面這幾種性質：

• 延遲：從使用者所在地連到主機的延遲主要由距離決定，量級上同一洲之內是幾十毫秒、跨洲是一兩百毫秒；實際的值用各家提供的區域延遲測試頁量，或從自己的電腦對那一區的服務端點量往返時間。
• 出口 IP 屬於哪個國家：主機對外連線時，對方看到的來源 IP 登記在區域所在的國家。要讓連線看起來從某個國家發出（例如自架 VPN），只有那個國家的區域符合。
• 資料受哪個國家的法律管轄：主機與它的磁碟實體上放在區域所在的國家，裡面的資料受那個國家的法規管轄。服務有資料落地的要求（個人資料不出境、產業法規指定存放地）時，能選的區域只剩那個國家或那個法域裡的區域。
• 能選的機型與服務：區域之間提供的機型不同，新開的區域常常缺幾種舊機型。一個區域實際提供哪些機型，要在那一區的建立頁或 API 上查，不能從另一區推。

主機建好之後不能搬到另一個區域。要換區域，做法是在新區域建一台新主機、把資料搬過去，再刪掉舊的。

免費額度常常綁在特定區域上：Oracle Cloud 的 Always Free 只能用在申請時選的 home region，Google Cloud 的 Free Tier 只適用於三個美國區域。Oracle Cloud 的 home region 在申請帳號時就定了、之後不能改，所以這一層在 Oracle Cloud 上要在申請帳號之前想清楚；Google Cloud 的區域在建立主機時才選，選在三個美國區域以外就不算免費。各家的區域限制見 雲端免費額度與小型主機的收費比較。

可用區（availability zone / availability domain）：區域裡的哪一棟

可用區是區域裡彼此隔離的資料中心，各自有獨立的電力、冷卻與網路，設計上不會同時故障。建立頁上的這個欄位決定主機落在哪一個可用區，知識卡見 Availability Zone（可用區）。

單一台主機選哪個可用區，影響的是兩件事：

• 容量：免費機型與熱門機型的容量是按可用區分配的。一個可用區回報容量不足時，同一區域的另一個可用區可能還有。換可用區是容量不足時的退路之一，其他退路（等待重試、不指定故障域、改小規格、建立前查容量、換架構、可被收回的容量、預留容量、升級付費帳戶）在 Oracle Cloud 上的完整清單，連同哪幾項會計費，見 Oracle Cloud 的帳號結構與 home region 的〈A1 容量不足時的退路〉。只有一個可用區的區域少了換可用區這條退路——Oracle Cloud 的商用區域多數只有一個可用區，有三個可用區的只有少數幾個，名單與查證日期見 Availability Zone（可用區） 卡；業者開新區域時這份名單會變，選區之前回到官方〈Regions and Availability Domains〉的區域表看一次。
• 磁碟與主機要在同一個可用區：開機磁碟與區塊磁碟屬於某一個可用區，主機只能掛同一個可用區的磁碟。從保留下來的開機磁碟重建主機時，新主機要建在那顆磁碟所在的可用區。

主機建好之後也不能換可用區，換的做法跟換區域相同。

故障域（fault domain）：同一棟裡的哪一組硬體

故障域是可用區內部的一組硬體與基礎設施，Oracle Cloud 的每個可用區有三個。它防的是兩種事件：某一組實體主機的硬體故障，以及業者對那一組硬體做的計畫性維護。一個故障域出事時，放在其他故障域的主機不受影響。知識卡見 Fault Domain（故障域）。

只有一台主機時，故障域沒有選擇的意義：不論放在哪一個，那台主機都只在一組硬體上。建立頁的預設「讓業者選」就是對的選擇，Oracle Cloud 會依當下的容量挑一個（實測紀錄在只有一個可用區的 ap-batam-1 就是這樣填的）。手動指定故障域還會縮小可用的容量：指定之後只接受那一個故障域裡的硬體。Oracle Cloud 的 Compute〈Known Issues〉頁對 Out of host capacity 列的處置裡，就有一項是不指定 fault domain 再建一次。

故障域的作用在兩台以上。同一個服務的兩台主機，區域有多個可用區時先分到不同可用區，因為可用區隔離的是整棟資料中心的電力與網路，範圍比故障域大（見 Availability Zone（可用區） 的〈設計責任〉）；區域只有一個可用區時，才靠故障域把兩台放在不同的硬體上，一組硬體故障時只停一台。跨可用區的代價是兩台之間的流量多一段距離：AWS 與 Google Cloud 對跨可用區的流量另外計費，兩台之間做同步複製時延遲也比同一個可用區裡高。

Oracle Cloud 允許建立之後修改故障域。AWS 與 Google Cloud 沒有故障域這個欄位，對應的功能是放置政策（AWS 的 placement group 用 spread 策略、Google Cloud 的 spread placement policy），作用同樣是讓一組主機分散到不同的實體硬體上。兩家都能套用到既有的主機：AWS 要先停止主機才能把它換進或移出 placement group，Google Cloud 的 spread placement policy 指定了多個 availability domain（官方的說明是彼此隔離、各自不同的一組硬體；它跟 Oracle Cloud 的 availability domain 同名、層級不同，Oracle Cloud 那一層對應的是可用區）時，官方說明可以不停機就套用到既有的主機；套用時 Compute Engine 可能要把主機搬到另一個 availability domain，搬的方式依主機的維護政策，是即時遷移或停止主機。

各家的欄位名稱：區域、可用區與故障域

Oracle Cloud 建立頁的 Placement 區塊裡另有一個 Capacity type 欄位，它決定的是計費與可被收回的條件，跟位置無關，說明在 機型與映像檔。

延伸閱讀：同一組選項的下一層

• 機型與映像檔：那一區能選哪些機型，以及容量不足時改小規格、換架構或改用可被收回容量各自的代價
• Oracle Cloud 的帳號結構與 home region：免費額度綁在區域上時，申請帳號那一刻就決定了位置；配額表列出某個機型、而那一區沒有那種硬體時，建立會失敗而錯誤碼分不出原因

免費方案的兩種額度：有期限的試用金與沒有期限的固定額度

三家的免費方案都由兩種性質不同的額度組成：試用金與固定額度。

試用金（free trial credits）是一筆有期限的金額，可以花在大部分付費服務上。有了它，試用期限內可以試用較大的機型或付費服務；期限一到、或金額用完，額度就結束。

固定額度是每個月重置、沒有期限的用量上限，只適用於指定的機型與服務。一台小主機要長期免費開著，靠的是這一種額度。各家對固定額度的稱呼不同：Oracle Cloud 叫 Always Free，Google Cloud 叫 Free Tier，AWS 叫 Always free services。

要長期跑一台小主機時，看的是固定額度；試用金只影響開頭那一段期限（Oracle Cloud 30 天、Google Cloud 90 天、AWS 6 個月，見比較表）。AWS 目前的 Free plan 沒有 EC2 的固定額度，長期跑主機要升級成付費帳戶，見下一節。

計費單位的換算：OCPU、vCPU 與機型配額

三家描述運算額度的單位不同。比較的基準是 vCPU：作業系統看到的一個虛擬處理器。多數 x86 機型的一顆實體核心跑兩個硬體執行緒（超執行緒），雲端業者把每個硬體執行緒算成一個 vCPU，這時一個 vCPU 是半顆核心。例外是每核只跑一個執行緒的 x86 機型：AWS 的 CPU 選項對照表 上，AMD 處理器的 M7a、C7a、R7a 與 M8a、C8a、R8a 等系列每核執行緒數只有 1，它們的一個 vCPU 就是一顆實體核心。ARM 處理器裡，Oracle Cloud 的 Ampere A1 與 AWS Graviton 每核一個執行緒，一顆核心就是一個 vCPU；Oracle Cloud 較新的 Arm 機型 A2 與 A4 的 OCPU 換算跟 A1 不同，見下方 Oracle Cloud 那一項。

• Oracle Cloud 用 OCPU 計：官方〈Compute Shapes〉的〈OCPUs and vCPUs〉一節把 OCPU 定義為實體核心，換算成 vCPU 的比例依處理器不同：x86（AMD、Intel）的 1 OCPU 等於 2 個 vCPU，Ampere A1 的 1 OCPU 等於 1 個 vCPU；同一節另列較新的 Arm 機型 A2 與 A4，它們的 1 OCPU 等於 2 顆核心、也就是 2 個 vCPU，不在 Always Free 額度內。Always Free 的 A1 額度以「OCPU 小時」與「GB 小時」計，每月 1,500 OCPU 小時、9,000 GB 小時，可以自由切成一台或兩台；整個月開著的 2 OCPU A1 主機，作業系統看到的是 2 個 vCPU。付費 tenancy 的 A1 免費量是每月 3,000 OCPU 小時、18,000 GB 小時（相當於 4 OCPU、24 GB 整個月開著；2026-10-26 讀到的 Oracle 的 Compute 價目頁，頁名這次沒有記下）。
• Google Cloud 以機型與台數計：Free Tier 是每月一台 e2-micro。e2-micro 是共享核心機型，作業系統看到 2 個 vCPU，而持續使用量是每個 vCPU 12.5%、合計 25% 的 CPU 時間；每個 vCPU 可以短時間爆發到 100%，全速爆發約 30 秒。持續高負載時，它能用的運算量是 0.25 個 vCPU。
• AWS 以帳號層級的試用金計：目前的 Free plan 不再列出每月固定的機型時數，EC2 的用量由試用金支付。

所以「OCI 給 2 OCPU、GCP 給 2 vCPU」這類比較不成立：OCI 的 2 OCPU A1 在持續負載下是 2 個完整的 vCPU，GCP 的 e2-micro 是 0.25 個。要比的是在持續負載下能拿到多少運算量，以及免費的部分是以時數、台數還是金額計算。

固定額度的區域限制

固定額度通常只適用於部分區域，而區域決定主機的實體位置——從使用者所在地連過去的延遲，以及主機對外連線時出口 IP 屬於哪個國家。

• Oracle Cloud：Always Free 的運算與區塊磁碟只能建在 home region，home region 在申請時選定、之後不能改（細節見 Oracle Cloud 的帳號結構與 home region）。
• Google Cloud：Free Tier 的 e2-micro 只適用於美國的三個區域：us-west1（奧勒岡）、us-central1（愛荷華）、us-east1（南卡羅來納）。在亞洲區域建同一個機型照一般價格計費。
• AWS：〈Free Tier FAQ〉寫明試用金與方案選擇在中國的 ZHY、BJS 兩區不提供（原文「The AWS Free Tier credits and account plan selections are not available in the China (ZHY) and China (BJS) regions.」），GovCloud（US）區域不適用 Free Tier（Lambda 等少數服務例外）；其他區域 FAQ 沒有列出限制。

用途需要特定國家的出口 IP 時（例如要讓連線看起來從日本發出），固定額度的區域限制是第一個篩選條件。Google Cloud 的固定額度只在美國；Oracle Cloud 的前提是申請時就把 home region 選在那個國家，而那個國家的區域多半只有一個可用區，A1 免費機型容量不足時沒有別的可用區可以換（容量不足時還有哪些退路，見 Oracle Cloud 的帳號結構與 home region 的〈A1 容量不足時的退路〉）；AWS 的 Free Tier FAQ 排除的只有中國與 GovCloud 的區域，日本的區域不在排除之列，而 Free plan 帳號最晚 6 個月後關閉，長期使用要升級成付費帳戶。

試用結束後帳號與資源的處置

試用期結束、而沒有升級成付費帳戶時，主機繼續免費、被停掉還是開始收費，各家不同。

• Oracle Cloud：試用結束後帳號照常存在，Always Free 資源不中斷。除非升級成付費帳戶，用試用金建的付費資源會被回收；tenancy 裡全部 A1 主機的合計超過 2 OCPU、12 GB 時，全部 A1 主機會被停用、30 天後刪除。A1 合計的判斷方式與試用結束前怎麼避免，見 Oracle Cloud 的帳號結構與 home region 的〈Always Free 的額度與它綁在 home region 上的範圍〉。
• Google Cloud：試用結束時如果沒有升級成付費帳戶，帳單帳戶會被停用、資源會被停止、帳號失去 Google Cloud 產品的存取權，有 30 天的寬限期可以升級回復。Free Tier 的固定額度要在付費帳戶上才能繼續用；升級之後超出額度的用量開始計費。
• AWS：Free plan 在開立 6 個月後或試用金用完時（先到者為準）結束，帳號隨即自動關閉、失去資源與資料的存取權；AWS 保留帳號內容 90 天，90 天內升級到 Paid plan 可以保住帳號的存取權，剩下的試用金會用在之後的帳單上。升級之後超出試用金的用量開始計費。

三家在不升級時的處置不同：Oracle Cloud 不升級也能留著免費資源，Google Cloud 與 AWS 不升級的話資源會停掉或帳號會關閉，而升級之後這兩家超出額度的部分會直接計費。升級成付費帳戶之前先設好預算警示，讓超出額度的費用在發生時有人收到通知。預算門檻怎麼算、扣款的信用卡要留多少額度、配額怎麼當成費用的上限，在 租用雲端主機之前的費用規劃：費用訊號的延遲、停止之前的最大超支、扣款的信用卡額度、配額與預算門檻的計算，以及停損停到哪一層；Google Cloud 預算的實際花費與預測花費兩種依據在 GCP 上的雲端費用失控防護，門檻比例、建立指令與從預算通知觸發停損的建置在 GCP 預算警示與停損開關的實測紀錄；成本監控與異常告警的設計見 運行期維運的成本管理。Oracle Cloud 不同帳號狀態下超出額度的結果，見 Oracle Cloud 的帳號結構與 home region 的〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉。

出站流量與閒置回收

主機本身免費，費用仍可能來自出站流量（outbound data transfer，也常寫作 egress）——主機送到網際網路的資料量。跑 VPN、下載站這類用途，流量才是主要成本。出站流量在整份帳單裡跟其他隱藏成本（NAT 閘道的流量費、被遺忘的資源）放在一起看，見 計費模式理解 的〈隱藏成本：帳單上的意外〉。

• Oracle Cloud：每月 10 TB 出站流量免費。
• Google Cloud：Free Tier 每月 1 GB 從北美送往各地的出站流量（不含中國與澳洲）；超過的部分計費。
• AWS：Free plan 頁面沒有列流量額度，額度寫在 EC2 的價格頁：每月 100 GB 送往網際網路的出站流量免費，所有服務與區域合計（不含中國與 GovCloud 區域）。

另一項只有 Oracle Cloud 明文寫出的規則是閒置回收：Always Free 主機在 7 天內的 CPU 使用率（取第 95 百分位）、網路使用率、記憶體使用率（只算 A1 機型）都低於 20% 時，Oracle 可能回收它（官方沒有寫網路使用率的 20% 是對什麼的比例）；官方頁用的詞是 reclaim，沒有寫回收之後主機是停止還是刪除。規則的出處見 Oracle Cloud 的帳號結構與 home region。一台大部分時間沒有流量的 VPN 或實驗機會落在這個條件裡。主機會被回收、而回收是停止還是刪除不明時，維護與暫停期間要先做的準備（資料備份到主機以外、確認照 repo 重建得出來），見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停時保留的範圍：只停服務、停止主機、終止主機、全部刪除〉。

三家免費方案比較表（查證日期 2026-10-24）

表裡 Oracle Cloud 磁碟那一格的 47 GB 不是來自官方頁面：2026-10-27 用 oci limits resource-availability get 查區塊磁碟額度的用量，三顆預設大小的開機磁碟合計扣 141，每顆 47，數值是 46.6 GiB 進位。合計超過 200 GB 時，判定免費與否的單位是整顆磁碟：同一天在付費 tenancy 建一顆 60 GB 的開機磁碟讓合計變成 201，免費額度的用量停在 141，那一顆整顆不算免費額度。查法與推論過程在 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉。

查付費主機價格時要輸入的項目

固定額度不夠用、或要把主機放在固定額度以外的區域時，價格要回到各家的價格頁與計算器查。這篇不列單價，理由是單價隨區域、機型世代與時間改變，寫在這裡的數字很快就會跟讀者看到的帳單對不上。查價時把這幾項一起輸入計算器，算出來的才是一台主機一個月的實際費用：

• 運算：機型、核心數（注意 OCPU 與 vCPU 的換算）、記憶體、每月開機時數
• 開機磁碟的容量與類型
• 公開 IPv4 位址：AWS 對每個公開 IPv4 位址按小時另外計費，其他業者去各自價格頁的 IP 位址那一項查
• 出站流量的預估量
• 負載平衡器：服務對外、主機留在私有 subnet 時要用。Oracle Cloud 的 Always Free 含一個 10 Mbps 的負載平衡器，AWS 與 Google Cloud 另外計費
• NAT 閘道：私有 subnet 的主機要下載套件更新時要用，AWS 的 NAT Gateway 與 Google Cloud 的 Cloud NAT 另外計費；Oracle Cloud 的價目表（2026-10-27 讀）沒有 NAT gateway 這一項。一個 NAT gateway 開了約 6 小時的那一天，帳務明細也沒有它的項目，經它出去的流量記在送出流量的主機的 VNIC 上、照出站流量計（從這一天的明細推論，沒有讀完一個帳單週期），實測與讀法見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉

Tenancy、home region、compartment 與 availability domain

OCI 的帳號叫 tenancy（主控台中文介面寫作「租用戶」）。一個 tenancy 對應一個客戶，裡面所有的使用者、群組、政策與資源都屬於它；申請時填的 Cloud Account Name 就是 tenancy 的名稱。Tenancy 與它底下的每一個資源各有一個以 ocid1. 開頭的唯一識別碼，叫 OCID（Oracle Cloud ID），CLI 與 API 用它指定要操作的對象；tenancy 的 OCID 在 Tenancy Details 頁，其他資源的在各自的詳細頁上。

Home region 是 tenancy 建立時所在的那一個區域。官方文件〈Managing Regions〉說明它存放帳號資訊與身分資源（使用者、群組、政策），而且建立之後不能變更，FAQ 的原文是「No. Oracle assigns your home region and you can’t change it.」使用者、群組、政策與 compartment 的定義住在 home region、只能在那裡修改：用 API 改 IAM 資源時要打 home region 的端點，用主控台改時主控台會替使用者把請求送到 home region，改完之後由 IAM 自動傳播到 tenancy 訂閱的其他區域，官方提醒傳播可能要幾分鐘。

Tenancy 可以另外訂閱其他區域（region subscription），訂閱之後能在那一區建資源，而帳號與身分資源仍然住在 home region。訂閱改變的是資源能放在哪裡，不改變 home region。訂閱的數量有上限：官方〈Regions and Availability Domains〉寫明試用、Free Tier 與 Pay As You Go 的 tenancy 都只能有一個訂閱區域，也就是 home region 本身；升級成付費帳戶（Pay As You Go）之後可以申請提高這個上限；試用與 Free Tier 的 tenancy 不能申請，訂閱區域就只有 home region 一個。

Compartment 是 tenancy 底下用來分組資源與套用政策的容器。Tenancy 本身就是最上層的 root compartment，新帳號一開始只有它。實驗用的資源另開一個 compartment 放，清理時刪那一個 compartment 底下的資源就好，不會碰到 root 裡的其他設定。

Availability domain（AD）是一個區域裡彼此隔離的資料中心，跨業者的概念見 Availability Zone（可用區）。區域之間的 AD 數量不同：有些區域有三個，有些只有一個。申請之前，各區域的 AD 數列在官方〈Regions and Availability Domains〉頁的區域表；申請之後，oci iam availability-domain list（登入方式見 從本機用 OCI CLI 操作 Oracle Cloud）回傳的清單長度就是自己 home region 的 AD 數。AD 數會影響免費機型建不起來時的退路，見〈A1 容量不足時的退路〉。

Always Free 的額度與它綁在 home region 上的範圍

OCI 的免費方案有兩個部分。試用金是 300 美元、30 天內有效，可以用在大部分付費服務上；Always Free 是沒有期限的固定額度，試用結束之後仍然繼續。官方 Free Tier 頁的原文是「After your trial ends, your account remains active. There is no interruption to the availability of the Always Free Resources you have provisioned.」沒有升級成付費帳戶的帳號，試用結束後不會開始扣款；試用期間用試用金建的付費資源，在試用結束時被回收，A1 主機另有一條依合計規格停用的規則，見下方〈試用結束時超出額度〉那一項。試用中、試用結束而沒有升級、付費帳戶這三種狀態下超出額度各自的結果，整理在〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉。

運算的 Always Free 額度有兩種機型：

• Ampere A1（VM.Standard.A1.Flex，ARM）：每月 1,500 OCPU 小時與 9,000 GB 小時的記憶體，相當於 2 OCPU、12 GB 記憶體整個月開著。可以全部給一台，也可以拆成兩台各 1 OCPU。付費 tenancy 的免費量比這個大：2026-10-26 讀到的 Oracle 的 Compute 價目頁（頁名這次沒有記下）寫的是「Each paid tenancy gets the first 3,000 OCPU hours and 18,000 GB hours per month for free」，也就是每月 3,000 OCPU 小時、18,000 GB 小時，相當於 4 OCPU、24 GB 整個月開著。OCI 的 OCPU 是一顆實體核心，跟其他業者以 vCPU 計價時的單位不同，比較時見 雲端免費額度與小型主機的收費比較。
• AMD Micro（VM.Standard.E2.1.Micro，x86）：最多兩台，每台 1/8 OCPU、1 GB 記憶體。

儲存與網路另有額度：開機磁碟與區塊磁碟合計 200 GB（每台主機的開機磁碟預設 50 GB，從同一份 200 GB 額度裡扣）、備份最多 5 份、出站流量每月 10 TB；試用結束後沒有升級的 Free Tier tenancy，VCN 最多 2 個。預設 50 GB 的開機磁碟實際扣 47 GB 額度，數值是 46.6 GiB 進位（2026-10-27 從用量推論），查法見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉。

運算與區塊磁碟的 Always Free 額度只能用在 home region。 Free Tier 頁寫的是「You can provision Always Free Autonomous AI Databases and compute instances only in the home region」；Always Free Resources 頁對區塊磁碟的原文是「the volume must be created in the home region of the tenancy」。升級成付費帳戶並訂閱其他區域之後，建在 home region 以外那些訂閱區域的主機照一般價格計費。

免費主機只能建在 home region，主機的實體位置因此就是 home region。這個位置決定兩件事。一是出口 IP 的國家：業者配給一台主機的公開 IP 位址，屬於那個區域所在國家的位址段，主機對外連線時，對方看到的來源 IP 就登記在那個國家。二是延遲：從使用者所在地連到主機的延遲，由兩地的距離決定。

Always Free 的主機另有兩條回收規則：

• 閒置回收：連續 7 天內 CPU 使用率（第 95 百分位）、網路使用率、記憶體使用率（只算 A1）三項指標各自都低於 20%，Oracle 可能回收這台主機。官方頁用的詞是 reclaim，沒有寫回收之後主機是停止還是刪除。只在需要時才登入的實驗機會符合這個條件。
• 試用結束時超出額度：Free Tier 頁判斷 A1 是否超額，看的是 tenancy 裡全部 A1 主機的合計（OCPU 加總、記憶體加總），不看單台主機的規格。合計超過 2 OCPU、12 GB 時，試用結束那一刻 tenancy 裡的 A1 主機全部被停用，30 天後刪除，除非升級成付費帳戶。被停用的是每一台 A1 主機，包括單台規格在額度內的那幾台。官方沒有寫已經被停用的主機在升級之後會不會恢復。試用期間超出的部分由試用金支付，帳單上看不到費用，所以 A1 合計超額的後果要到試用結束那一刻才浮現。這個合計要自己加總：到 Compute → Instances 清單逐台記下 A1 主機的 OCPU 與記憶體；清單一次只列一個 compartment，每個放過主機的 compartment 都要切過去看。要保留 A1 主機，試用結束前把合計壓回 2 OCPU、12 GB 以內：把其中幾台的 OCPU 或記憶體改小，或刪掉其中一台。

官方對閒置回收只寫了三項指標都要低於 20%，沒有寫網路使用率的 20% 是對什麼的比例，也沒有寫升級成付費帳戶之後這條規則還適不適用；被回收之後主機的狀態與能不能恢復同樣沒寫。回收之後是停止或刪除兩種情形各自留下哪些資源、怎麼發現，以及照原樣重建一台 A1 主機的腳本，見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈被回收之後的重建：怎麼發現、留下與消失的資源、重建腳本〉。

A1 容量不足時的退路

A1 免費機型在某個 AD 暫時沒有容量時，建立主機的 API 回 Out of host capacity。可以做的事有下面這些，出處分別是官方 Always Free 頁與 Compute 的〈Known Issues〉頁；標明「會計費」的幾項不在 Always Free 額度內，結果依帳號狀態而定，見〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉：

• 換一個 AD（Always Free 頁）：home region 只有一個 AD 時，這一項不存在。
• 等一段時間再試（Always Free 頁）：有人釋出資源時才會短暫空出位置。重送的間隔看回應碼調整：429 TooManyRequests 是請求太頻繁被限流（Rate Limit 卡），收到就拉長間隔，做法見 Exponential Backoff 卡；Out of host capacity 才是那個 AD 當下沒有硬體。限流的門檻依帳號與 API 而定。
• 不指定 fault domain（Known Issues 頁）：建立頁的 Fault domain 欄選「Let Oracle choose the best fault domain」，不把主機限定在單一個 fault domain 的硬體上。
• 改小規格（Known Issues 頁）：同一個機型把 OCPU 或記憶體改小，需要的硬體少，容量比較容易拿到，仍然在免費額度內。
• 建立前查容量（Known Issues 頁）：用 CreateComputeCapacityReport 這個 API 查某個機型當下在某個 AD 有沒有容量，查完再送建立請求。
• 換成 x86 機型（會計費）：x86 的 Flex 機型不在免費額度內；試用期間用試用金建，當天就有主機可用，代價是這台用試用金建的 x86 主機在試用結束時會被回收。換架構要重新確認軟體有沒有那個架構的版本，見 機型與映像檔 的〈CPU 架構：x86 與 ARM〉。免費的 x86 機型 E2.1.Micro 在一個區域裡只建得在一個 AD 上，2026-10-24 實測的 ap-batam-1 沒有這種機型，出處與實測見〈E2.1.Micro 在各區域的供應：服務配額表與 404 錯誤〉。
• 改用可被收回的容量（preemptible）（官方沒有寫它算不算免費額度，這裡按會計費看待）：官方 Always Free 頁與 Free Tier 頁都沒有提到 preemptible。業者需要容量時會直接終止這種主機，價格與限制見 機型與映像檔 的〈計費模式：隨用隨付、可被收回、預留容量與專屬主機〉。
• 預留容量（capacity reservation）（會計費）：先向業者保留某種機型的容量，保留期間的計費方式見 機型與映像檔 的〈計費模式：隨用隨付、可被收回、預留容量與專屬主機〉。
• 升級成付費帳戶（Always Free 頁）：官方寫升級之後能用的運算資源種類變多（原文「gives you access to more types of Compute resources」）。對容量不足來說，升級的作用是讓上面那幾項會計費的選項（x86 的 Flex 機型、可被收回的容量、預留容量）在試用金用完或試用結束之後仍然建得起來。Always Free 的部分仍然不收費，額度以外建的資源照一般價格計費。

Home region 只有一個 AD、而且只用免費額度時，能用的退路是等待重試、不指定 fault domain、改小規格與建立前查容量這四項；換 AD 在這種區域不存在；x86 的 Flex 機型、可被收回的容量與預留容量不在免費額度內，要用試用金或升級成付費帳戶才建得起來。在只有一個 AD 的 ap-batam-1 實際重送的紀錄、OCI CLI 在一條指令裡自己重送造成的限流，以及依回應碼調整間隔的重送腳本，見 Oracle Cloud 建立主機的實測紀錄 的〈重送建立請求：CLI 自己的重送、限流門檻與重送腳本〉。

E2.1.Micro 在各區域的供應：服務配額表與 404 錯誤

E2.1.Micro 是 Always Free 的另一種機型。官方 Always Free 頁對它的供應寫的是 AD 層級：「Instances using the VM.Standard.E2.1.Micro shape can only be created in one availability domain.」也就是一個區域裡只有一個 AD 建得了 Micro，而官方沒有列出是哪一個 AD、哪些區域完全沒有。2026-10-24 在 ap-batam-1 實測，這一區唯一的 AD 沒有 E2.1.Micro，所以在這一區，A1 建不起來時改用 Micro 也建不起來。

主控台的服務配額表（Limits, quotas and usage 頁）上的數字是這個帳號允許開的台數上限，它不反映那一區是否提供那種硬體。這次的帳號在配額表上的 vm-standard-e2-1-micro-count 是 2，而 ap-batam-1 一台 Micro 也建不起來。

在沒有這個機型的區域用 CLI 建立 Micro 主機，API 回的是 404 NotAuthorizedOrNotFound。這個錯誤碼同時涵蓋權限不足與資源不存在，從訊息本身分不出是哪一種。一個區域實際提供哪些機型，用 oci compute shape list --compartment-id <compartment 的 OCID> --availability-domain <AD 名稱> 查，回傳的清單才是那個 AD 能建的機型；AD 名稱要填 oci iam availability-domain list 回傳的完整名稱，它帶有 tenancy 專屬的前綴，只寫 AD-1 會失敗。這條指令要先有 tenancy 才能跑，所以申請之前沒有辦法確認某一區有沒有 E2.1.Micro；申請之後才發現缺機型時，能做的事見〈選錯 home region 之後的選項〉。

超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果

多建一台 A1、加大一顆磁碟、改用不在免費額度內的 x86 機型，這類讓用量超出 Always Free 額度的操作，結果由帳號當下的狀態決定：

• 試用中：超出的部分由試用金支付，帳單上看不到費用。試用結束時，用試用金建的付費資源會被回收，A1 合計超額時全部 A1 主機會被停用。
• 試用結束而沒有升級：官方 Always Free 頁寫明，用不在 Always Free 範圍內的映像建主機，帳號必須是付費帳戶、或是還有試用金餘額的 Free Trial 帳號（原文「you must have a paid account or a Free Trial account with available credits」）；試用結束而沒有升級的帳號兩者都不是，所以超出額度的運算資源建不了，運算以外的資源這一頁沒有逐字寫；Free Tier 頁另外寫明，不升級的話申請時填的信用卡不會被扣款。
• 升級成付費帳戶（Pay As You Go）：Always Free 的部分仍然不收費，超出的部分照一般價格計費。區塊磁碟的「超出的部分」以整顆磁碟計：沒有用 compartment quota 另設上限時，合計超過 200 GB 的建立請求不會被擋下，新建而放不進剩餘額度的那一顆整顆不算免費額度（2026-10-27 實測，見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉）。A1 的免費量是每月 3,000 OCPU 小時、18,000 GB 小時（相當於 4 OCPU、24 GB 整個月開著），出處是 2026-10-26 讀到的 Oracle 的 Compute 價目頁，見〈Always Free 的額度與它綁在 home region 上的範圍〉的 A1 那一項。

站內各篇寫到「超出免費額度」的地方，指的都是這三種結果。升級之前先設好預算警示，見 雲端主控台的管理領域 的〈帳單與成本：花了多少、會花多少〉；升級時的 100 美元預先授權、扣款的信用卡要留多少額度、預算門檻與配額怎麼從每月能接受的上限推出來，見 租用雲端主機之前的費用規劃：費用訊號的延遲、停止之前的最大超支、扣款的信用卡額度、配額與預算門檻的計算，以及停損停到哪一層。

選 home region 時要先確認的事

Home region 在申請表上是一個下拉選單，選定的區域同時決定了免費主機的實體位置（出口 IP 的國家、延遲）與容量不足時有沒有別的 AD 可以換。選之前先確認這台免費主機要做什麼：

• 用途需要特定國家的出口 IP（例如要讓連線看起來從日本發出）：只有那個國家的區域符合，其他區域的延遲再低都達不到目的。以日本為例，這個條件與下方「主要拿來實驗」那一條的「選 AD 多的區域」同時滿足不了：日本的兩個區域（東京 ap-tokyo-1、大阪 ap-osaka-1）都只有一個 AD，選了日本，A1 容量不足時就沒有別的 AD 可以換，而 E2.1.Micro 有沒有提供要申請之後才查得到。兩者只能取一個：日本的出口 IP 是硬條件時，選日本的區域，接受 A1 容量不足時無處可換；出口 IP 只是加分項時，選 AD 多的區域，放棄日本的出口 IP。東京與大阪之間，官方沒有公開各區的容量資訊，選哪一個只能看延遲。預算為零而容量一直不足時，能用的退路見〈A1 容量不足時的退路〉最後一段。
• 用途是給特定地區的使用者連：選離使用者近的區域，延遲由距離決定。
• 主要拿來實驗：優先選 AD 多的區域（官方區域表上 AD 數為 3 的那幾個，名單見 Availability Zone（可用區） 卡），A1 容量不足時有其他 AD 可以換。AD 多代表的是多了可以換的地方，不代表那一區的 A1 空閒容量比較多。
• 資料要留在特定國家（法規或合約要求）：只有那個國家的區域符合，跟出口 IP 那一條同樣是硬條件。

選錯 home region 之後的選項

Home region 不能改；官方有刪除 tenancy 的流程（〈Deleting a Free Tier Tenancy and Cloud Account〉：管理員在 Tenancy Details 頁按「Request tenancy deletion」），刪除後資源先被暫停、30 天後永久刪除且無法復原，而官方文件沒有寫明刪除之後能不能用同一個 email 與付款方式重新申請。走這條路之前，先開 support ticket 問清楚重新申請的條件。不刪 tenancy 的做法是保留原帳號、在想要的區域另建付費主機：管理員先把帳號升級成 Pay As You Go，再到 Limits, quotas and usage 頁申請提高訂閱區域的上限（Subscribed region count）；核准之後訂閱想要的區域，在那一區建的主機照一般價格計費。Always Free 額度仍然只能用在原本的 home region。

主控台登入：租用戶與使用者名稱兩個欄位，與「使用者名稱或密碼無效」

OCI 的登入頁把登入拆成兩個欄位，依序出現：

1. 租用戶（Cloud Account Name）：填 tenancy 的名稱，也就是申請時取的帳戶名稱。OCI 用它找到要登入的是哪一個 tenancy。已經登入的主控台上，右上角人像選單的「租用戶」或「Tenancy:」後面就是這個值。
2. 使用者名稱：填 tenancy 裡那個使用者的名稱。申請時建立的管理員帳號，使用者名稱是申請用的 email。頁面要求選 identity domain（tenancy 裡存放使用者與群組的分區）時選 Default，新帳號只有這一個。

兩個欄位任一個填錯，登入頁顯示的都是同一句「使用者名稱或密碼無效」，不會指出是哪一欄錯。實際登入時，租用戶欄填對、使用者名稱欄填成 tenancy 名稱，得到的就是這句訊息，密碼本身沒有錯。從本機用 oci session authenticate 登入時開出的瀏覽器頁面是同一個登入頁，欄位與錯誤訊息相同。

延伸閱讀：CLI 登入、免費額度比較、位置與管理通道

同一個 tenancy 從終端機登入的做法，以及 session token 與 API 簽章金鑰各自的時效，見 從本機用 OCI CLI 操作 Oracle Cloud；Always Free 的 home region 限制跟 Google Cloud、AWS 的區域限制並排，見 雲端免費額度與小型主機的收費比較；home region 這一層之下，可用區與故障域在建立主機時各決定什麼，見 位置：區域、可用區與故障域；compartment 這種資源分組在三家主控台上的對應，見 雲端主控台的管理領域；主機建好之後，管理員登入它要經過的網路可達性、通道授權與主機登入驗證三層，見 伺服器管理通道的設計。

章節文章

各篇共用的寫法

每一篇都寫這幾項：這一類選項是什麼、建立後能不能改（改不了的才需要在建立頁上想清楚）、對費用的影響、選錯時的徵兆、實驗用的小主機怎麼選，結尾是三家的欄位名稱對照。維護時照這一份清單檢查各篇。主要例子取自 Oracle Cloud（實測在那一家），寫通則句之前先確認另兩家的行為，只對一家成立的句子在句首寫明業者。各家的實測紀錄放在業者子資料夾底下的 hands-on/，例如 Oracle Cloud 建立主機的實測紀錄，那一篇照主控台的分頁順序，每一欄連回這裡對應的那一篇。

Backlog

CPU 架構：x86 與 ARM

機型的第一個屬性是 CPU 架構，目前雲端上有兩種：x86（Intel、AMD）與 ARM（Oracle Cloud 的 Ampere A1、AWS 的 Graviton、Google Cloud 的 Axion 與 Tau T2A）。架構決定主機能執行哪些程式：

• 作業系統與套件庫提供兩種架構的版本，套件管理員（apt、dnf）依主機的架構下載對應的套件。
• 只發佈 x86 版本的程式（部分商用軟體、舊版工具、只建了 amd64 映像的容器）在 ARM 主機上跑不起來，或要靠模擬執行而變慢。容器最常在這裡出事：在 x86 的筆電或 CI 上 build 出來的映像預設只有 amd64，本機測試全部通過，拿到 A1 主機上啟動才出現 exec format error。在 x86 機器上一次 build 出 amd64 與 arm64 兩種映像的做法見 BuildKit 與跨平台 build 的〈跨平台 build：一次出多架構〉。

ARM 機型的同等規格通常比較便宜，Oracle Cloud 的 Always Free 額度大部分也在 ARM（A1）上。要跑的軟體確認有 ARM 版本時，ARM 是比較划算的選擇；不確定時，先查那個軟體的下載頁或容器映像的平台清單有沒有 arm64。

架構在建立之後不能換，因為開機磁碟上的作業系統是為那個架構編譯的，換架構只能用另一個架構的映像檔重建。用 IaC 管理主機時，改映像檔這一類屬性在 Terraform 的 plan 上顯示成先刪後建（forces replacement），主機與它的開機磁碟會被重建，見 terraform plan / apply。

核心數與記憶體

固定規格的機型名稱本身就決定了核心數與記憶體（AWS 的 t3.micro、Google Cloud 的 e2-micro）。彈性機型（Oracle Cloud 名稱以 .Flex 結尾的 shape、Google Cloud 的自訂機型）讓使用者在範圍內自己填核心數與記憶體，而記憶體能填的範圍隨核心數變動。

各家計算核心的單位不同。vCPU 是作業系統看到的一個虛擬處理器；Oracle Cloud 用 OCPU，官方把一個 OCPU 定義為一顆實體核心；Oracle Cloud 的 x86 機型（AMD、Intel）1 OCPU 等於 2 個 vCPU，因為多數 x86 處理器的一顆核心跑兩個硬體執行緒，Ampere A1 的 1 OCPU 等於 1 個 vCPU；其他兩家直接用 vCPU。x86 裡每核只跑一個執行緒的例外機型與 Oracle Cloud 較新的 Arm 機型怎麼換算，見 雲端免費額度與小型主機的收費比較 的〈計費單位的換算：OCPU、vCPU 與機型配額〉。共享核心機型（Google Cloud 的 e2-micro）作業系統看得到 2 個 vCPU，持續使用量卻只有 0.25 個，三家規格放在一起比較時的換算也在同一節。

核心數與記憶體建立之後可以調整，代價是一段停機。Oracle Cloud 的官方說明是主機在執行中時，改機型的過程會把它重開，私有 IP、公開 IP 與掛載的磁碟維持不變；改之前在作業系統裡先把應用程式正常關掉，避免寫到一半的資料損壞。官方的主控台步驟另外註明，主機掛了兩顆以上的區塊磁碟時（原文是 more than one block volume attached），要先把區塊磁碟卸下才能改機型。Google Cloud 與 AWS 要先把主機停止才能換機型，換完再啟動；AWS 停止再啟動時，自動指派的公開 IP 會換成新的。能調整的機型也有限：Oracle Cloud 的 VM.Standard.E2.1.Micro 不能調整，開了安全開機（shielded instance）的主機也不能改機型，A1 Flex 可以在 Always Free 額度內調整核心數與記憶體。

既然改大只要一段停機、不必重建，實驗機先開小一點、不夠再加；前提是改大的時候那一區還有容量，A1 這種容量經常不足的機型，在建得起來的那一刻就要把規格想好；要在改機型之前確認新機型當下有沒有容量，Oracle Cloud 的改機型說明寫明用 CreateComputeCapacityReport 這個 API 查。付費機型開小直接省錢，Always Free 的 A1（每月額度相當於 2 OCPU、12 GB 整個月開著，見 雲端免費額度與小型主機的收費比較）則是把剩下的額度留給第二台主機。「不夠」的訊號在主機的指標上：CPU 使用率長時間接近滿載、或記憶體用完開始用 swap、程式被 OOM 終止。

某個機型在一個區域建不起來（容量不足）時，本篇處理的是改小規格、換架構與改用可被收回的容量，代價看選哪一種；其餘的退路（換可用區、等待重試、不指定故障域、建立前查容量、預留容量、升級付費帳戶）與這幾種排在一起的完整清單，見 Oracle Cloud 的帳號結構與 home region 的〈A1 容量不足時的退路〉。在同一種機型裡改小規格，容量比較容易拿到，免費額度也不變；換到另一個架構（例如 A1 建不起來改用 x86 的 Flex 機型），要重新確認軟體有沒有那個架構的版本，而且 Oracle Cloud 上 x86 的 Flex 機型不在 Always Free 額度內，試用期間由試用金支付、當天就建得起來，試用結束之後的結果依帳號狀態而定，見 Oracle Cloud 的帳號結構與 home region 的〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉；改用可被收回的容量，價格低，但主機隨時可能被收回，而官方 Always Free 頁沒有寫這種容量是否算在免費額度內。換可用區的部分見 位置：區域、可用區與故障域。

計費模式：隨用隨付、可被收回、預留容量與專屬主機

同一個機型可以用不同的方式取得容量，差別在價格與「業者能不能把這台主機收回去」。Oracle Cloud 建立頁的 Capacity type 欄位列出這幾種：

• 隨用隨付（on-demand）：預設值。在共享的實體主機上開一台虛擬機，開著的時間計費，業者不會因為別人要用而收回它。Oracle Cloud 的官方 Always Free 頁沒有提到其他計費模式，在 Always Free 額度內建主機時維持這個預設。
• 可被收回（preemptible）：同樣的機型，價格較低，而業者需要容量時會直接終止它。Oracle Cloud 的 preemptible 是隨用隨付價格的一半，沒有保證的最短執行時間，終止前兩分鐘發出一個事件通知，建立後不能停止、啟動或重開，也不能轉成隨用隨付。Google Cloud 與 AWS 的同類機型叫 Spot，規則各自不同，例如 Google Cloud 的 Spot VM 被收回之後可以再啟動。適合跑得斷、可以重來的批次工作；要一直開著的服務與手動設定過的實驗機不適合，被收回時設定會跟著消失。
• 預留容量（capacity reservation）：先向業者保留一定數量的某種機型容量，之後建主機時從保留的額度裡扣。它處理的是「要用的時候沒有容量」，用在必須在某個時間點拿到主機的情境：大促前要擴容、災難時要在另一區重建、熱門機型經常容量不足。保留期間不論有沒有主機在用都計費。大促前什麼情形才需要預留容量，以及預留期間的費用怎麼從建立預留那一刻算進活動預算，見 預知的大流量要加多大、編多少預算：從業務預估到擴容規格與費用區間的換算鏈、給決策者與會計的數字，以及每次活動之後的校準。
• 專屬主機（dedicated host）：整台實體主機只給這個帳號的虛擬機用，不跟其他客戶共用硬體，用在合規要求或授權按實體主機計算的軟體。Oracle Cloud 只允許在建立時把主機放上專屬主機。

Oracle Cloud 的 Capacity type 欄位一次只能選其中一種；AWS 的 capacity reservation 則是讓隨用隨付的主機去使用保留下來的容量，兩者同時成立。預留容量跟用一到三年的承諾換取折扣的 reserved instance 是兩件事：預留容量保證拿得到容量、不打折；AWS 的 reserved instance 打折，而保不保證容量看範圍，以區域為範圍的 regional reserved instance 不保留容量，指定可用區的 zonal reserved instance 另外保留那一區的容量。Reserved instance 與 savings plan 的承諾差異、什麼時候值得買，見 計費模式理解 的〈承諾模式：用彈性換折扣〉。實驗用的小主機選隨用隨付。

停止主機時的計費

停止（stop）跟終止（terminate）是兩件事：停止是關機，主機與磁碟都保留，之後可以再開；終止是刪除主機。Oracle Cloud 的標準機型在停止期間暫停計算資源的計費，但仍然佔用服務配額（2026-10-27 一台 A1 停止的那一小時，逐小時的帳務明細沒有 A1 的項目，而 A1 的核心數與記憶體用量照算，見 Oracle Cloud 主機的暫停與恢復上線實測紀錄：暫停前的基準、收窄入口、停止主機、停止期間的計費與 Cloudflare 的回應、恢復上線的每一步與耗時，以及收尾時 DNS 紀錄與主機的刪除順序）；Dense I/O、HPC 與多數 GPU 機型停止時照樣計費，要終止才會停。官方另外提醒，在作業系統裡下 shutdown 不會停止計費，要從主控台或 API 停止主機。Google Cloud 與 AWS 的規則方向相同：停止期間不收 vCPU 與記憶體的費用，磁碟與保留的公開 IP 照樣計費。磁碟的計費跟主機是否開著無關，見 磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留。服務要暫停一段時間時，在只停服務、停止主機、終止主機與全部刪除之間怎麼選，以及停止之後仍在計費、仍被 DNS 指向的資源，見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序。

映像檔：開機磁碟上的作業系統

映像檔是建立主機時複製到開機磁碟上的作業系統內容。主控台的映像檔清單通常分成三種來源：

• 業者提供的平台映像（platform image）：Ubuntu、Oracle Linux、Debian、Windows 等，由業者維護並預先裝好它自己的代理程式（agent，見 代理程式、中繼資料服務、初始化腳本、維護行為與標籤）。實驗與一般用途選這一種。
• 市集映像（marketplace）：第三方預先裝好特定軟體的映像，部分要另外付授權費。
• 自訂映像（custom image）：從自己的主機或開機磁碟做出來的映像，用來複製已經設定好的環境。

同一個作業系統常有完整版與 minimal 版。Minimal 版只裝開機與連網需要的套件，開機磁碟用量小、要修補的套件少，代價是常用工具（文字編輯器、部分診斷工具）要自己裝。要登入主機手動操作、排錯的實驗機選完整版；只跑容器或由初始化腳本、IaC 裝好全部軟體、平常不登入的主機選 minimal 版。

映像檔要跟機型的架構一致：Oracle Cloud 的映像清單上，Ubuntu 的 ARM 版名稱帶 aarch64、x86 版不帶；AWS 與 Google Cloud 的映像多半以 arm64 標示 ARM 版，名稱看不出時看映像詳細資料裡的架構欄位。Oracle Cloud 的主控台只列出這一區有的機型，並把跟已選映像檔不相容的標成不可選；用 CLI 或 API 建立時沒有這層畫面上的提示，映像檔要自己挑對架構。查詢映像檔的指令是 oci compute image list --compartment-id <tenancy 的 OCID> --shape <機型名稱>：Oracle Cloud 給每個資源一個唯一識別碼叫 OCID，平台映像列在 tenancy（帳號本身，也是最上層的 compartment）底下，所以 --compartment-id 填 tenancy 的 OCID；--shape 填機型名稱（例如 VM.Standard.A1.Flex），CLI 只回傳跟那個機型相容的映像檔。tenancy 的 OCID 在哪裡查見 Oracle Cloud 的帳號結構與 home region。映像檔也決定了預設的登入使用者名稱，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務。

映像檔只在建立的那一刻複製一次。之後作業系統的更新由主機自己的套件管理員處理，跟映像檔清單上出現的新版本無關；換作業系統同樣要用新的映像檔重建。

各家的欄位名稱：機型、可被收回、預留容量與映像檔

映像檔複製到的那顆開機磁碟能設定的大小、效能與加密，見 磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留；一台 Always Free 的 A1 Ubuntu 主機實際選的規格與映像檔，見 Oracle Cloud 建立主機的實測紀錄 的 Basic information 段。

CLI 的兩種身分驗證：session token 與 API 簽章金鑰

OCI 的 API 不收帳號密碼。CLI 送出的每一個請求都用一把私鑰簽章，OCI 用對應的公鑰驗證簽章、再查這把公鑰屬於哪個使用者，以那個使用者的權限執行請求。兩種做法的差別在這對金鑰從哪裡來、公鑰怎麼讓 OCI 認得：

• Session token：CLI 在本機產生一對臨時金鑰，開瀏覽器讓使用者登入主控台；登入成功後 OCI 簽發一個綁定這把臨時公鑰的 token，token 過期之後這對金鑰就沒有用了。
• API 簽章金鑰：使用者在主控台把一把公鑰登記到自己的帳號下，之後持有對應私鑰的程式都能以這個使用者的身分呼叫 API，直到公鑰被刪除為止。

兩者在本機都會留下一個私鑰檔，差別在私鑰檔外洩之後能用多久。Session token 的私鑰在 token 過期後失效；API 簽章金鑰的私鑰在使用者到主控台刪掉公鑰之前一直有效。實驗與互動式操作用 session token，私鑰外洩之後可被冒用的時間最長到登入後 24 小時（見〈Session token 的時效與 refresh〉）；排程腳本、CI，以及經由 SSH 連進去、沒有瀏覽器可開的遠端機器，這類沒有人能開瀏覽器登入的場合才需要 API 簽章金鑰。

用瀏覽器登入換 session token

1oci session authenticate --region ap-batam-1 --profile-name DEFAULT

• --region：填 tenancy 的 home region 的識別碼，這次實測的 home region 是 ap-batam-1，換成自己的。CLI 用它決定開哪一區的登入頁、並寫進設定檔當成之後指令的預設區域；試用與 Free Tier 的 tenancy 只訂閱 home region 一個區域，填它就對。識別碼與主控台上的顯示名稱（例如「Indonesia North (Batam)」）是兩種寫法，對照列在 Governance & Administration → Account Management → Region Management 頁；不給這個選項時，CLI 也會列出全部區域的識別碼讓使用者輸入編號。
• --profile-name：設定檔 ~/.oci/config 裡這一組身分的名稱。DEFAULT 是 CLI 在指令沒有指定 --profile 時使用的那一組；同一台機器要切換多個 tenancy 時，每個 tenancy 用一個不同的 profile 名稱。

實測 Homebrew 版的 CLI 跑在 Python 3.15 上時，這條指令與之後每條指令的開頭都會印一行 SyntaxWarning，來源是 CLI 自己的程式碼裡的正規表示式字串，不影響結果。要讓輸出乾淨，在指令前面加上 PYTHONWARNINGS=ignore（例如 PYTHONWARNINGS=ignore oci session validate）只對那一條生效；改用 export PYTHONWARNINGS=ignore 的話，整個 shell 裡所有 Python 程式的警告都會被關掉。

登入過程中 CLI 會問兩個問題：區域與 profile 名稱，兩個都給在選項裡就不必互動輸入。這一點在 CLI 不是跑在互動式終端機裡時有差別——例如透過另一個程式代為執行、標準輸入沒有接到鍵盤——CLI 讀不到輸入，印出 Abort 後結束。實測少給 --region 時就是在區域清單之後直接 Abort。

CLI 接著開瀏覽器到登入頁，並在本機的 localhost:8181 等登入結果。瀏覽器的登入頁跟主控台是同一個，先填租用戶，頁面要求選 identity domain 時選 Default，再填使用者名稱與密碼，各欄的填法見 Oracle Cloud 的帳號結構與 home region 的〈主控台登入：租用戶與使用者名稱兩個欄位，與「使用者名稱或密碼無效」〉。登入成功後瀏覽器把 token 送回 localhost:8181，終端機印出 Completed browser authentication process! 與 Config written to: /Users/<user>/.oci/config。瀏覽器頁面不小心關掉時，終端機上印著同一個登入網址，貼回瀏覽器就能繼續；網址裡帶著這次產生的臨時公鑰，所以只對正在等待的這一次登入有效。

設定檔裡的這一組長這樣（值是佔位的）：

1[DEFAULT]
2fingerprint=<臨時公鑰的指紋>
3key_file=/Users/<user>/.oci/sessions/DEFAULT/oci_api_key.pem
4tenancy=<tenancy 的 OCID>
5region=<home region 的識別碼>
6security_token_file=/Users/<user>/.oci/sessions/DEFAULT/token

tenancy 是 tenancy 的 OCID：OCI 給每一個資源（tenancy、compartment、VCN、主機）一個以 ocid1.<資源類型>. 開頭的唯一識別碼，叫 OCID（Oracle Cloud ID），CLI 與 API 用它指定要操作哪一個資源，各資源的詳細頁上都有一個可以複製的 OCID 欄位。key_file 是 CLI 產生的臨時私鑰，security_token_file 是 OCI 簽發的 token，兩個檔都在 ~/.oci/sessions/<profile 名稱>/ 底下。

不再使用時跑 oci session terminate --profile <profile 名稱>。官方 CLI 參考對這條指令的說明是從設定檔移除這一組，並刪掉它參照的資源（例如金鑰檔），沒有寫 OCI 那一端會不會撤銷已經簽發的 token。所以 token 與私鑰檔在 terminate 之前被複製走時，要假設那份 token 仍然有效：拿到的人可以在它過期前跑 oci session refresh，按〈Session token 的時效與 refresh〉寫的上限，影響的期限最長到登入後 24 小時。

使用 session token 時每條指令要帶的設定：config file is invalid 與 user missing

CLI 預設用 API 簽章金鑰的方式驗證身分，用 session token 時要明確告訴它。兩種寫法效果相同：

1# 每條指令各自指定
2oci iam region-subscription list --auth security_token
3# 整個 shell 工作階段都用 session token
4export OCI_CLI_AUTH=security_token

少了這個設定，CLI 照 API 簽章金鑰的流程檢查設定檔，而那個流程要求設定檔裡有 user（使用者的 OCID），session 登入寫出的設定檔沒有這一欄。實測 CLI 在送出請求之前就停下來，印出 ERROR: The config file at ~/.oci/config is invalid，表格裡列出 user | missing，提示去主控台找使用者的 OCID——照提示補上 user 是在改成 API 簽章金鑰的做法，對 session token 是錯的方向，該補的是 --auth security_token。

確認登入成功、同時查出 tenancy 的基本資訊，可以跑這幾條：

1oci session validate --auth security_token          # 印出 token 的到期時間
2oci iam region-subscription list --auth security_token   # 訂閱的區域，is-home-region 為 true 的是 home region
3oci iam availability-domain list --auth security_token   # home region 的 availability domain 清單

Session token 的時效與 refresh

Token 的預設效期是 1 小時：實測 17:44 登入，oci session validate 回報到期時間 18:44。過期之前可以延長：

1oci session refresh --profile DEFAULT

--profile 填登入時取的 profile 名稱；登入那一條指令的選項叫 --profile-name，其他指令（refresh、terminate、一般查詢）都叫 --profile。profile 不是 DEFAULT 時，上一節那幾條查詢指令也要各加 --profile <名稱>。官方文件說明 refresh 要在 token 還有效時做，可以一路延長到登入後的 24 小時；超過 24 小時，或 token 已經過期，就要重新跑一次 oci session authenticate、在瀏覽器重新登入。

API 簽章金鑰：不需要每天登入的做法

API 簽章金鑰在主控台的人像選單 → User settings 頁建立。官方〈Required Keys and OCIDs〉對這一頁的寫法有兩種：一處寫進入「Token and keys」分頁，另一處寫左下角 Resources 區段裡的「API Keys」，畫面上找得到哪一個就用哪一個；兩者都從「Add API Key」按鈕開始。在 Add API Key 的對話框讓主控台產生金鑰對並下載私鑰（Download Private Key），按 Add 之後頁面顯示一段 [DEFAULT] 開頭的設定文字。官方寫明一個使用者最多三把 API 金鑰。

那段文字是 CLI 設定檔的一組 profile，其中 key_file 是一個佔位路徑，CLI 會照這一行去讀私鑰，所以貼進 ~/.oci/config 之後要把它改成私鑰實際存放的路徑。同一台機器已經照上面的步驟用 session token 登入過時，設定檔裡已經有一組 [DEFAULT]，貼上的這一組要改成另一個名稱（例如 [apikey]），兩組同名時 CLI 只會讀其中一組。私鑰檔的權限設成只有自己能讀寫，因為持有它的人能以這個使用者的全部權限呼叫 API：

1mv ~/Downloads/<下載的私鑰檔名>.pem ~/.oci/   # 瀏覽器下載的位置換成自己的
2chmod 600 ~/.oci/<下載的私鑰檔名>.pem          # 私鑰檔只允許擁有者讀寫
3unset OCI_CLI_AUTH                              # 前面設過 session token 的 shell 要先取消，否則仍走 session
4oci iam region-subscription list --profile apikey   # 不帶 --auth，CLI 用 API 簽章金鑰

這把金鑰沒有到期時間。不用的時候回到 User settings 頁的 API 金鑰清單刪掉它，持有私鑰的程式就無法再呼叫 API。私鑰外洩的影響範圍是這個使用者的全部權限，所以給排程與 CI 用的金鑰，建在一個只有必要權限的專用使用者底下，不建在申請時建立的管理員帳號底下。

延伸閱讀：帳號結構、免費額度與憑證設計

登入頁的租用戶與使用者名稱欄位、home region 對 Always Free 的限制，見 Oracle Cloud 的帳號結構與 home region；登入之後要建主機時各家免費額度的計算方式，見 雲端免費額度與小型主機的收費比較；session token 與 API 簽章金鑰這組取捨背後的概念，見 身分與存取憑證地基 — IAM 模型、OIDC 短期憑證與權限邊界設計 的〈長期 access key 的風險〉與〈OIDC：給 CI/CD 的短期憑證〉。

主控台的共通結構：選單、區域選擇器與資源分組篩選器

主控台上有三種元件第一次登入時要先找到，各家有沒有、放在哪裡不同：

• 導覽選單：列出所有服務，依領域分類。Oracle Cloud 是左上角的 ☰，AWS 與 Google Cloud 也有同樣位置的選單，另外都有一個搜尋框，打服務名稱就能直接跳過去。不知道某個功能在哪一類底下時，搜尋框比翻選單快。
• 區域選擇器：大部分資源屬於某一個區域，主控台一次只顯示目前選定區域裡的資源。主機建在東京、選擇器停在新加坡時，主機清單是空的。Oracle Cloud 與 AWS 的選擇器在右上角；Google Cloud 的主控台不以區域切換，而是在清單上列出每個資源的區域。
• 資源分組篩選器：資源還歸屬於某一個分組（Oracle Cloud 的 compartment、Google Cloud 的 project、AWS 的帳號），清單頁只列出目前選定分組裡的資源。Oracle Cloud 的清單頁上有一個 compartment 篩選器，預設常停在 root，資源建在別的 compartment 時，要切過去才看得到；Google Cloud 在頂端列切換專案；AWS 的分組由目前登入的帳號決定，清單頁上沒有篩選器。

清單看起來是空的、或剛建的資源找不到時，先查區域與分組這兩個篩選條件，多數時候資源還在，只是篩掉了。

身分與權限：誰能登入、能做什麼

帳號的管理員在這個領域管理使用者、群組、角色與權限政策，以及登入方式（密碼政策、多因素驗證、外部身分提供者）。日常的工作是加人、移除人、調整誰能動哪些資源，以及替程式建立服務帳號或 API 金鑰。

新帳號開好之後，這個領域裡要先做兩件事：替申請時建立的管理員帳號開啟多因素驗證，並另外建一個日常使用、權限較小的帳號（權限只給到工作需要的範圍，見 Least Privilege 卡），管理員帳號只在必要時用。理由是管理員帳號能動整個帳號裡的一切，它的密碼外洩時沒有任何一層權限擋得住；日常操作用權限較小的帳號，外洩時影響範圍就限在那些權限裡。帳號不是自己申請的（公司指派、接手別人的帳號）時，先確認誰持有那個管理員帳號、它有沒有開多因素驗證。公司的帳號常屬於一個組織，組織的政策（AWS Organizations 的 SCP、Google Cloud 的組織政策）可能讓某些選項建不起來，建立時收到權限不足的錯誤而自己的權限看起來沒問題時，去問管理組織的人。權限的分級與日常帳號的設計見 團隊權限分級與存取管理，概念見 IAM 卡。

資源分組與標籤：資源屬於哪個專案、誰付錢

管理員與使用者在這個領域把資源分組，讓權限、預算與清理以組為單位進行；標籤則在組之外再加一層分類，用來分攤費用、篩選資源。Oracle Cloud 的分組是 compartment（可以巢狀），Google Cloud 是 project（上面還有 folder 與 organization），AWS 是帳號本身（多個帳號由 Organizations 統一管理）。

實驗用的資源放進一個專用的分組，清理時刪那一組的資源，不會碰到正式環境；權限政策也能限定只作用在那一組。用帳號或專案隔開環境的設計見 跨帳號策略 — Organizations、SCP 與帳號工廠。

運算：主機與映像檔

使用者在這個領域建立、停止、刪除主機，管理映像檔、主機範本與自動擴展的主機群組，建立主機時的每個選項見 建立雲端虛擬機的選項。日常會來這裡做的事是看主機狀態、停機省錢、調整規格，以及刪除不用的主機。

網路：虛擬網路、負載平衡、DNS 與公開 IP

管理虛擬網路與 subnet、路由與閘道、防火牆規則、負載平衡器、DNS 區域、保留的公開 IP。主機連不進去、或連不到其他服務時，原因多半在這個領域的路由與防火牆規則。subnet 怎麼切、路由與防火牆規則怎麼設計見 模組三：網路地基；建立主機時的網路欄位見 網路：subnet、私有 IP、公開 IP 與防火牆規則。

儲存：區塊磁碟、物件儲存與檔案系統

三種儲存在選單上通常分開：區塊磁碟（主機的開機磁碟與資料磁碟、它們的備份）、物件儲存（以 bucket 存放檔案，經由 HTTP 存取）、共享檔案系統（多台主機同時掛載）。刪除主機之後留下的開機磁碟、沒有人記得的備份與 bucket 仍然是存在的資源，會繼續佔用免費額度，超出額度之後的結果依業者與帳號狀態而定（例如試用中由試用金支付、付費帳戶照一般價格計費），清理時要回來看。Oracle Cloud 三種帳號狀態各自的結果見 Oracle Cloud 的帳號結構與 home region 的〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉，Google Cloud 與 AWS 的見 雲端免費額度與小型主機的收費比較 的〈試用結束後帳號與資源的處置〉。開機磁碟的選項見 磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留。

帳單與成本：花了多少、會花多少

負責付款的人在這個領域查看帳單與付款方式、依服務與分組分析費用、設定預算與警示。新帳號開好之後要來這裡設一個預算警示，讓費用超過預期時有人收到通知。帳號已經升級成付費帳戶時，超出免費額度或用到非免費機型的費用會直接扣款，所以這類帳號一定要設。

Oracle Cloud 沒有升級的帳號在試用結束後不會開始計費，預算警示在這種帳號上的用處是在試用期間提早看到哪些資源不在免費額度內。成本監控與異常告警見 運行期維運的成本管理；預算門檻怎麼從每月能接受的上限與費用訊號的延遲推出來、扣款的信用卡要留多少額度，在 租用雲端主機之前的費用規劃：費用訊號的延遲、停止之前的最大超支、扣款的信用卡額度、配額與預算門檻的計算，以及停損停到哪一層；Google Cloud 各機制的範圍在 GCP 上的雲端費用失控防護，門檻比例、建立指令與從預算通知觸發自動停損的建置在 GCP 預算警示與停損開關的實測紀錄。帳單上已經出現費用、要找出是哪個資源在計費時，在成本分析頁依服務與資源拆開；免費額度的帳號最常見的來源是刪除主機後留下的開機磁碟（磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留 的〈刪除（終止）主機時開機磁碟的預設去留〉）、選到不在免費額度內的機型，以及 AWS 對公開 IPv4 位址的計費。免費額度的規則見 雲端免費額度與小型主機的收費比較。

監控、日誌與告警：系統現在的狀態

主機與服務的指標（CPU、記憶體、網路流量）、日誌的收集與搜尋、告警規則與通知管道。主機變慢、服務停掉時，先來這裡看指標與日誌。log group、metric 與 alarm 怎麼跟資源一起管理見 模組六：可觀測性與 log。

稽核紀錄：誰在什麼時候做了什麼

業者自動記錄對雲端資源的管理操作（建立、修改、刪除）：誰、什麼時間、從哪個 IP、做了什麼操作、對哪個資源。主控台上建立、修改、刪除資源的點擊最後也是 API 呼叫，同樣會留下紀錄。要查出某個資源是誰、在什麼時候改掉或刪掉的，看這裡的紀錄。讀取資料這一類操作不一定預設記錄：Google Cloud 的 Data Access 稽核紀錄除了 BigQuery 之外預設關閉，AWS CloudTrail 的 Event history 只列管理操作，兩者都要另外打開。稽核紀錄的保存期限各家不同，要長期保存時要另外匯出。AWS 的同一個功能見 CloudTrail 卡。

安全服務：管理通道、金鑰、秘密與弱點掃描

業者提供的安全服務多半集中在一個領域：不經公開 IP 登入主機的服務（Oracle Cloud Bastion、Google Cloud IAP、AWS Systems Manager）、金鑰與秘密的保管（Oracle Cloud 的 Vault、Google Cloud 的 Secret Manager、AWS 的 Secrets Manager）、主機的弱點掃描、組態風險的偵測。管理通道的設計見 伺服器管理通道的設計。Oracle Cloud 的 Vault 是業者的金鑰管理服務，跟 HashiCorp 公司的同名自架產品是兩個不同的產品；不用業者服務、自己架秘密管理時的選項見 HashiCorp Vault 卡。

配額與限制：帳號最多能開多少

每個帳號對每種資源都有數量上限（主機台數、核心數、公開 IP 數），超過時建立會失敗。這個領域列出每項上限與目前用量，要開更多時從這裡申請調高。上限是帳號允許的數量，不保證那一區有那麼多硬體——Oracle Cloud 的配額表會列出某一區根本沒有提供的機型，實例見 Oracle Cloud 的帳號結構與 home region 的〈E2.1.Micro 在各區域的供應：服務配額表與 404 錯誤〉。為一次預知的活動調高上限時，申請要排在活動前多久、被拒時怎麼辦，見 9.11 高峰事件準備〈T-90 → T-0 準備時程〉的 T-30。

新帳號開好之後先看的領域

帳號的第一小時要處理的安全底線——管理員帳號的多因素驗證、確認自己的登入身分、檢查既存的存取金鑰、確認稽核紀錄有在記、設帳單警報——整理在 拿到雲端帳號的第一天 的〈第一小時：安全底線〉，那一篇的操作路徑以 AWS 為例，其他業者對應的選單見下方〈各家的選單名稱：各管理領域在三家主控台上的位置〉；接手已經有資源的帳號時，先看同一篇的〈帳號現況判讀：空帳號還是既有資源〉。在那幾項之外，要開始建資源之前再處理下面這幾件事：

• 身分與權限：另外建一個日常使用、權限較小的帳號，理由見〈身分與權限：誰能登入、能做什麼〉。

• 資源分組：建一個實驗用的分組，之後的資源都建在裡面，清理時只看這一組。Oracle Cloud 建一個 compartment，compartment 要先清空裡面的所有資源才能刪除，刪除的順序見 Oracle Cloud 建立主機的實測紀錄 的〈刪除這組資源的順序〉；Google Cloud 建一個 project，刪除 project 會連同裡面的資源一起刪；AWS 的分組單位是帳號本身，另開帳號要由組織的管理帳號在 AWS Organizations 裡做，被指派管理單一帳號的人在那個帳號裡改用標籤與 Resource Groups 分組。

• 配額與限制：上限依帳號類型而不同（Oracle Cloud 的〈Service Limits〉在運算的上限表上分成 Universal Credits 一欄，與 Pay As You Go 和試用帳號共用的一欄（欄名「Pay As You Go or Trial」），兩欄的值不同），所以要用的機型在自己這個帳號、這個區域的上限是多少，要到這個領域的頁面查；上限是 0 時那種機型建不起來，要先申請調高。上限不是 0 也不代表那一區有那種硬體。

各家的選單名稱：各管理領域在三家主控台上的位置

AWS 的身分與權限有兩處：公司帳號用 SSO 登入時，人員與他們能進的帳號在 IAM Identity Center 管理；IAM 管的是帳號裡的角色與程式用的身分。Oracle Cloud 的選單取自 2026-10-24 的主控台英文介面；選單名稱各家會隨改版調整，對不上時用搜尋框找服務名稱。Oracle Cloud 主控台各分類的完整內容見 Oracle Cloud 主控台導覽。

延伸閱讀：服務層的對照

這篇對照的是三家主控台上的管理領域與建立主機的欄位；資料庫、訊息佇列、函式這類託管服務在 AWS、Google Cloud 與 Azure 之間怎麼對應、對應的服務在哪些地方不等價，見 雲端服務對照地圖（AWS / GCP / Azure）。

虛擬網路與 subnet：主機放在哪一段網路

每台主機的網卡都接在一個虛擬網路裡的某一個 Subnet 上；虛擬網路在 Oracle Cloud 叫 VCN，在 Google Cloud 與 AWS 叫 VPC（見 VPC 卡）。建立主機的人在建立頁要決定的是接在哪一個 subnet。在 Oracle Cloud 與 AWS 上，選定的 subnet 的路由表決定網際網路來的連線能否送到這台主機、主機對外連線時走哪一條路；網卡能否拿到公開 IP，Oracle Cloud 由 subnet 的屬性決定，AWS 是另一個獨立的設定（見下文 AWS 的說明）。Google Cloud 的 subnet 沒有公開與私有之分，主機能否從網際網路直接連到、對外連線走哪一條路，由主機是否有外部 IP 與防火牆規則決定。

概念上，subnet 分成公開與私有兩種：

• 公開 subnet：路由表（route table）有一條通往網際網路閘道（internet gateway）的路由，裡面有公開 IP 的主機可以被網際網路直接連到開放的 port，也經由這個閘道對外連線。
• 私有 subnet：沒有那一條路由，外面連不進來。主機要對外連線（下載套件更新）時經由 NAT 閘道（NAT gateway）出去；要連業者自己的服務（物件儲存、監控、管理通道服務）時，經由業者提供的私有連線，Oracle Cloud 叫服務閘道（service gateway）、AWS 叫 VPC endpoint、Google Cloud 叫 Private Google Access。

公開與私有這個區分記在哪裡，Oracle Cloud 與 AWS 的做法不同。Oracle Cloud 記在 subnet 自己的屬性上：建立 subnet 時有一個「禁止公開 IP」的屬性，打開的就是私有 subnet，裡面的網卡指派不了公開 IP。AWS 上公開 IP 與路由是兩個獨立的設定，官方〈Subnets for your VPC〉分別寫了兩者：

• 網卡是否有公開 IP：由 subnet 的「自動指派公開 IPv4」屬性決定，建立主機時可以對那一台主機覆寫這個屬性。
• 網際網路來的連線能否送到主機：由 subnet 的路由表決定。官方的定義是，有直接通往 internet gateway 路由的是公開 subnet，沒有的是私有 subnet。

所以 AWS 私有 subnet 裡的主機可以有公開 IP，而那個公開 IP 收不到網際網路來的連線。Google Cloud 沒有公開與私有 subnet 之分，任何 subnet 裡的主機都可以有外部 IP。另外，AWS 的一個 subnet 只在一個可用區裡，兩台主機要分到不同可用區時，要放進兩個不同可用區的 subnet；Oracle Cloud 與 Google Cloud 的 subnet 可以跨同一區域內的可用區，見 位置：區域、可用區與故障域。

在 Oracle Cloud 上，公開 subnet 裡沒有公開 IP 的主機完全沒有出站路徑：官方〈Internet Gateway〉的說明是，要經由 internet gateway 連網際網路的資源必須在公開 subnet 裡、而且有公開 IP，只有私有 IP 的資源要改走 NAT 閘道。所以在 Oracle Cloud 上，放進公開 subnet 的主機要同時給公開 IP 才有出站路徑；不給公開 IP 的主機放私有 subnet，出站走 NAT 閘道。在私有 subnet 的 Ubuntu 主機上實際加過 NAT 閘道、路由規則與只掛在那台主機上的 NSG，指令與加之前的錯誤原文見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉。

替單一台實驗機選 subnet 與公開 IP 時，要先確定三項需求：主機上是否有服務要讓網際網路的人連、管理員從哪裡登入、主機自己是否要對外連線（下載套件更新）。下面各條依對外服務與登入方式的組合寫出放法，出站路徑寫在各條裡：

• 沒有對外的服務、管理員經由業者的管理通道登入：放私有 subnet、不給公開 IP，外面連不進來。Oracle Cloud 的 Bastion 是業者託管的服務、不是自己架的 跳板機（bastion host），經由它登入的主機不需要公開 IP；它的網路條件、費用與配額見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉。主機要下載套件更新時，路由表要另外有一條經過 NAT 閘道的路由；AWS 的 NAT Gateway 與 Google Cloud 的 Cloud NAT 另外計費，費率見各家價格頁。
• 沒有對外的服務、管理員直接用 SSH 登入：放公開 subnet、給公開 IP，設定最少，出站也經由網際網路閘道。代價是 SSH port 對網際網路可見，要把防火牆規則的來源收緊成自己的 IP，自己的 IP 會變時每次都要改規則。三家業者預先準備的網路規則（Oracle Cloud 主控台新建 VCN 時的 Default Security List、Google Cloud default 網路的 default-allow-ssh、AWS 啟動精靈新建的 security group）預設都放行 22 port；Google Cloud 那一條的來源是整個網際網路，Oracle Cloud 那一份在 2026-10-24 實測時也是，見〈各家預設網路規則對 SSH 的開放〉。
• 有一個服務要讓網際網路的人直接連（例如自架 VPN）：放公開 subnet、給公開 IP，防火牆規則只放行那一個服務的 port。管理員的 SSH 不必跟著對外：來源收緊成自己的 IP，或先連上 VPN、再經由主機的私有 IP 登入。
• 網頁這類 HTTP 服務：主機放私有 subnet，由放在公開 subnet 的負載平衡器承接網際網路來的連線。Oracle Cloud 的 Always Free 含一個 10 Mbps 的負載平衡器；AWS 與 Google Cloud 的負載平衡器另外計費，計費項目見各家價格頁。

建立頁替主機準備網路的方式，各家預先準備的東西不一樣。Oracle Cloud 的建立頁提供「選既有的 VCN」與「建一個新的 VCN」兩條路，選「建新的」時，主控台會順手建一個 VCN、一個 subnet 與一份預設的防火牆規則；Google Cloud 的專案預先就有一個 default 網路，建立頁預設把主機放進去；AWS 的啟動精靈把主機放進帳號的預設 VPC，並順手建一個新的 security group。要把主機放進自己設計過的網路時，先在網路的頁面建好虛擬網路與 subnet，再回到建立頁選那個 subnet。Oracle Cloud 的網路下拉選單還受 compartment（tenancy 底下分組資源的容器）篩選，只列出選定的 compartment 裡的 VCN；篩選的規則見 Oracle Cloud 主控台導覽 的〈清單頁的 compartment 篩選器〉，實際卡住的情形見 Oracle Cloud 建立主機的實測紀錄 的 Networking 段。

私有 IP：主機在虛擬網路裡的位址

每張網卡一定有一個私有 IP，從 subnet 的位址範圍裡分配。建立頁的選項是自動分配（預設）或手動指定一個位址。單一台主機選自動分配；要讓其他設定寫死這台主機的位址時（例如另一台主機的設定檔、防火牆規則只放行這一個位址），才手動指定。

主機停止與重開時，私有 IP 都不會變，終止主機時業者才把它釋放。同一個虛擬網路裡的其他主機用這個位址連它。

Oracle Cloud 另有一個 DNS record 選項：勾選之後，網卡會在 VCN 的內部 DNS 裡得到一個名稱，同一個 VCN 裡的主機可以用名稱代替 IP 連它。這個選項要 VCN 與 subnet 都設了 DNS label（建立 VCN 與 subnet 時填的名稱片段）才能用，名稱只在 VCN 內部有效，網際網路上查不到。同一個 VCN 裡有其他主機要連這一台時勾選，設定檔寫名稱比寫 IP 好維護；只有一台主機時勾不勾都沒有差別。

公開 IP：網際網路上的入口

公開 IP 讓網際網路上的人能直接連到這台主機。在 Oracle Cloud 上，它只能指派給公開 subnet 裡的網卡；主機放在私有 subnet 時，建立頁上的公開 IP 選項是灰的。

Oracle Cloud 的公開 IP 分兩種，性質在建立後不能互換：

• 臨時（ephemeral）：跟著主機的生命週期。主機停止時保留，終止時自動刪除（Oracle Cloud 上一台主機停止 2 小時再啟動，公開 IP 前後相同；收掉時先刪 DNS 紀錄再終止主機的實測，見 Oracle Cloud 主機的暫停與恢復上線實測紀錄：暫停前的基準、收窄入口、停止主機、停止期間的計費與 Cloudflare 的回應、恢復上線的每一步與耗時，以及收尾時 DNS 紀錄與主機的刪除順序）。建立頁上勾選「自動指派公開 IPv4」拿到的是臨時公開 IP。DNS 記錄指向臨時 IP 時，主機終止、重建之後拿到的是另一個位址，DNS 記錄仍然指向那個已經刪除、不再屬於這個帳號的舊位址；DNS 查詢照常回應那個舊位址而不會報錯。業者會把收回的位址再分配給別的客戶，DNS 還指著它時，網域的流量會送到對方的主機，對方也能替這個網域申請到憑證，這是懸空 DNS 的成因，處置見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS〈懸空 DNS 與子網域接管〉；暫停或重建主機時哪些情形會把 IP 還給業者，見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停期間仍指向這台主機的外部設定〉。AWS 自動指派的公開 IPv4 與 Oracle Cloud 不同，主機停止時就收回、再啟動時換成新的位址（AWS 文件〈Amazon EC2 instance IP addressing〉）。
• 保留（reserved）：獨立的資源，主機終止之後仍然存在，可以再指派給另一台主機。要讓 DNS 記錄或外部白名單長期指向同一個位址時用保留公開 IP。

在 Oracle Cloud 上，公開 IP 可以在建立之後再加、也可以拿掉：公開 subnet 裡的網卡沒有公開 IP 時，可以另外建一個臨時公開 IP 指派上去。AWS 上建立時沒有自動指派的主機，之後要對外得另外掛一個 Elastic IP。

主機所在的 subnet 在建立之後能否更換，三家的官方說明不同。Oracle Cloud 與 AWS 的官方網卡說明都寫明主要網卡（建立主機時自動建的那一張）不能從主機拿掉，網卡的私有 IP 從它所在的 subnet 分配，兩家的文件都沒有寫主要網卡可以換到另一個 subnet；所以在這兩家，把 subnet 當成建立時就決定的選項，主機要不要對外在建立頁選 subnet 時就決定。

在 Oracle Cloud 上，放在私有 subnet 的主機之後要對外，可走的路是加一張接在公開 subnet 的次要網卡、改由放在公開 subnet 的負載平衡器承接，或重建主機。官方說明次要網卡可以接在同一個或另一個 VCN 的其他 subnet，條件是跟主機在同一個可用區。在 Oracle Cloud 上，放在公開 subnet 卻不給公開 IP 的主機沒有出站路徑（見〈虛擬網路與 subnet：主機放在哪一段網路〉）。

Google Cloud 的〈Migrating a VM between networks〉說明頁寫明，主機的網卡可以換到同一個 VPC 網路裡的另一個 subnet：主機要先停止，換完之後主機仍在原來的區域與可用區，網卡的 MAC 位址會改變，目標 subnet 的位址範圍與原本不同時，內部 IP 也會改變。

AWS 對每個公開 IPv4 位址按小時另外計費，見 雲端免費額度與小型主機的收費比較。

主機是否指派了公開 IP，決定它在網際網路上暴露的面積。管理用的 SSH port 經由公開 IP 對外開放之後，網際網路上的掃描程式會持續嘗試登入。

防火牆規則的位置與合併方式

一個封包要到得了主機上的程式，要通過兩道關：雲端業者那一側的防火牆規則，以及主機作業系統裡的防火牆，兩道都放行才到得了。

雲端業者那一側，Oracle Cloud 與 AWS 有兩個掛規則的位置，Google Cloud 只有一個：

兩個位置的規則同時存在時，Oracle Cloud 取兩邊的聯集，AWS 要兩邊都放行，Google Cloud 的 VPC 防火牆規則只有一個位置而不必合併：

• Oracle Cloud 取聯集：官方〈Security Rules〉的說明是，套用在一張網卡上的規則是 subnet 的 security list 與這張網卡加入的所有 NSG 的聯集。Security list 與 NSG 都只能寫放行的規則，沒有拒絕規則，所以任何一邊有一條規則放行，封包就通過雲端那一道關。以 22 port 為例：

  Security list 對 22 port	NSG 對 22 port	封包能不能通過雲端那一道關
  有放行規則	沒有規則	能
  沒有規則	有放行規則	能
  沒有規則	沒有規則	不能

  任一邊有一條放行規則，封包就通過雲端那一道關，所以兩邊都沒有放行 22 port 的規則時，22 port 的連線才會被擋下。預設的 security list 放行 22 port 時，NSG 裡即使沒有 22 port 的規則，22 port 的連線照樣由 security list 放行通過。

• AWS 兩個位置都要放行：封包要先通過 subnet 的 Network ACL，再通過網卡的 security group。Network ACL 可以寫拒絕規則，官方建議把它當成第二道控制，用來擋掉特定的流量；security group 放行了，Network ACL 擋下來的封包仍然到不了。

• Google Cloud 的 VPC 防火牆規則只有一個位置：防火牆規則設在 VPC 上，再用 網路標籤（network tag） 或 服務帳號（service account） 選出規則要套用的主機，沒有 subnet 這一層的規則。單一專案、沒有另外建過防火牆政策時只會遇到 VPC 防火牆規則；Google Cloud 另有掛在 VPC 網路上的 network firewall policy 與組織層的 hierarchical firewall policy，建了之後會跟 VPC 的防火牆規則依官方說明的評估順序一起評估，那時套用到一台主機的規則就不只 VPC 防火牆規則這一個來源。

Oracle Cloud 建立頁上能設定的只有 NSG：「Use network security groups to control traffic」這個選項把主機的網卡加入某幾個 NSG，只有選既有的 VCN 時才出現。Security list 要到 VCN 的頁面設。官方文件說明 NSG 讓 subnet 的切法與應用程式的安全需求分開管理：同一個 subnet 裡的資料庫主機與網頁主機可以開不同的 port，不必為了開不同的 port 拆成兩個 subnet。

作業系統的防火牆（iptables、nftables、ufw）由主機自己管，不在雲端的主控台上。雲端那一道關放行了某個 port、連線仍然被拒絕時，要進主機查作業系統這一道。Oracle Cloud 的平台映像出廠就帶著一組作業系統防火牆規則，其中有讓主機連到開機磁碟與區塊磁碟的 iSCSI 端點的必要規則，官方〈Images〉建議不要移除；官方〈Images〉那一頁另外寫明在 Ubuntu 映像上不要用 ufw 改規則，用它改可能讓主機開不了機。SSH 連不上時，先看症狀是連線逾時還是連線被拒：逾時代表封包沒有送到主機（雲端規則、路由或作業系統防火牆丟棄了封包），被拒代表封包到了主機而 22 port 沒有程式接受連線或防火牆明確回拒，分辨方法見 Connection Refused vs. Timeout（連線被拒與逾時）。主機上跑 Docker 時，容器發佈的連接埠由 Docker 在作業系統防火牆之前轉給容器，ufw 與 firewalld 的一般規則管不到它；封包路徑與限制的寫法見 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖 的〈Docker 發佈的連接埠：封包路徑與限制的寫法〉。

各家預設網路規則對 SSH 的開放

三家業者替使用者預先建好或順手建的網路，預設的規則都放行 22 port 的 SSH 流量。Google Cloud 那一條規則的來源是整個網際網路，Oracle Cloud 那一份的來源在 2026-10-24 實測時也是整個網際網路：

• Oracle Cloud：建立頁選「建一個新的 VCN」時，主控台一起建一份「Default Security List」。官方〈Security Lists〉描述的是這條規則的用途：放行來自「authorized source IP addresses」的 TCP 22，讓使用者建好新的 VCN 與公開 subnet 之後，不必自己寫規則就能用 SSH 連上新建的 Linux 主機；這段描述沒有寫來源欄位的預設值。2026-10-24 實測時，主控台建出來的這條規則來源是 0.0.0.0/0。兩者不衝突：官方寫的是規則的用途，實測讀到的是那一次建出來的預設值。官方沒有寫預設值，所以建好之後到 subnet 的 security list 看一次實際的來源。Subnet 沒有另外指定 security list 時套用的就是這一份，所以這條規則的來源是 0.0.0.0/0 時，在新建的公開 subnet 裡建一台有公開 IP 的主機，那台主機的 SSH port 一建好就對網際網路開放。這份規則的完整內容（實測值）見 Oracle Cloud 建立主機的實測紀錄 的 Networking 段。
• Google Cloud：專案建立時就有的 default 網路帶一條 default-allow-ssh 規則，放行 0.0.0.0/0 的 TCP 22，套用在這個網路裡的每一台主機。換掉這條規則的順序見 GCP VM 的 SSH 與 RDP 管理通道 的〈切換到 IAP 的順序〉，逐步的指令見 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄。
• AWS：EC2 啟動精靈順手建的 security group 預設放行進來的 SSH 流量（官方〈Prerequisites for EC2 Instance Connect〉的說明），放行的來源要在精靈的網路設定那一步確認並收緊。

收緊的做法是把來源改成管理員的 IP，或改用不需要對外開放 SSH 的管理通道（見 伺服器管理通道的設計）。

其他網路欄位：VNIC 名稱、IPv6 與 Launch options

• 網卡名稱（VNIC name）：顯示用的名稱，不必唯一、之後可以改，不影響連線。留空時業者自動產生。
• IPv6：只有 VCN 與 subnet 都設了 IPv6 位址段時才能勾。只用 IPv4 連線的實驗機不需要。
• Launch options（Oracle Cloud）：網卡的虛擬化方式，只對虛擬機有效。預設值由映像檔決定，是那個映像檔支援的方式；改成映像檔不支援的方式時，主機可能開機後沒有網路，所以維持預設。

各家的欄位名稱：虛擬網路、網卡、防火牆規則與保留的公開 IP

Subnet 的切法、路由表與 NAT 的設計見 VPC、subnet 與 security group；網路通了之後，登入時用的金鑰與帳號見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務。

章節文章

子資料夾

• Oracle Cloud 的實作紀錄：照著做就能重現的操作紀錄（建立 A1 主機與建立前的檢查、容量不足時的重送腳本、Bastion 工作階段逾時的排查、Run Command 補公鑰的嘗試、改用 Oracle Linux 並放公鑰重建後經由 port forwarding session 登入；私有子網路的 Ubuntu 主機加出站、序列主控台的連線、被閒置回收之後的重建腳本；放在 Cloudflare 後面的主機停機再恢復上線的演練與收尾時的刪除順序），概念寫在本層的文章，實作文章連回來

Backlog

SSH 金鑰欄位把公鑰放進主機的方式

Linux 主機用 SSH 公鑰驗證登入：主機的使用者家目錄裡有一份允許清單（~/.ssh/authorized_keys），持有清單上某一把公鑰對應私鑰的人才能登入。建立頁的 SSH 金鑰欄位把一把公鑰交給業者，業者把它存進主機的中繼資料（metadata）。Oracle Cloud 與 AWS 的 Linux 映像由 cloud-init（多數 Linux 雲端映像預先裝好、開機時讀中繼資料做初始設定的程式）在主機第一次開機時讀出公鑰、寫進預設使用者的 authorized_keys；Google Cloud 的映像由業者的 guest agent 持續依中繼資料同步金鑰，不限第一次開機。

Oracle Cloud 的建立頁提供四個選項：

• 讓業者產生一對金鑰（Generate a key pair for me）：業者產生一對 RSA 金鑰，公鑰放進主機，私鑰讓使用者在這一頁下載。私鑰只能在這一刻下載，離開頁面之後就拿不到；官方提醒持有私鑰的人都能登入這台主機，要存在安全的位置。
• 上傳公鑰檔（Upload public key files）：上傳自己電腦上已經有的公鑰（.pub 檔）。私鑰從頭到尾只在自己的電腦上。
• 貼上公鑰（Paste public keys）：同上，改成貼上公鑰的文字。誤貼私鑰時頁面會報錯。
• 不放金鑰（No SSH keys）：主機裡沒有任何允許登入的公鑰，而且官方說明選了之後就不能再提供公鑰。SSH 登入只能經由 Bastion 的 managed SSH session（見〈不放金鑰時的登入服務〉）；Bastion 的 port forwarding session 要用主機 authorized_keys 裡事先放好的公鑰，選了 No SSH keys 的主機用不了它。所以 managed SSH session 不支援的主機（A1 機型加非 Oracle Linux，或可用的 plugin 裡沒有 Bastion 的作業系統版本，見〈不放金鑰時的登入服務〉）選了 No SSH keys，就沒有 SSH 登入的入口。其餘的入口是〈建立之後加金鑰與金鑰遺失時的入口〉列的救援入口。

自己已經在用 SSH 的話，上傳或貼上自己的公鑰比較好：私鑰不經過任何網頁，也不必管理另一把專門給這台主機的金鑰。本機還沒有金鑰時，用 ssh-keygen -t ed25519 產生一對（ed25519 是新版 OpenSSH 的 ssh-keygen 預設產生的型別），公鑰在 ~/.ssh/id_ed25519.pub；那個路徑已經有一把金鑰時，ssh-keygen 會問要不要覆寫，回答 n，或用 -f <新的檔名> 另存一把。

預設使用者名稱與映像檔的對應

在 Oracle Cloud 與 AWS 上，公鑰寫進的是映像檔預先建立的那個使用者，名稱依作業系統而定。Oracle Cloud 的官方說明是 Ubuntu 平台映像的使用者名稱是 ubuntu，Oracle Linux 與相容 RHEL 的平台映像是 opc。登入指令因此是 ssh ubuntu@<主機的 IP> 或 ssh opc@<主機的 IP>，用錯名稱時 SSH 回的是 Permission denied (publickey)，看起來跟金鑰錯了一樣。Google Cloud 的使用者名稱取自中繼資料裡每一把公鑰附帶的名稱，guest agent 依那個名稱在主機上建使用者。

這個預設使用者有 sudo 權限，而且只用金鑰登入、沒有設密碼。多人共用同一台主機時，各自建自己的使用者、各自放自己的公鑰，誰做了什麼才分得出來；共用一個帳號時，登入紀錄只顯示那個帳號，對不到是哪一個人，有人離職也無法只撤銷他一個人的存取，見 伺服器管理通道的設計 的〈主機登入驗證的做法：SSH 金鑰怎麼發、怎麼收回〉。

建立之後加金鑰與金鑰遺失時的入口

建立之後能不能再加金鑰，看業者用什麼把金鑰寫進主機。Oracle Cloud 的金鑰由 cloud-init 在第一次開機時寫進主機一次，之後要加金鑰，做法是先用現有的金鑰登入，再在主機裡把新的公鑰加進 authorized_keys。Google Cloud 的 guest agent 持續同步中繼資料，主機建好之後把公鑰加進主機或專案的中繼資料，guest agent 就會把它寫進主機。AWS 的 Systems Manager Session Manager 不經過 SSH，主機的 authorized_keys 裡沒有任何公鑰也能開工作階段，條件備齊時可以當成另一個入口。

所以在 Oracle Cloud 上，金鑰遺失或一開始沒放、又沒有開代理程式的 Bastion plugin（讓 Oracle Cloud 的 Bastion 服務在建立工作階段時，把一把公鑰臨時放進主機的功能，見〈不放金鑰時的登入服務〉）時，主機上沒有可以用 SSH 進去的入口。剩下的入口各有前提，而多數前提要在金鑰遺失之前就準備好：

• 序列主控台（serial console）：不經過網路與 sshd，在主控台上建一個主控台連線就能看到主機的開機畫面與登入提示。要在登入提示登進去，主機裡要事先有一個設了密碼的帳號，而平台映像的預設使用者只用金鑰、沒有密碼；沒有這種帳號時，只能照官方範例從開機選單進維護模式重設金鑰，那份範例只寫了 Oracle Linux 的 opc。救援帳號怎麼事先準備見 Serial Console（序列主控台） 的〈設計責任〉；在 Oracle Cloud 的 Ubuntu 24.04 主機上建序列主控台連線、改寫成 ProxyJump 設定與連上之後看到的開機輸出，見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈序列主控台：RSA 金鑰、建立連線、ProxyJump 設定與看到的開機輸出〉。
• Compute Instance Run Command：在主控台送一段腳本到主機裡執行。官方說明這個 plugin 以 ocarun 這個使用者執行，要寫另一個使用者家目錄裡的 authorized_keys，得事先在主機上替 ocarun 設好 sudo（官方列的做法是建立時用 cloud-init 設，或建好之後登入主機設；主機登不進去時只剩前一種）；2026-10-25 對一台沒設的 A1 Ubuntu 主機實測，ocarun 沒有 sudo，見 Oracle Cloud 建立主機的實測紀錄 的〈Run Command 補公鑰的嘗試：dynamic group、IAM 政策與 ocarun 沒有 sudo 的結果〉；送指令的人也要有對應的權限政策，主機上的代理程式要連得到 Oracle 的服務端點（主機在私有 subnet 時經由服務閘道或 NAT 閘道；官方只對「腳本或輸出放在 Object Storage」這種用法寫明出站條件，列的是 NAT 閘道、服務閘道或 internet gateway 其中一種）。
• 把開機磁碟掛到另一台主機：停止這台主機、把它的開機磁碟卸下，當成資料磁碟掛到另一台主機上，直接修改裡面的 authorized_keys，再掛回去開機。這一條不需要事先準備，代價是一段停機。
• 重建：終止這台主機，帶著新的公鑰重建。官方對金鑰遺失列的處置就是重建與序列主控台這兩種。

不放金鑰時的登入服務

選「不放金鑰」是一種刻意的設計：主機裡不放固定的公鑰，登入時由業者的服務決定這一次可以用哪一把金鑰。管理員登入一台主機要過三關，伺服器管理通道的設計 把它們叫做網路可達性（連線怎麼到得了主機）、通道授權（誰可以開這條連線）與主機登入驗證（主機是否接受登入者出示的金鑰）。業者的服務各自包辦其中幾關，所以三家對應的服務包辦的範圍不同：

• Oracle Cloud 的 Bastion：Bastion 是業者託管的服務，不是自己架的 跳板機（bastion host）。官方〈Bastion〉概觀頁的說明是 Bastion 位在公開 subnet（原文 reside in a public subnet），替使用者建好連到私有 subnet 裡目標資源所需的網路設施，所以經由它登入的主機不需要公開 IP；同一頁寫明 Bastion 不收費，但有服務配額（service limits）。誰能建工作階段由 Oracle Cloud 的權限政策決定。登入的流程是在主控台 Identity & Security → Bastion 建一個 Bastion，選一個目標 subnet、設定允許連入的來源位址範圍，再建一個工作階段（session），主控台會給出一條經由 Bastion 轉接的 ssh 指令。官方建立 Bastion 的說明頁寫明，目標 subnet 要是主機所在的 subnet，或主機所在的 subnet 接受其流量的另一個 subnet。概觀頁列的工作階段有三種，每一種都只在建立時設定的存續時間內能用來連線：

  • managed SSH session：主機上代理程式的 Bastion plugin 把建立工作階段時指定的公鑰臨時放進主機。網路可達性、通道授權與主機登入驗證都由 Bastion 包辦，所以主機可以不放任何金鑰。官方〈Known Issues for Bastion〉寫明，用 Arm 架構的 Ampere A1 機型建立、作業系統不是 Oracle Linux（例如 Ubuntu）的主機不支援這種工作階段，要改用下一項的 port forwarding session；Always Free 的 A1 主機選 Ubuntu 時就落在這個組合，實測的經過見 Oracle Cloud 建立主機的實測紀錄 的〈建立之後：Bastion managed SSH session 逾時的排查〉。Known Issues 只寫到作業系統，沒有寫版本，而 Bastion plugin 是否提供依作業系統的版本而定：同一份實測紀錄在 2026-10-25 用 oci instance-agent available-plugins get 查到 Oracle Linux 10 可用的 plugin 裡確定沒有 Bastion（9 與 8 的回應跟查不到時相同，這支工具分不出），查法與改用 Oracle Linux 並放公鑰重建的經過在〈重建：Oracle Linux 映像加建立時放公鑰，經由 port forwarding session 登入〉。
  • SSH port forwarding session：只把連線轉到一台主機的 22 port，不經過代理程式，只包辦網路可達性與通道授權；主機登入驗證仍然是主機自己的 sshd 與 authorized_keys 裡事先放好的公鑰。建立工作階段、在本機開轉送與登入的指令，見同一份實測紀錄的〈重建〉那一節。
  • dynamic port forwarding（SOCKS5）session：跟 SSH port forwarding session 一樣不經過代理程式，差別是轉接的目標不固定，可以動態連到私有 subnet 裡的任何資源；只登入一台主機時，用 managed SSH session 或 SSH port forwarding session 就夠。

• Google Cloud 的 IAP 加 OS Login：兩個服務各管一部分。IAP TCP forwarding 把連線轉進沒有外部 IP 的主機，誰能開這條通道由 IAM 決定，包辦網路可達性與通道授權；OS Login 在登入當下由 Google 查這個 Google 帳號登記的公鑰與 IAM 角色，決定能不能登入、以主機上的哪個 Linux 帳號登入，只包辦主機登入驗證。只開 OS Login、不用 IAP 時，連線是一般的 SSH：從 VPC 外面登入的話，主機要有外部 IP，防火牆規則要放行登入者的位址連到 22 port。兩者的機制與 OS Login 的啟用條件見 GCP VM 的 SSH 與 RDP 管理通道 與 OS Login 卡，啟用 OS Login 的指令見 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈啟用 OS Login：先授角色、單台先行、再做專案層級〉。

• AWS 的 Systems Manager Session Manager：經由主機上的 SSM Agent 開工作階段，不經過 SSH port，網路可達性、通道授權與主機登入驗證都由 Session Manager 包辦。EC2 Instance Connect 則只包辦主機登入驗證：它把一把公鑰推送到主機的中繼資料，官方說明這把公鑰在中繼資料裡保留 60 秒；連線本身仍然是一般的 SSH，主機的 security group 要放行 22 port。

這幾種服務需要的條件，依各個服務包辦的是哪幾關而不同：

• 主機上的代理程式（agent）：Oracle Cloud 的 managed SSH session 要代理程式的 Bastion plugin，在建立頁或主機頁面的 Oracle Cloud Agent 設定裡打開。AWS 的 Session Manager 要主機上有 SSM Agent 在執行，多數 AMI 預先裝了它。兩家的代理程式見 代理程式、中繼資料服務、初始化腳本、維護行為與標籤 的〈代理程式與 plugin：業者裝在主機裡的程式〉。Oracle Cloud 的 port forwarding session 與 Google Cloud 的 IAP 不需要代理程式，OS Login 由映像預先裝好的 guest environment 處理。

• 主機自己的權限：AWS 的 Systems Manager 要管理一台主機有兩個條件：主機上有 SSM Agent 在執行，以及 Systems Manager 有操作這台主機的權限。Systems Manager 預設沒有這個權限，給法有兩種，擇一即可：替主機掛一個 instance profile（主機用的 IAM 角色），或在 Systems Manager 的 Fleet Manager 打開 Default Host Management Configuration。Default Host Management Configuration 以帳號加區域為範圍，替那一區的每一台主機套用一個預設的 IAM 角色；它對一台主機生效的條件是那台主機用 IMDSv2、SSM Agent 在 3.2.582.0 以上。

• 登入者的權限：登入的人在雲端帳號裡要有建立工作階段、連到這台主機的權限，由管理員在身分與權限的政策裡授予。

• 連線的路徑：Oracle Cloud 的 managed SSH session 與 AWS 的 Session Manager，是主機上的代理程式主動往外連到業者的服務端點；主機在私有 subnet 時，這條往外的路經由業者的私有連線或 NAT 閘道，私有連線與 NAT 閘道有一種就夠；主機在公開 subnet 而且有公開 IP 時，經由 internet gateway。私有連線在 Oracle Cloud 是服務閘道；在 AWS 是 interface VPC endpoint，官方〈Improve the security of EC2 instances by using VPC endpoints for Systems Manager〉列出要建的有 ssm、ssmmessages、ec2messages 三個，這三個 endpoint 都要建（同一頁註明 SSM Agent 3.3.40.0 起，有 ssmmessages 可用時改走它而不走 ec2messages；SSM Agent 自己更新時另外要 s3 的 endpoint）。

  Oracle Cloud 對 managed SSH session 的閘道要求，官方兩頁的寫法不同：〈Bastion〉概觀頁寫的是 VCN 要有服務閘道、internet gateway、NAT 閘道三者之中的一個，以及通往那個閘道的路由規則；建立 Bastion 的說明頁只寫 VCN 要有服務閘道與通往它的路由規則。VCN 有服務閘道與對應的路由規則時，兩頁的要求都滿足。

  Oracle Cloud 的 port forwarding session 與 Google Cloud 的 IAP 是服務往裡連到主機的 22 port，主機的防火牆規則要放行來自服務那一端的連線。Oracle Cloud 那一端是建立 Bastion 時選的目標 subnet，主機的 security list 要放行來自那個 subnet 的 22 port；Google Cloud 那一端是官方 IAP TCP forwarding 說明列的 IAP 來源位址範圍 35.235.240.0/20。

上面這幾項條件少了任一項時，主機照樣建得起來，而登入會失敗；主機上又沒有放公鑰，能進去查原因的只剩〈建立之後加金鑰與金鑰遺失時的入口〉那一節列的序列主控台、Run Command、把開機磁碟掛到另一台主機修改，以及重建。在 Oracle Cloud 上第一次建主機、還不熟這些服務時，先放自己的公鑰比較保險：代理程式或 plugin 出問題、managed SSH session 建不起來時，port forwarding session 不經過代理程式，用自己的公鑰仍然登得進去。這條退路有兩個前提：主機讀得到中繼資料（cloud-init 要從那裡讀出公鑰寫進 authorized_keys，中繼資料的設定見 代理程式、中繼資料服務、初始化腳本、維護行為與標籤 的〈中繼資料服務與 Authorization header〉），以及主機的 security list 放行來自 Bastion 目標 subnet 的 22 port。managed SSH session 走通之後，這把公鑰拿掉與否取決於還有沒有另一條不經過代理程式的入口：拿掉之後只剩代理程式那一條；先建好序列主控台的救援帳號並登入過，拿掉公鑰時才仍然有兩條入口，判斷依據見 建立主機之前的檢查 的〈兩條登入路徑：各自依賴的元件與仍然共用的部分〉。這個做法只適用於 Oracle Cloud：Google Cloud 開了 OS Login 之後，guest agent 會忽略中繼資料裡的 SSH 公鑰。

各家的欄位名稱：金鑰欄位、預設使用者與不放金鑰時的登入服務

金鑰對了之後，連線還要通過的網路與防火牆見 網路：subnet、私有 IP、公開 IP 與防火牆規則，SSH 連線逾時與連線被拒兩種症狀各自指向哪一層見 Connection Refused vs. Timeout（連線被拒與逾時）；選 No SSH keys、改走 Bastion 時建立頁上要一起改的設定，見 Oracle Cloud 建立主機的實測紀錄 的 SSH keys 與 Management 段。

章節文章

子資料夾

• Google Cloud 的實作紀錄：2026-10-24 在測試專案上實跑的三篇操作紀錄（SSH 與 RDP 改走 IAP：盤點、救援入口、IAP 規則與 IAM、停用與刪除舊規則、OS Login、Cloud NAT 與移除外部 IP；MIG 與 GKE：新 template 與 canary、重建、退回 template、節點除錯、node pool、控制平面端點；預算與停損開關：預算、主題、服務帳號、函式與觸發器、兩段驗收、心跳監看、恢復），概念寫在本層的三篇文章，實作文章連回來

Backlog

這篇記錄在 Oracle Cloud 建立一台主機的實際操作，目標是 Always Free 額度內、沒有公開 IP、之後經由 Bastion 服務登入的 A1 Ubuntu 主機。Bastion 是 Oracle Cloud 代管的登入服務：建立 Bastion 時指定一個目標 subnet，它替那個 subnet 裡沒有公開 IP 的主機開有時效的 SSH 工作階段（session）；這次要用的 managed SSH session 這種工作階段，由主機上 Oracle Cloud Agent 的 Bastion plugin 在建立工作階段時把一把公鑰臨時放進主機。工作階段的種類與需要的條件見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉。內容依操作的順序是：建立之前的檢查（哪些設定建好就改不了、登入路徑上每個服務支援哪些機型與作業系統、登入路徑要有兩條、各自依賴哪些元件、容量稀缺時怎麼選設定）；前置的 compartment、VCN、service gateway 與 private subnet；主控台建立頁 Basic information、Security、Networking、SSH keys、Storage、Management 各分頁的取值與理由，含 Oracle Cloud Agent 各 plugin 的用途；等效的 CLI 指令；按下 Create 之後的容量不足，CLI 自己的重送、這個帳號量到的限流門檻與依回應碼調整間隔的重送腳本；主機建好之後建立 Bastion 與 managed SSH session、工作階段建立逾時的排查與官方列出的成因；用 Run Command 補公鑰時建立的 dynamic group 與 IAM 政策、送指令與讀結果的指令，以及 ocarun 沒有 sudo 的結果；這台主機剩下的登入入口；改用 Oracle Linux 映像、建立時放公鑰重建一台：建立之前依作業系統版本查可用的 plugin、指定大版本查映像、Oracle Linux 10.2 主機上沒有 Bastion plugin 的結果，以及經由 port forwarding session 登入與比對主機金鑰的指令；以及刪除這組資源的順序。每一節除了這次的取值，也寫出那一步沒做時會看到什麼、有哪些替代做法與各自換到什麼。每個欄位背後的概念連到 建立雲端虛擬機的選項 底下對應的那一篇，這裡只寫 Oracle Cloud 的欄位、這次的取值與實際跑過的指令。

這次的實測沒有在建立之前做那幾項檢查，結果是主機建好之後登不進去：managed SSH session 逾時三次，Run Command 執行得了指令卻沒有 sudo，主機又沒有公鑰。所以〈建立之前的檢查：套在這台主機上的查法與結果〉是事後補上的檢查，最後是照那幾項檢查重建一台才登入成功。

建立之前的檢查：套在這台主機上的查法與結果

這些檢查的判斷依據在 建立主機之前的檢查，這一節是套在這台主機（A1、Ubuntu 24.04、private subnet、經由 Bastion 登入）上的查法與結果。這些檢查排在進建立頁之前，因為結果會改變建立頁上的選擇：映像檔、SSH keys 欄位與要打開的 plugin。

建好就改不了的設定。用 CLI 讀修改主機的說明，找出建立後不能改的欄位：

1oci compute instance update --help | sed -n '/--metadata/,/--extended-metadata/p'

說明裡寫明 user_data 與 ssh_authorized_keys 建立後不能改，送出修改的請求會被拒絕。這台的設定裡落在這一種的是 SSH keys（選了 No SSH keys）、初始化腳本（沒放）、映像檔（Ubuntu；替換開機磁碟只能換同一個發行版）與 Shielded instance（Secure Boot、Measured Boot、Trusted Platform Module 都關閉）。指令裡 sed -n 的範圍從 --metadata 印到下一個選項 --extended-metadata，這是本機這一版 CLI 的選項順序；版本不同、順序不同時，把結束的 pattern 換成 --metadata 之後的那一個選項。

登入路徑上各服務的支援組合。這台規劃的 managed SSH session、不經過 plugin 的 port forwarding session，與事後想用的 Run Command，在官方文件上的結果：

這幾項在建立之前都查得到，Run Command 要事先替 ocarun 設 sudo、第一次建主機先放公鑰比較保險這兩點，登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 也有寫。2026-10-25 的建立沿用 2026-10-24 寫好的重送腳本，腳本的參數寫在讀這些文件之前，重新啟動時沒有再對一次。Known Issues 只寫到作業系統，沒有寫版本，而同一個作業系統的不同版本可用的 plugin 不同：後來重建時，2026-10-25 查到 Oracle Linux 10 確定沒有 Bastion plugin，9 與 8 的結果跟查不到時的回應相同、分不出來；這份清單隨代理程式的版本更新，要在建立當下自己查一次，查法見〈建立之前查映像檔版本與它可用的 plugin〉。

兩條登入路徑各自依賴的元件。這台只規劃了 managed SSH session 一條，它依賴 Bastion plugin 與支援範圍，而這次最沒有把握的正是這兩項。不經過 plugin 的 port forwarding session 要主機裡有公鑰，選了 No SSH keys 就沒有；兩種工作階段都經過 Bastion、security list 的 22 port 與主機的 sshd，所以有公鑰時，這一組擋得住 plugin 與支援範圍的問題，擋不住 sshd 改壞。不經過 sshd 的是序列主控台，它要一個設了密碼的帳號，Ubuntu 平台映像的 ubuntu 只用金鑰登入，要用初始化腳本在建立時建，而初始化腳本也是建立後不能改的欄位。所以這台建立的那一刻就只剩一條 SSH 路徑，而那條路徑是不支援的組合；剩下的入口是替換開機磁碟、把開機磁碟掛到另一台主機修改、序列主控台與重建，各自的條件見〈這台主機剩下的登入入口〉。

容量稀缺時的取捨。A1 在這一區的容量要靠重送腳本搶（〈重送建立請求：CLI 自己的重送、限流門檻與重送腳本〉），選錯建立後不能改的設定，補救就是再搶一次。照這一項，這台的設定該選補救代價低的那一種：放自己的公鑰、或改用 Oracle Linux 映像（A1 加 Oracle Linux 是 managed SSH session 支援的組合，版本要選可用 plugin 裡有 Bastion 的那一個）。「完全不放金鑰」裡跟機型無關的部分（Bastion 與 plugin 的設定、security list）可以在容易重建的機型上驗，而 A1 加 Ubuntu 這個組合支不支援只能讀 Known Issues，演練驗不到。這一區的 Change shape 視窗沒有列出 E2.1.Micro（見〈Basic information：名稱、compartment、位置、映像檔與機型〉），所以這個帳號找不到容易重建的免費機型；這時的做法是建這台時就選 A1 加 Oracle Linux 這個支援的組合來驗「完全不放金鑰」；它同樣要搶 A1 的容量，差別在組合不支援的風險已經由 Known Issues 排除，失敗的代價同樣是再搶一次。

進建立頁之前：compartment、VCN、閘道與 private subnet

建立頁上的網路欄位只能選已經存在的 VCN 與 subnet，或讓主控台建一個新的（新建的那個會帶一份對網際網路開放 22 port 的預設規則，見〈Networking：VCN、subnet 與公開 IP〉）。這次先用 OCI CLI 建好下面幾項，建立頁上一律選既有的。CLI 的登入方式見 從本機用 OCI CLI 操作 Oracle Cloud，主控台上的對應頁面是 Identity & Security → Identity → Compartments 與 Networking → Virtual cloud networks。

• compartment blog-verify：tenancy 底下分組資源的容器，實驗用的資源都放在這裡，清理時不碰 root 裡的其他設定。
• VCN verify-vcn（10.0.0.0/16，位址範圍的寫法見 CIDR 卡）：主機所在的虛擬網路。
• service gateway 與路由表 private-rt：私有 subnet 沒有通往網際網路的路由，主機上的 Oracle Cloud Agent 要連到 Oracle 自己的服務端點，經由 service gateway 出去；路由表裡那一條規則把送往 Oracle 服務網段的流量導向 service gateway。managed SSH session 對閘道與路由的要求見 登入 的〈不放金鑰時的登入服務〉，這次在其中選了 service gateway。

這份網路刻意沒有 NAT 閘道，主機只用來測 Bastion 登入；沒有 NAT 時，主機連不到 Ubuntu 的套件來源，apt 更新與安裝都會失敗。要當一般主機用，就另外建一個 NAT 閘道，在路由表加一條通往它的路由，並在 security list 的出站規則放行網際網路。這三項在 Ubuntu 24.04 主機上實際加過一次，出站規則改放在只掛在那台主機上的 NSG，指令與錯誤原文見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉。

• security list private-sl：入站只放行來源是同一個 subnet（10.0.1.0/24）的 22 port，因為 Bastion 的目標 subnet 設成這個 subnet，經由 Bastion 的 SSH 連線從這個 subnet 進來；出站只放行送往 Oracle 服務網段與同一個 subnet 的流量。
• subnet private-subnet（10.0.1.0/24）：建立時設定禁止公開 IP，並掛上上面的路由表與 security list。

1# 以下每條都以 --wait-for-state 等資源建好，再用 --query 取出新資源的 OCID 給下一條用
2oci iam compartment create --compartment-id <tenancy 的 OCID> --name blog-verify --description "<用途說明>"
3oci network vcn create -c <compartment 的 OCID> --cidr-blocks '["10.0.0.0/16"]' --display-name verify-vcn --dns-label verifyvcn
4oci network service-gateway create -c <compartment 的 OCID> --vcn-id <VCN 的 OCID> --services '[{"serviceId":"<All Services 的 service ID>"}]'
5oci network route-table create -c <compartment 的 OCID> --vcn-id <VCN 的 OCID> --display-name private-rt \
6  --route-rules '[{"destination":"<All Services 的網段>","destinationType":"SERVICE_CIDR_BLOCK","networkEntityId":"<service gateway 的 OCID>"}]'
7oci network subnet create -c <compartment 的 OCID> --vcn-id <VCN 的 OCID> --cidr-block 10.0.1.0/24 --display-name private-subnet \
8  --dns-label priv --prohibit-public-ip-on-vnic true --route-table-id <路由表的 OCID> --security-list-ids '["<security list 的 OCID>"]'

• <All Services 的 service ID> 與 <All Services 的網段>：用 oci network service list 查，名稱帶「All」的那一筆就是 Oracle 全部服務的網段，service gateway 與路由規則都指向它。
• security list 用 oci network security-list create 建，入站與出站規則以 JSON 給，內容照上面清單的那兩條。
• --prohibit-public-ip-on-vnic true：這個 subnet 裡的網卡不能指派公開 IP，也就是 private subnet。
• 網段 10.0.0.0/16 與 10.0.1.0/24 是這次選的私有位址，換成自己規劃的也可以，security list 的來源要跟著改成 subnet 的網段。

這幾項各自沒做時的結果與替代做法：

• 不建 compartment、資源放在 root：主機照樣建立成功（照文件推出，這次沒有在 root 建）。清理時要在 root 的資源清單裡逐項挑出這次建的，權限政策也只能寫成整個 tenancy 的範圍；〈Run Command 補公鑰的嘗試：dynamic group、IAM 政策與 ocarun 沒有 sudo 的結果〉那條政策寫成 in compartment blog-verify，範圍就只到這組實驗資源。
• 不用 private subnet、改用公開 subnet 加公開 IP：主機有公開 IP，security list 只放行自己的公開 IP 連 22 port，就能用 ssh 直接登入，不需要 Bastion（照文件推出，這次沒有建公開 subnet）；代價是主機的位址暴露在網際網路上，家用網路的公開 IP 改變時規則要跟著改。兩種做法對管理通道各層的影響見 網路 的〈公開 IP：網際網路上的入口〉與 伺服器管理通道的設計。
• 不建 service gateway 與它的路由：主機上的 Oracle Cloud Agent 連不到 Oracle 的服務端點。官方〈Managed SSH Session Creation Failed〉寫明這時 Bastion plugin 的狀態是 INVALID、managed SSH session 建不起來；Run Command 的說明頁只對腳本或輸出放在 Object Storage 的用法寫了出站條件，純文字的用法同樣要讓 plugin 連得到服務端點才領得到指令，這一點是推論，這次沒有在缺閘道的情況下實跑。替代做法是 NAT 閘道：它同樣讓代理程式連得到服務端點，另外讓主機連得到網際網路上的套件來源。
• security list 的 22 port 放行 0.0.0.0/0：這個 subnet 禁止公開 IP，網際網路上的來源本來就到不了主機，所以結果相同（從網路設定推出，這次沒有改成全開驗證）；收窄成同一個 subnet，是讓這份 security list 之後被掛到另一個允許公開 IP 的 subnet 時，那個 subnet 的 22 port 不會跟著對網際網路開放。

Basic information：名稱、compartment、位置、映像檔與機型

「Change shape」的視窗依處理器分欄。這一區的 Ampere 欄有 VM.Standard.A1.Flex 並標示 Always Free-eligible；AMD 欄只列出 VM.Standard.E5.Flex，Always Free 的 VM.Standard.E2.1.Micro 不在清單上。E5.Flex 不在免費額度內，選了之後的結果依帳號狀態而定（試用中由試用金支付、試用結束而沒有升級的帳號建不了、付費帳戶照一般價格計費），見 Oracle Cloud 的帳號結構與 home region 的〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉；區域之間提供的機型不同，見同一篇的〈E2.1.Micro 在各區域的供應：服務配額表與 404 錯誤〉。

這一頁影響後面結果最大的是映像檔。這次選 Ubuntu，A1 加 Ubuntu 落在 managed SSH session 不支援的組合裡（〈建立之前的檢查：套在這台主機上的查法與結果〉）。替代做法是 Oracle Linux 的 aarch64 平台映像：A1 加 Oracle Linux 是 managed SSH session 支援的組合，條件是選的版本可用的 plugin 裡有 Bastion（2026-10-25 實測 10 確定沒有，9 與 8 用查詢工具分不出，查法與讀法見〈建立之前查映像檔版本與它可用的 plugin〉），Oracle Linux 也在 Run Command 的支援映像清單上；換到的代價是預設使用者改成 opc、套件管理改用 dnf，照 Ubuntu 寫的教學指令要換寫法。映像檔建立之後只能換成同一個發行版（〈Replacing a Boot Volume〉），所以這一欄選錯，補救就是重建。

Security：Shielded instance

Secure Boot、Measured Boot、Trusted Platform Module 三項預設都是 Disabled，這次維持關閉。三項在建立之後不能改，要測試這個功能時另外建一台；判斷要不要開見 安全開機：Secure Boot、Measured Boot 與 TPM。

Networking：VCN、subnet 與公開 IP

這一頁實測卡住的地方是 VCN 下拉選單：它只列出「Virtual cloud network compartment」那一欄選定的 compartment 裡的 VCN，而那一欄預設停在 root compartment。verify-vcn 建在 blog-verify，所以要先把那一欄切過去，選單裡才會出現它。

選「Create new virtual cloud network」時，主控台會一起建一份「Default Security List for <VCN 名稱>」。當天實測一個新建的 VCN，這份預設規則的入站部分是：

• TCP 22（SSH），來源 0.0.0.0/0，也就是網際網路上的任何位址
• ICMP type 3 code 4（Path MTU Discovery 需要的封包），來源 0.0.0.0/0
• ICMP type 3，來源是 VCN 自己的位址範圍

出站是全部放行。Subnet 沒有另外指定 security list 時套用的就是這一份，所以在新建的公開 subnet 裡建一台有公開 IP 的主機，那台主機的 SSH port 一建好就對整個網際網路開放。官方文件把 TCP 22 那一條規則寫成允許「authorized source IP addresses」，而預設填的來源是 0.0.0.0/0，等於任何位址都算在內；官方建議把來源收緊。這份規則跟 NSG 怎麼合併，以及為什麼 NSG 裡不寫 22 port 的規則時，22 port 的連線照樣由這份 security list 放行通過，見 網路：subnet、私有 IP、公開 IP 與防火牆規則 的〈防火牆規則的位置與合併方式〉。

SSH keys

這次選 No SSH keys，目的是驗證主機完全不放金鑰時，managed SSH session 這條路本身走不走得通；managed SSH session 在主機有放公鑰時照樣能用，只是那樣就驗不出這件事。選了之後主機裡不放任何長期有效的公鑰，登入改用 Bastion 的 managed SSH session，由主機上的 Bastion plugin 臨時放進一把公鑰。Oracle Cloud 對這個選項的說明是選了之後就不能再提供公鑰，所以這條路要求〈Management：Oracle Cloud Agent 與其他進階選項〉那一節的 Bastion plugin 一定打開。這次刻意不留退路，代價在〈建立之後：Bastion managed SSH session 逾時的排查〉與〈Run Command 補公鑰的嘗試：dynamic group、IAM 政策與 ocarun 沒有 sudo 的結果〉兩節出現：工作階段的建立逾時之後，主機上沒有任何 SSH 登入的入口，Run Command 又寫不了 ubuntu 的 authorized_keys。

放公鑰與不放公鑰，差在 managed SSH session 失敗之後還剩什麼：

• 放自己的公鑰（上傳或貼上）：managed SSH session 失敗時，改建不經過 plugin 的 SSH port forwarding session，用那把公鑰登入。主機在 private subnet、沒有公開 IP，這把公鑰只對經由 Bastion 進來的連線有用；代價是這把金鑰要自己保管。這次如果這樣選，cloud-init 在 Authorization header 開著時寫入公鑰、security list 放行 Bastion 目標 subnet 的 22 port 這兩項成立的話，三次逾時之後就能登入主機查 plugin 的日誌；這是推論，cloud-init 寫公鑰這一段沒有在這台實跑；後來重建的 Oracle Linux 10.2 主機在 Authorization header 開著時寫入了公鑰（〈重建：Oracle Linux 映像加建立時放公鑰，經由 port forwarding session 登入〉），2026-10-26 在 Ubuntu 24.04 平台映像上也驗過寫得進（Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈建 Ubuntu 24.04 主機與經由 port forwarding 登入〉）。
• No SSH keys：主機裡沒有長期有效的公鑰，登入完全依賴 Bastion plugin，而這個欄位建立後不能改（ssh_authorized_keys 不接受修改）。plugin 這條路不通時，剩下的入口見〈這台主機剩下的登入入口〉。

第一次建主機、還沒走通 Bastion 時先放公鑰的做法與它的前提，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉。

Storage

開機磁碟維持映像檔的預設大小（50 GB）、效能等級 Balanced、Use in-transit encryption 為 Enabled、不指定自己的加密金鑰，不另外建立區塊磁碟。50 GB 在 Always Free 的 200 GB 額度內。要記住的是刪除這台主機時，終止對話框裡的「Permanently delete the attached boot volume」預設不勾，不勾的話開機磁碟會留下來繼續佔著額度，見 磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留。

Management：Oracle Cloud Agent 與其他進階選項

Oracle Cloud Agent 的每一項功能是一個 plugin。官方列出的 plugin 與這次建立頁上的預設值：

官方的 plugin 說明頁對 Custom Logs Monitoring 在 A1 上的支援前後不一致：頁面上的註記寫它不支援 A1 機型，同一頁的代理程式版本紀錄（1.29.0）寫已經支援 Arm 處理器。這次維持建立頁的預設（開啟）：這個 plugin 只負責把日誌送進 Logging，要在 Logging 服務裡設定收哪些日誌之後才開始收，費用依收進來的日誌量計算（官方〈Custom Logs〉）；沒有設定時它不影響主機建立與登入。

這次要改的只有一項：把 Bastion 打開。沒有放 SSH 金鑰的主機，SSH 登入只能經由 Bastion 的 managed SSH session，而這個 plugin 預設關閉；不經過 SSH 的其他入口見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈建立之後加金鑰與金鑰遺失時的入口〉。漏開時不必重建，主機建好之後可以在主機頁面的 Oracle Cloud Agent 分頁打開，官方說明最多 10 分鐘生效。

其餘維持預設，理由各自如下：

• Authorization header：Enabled。這是建立頁對 Ubuntu 的預設，而官方列出支援中繼資料第二版的平台映像只有 Oracle Linux 系列，Ubuntu 不在清單上。2026-10-25 建好的主機開著這個選項，代理程式照常回報各 plugin 的狀態；managed SSH session 的建立逾時時，暫時改成允許第一版也一樣逾時，所以這個選項不是那次失敗的成因，見〈建立之後：Bastion managed SSH session 逾時的排查〉。cloud-init 從中繼資料讀出公鑰寫進 authorized_keys 這一段，這台選了 No SSH keys 驗不到；後來重建的 Oracle Linux 10.2 主機開著這個選項時寫入了，2026-10-26 另一台放了公鑰的 Ubuntu 24.04 主機開著這個選項時也寫入了（〈SSH keys〉那一節的「放自己的公鑰」那一項）。要怎麼確認見 代理程式、中繼資料服務、初始化腳本、維護行為與標籤 的〈中繼資料服務與 Authorization header〉。
• Live migration：讓 Oracle 選擇、Restart after infrastructure maintenance：Enabled：實驗機能接受維護時被遷移或重開。
• 不放初始化腳本、不加標籤：這台主機只用來測登入，沒有要預先裝的軟體。沒放初始化腳本的結果，到了要用 Run Command 救援時才出現：Run Command 以 ocarun 執行，沒有 sudo（〈Run Command 補公鑰的嘗試：dynamic group、IAM 政策與 ocarun 沒有 sudo 的結果〉），而替 ocarun 設 sudo 的 sudoers 檔，官方列的做法有兩種：建立時用 cloud-init 放，或建好之後登入主機設定；登不進去時只剩前一種。所以要把 Run Command 當成救援入口，替代做法是在這一欄放一段 cloud-init，建立時把官方說明頁列的那一行 sudoers（ocarun ALL=(ALL) NOPASSWD:ALL，或只列救援要用的指令）寫進 /etc/sudoers.d/ 底下的一個檔；這個欄位也是建立後不能改的那一種。這段 cloud-init 的寫法這次沒有實跑，所以這裡不附，實跑過再補（記在 Oracle Cloud 目錄頁的 Backlog）。給 ocarun 不限指令的 sudo，等於讓有權限送 Run Command 的人取得主機的 root，所以送指令的權限政策要跟著收窄。

等效的 CLI 指令

同一組設定用 OCI CLI 建立：

 1oci compute instance launch \
 2  --compartment-id <compartment 的 OCID> \
 3  --availability-domain <AD 名稱，例如 XXXX:AP-BATAM-1-AD-1> \
 4  --display-name verify-a1 \
 5  --shape VM.Standard.A1.Flex --shape-config '{"ocpus":1,"memoryInGBs":6}' \
 6  --image-id <Ubuntu 24.04 aarch64 映像檔的 OCID> \
 7  --subnet-id <private subnet 的 OCID> \
 8  --assign-public-ip false \
 9  --agent-config '{"pluginsConfig":[{"name":"Bastion","desiredState":"ENABLED"}]}' \
10  --is-pv-encryption-in-transit-enabled true \
11  --instance-options '{"areLegacyImdsEndpointsDisabled":true}' \
12  --auth security_token

• --compartment-id、--subnet-id：compartment 與 subnet 的 OCID，在主控台各自的詳細頁複製，或用 oci iam compartment list 與 oci network subnet list --compartment-id <compartment 的 OCID> 查。OCID 是 Oracle Cloud 給每個資源的唯一識別碼，說明見 Oracle Cloud 的帳號結構與 home region。
• --availability-domain：AD 的完整名稱帶有 tenancy 專屬的前綴，用 oci iam availability-domain list 查，不能只寫 AD-1。
• --shape-config：ocpus 與 memoryInGBs 對應 Basic information 表裡 Shape 那一列的 1 OCPU、6 GB。
• --image-id：映像檔的 OCID 每個區域不同、每次更新都會換，用 oci compute image list --compartment-id <tenancy 的 OCID> --operating-system "Canonical Ubuntu" --operating-system-version "24.04" --shape VM.Standard.A1.Flex 查最新的那一個。這裡的 --compartment-id 填 tenancy 的 OCID 而不是實驗用的 compartment，因為平台映像列在 tenancy 的 root 層；指令加上 --shape VM.Standard.A1.Flex 之後，CLI 只回傳跟 A1 相容的 aarch64 映像檔。
• --agent-config：只列出要改的 plugin，其餘維持預設。這裡把 Bastion 設成 ENABLED。
• --is-pv-encryption-in-transit-enabled true 與 --instance-options '{"areLegacyImdsEndpointsDisabled":true}'：前者對應 Storage 段的 in-transit encryption，後者對應 Management 段的 Authorization header（只允許中繼資料第二版）。這兩項在主控台是預設開啟，CLI 不給時，官方的 CLI 參考寫明 in-transit encryption 的預設值是 false，所以要跟主控台一致就要明確帶上。2026-10-24 背景重試用的指令一開始沒有這兩行，之後才補上。
• --auth security_token：用 session token 登入時每條指令都要帶，不帶會報設定檔缺 user；用 API 簽章金鑰時拿掉。在主控台的 Cloud Shell 裡跑時也拿掉，Cloud Shell 裡的 CLI 用 Cloud Shell 自己的驗證，沒有本機的 session 設定。
• 沒有給 --ssh-authorized-keys-file，等同主控台的 No SSH keys。

主控台與 CLI 的差別在錯誤訊息的可讀性：主控台的 Change shape 視窗只列出這一區有的機型，並把跟所選映像檔架構不相容的機型標成不可選；這次用 CLI 送出這一區沒有的 E2.1.Micro，回的是 404 NotAuthorizedOrNotFound，這個錯誤碼怎麼讀與怎麼查一區有哪些機型，見 Oracle Cloud 的帳號結構與 home region 的〈E2.1.Micro 在各區域的供應：服務配額表與 404 錯誤〉。

按下 Create 之後的結果：容量不足

主控台回的訊息是：

1Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1. Create the instance in a different availability domain or try again later.

意思是這個 AD 裡跑 A1 的實體主機當下沒有空出這個規格需要的資源；同一段時間用 CLI 送出的請求回的是 InternalError: Out of host capacity.，偶爾是 429 TooManyRequests（請求太頻繁被限流）。訊息建議的換 AD 在這一區不存在（只有一個 AD），fault domain 這次已經是讓 Oracle 選，規格 1 OCPU、6 GB 只用了額度的一半，還能再改小。容量不足時全部的退路與哪幾項會計費，列在 Oracle Cloud 的帳號結構與 home region 的〈A1 容量不足時的退路〉；這次的帳號只用免費額度，選的是隔一段時間再試。

2026-10-24 的重送紀錄：先以 90 秒的間隔送了九次，前三次收到 429、後六次是容量不足；之後改成每 5 分鐘一次，到當天晚上仍然是容量不足。兩種回應碼的讀法見 Oracle Cloud 的帳號結構與 home region 的〈A1 容量不足時的退路〉裡「等一段時間再試」那一項。

重送建立請求：CLI 自己的重送、限流門檻與重送腳本

2026-10-25 改用下面這支腳本重送，從 10:32 開始，第 16 次（11:00）建立成功。這一天量到的兩件事決定了腳本的間隔怎麼設：

• OCI CLI 在一條指令裡會自己重送：oci 預設會在同一條指令裡重送失敗的請求，oci --help 對 --max-retries 的說明是多數指令最多送 7 次（哪些回應碼算可以重送，--help 沒有列）。所以外層迴圈每「試一次」，送到 API 的是一連串請求，前一天以 90 秒間隔送、前三次就收到 429，跟這一點對得上。指令加上全域選項 --no-retry 之後，一次嘗試只送一個請求，間隔才完全由外層迴圈決定。
• 這個帳號的限流門檻：只送單一請求的那一輪共 16 次，收到 429 Too many requests for the user 的有 2 次，這兩次送出之前，腳本分別等了 75 秒與 67 秒；其餘 13 次送出之前等了 76 到 171 秒，回的都是容量不足。前一輪以 46 秒的等待送，第三次就收到 429。訊息裡的「for the user」代表限流按使用者計算，同一個使用者並行開幾個迴圈，只會更快被限流。門檻依帳號與 API 而定，這是這個帳號這一天的量測；腳本因此不寫死間隔，而是依回應碼調整。

 1#!/bin/bash
 2# 容量不足時重送建立主機的請求，建立成功或認證失效時結束
 3set -uo pipefail
 4export OCI_CLI_AUTH=security_token
 5C="<compartment 的 OCID>"; SN="<private subnet 的 OCID>"; IMG="<映像檔的 OCID>"; AD="<AD 的完整名稱>"
 6back=120 last_refresh=0                               # 0：開跑時先延長一次 token
 7while :; do
 8  if (( $(date +%s) - last_refresh >= 1800 )); then   # session token 一小時過期，每 30 分鐘延長一次
 9    oci session refresh --profile DEFAULT >/dev/null 2>&1 || { echo "token 無法延長，重新登入"; exit 2; }
10    last_refresh=$(date +%s)
11  fi
12  out=$(oci --no-retry compute instance launch -c "$C" --availability-domain "$AD" --display-name verify-a1 \
13    --shape VM.Standard.A1.Flex --shape-config '{"ocpus":1,"memoryInGBs":6}' --image-id "$IMG" \
14    --subnet-id "$SN" --assign-public-ip false \
15    --agent-config '{"pluginsConfig":[{"name":"Bastion","desiredState":"ENABLED"}]}' \
16    --is-pv-encryption-in-transit-enabled true --instance-options '{"areLegacyImdsEndpointsDisabled":true}' \
17    --query data.id --raw-output 2>&1)
18  id=$(grep -o 'ocid1\.instance\.[^" ]*' <<<"$out" | head -1)   # 輸出前面可能夾著 CLI 的警告
19  if [[ -n "$id" ]]; then echo "建立成功：$id"; exit 0; fi
20  status=$(grep -o '"status": [0-9]*' <<<"$out" | head -1 | grep -o '[0-9]*$')
21  case "$status" in
22    "")  echo "讀不出回應碼，停下來看輸出：$out"; exit 3 ;;   # 設定檔錯誤、網路錯誤這類沒有回應碼的失敗
23    401) echo "認證失效，重新登入"; exit 2 ;;
24    429) back=$(( back * 2 > 600 ? 600 : back * 2 )) ;;   # 被限流：間隔加倍，上限 600 秒
25    500) back=$(( back - 10 < 60 ? 60 : back - 10 )) ;;   # 容量不足：每次縮 10 秒，下限 60 秒
26    *)   echo "回應碼 ${status}，重送也不會好，停下來看訊息：$(grep -o '"message": "[^"]*"' <<<"$out" | head -1)"; exit 4 ;;   # 400 參數錯誤這類
27  esac
28  echo "$(date +%H:%M:%S) ${status:-?}，約 ${back} 秒後再送"
29  sleep $(( back - 15 + RANDOM % 31 ))                   # 加 ±15 秒的隨機抖動
30done

• 四個佔位值的查法與〈等效的 CLI 指令〉那一節相同；--display-name verify-a1 是主機在清單上的名稱，換成自己要的名稱時，〈重複建立的風險〉那一項查同名主機的指令也跟著換；--shape-config 到 --instance-options 是那一節的同一組設定，--no-retry 是寫在子命令之前的全域選項。
• 間隔的調整方式：收到 429 時間隔加倍，收到容量不足的 500 時每次縮 10 秒，所以間隔會在「剛好不被限流」的附近來回。被限流的期間就算剛好有容量空出來也送不進去，所以把頻率壓在門檻下、讓請求能長時間穩定地送，比把間隔縮到最短更有機會碰上容量釋出的那一刻。120、600、60 這三個值是起點、上限與下限，換帳號時從 120 起跑，讓腳本自己往門檻靠。
• 抖動（jitter）：每次的等待多加 ±15 秒的隨機值，讓送出的時間點不落在固定的週期上。間隔加倍的退避做法見 Exponential Backoff 卡，那張卡把 jitter 列為退避要一起搭配的一項；抖動對這次搶到容量有沒有影響，這次沒有量。
• 驗證方式：export OCI_CLI_AUTH=security_token 等同每條指令都帶 --auth security_token。--profile DEFAULT 填 oci session authenticate 時取的 profile 名稱，沒有另外取名時就是 DEFAULT。
• 判斷建立成功的方式：輸出裡找得到 ocid1.instance. 開頭的 OCID 就算成功。標準錯誤併進了 $out，CLI 在 OCID 之前印出警告時（例如設定檔權限的警告），整段輸出就不是以 OCID 開頭；只比對開頭的話，已經建成的這一次會被當成失敗、再送一次，建出第二台。
• 結束條件：建立成功（exit 0）、session token 無法再延長或收到 401（exit 2）、輸出裡讀不出回應碼（exit 3，設定檔或網路錯誤這類，重送也不會好）、收到 500 與 429 以外的回應碼（exit 4）。只有 500（容量不足）與 429（限流）是等一段時間就可能變好的回應；400 這類回應代表請求本身有誤（例如 <AD 的完整名稱> 沒換掉或填錯），重送幾次都是同一個結果，所以腳本印出回應碼與 message 就結束，照訊息改好參數再跑。last_refresh=0 讓腳本開跑時先延長一次 token，開跑時 token 只剩不到 30 分鐘也不會在第一次延長之前過期。session token 一次登入最長延到 24 小時，超過就要重跑 oci session authenticate，見 從本機用 OCI CLI 操作 Oracle Cloud；要讓腳本跑超過一天，改用 API 簽章金鑰，並拿掉 OCI_CLI_AUTH 與延長 token 的那一段。
• 重複建立的風險：建立成功就結束，所以收得到回應時，同一支腳本不會建出第二台。收不到回應的情形擋不住：建立請求在 Oracle 那一端已經成功、回應卻因為網路中斷沒有回到本機，這一次會落進讀不出回應碼的分支而結束（exit 3）。所以腳本以 exit 3 結束、或要再次執行之前，先用 oci compute instance list -c <compartment 的 OCID> --display-name verify-a1 確認沒有還在的同名主機。

2026-10-25 實際跑的版本另外在開跑前查一次有沒有同名主機、把每次的結果寫進紀錄檔，重送與間隔的邏輯跟上面相同，只是那時遇到 500 與 429 以外的回應碼也會重送；2026-10-25 那一輪回的都是 500 與 429，沒有走到這個分支。2026-10-27 補上 exit 4 那一個分支之後，上面這一份用一支假的 oci 指令跑過六組回應，確認每個分支的間隔與結束碼：依序回 500、429、500 與成功（間隔 110、220、210 秒，exit 0）、先在標準錯誤印警告再印 OCID（只送一次，exit 0）、回一段沒有回應碼的錯誤（exit 3）、回 401（exit 2）、回 400（只送一次，印出回應碼與 message，exit 4）、先回 500 再回 400（重送一次之後 exit 4）；六組都在第一次送出之前先延長了一次 token。400 那兩組的 message 是假的 oci 自己編的，Oracle 實際回的訊息這次沒有看過。

不用腳本時，替代做法是在主控台隔一段時間按一次 Create：每一次要有人在場，間隔不固定；2026-10-24 在主控台手動按 Create、加上背景以 90 秒與 5 分鐘間隔跑的 CLI 迴圈，整天的回應都是容量不足。不加 --no-retry、沿用 CLI 自己的重送時，外層的每一次嘗試送出好幾個請求，同樣的間隔下更早被限流（2026-10-24 以 90 秒送，前三次就收到 429）。換區域、換機型、改付費這些不在重送範圍內的退路，與各自是否計費，見 Oracle Cloud 的帳號結構與 home region 的〈A1 容量不足時的退路〉。腳本送出的建立參數是寫腳本那一刻的設定，重新啟動腳本之前，參數要再拿〈建立之前的檢查：套在這台主機上的查法與結果〉對一次。

建立之後：Bastion managed SSH session 逾時的排查

這一節記錄主機建好之後建立 Bastion 與 managed SSH session、工作階段停在 CREATING 約 15 分鐘後轉成 DELETED、從 work request 讀到的兩則錯誤，以及對照官方 Known Issues 找到的成因。這一節的指令跟腳本一樣用 session token 驗證：先在 shell 裡 export OCI_CLI_AUTH=security_token，或每條指令加 --auth security_token，兩種寫法等效。

建立 Bastion 與 managed SSH session

Bastion 在 2026-10-24 主機還沒建成時就先建好，建立 Bastion 只需要目標 subnet 存在：

1oci bastion bastion create -c <compartment 的 OCID> --bastion-type STANDARD --target-subnet-id <private subnet 的 OCID> \
2  --name verifybastion --client-cidr-list '["<本機的公開 IP>/32"]' --max-session-ttl 3600 --wait-for-state SUCCEEDED

• --target-subnet-id：Bastion 替哪一個 subnet 裡的主機開工作階段。Bastion 在這個 subnet 裡放一個私有端點，從那裡連主機的 22 port，所以〈進建立頁之前〉的 security list 放行來源是同一個 subnet 的 22 port。
• --client-cidr-list：允許從哪些位址連到 Bastion，填本機目前的公開 IP 加 /32。這個參數整份取代既有的清單；本機的 IP 變了（家用網路重新撥號之後常見）就用 oci bastion bastion update --bastion-id <Bastion 的 OCID> --client-cidr-list '["<新的公開 IP>/32"]' 換掉，2026-10-25 就換過一次。這一項影響的是連線，不影響工作階段的建立。
• --max-session-ttl 3600：這個 Bastion 上工作階段的最長時效（秒），建工作階段時的 --session-ttl 不能超過它。
• 這次用 tenancy 的管理員帳號操作，沒有另外建 IAM 政策；一般使用者建 Bastion 與工作階段需要的政策，這篇沒有寫。

主機在 2026-10-25 11:00 建立，11:04 主機頁面的 Oracle Cloud Agent 回報 Bastion plugin 是 RUNNING。代理程式回報得了 plugin 狀態，代表代理程式本身在只允許中繼資料第二版（Authorization header 開著）的設定下照常運作。接著建 managed SSH session：

1oci bastion session create-managed-ssh --bastion-id <Bastion 的 OCID> --target-resource-id <主機的 OCID> \
2  --target-os-username ubuntu --target-private-ip <主機的私有 IP> \
3  --ssh-public-key-file <這次工作階段用的公鑰> --session-ttl 3600

• --target-os-username ubuntu：Ubuntu 平台映像的預設使用者，Oracle Linux 是 opc。
• --target-private-ip：用 oci compute instance list-vnics --instance-id <主機的 OCID> --query 'data[0]."private-ip"' --raw-output 查。
• --ssh-public-key-file：只給這一次工作階段用的公鑰（例如用 ssh-keygen -t rsa -b 4096 -f <檔名> 另產一組），plugin 在工作階段期間把它放進主機，連線時用對應的私鑰。
• --session-ttl 3600：工作階段的時效（秒），上限是 Bastion 的 --max-session-ttl。

結果：停在 CREATING 約 15 分鐘後轉成 DELETED

三次建立的工作階段都停在 CREATING 約 15 分鐘，接著轉成 DELETED，lifecycle-details 是空的。失敗的原因記在建立工作階段的 work request 上；work request 是 Oracle Cloud 記錄一次非同步操作的進度與錯誤的物件：

1# 取這個 compartment 裡最近一次建立工作階段的 work request，再讀它的錯誤
2oci bastion work-request list -c <compartment 的 OCID> --all \
3  --query 'data[?"operation-type"==`CREATE_SESSION`] | sort_by(@, &"time-accepted")[-1].id' --raw-output
4oci bastion work-request-error list --work-request-id <上一條印出的 work request OCID>

• --query 只留操作類型是 CREATE_SESSION 的 work request，依受理時間排序後取最後一筆。同一個 compartment 裡還有建立 Bastion、更新允許清單、刪除工作階段的 work request，只取清單第一筆的話可能取到那些。

三次讀到的都是同兩則訊息：End host agent didn't respond back on session status in time 與 End host agent hasn't responded back within max allowed time，也就是 Bastion 服務等不到主機上的 plugin 回報工作階段的狀態。三次之間各改了一個條件，排除了兩個成因：

第三次之後把設定改回只允許第二版（oci compute instance update --instance-id <主機的 OCID> --instance-options '{"areLegacyImdsEndpointsDisabled":true}'，不必重開機）。

主機開機時的序列主控台輸出（console history：開機輸出的唯讀快照，不是 序列主控台 的互動連線）可以不登入就讀，用來確認開機與代理程式的啟動：

1oci compute console-history capture --instance-id <主機的 OCID> --wait-for-state SUCCEEDED --query data.id --raw-output
2oci compute console-history get-content --instance-console-history-id <上一條印出的 OCID> --length 10000000 --file <存檔的路徑>

• --wait-for-state SUCCEEDED：擷取是非同步的作業，等它完成再讀內容；不等的話，緊接著的 get-content 可能讀到還沒擷取完的內容。
• --length 10000000：要讀的位元組數。官方說明一次擷取最多 1 MB，填一個比 1 MB 大的數字就是讀全部。

這次的輸出（1576 行）裡，cloud-init 在開機 63 秒時完成，oracle-cloud-agent（Ubuntu 上是 snap 套件）有啟動，ssh.socket 在監聽；no authorized SSH keys fingerprints found for user ubuntu 是選了 No SSH keys 的預期結果。序列主控台輸出不含 plugin 的日誌。

成因：A1 加 Ubuntu 是官方列出的不支援組合

Oracle 官方〈Known Issues for Bastion〉的第一條寫明，用 Arm 架構的 Ampere A1 機型建立、而且作業系統不是 Oracle Linux（例如 Ubuntu）的主機，不支援 managed SSH session；原文的理由是這類主機上的 Bastion plugin 沒有正確啟用（「isn’t properly enabled on some Arm-based instances」），所以建立工作階段會失敗。這台正是 A1 加 Ubuntu 24.04。主控台上的 plugin 狀態是 RUNNING，跟原文說的「沒有正確啟用」在主控台上看不出差別，所以 plugin 的狀態不能當成這條路走得通的證據。官方給的替代做法是改用 SSH port forwarding session。同一頁的另一條是 Ubuntu 上的 Oracle Cloud Agent 低於 1.11 版時 managed SSH session 也會失敗（處置是在主機上跑 sudo snap refresh oracle-cloud-agent）。這台主機的代理程式版本，後來用 Run Command 讀到是 1.61.0，這一條可以排除，見〈用 Run Command 讀代理程式的版本與日誌〉。

上面那張表的三次是在查到這一條之前做的。官方〈Managed SSH Session Creation Failed〉列的成因，對這台的狀況是：代理程式與 Bastion plugin 都在跑；VCN 有 service gateway 與路由，缺 gateway 時 plugin 的狀態會是 INVALID，這台不是；ubuntu 是存在的使用者；sshd 設定那一項，這台沒有 SSH 登入的入口可以查。建 managed SSH session 之前先讀 Known Issues 那一頁，確認機型與作業系統的組合有支援，三次各 15 分鐘的等待就可以省掉。

Port forwarding session 不經過 plugin，主機的登入驗證仍然是主機上的 sshd 與 authorized_keys；這台建立時選了 No SSH keys，主機裡沒有任何公鑰，所以 port forwarding session 建得起來也登不進去。下一節試的是先用 Run Command 把公鑰寫進主機。

Run Command 補公鑰的嘗試：dynamic group、IAM 政策與 ocarun 沒有 sudo 的結果

Run Command 從 API 把一段腳本送進主機執行，由主機上的 Run Command plugin 定期向服務領取。要用它寫公鑰，有三件事要同時成立：主機有權限領取指令、plugin 在這個作業系統上執行得了腳本、執行腳本的使用者寫得了 ubuntu 家目錄裡的 authorized_keys。後兩件在官方文件上都不利：Run Command 說明頁的支援映像清單沒有 Ubuntu，而 plugin 以 ocarun 這個使用者執行，要以管理員權限執行得先在主機上加 sudoers 檔。主機頁面上這個 plugin 的狀態是 RUNNING，而〈成因：A1 加 Ubuntu 是官方列出的不支援組合〉已經看過 plugin 的狀態不能當成支援的證據，所以第一次只送唯讀的探測腳本，先查 ocarun 能不能 sudo，再決定要不要寫公鑰。

plugin 的狀態用這條指令列：

1oci instance-agent plugin list --instanceagent-id <主機的 OCID> --compartment-id <compartment 的 OCID> \
2  --query 'data[].{name:name,status:status}' --output table

這台列出 Compute Instance Run Command、Bastion、Custom Logs Monitoring、Compute Instance Monitoring、Cloud Guard Workload Protection 是 RUNNING，其餘是 STOPPED 或 NOT_SUPPORTED。

讓主機領得到指令：dynamic group 與 IAM 政策

主機向 Run Command 服務領取指令，用的是主機自己的身分，所以要先把主機放進一個 dynamic group，再寫政策允許這個群組領取與回報指令：

1oci iam dynamic-group create --compartment-id <tenancy 的 OCID> --name verify-a1-runcommand \
2  --description "<用途說明>" --matching-rule "ALL {instance.id = '<主機的 OCID>'}"
3
4oci iam policy create --compartment-id <compartment 的 OCID> --name verify-a1-runcommand --description "<用途說明>" \
5  --statements '["Allow dynamic-group verify-a1-runcommand to use instance-agent-command-execution-family in compartment blog-verify"]'

• dynamic group：依比對規則把資源本身當成 IAM 主體的群組。它建在 tenancy 層（--compartment-id 填 tenancy 的 OCID）；這個帳號只有 Default 這一個 identity domain（Oracle Cloud 存放使用者、群組與 dynamic group 的身分網域，oci iam domain list --compartment-id <tenancy 的 OCID> 列得出來），oci iam dynamic-group create 直接建在它底下；有多個 identity domain 的帳號，dynamic group 建在哪一個 domain 要另外確認，這次沒有實跑。--matching-rule 寫成 instance.id = '<主機的 OCID>'，群組裡只有這一台；改寫成 instance.compartment.id = '<compartment 的 OCID>' 會納入整個 compartment 的主機，之後新建的主機也自動有領取指令的身分（這時政策要加下一項說的 where 條件）。
• 政策：建在 blog-verify 這個 compartment，instance-agent-command-execution-family 是領取與回報指令的權限，對象只有這個 dynamic group。官方〈Required IAM Policy for Working with Instances〉的範例在句尾多了 where request.instance.id=target.instance.id，限制每台主機只領取送給自己的指令；這次群組裡只有一台主機，加不加結果相同，比對規則改成整個 compartment 時要加上，否則群組裡的每一台主機都領得到送給其他主機的指令。政策裡的 blog-verify 與 verify-a1-runcommand 換成自己的 compartment 與群組名稱。
• 送指令的人：這次用 tenancy 的管理員帳號送，沒有另外寫送指令的政策；一般使用者要送指令，另外需要送指令的權限政策，Run Command 說明頁指向官方〈Required IAM Policy for Working with Instances〉，這次沒有實跑。

沒有這組政策時，官方的疑難排解寫明 plugin 的日誌（/var/log/oracle-cloud-agent/plugins/runcommand/runcommand.log）會出現 NotAuthorizedOrNotFound 的 404，plugin 領不到指令。官方寫的等待時間依建立的先後而定：先建 dynamic group、再建主機時，主機一建好就開始領取；主機建好之後才加進 dynamic group 時，最多要 30 分鐘。這次屬於後一種，政策在 13:03:06（台北時間）建好，13:03:26 送出指令，13:10:27 執行完，從送出到執行完約 7 分鐘。

送出唯讀的探測腳本

探測腳本只讀狀態，不改主機上的任何東西：

1#!/bin/bash
2# 第一次 Run Command：只讀，確認 ocarun 的身分與能不能 sudo
3id
4. /etc/os-release && echo "$PRETTY_NAME"
5if sudo -n true 2>/dev/null; then echo "SUDO=yes"; else echo "SUDO=no"; fi
6ls -l /etc/sudoers.d/ 2>&1

sudo -n 在需要輸入密碼時直接失敗、不等待輸入，Run Command 不支援會要求輸入的腳本。腳本以文字的形式放進指令內容的 JSON，再送出：

1python3 -c 'import json;print(json.dumps({"source":{"sourceType":"TEXT","text":open("runcmd-probe.sh").read()},"output":{"outputType":"TEXT"}}))' > probe-content.json
2
3oci instance-agent command create --compartment-id <compartment 的 OCID> --display-name verify-probe \
4  --timeout-in-seconds 600 --target '{"instanceId":"<主機的 OCID>"}' --content file://probe-content.json

• runcmd-probe.sh 是上面那支腳本存成的檔名。用 json.dumps 產生 JSON，腳本裡的換行與引號會自動跳脫；以文字送出的腳本上限 4 KB。
• "outputType":"TEXT"：輸出以文字保存在指令的執行紀錄裡，只保留最後 1 KB；要完整的輸出改存到 Object Storage。
• --timeout-in-seconds 600：腳本執行的逾時。這個選項的名稱是 --timeout-in-seconds，寫成 API 欄位名稱的 --execution-time-out-in-seconds 時，CLI 回 No such option。

讀結果：ocarun 沒有 sudo

送出之後指令先停在 ACCEPTED，plugin 領取並執行完才改變狀態。狀態與輸出各用一條指令讀：

1oci instance-agent command-execution get --command-id <指令的 OCID> --instance-id <主機的 OCID> \
2  --query 'data."lifecycle-state"' --raw-output
3oci instance-agent command-execution get --command-id <指令的 OCID> --instance-id <主機的 OCID> \
4  --query 'data.content.text' --raw-output

<指令的 OCID> 是 command create 輸出裡的 id。這次每 30 秒查一次，前 405 秒都是 ACCEPTED，之後是 FAILED，輸出是：

1uid=999(ocarun) gid=584788(snap_daemon) groups=584788(snap_daemon),4(adm)
2Ubuntu 24.04.5 LTS
3SUDO=no
4ls: cannot open directory '/etc/sudoers.d/': Permission denied

• FAILED 的意思：執行紀錄的 exit-code 是 2，來自腳本最後一行 ls 讀不了 /etc/sudoers.d/；同一筆紀錄的 delivery-state 是 ACKED，指令有送達並執行完。所以這裡的 FAILED 是腳本的結束碼，不是 plugin 沒有執行。
• plugin 在 A1 Ubuntu 上執行得了腳本：Ubuntu 不在支援映像清單上，而腳本確實執行了。Ubuntu 上的 Oracle Cloud Agent 是 snap 套件，ocarun 的群組是 snap_daemon 與 adm（adm 讀得到 /var/log 底下的系統日誌）。
• SUDO=no：ocarun 沒有 sudo，寫不了 /home/ubuntu/.ssh/authorized_keys，也加不了 sudoers 檔。要讓 ocarun 有 sudo，得先登入主機加 sudoers 檔，而這台正是登不進去才要用 Run Command，所以 Run Command 在這台主機上寫不了公鑰。建立時用初始化腳本放 sudoers 檔的做法，見〈Management：Oracle Cloud Agent 與其他進階選項〉。

用 Run Command 讀代理程式的版本與日誌

ocarun 寫不了其他使用者的檔案，讀得到的範圍則比較寬：它屬於 adm 群組，/var/log 底下開放給這個群組或所有人讀的檔案都讀得到。所以 Run Command 雖然救不回這台主機，仍然能在不登入的情況下查 managed SSH session 失敗時代理程式的狀態。2026-10-25 下午再送了兩次唯讀的腳本，送法同〈送出唯讀的探測腳本〉，只換腳本內容；兩次的內容合起來是：

1#!/bin/bash
2# 只讀：代理程式的版本、日誌目錄、代理程式主日誌裡 Bastion plugin 的紀錄
3snap list oracle-cloud-agent 2>&1
4ls -l /var/log/oracle-cloud-agent/plugins/ 2>&1
5ls /var/log/oracle-cloud-agent/plugins/bastions/ 2>&1
6grep -ih bastion /var/log/oracle-cloud-agent/*.log 2>&1 | tail -n 20

第二次從送出到執行完約 2 分半鐘（06:19:43Z 到 06:22:10Z；主機已經在 dynamic group 裡，不再等第一次探測的 7 分鐘）。兩次讀到的是：

• 代理程式的版本：snap list 印出 oracle-cloud-agent 1.61.0-6，Notes 欄是 classic,held。Known Issues 第二條的 1.11 版以下不成立，這台的逾時只剩 A1 加 Ubuntu 那一條成因。
• Bastion plugin 的日誌讀不到：plugin 的目錄叫 bastions（不是 bastion），裡面有 bastions.log，而目錄的權限是 drwxr--r--、擁有者與群組都是 snap_daemon；ocarun 的主要群組雖然是 snap_daemon，群組那一欄是 r--、沒有 x，列得出檔名、進不了目錄，讀不了裡面的檔案（其他使用者那一欄同樣是 r--，不在這個群組也是一樣）。runcommand 目錄的擁有者是 ocarun、群組 adm。
• 代理程式的主日誌讀得到：/var/log/oracle-cloud-agent/agent.log 開放所有人讀。它每 10 分鐘對 Bastion plugin 做一次健康檢查，紀錄是 health check of plugin:[bastions], desiredState:[Enable], currentState:[running], status:[running] version:[1.61.0-6] err:[<nil>]。讀到的是 05:51 與 06:01（UTC）這兩筆，都是 running、沒有錯誤；managed SSH session 逾時的那幾個時段（台北時間 11:04 到 12:07）的紀錄不在讀到的範圍裡。所以這次能確定的是：工作階段已經逾時三次之後，代理程式的健康檢查仍然回報 running，跟主控台上的 RUNNING 一樣看不出這個組合不支援。

以文字保存的輸出只留最後 1 KB，grep 的結果被截斷；要讀完整的日誌，輸出改存到 Object Storage（"outputType" 改成 Object Storage 的那一種，這次沒有實跑）。

這台主機剩下的登入入口

Run Command 寫不了公鑰之後，這台主機剩下的入口與各自的條件：

• 替換開機磁碟：官方〈Replacing a Boot Volume〉限定只能換成同一個 Linux 發行版，換不成 Oracle Linux。換成新的 Ubuntu 開機磁碟時，cloud-init 讀的仍是建立時的中繼資料，而 ssh_authorized_keys 是空的，所以新磁碟上也沒有公鑰；這是從兩份說明推出的結果，這次沒有實跑。換成自己做的 Ubuntu aarch64 自訂映像時，公鑰或設了密碼的救援帳號可以直接做進映像，不靠 cloud-init 從中繼資料讀；這條路不重建主機、不放掉 A1 的容量，代價是要自己做映像、匯入，而〈Replacing a Boot Volume〉沒有寫自訂映像在 A1 上能不能用，這次沒有實跑。
• 把開機磁碟掛到另一台主機修改：停止這台、卸下開機磁碟、掛到同一個可用區的另一台主機，在那裡把公鑰寫進 authorized_keys 再掛回來。另一台主機的架構不必相同：開機磁碟當成資料磁碟掛上去，讀寫的是上面的檔案系統，跟 CPU 架構無關（推論）。這個帳號在這一區能建的免費機型只有 A1，用 A1 要再搶一次容量；改用付費的 x86 機型（例如 VM.Standard.E5.Flex 的 1 OCPU）開幾十分鐘、改完就刪，付費 x86 機型通常不像 A1 那樣容量不足（推論，這一區沒有實測），費用依帳號狀態而定，見 Oracle Cloud 的帳號結構與 home region 的〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉。這次兩種都沒有實跑。
• 序列主控台：主機裡沒有設密碼的帳號，登入提示這一步登不進去；官方從開機選單進維護模式重設金鑰的範例只寫了 Oracle Linux，同樣的做法在這台 Ubuntu 上能不能用，官方沒有寫，這次也沒有實跑。
• 重建主機：重建時放自己的公鑰（不論映像），讓 port forwarding session 登得進去；要用 managed SSH session 時，另外選可用 plugin 裡有 Bastion 的 Oracle Linux 版本（10 確定沒有；9、8、7.9 查詢工具分不出，要建起來才確認）。只換成 Oracle Linux 而不放公鑰，選到沒有 Bastion plugin 的版本時一樣登不進去。重建要重新搶 A1 的容量；2026-10-25 照這一項重建了一台，見〈重建：Oracle Linux 映像加建立時放公鑰，經由 port forwarding session 登入〉。

截至 2026-10-25，這台主機還沒有登入過。登入是在另外重建的一台上完成的，見〈重建：Oracle Linux 映像加建立時放公鑰，經由 port forwarding session 登入〉。

重建：Oracle Linux 映像加建立時放公鑰，經由 port forwarding session 登入

2026-10-25 晚上另外建了一台 A1 主機 verify-a1-ol，Ubuntu 那台 verify-a1 留著不動。Free Tier 與試用中的 tenancy，Always Free 的 A1 額度合計 2 OCPU、12 GB（官方〈Always Free Resources〉；付費 tenancy 的免費量比這個大，見 Oracle Cloud 的帳號結構與 home region：tenancy、Always Free 的範圍與主控台登入欄位〈Always Free 的額度與它綁在 home region 上的範圍〉），兩台各 1 OCPU、6 GB 剛好用滿；要再建一台 A1 而不超出額度，得先刪掉其中一台（同一天稍晚終止了 verify-a1，見〈刪除這組資源的順序〉）。超出時的結果依帳號狀態而定（試用中照樣建得起來，試用結束那一刻合計超額的 A1 會全部停用），見 Oracle Cloud 的帳號結構與 home region 的〈Always Free 的額度與它綁在 home region 上的範圍〉。verify-a1-ol 改了兩個建立時才能決定的設定：映像檔換成 Oracle Linux，避開〈Known Issues for Bastion〉列為不支援 managed SSH session 的 A1 加非 Oracle Linux；建立時放自己的公鑰，讓 port forwarding session 這條不經過 Bastion plugin 的路徑也登得進去。其餘的設定（compartment、private subnet、不配公開 IP、只允許中繼資料第二版、Bastion plugin 開啟）跟 verify-a1 相同。這一節的指令跟〈建立之後〉那一節一樣，先在 shell 裡 export OCI_CLI_AUTH=security_token。

建立之前查映像檔版本與它可用的 plugin

managed SSH session 要主機上有 Bastion plugin，而哪些 plugin 可用是依作業系統與版本決定的。官方〈Managing Plugins with Oracle Cloud Agent〉寫明可以在建立之前用 ListInstanceagentAvailablePlugins 查，對應的 CLI 是 available-plugins get：

1# 依作業系統名稱與版本，列出代理程式在這種映像上可用的 plugin
2oci instance-agent available-plugins get -c <compartment 的 OCID> \
3  --os-name "Oracle Linux" --os-version <作業系統版本> --all --query 'data[].name'

• --os-name、--os-version：照抄 oci compute image list 輸出的 operating-system 與 operating-system-version 欄。這一欄是大版本：映像名稱是 Oracle-Linux-10.2-aarch64-… 的那一個，這一欄是 10；相容 A1 的 Oracle Linux 映像在這一欄只有 10、9、8、7.9 四種值。
• 先建一份對照：填一個不存在的版本（例如 99）查一次，記下回傳的清單。這支工具查不到對應時不報錯，回傳不分版本的全部 plugin（官方 CLI 參考寫明；實測填不存在的版本、或不存在的作業系統名稱，回傳的都是同一份 15 項的清單，裡面有 Bastion）。
• 讀法：查到的清單跟對照不同，才算查到這個版本的資料，這時清單裡有 Bastion 才建得了 managed SSH session；跟對照相同時，分不出是這個版本提供全部 plugin，還是工具沒有它的資料。
• 2026-10-25 的結果：Oracle Linux 10（填 10.2 也一樣）回傳 8 項、沒有 Bastion，跟對照不同，確定沒有；Ubuntu 24.04 回傳 12 項、有 Bastion，跟對照不同，確定有，但它在 A1 上受〈Known Issues for Bastion〉第一條限制；Oracle Linux 9、8、7.9 與 Ubuntu 26.04 回傳的清單跟對照完全相同，這支工具分不出它們有沒有 Bastion。要確認 Oracle Linux 9，剩下的做法是建一台再用 plugin list 看，或找官方逐版本列出 plugin 的文件（這次沒有找到）。

verify-a1-ol 建立時沒有做這一步，選的是建立時間最新的 Oracle Linux 10.2，結果見〈結果：這台 Oracle Linux 10.2 主機上沒有 Bastion plugin〉。

建主機：Oracle Linux 映像加 –ssh-authorized-keys-file

建立的指令跟〈等效的 CLI 指令〉那一條相同，改了映像檔、公鑰與名稱三處；--no-retry 是重送腳本裡的寫法（理由見〈重送建立請求〉），單跑一次時可以拿掉。容量不足時，把同樣的三處改進重送腳本裡的 launch 指令：

 1# 查相容 A1 機型、指定大版本的 Oracle Linux 映像，取這個版本最新的建置
 2oci compute image list -c <tenancy 的 OCID> --operating-system "Oracle Linux" --operating-system-version <大版本> \
 3  --shape VM.Standard.A1.Flex --sort-by TIMECREATED --sort-order DESC --query 'data[0].id' --raw-output
 4
 5# 建主機：換掉 --image-id 與 --display-name，加上 --ssh-authorized-keys-file
 6oci --no-retry compute instance launch -c <compartment 的 OCID> --availability-domain <可用區名稱> \
 7  --display-name verify-a1-ol --shape VM.Standard.A1.Flex --shape-config '{"ocpus":1,"memoryInGBs":6}' \
 8  --image-id <上一條印出的映像 OCID> --subnet-id <private subnet 的 OCID> --assign-public-ip false \
 9  --ssh-authorized-keys-file <登入主機用的公鑰檔> \
10  --agent-config '{"pluginsConfig":[{"name":"Bastion","desiredState":"ENABLED"}]}' \
11  --is-pv-encryption-in-transit-enabled true \
12  --instance-options '{"areLegacyImdsEndpointsDisabled":true}'

• -c <tenancy 的 OCID>：理由同〈等效的 CLI 指令〉的 --image-id 那一項；這次填實驗用的 compartment 也列得出同樣的平台映像。
• --operating-system-version <大版本>：決定取哪一個大版本，例如 9。不給時，--sort-by TIMECREATED 取到的是所有版本裡建立時間最新的那一個建置，這次取到 Oracle-Linux-10.2-aarch64-2026.10.16-0，也就是沒有 Bastion plugin 的版本。要用 managed SSH session，填〈建立之前查映像檔版本與它可用的 plugin〉確定有 Bastion 的版本；Oracle Linux 這次沒有一個版本查得到確定有，9、8、7.9 的查詢結果一樣，要建起來用 plugin list 才知道。這篇的 Backlog 選 9 去驗，理由是它在沒有被確定排除的版本裡最新，不是因為查詢結果比 8 好。
• --ssh-authorized-keys-file：公鑰檔的路徑，內容寫進主機的中繼資料 ssh_authorized_keys，開機時由 cloud-init 寫進預設使用者 opc 的 authorized_keys。這一項建立之後不能改（〈建立之前的檢查〉），所以要在這裡放。這次用自己另產的一組金鑰，跟 Bastion 工作階段用的那一組分開。用同一組也連得上，指令還少一把 -i；工作階段的私鑰外洩時，拿到的人還要一個有 IAM 權限的帳號替他建工作階段、來源 IP 也要在 Bastion 的允許清單裡，所以分開換到的主要是另一個方向：登入主機的私鑰外洩時，主機那一把要換（建立時放的這一把要另外改主機上的 authorized_keys），工作階段那一把不受影響（推論，這次沒有實跑）。

這次第一次送出就建成，沒有遇到容量不足：台北時間 19:06:13 送出，19:07 查詢時已經是 RUNNING。容量是否不足依區域與時段而變，verify-a1 在同一區重送到第 16 次才建成（〈重送建立請求〉），所以重送腳本仍然要準備好。

結果：這台 Oracle Linux 10.2 主機上沒有 Bastion plugin

主機開機約 30 分鐘後，oci instance-agent plugin list --instanceagent-id <主機的 OCID> -c <compartment 的 OCID> 列出的 plugin 裡沒有 Bastion：Compute Instance Run Command、Compute Instance Monitoring、Custom Logs Monitoring 是 RUNNING，其餘是 STOPPED 或 NOT_SUPPORTED，Bastion 這一項整個不在清單上。主機的 agent-config 仍然寫著 Bastion 是 ENABLED，同一時間查 verify-a1 的 Bastion plugin 是 RUNNING。登入之後在主機上查，代理程式是 oracle-cloud-agent-1.64.0-16.el10.aarch64，/var/log/oracle-cloud-agent/plugins/ 底下沒有 bastions（verify-a1 上 plugin 目錄的名字）也沒有 bastion，grep -i bastion 代理程式的日誌也沒有任何一行。plugin 清單、plugin 目錄與日誌這三處都沒有 Bastion，跟〈建立之前查映像檔版本與它可用的 plugin〉查到的結果一致：Oracle Linux 10 可用的 plugin 清單裡沒有 Bastion，所以 managed SSH session 在這台建不起來。〈Known Issues for Bastion〉只寫 Arm 主機要跑 Oracle Linux，沒有寫版本，所以只讀 Known Issues 看不出這一點。

這台建立時放了公鑰，port forwarding session 這條路徑還在，所以不必重建。

建 port forwarding session 並經由本機的轉送登入

port forwarding session 只替一個私有 IP 的一個 port 開 TCP 轉送。官方〈Bastion Overview〉寫明它不需要目標主機上執行 Oracle Cloud Agent，〈Connecting to a Port Forwarding Session〉也寫明不符合 managed SSH session 條件的主機可以用它連。主機那一端的登入驗證是 sshd 與 authorized_keys。Bastion 另有一種 dynamic port forwarding（SOCKS5）工作階段，一個工作階段連得到 subnet 裡的任何主機，同樣不經過代理程式，代價是本機要走 SOCKS 代理、能連到的範圍也變寬（〈Bastion Overview〉，這次沒有實跑）；這次用的是只轉到一台主機的 port forwarding：

 1# 建一個轉到主機 22 port 的 port forwarding session
 2oci bastion session create-port-forwarding --bastion-id <Bastion 的 OCID> \
 3  --target-private-ip <主機的私有 IP> --target-port 22 \
 4  --ssh-public-key-file <這次工作階段用的公鑰> --session-ttl 3600 \
 5  --wait-for-state SUCCEEDED --wait-for-state FAILED --query 'data.resources[0].identifier' --raw-output
 6
 7# 在本機開轉送：本機的 2222 port 經由 Bastion 轉到主機的 22 port（這條指令會一直佔著終端機）
 8ssh -i <這次工作階段用的私鑰> -N -L 2222:<主機的私有 IP>:22 -p 22 \
 9  <上一條印出的工作階段 OCID>@host.bastion.<區域>.oci.oraclecloud.com
10
11# 另開一個終端機，經由本機的 2222 port 登入主機
12ssh -i <登入主機用的私鑰> -p 2222 opc@localhost

• --target-private-ip、--target-port 22：轉送的終點。port forwarding session 不必指定主機的 OCID，也不經過主機上的代理程式。
• --session-ttl 3600：工作階段的時效（秒），上限是 Bastion 的 --max-session-ttl（oci bastion bastion get --bastion-id <Bastion 的 OCID> 的 max-session-ttl-in-seconds）；到期之後轉送中斷，要再建一個工作階段。
• --wait-for-state SUCCEEDED --wait-for-state FAILED：等建立的 work request 到其中一個狀態再回傳；--query 取出的是新工作階段的 OCID。work request 是 FAILED 時這一條一樣會印出 OCID，所以用 oci bastion session get --session-id <印出的 OCID> --query 'data."lifecycle-state"' 確認工作階段是 ACTIVE，不是的話照〈結果：停在 CREATING 約 15 分鐘後轉成 DELETED〉讀 work request（記錄這次非同步建立的進度與錯誤的物件）的錯誤。這次 11 秒就是 ACTIVE，verify-a1 的 managed SSH session 是等 15 分鐘之後逾時。
• 本機轉送那一條的 <這次工作階段用的私鑰>：對應 --ssh-public-key-file 的那一把，用來通過 Bastion 的驗證；-N 只開轉送、不執行遠端指令；-L 2222:<主機的私有 IP>:22 把本機的 2222 port 轉到主機的 22 port，本機 port 可以選任何沒在用的號碼（官方原文是 any available local port），選 1024 以上的不需要 root；-p 22 是 Bastion 端的 SSH port，也是 ssh 的預設值，照官方的範例寫出來；使用者名稱是工作階段的 OCID，<區域> 是 ap-batam-1 這種區域識別碼。
• 登入主機那一條的 <登入主機用的私鑰>：對應建立主機時 --ssh-authorized-keys-file 的那一把，用來通過主機上 sshd 的驗證。同一次登入用到兩把金鑰，各自通過一道驗證。
• 本機轉送那一條的完整寫法不必自己組：oci bastion session get --session-id <工作階段的 OCID> --query 'data."ssh-metadata".command' --raw-output 印出同一條指令，主機名稱、使用者名稱與私有 IP 已經填好，只留 <privateKey> 與 <localPort> 兩個位置要換（實測）。主控台的工作階段清單裡，那個工作階段的選單也有 Copy SSH command（〈Connecting to a Port Forwarding Session〉）。

替代做法：用 -J 一條指令完成轉送與登入。ssh 的 ProxyJump 經由 Bastion 直接連到主機，不必另開一個終端機、也不必挑本機 port。兩把私鑰要各自交代給 ssh，所以寫成一個設定檔，再用 ssh -F <設定檔> <主機的別名> 連：

 1# Bastion 這一段：使用者名稱是工作階段的 OCID，用工作階段的私鑰
 2Host <Bastion 的別名>
 3  HostName host.bastion.<區域>.oci.oraclecloud.com
 4  User <工作階段的 OCID>
 5  IdentityFile <這次工作階段用的私鑰>
 6  IdentitiesOnly yes
 7
 8# 主機這一段：經由上面那一段跳過去，用登入主機的私鑰
 9Host <主機的別名>
10  HostName <主機的私有 IP>
11  User opc
12  IdentityFile <登入主機用的私鑰>
13  IdentitiesOnly yes
14  ProxyJump <Bastion 的別名>

• IdentitiesOnly yes：只用 IdentityFile 指定的那一把，不把 ssh-agent 裡的其他金鑰一把把試過去；試的次數太多時伺服器會先斷線。
• 2026-10-25 用同一個 port forwarding session 實跑，登入成功（opc@verify-a1-ol）。這條路的終點跟 -L 一樣是工作階段指定的私有 IP 與 port，所以不必另建工作階段；主機金鑰記在 known_hosts 的私有 IP 底下，而 -L 的寫法記在 [localhost]:2222 底下，之後用同一個本機 port 轉到另一台主機時，ssh 會報 REMOTE HOST IDENTIFICATION HAS CHANGED。

第一次跑本機轉送那一條時，ssh 先要求確認的是 Bastion 自己（host.bastion.<區域>.oci.oraclecloud.com）的主機金鑰，這一把跟要登入的主機無關，官方文件沒有列出它的指紋。接著第一次連 localhost:2222 時，ssh 要求確認的才是主機的金鑰（機制與 known_hosts 見 SSH Host Key 與 known_hosts（主機金鑰））。這台主機的金鑰在開機時由 cloud-init 產生，指紋印在序列主控台輸出裡：用〈結果：停在 CREATING 約 15 分鐘後轉成 DELETED〉那兩條 console-history 指令讀出輸出，找 BEGIN SSH HOST KEY FINGERPRINTS 那一段的 ED25519 指紋，跟 ssh 顯示的指紋相同才接受。這次是先接受、登入之後才讀序列主控台輸出比對，兩邊的 ED25519 指紋完全相同；照上面的順序先比對再接受，才擋得住連到別台主機的情形。這台的 Run Command plugin 是 RUNNING，所以另一個取得指紋的方式是用 Run Command 送 ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub，主機金鑰的公鑰檔所有人都讀得到，ocarun 沒有 sudo 也讀得了；要先有〈讓主機領得到指令：dynamic group 與 IAM 政策〉那一組設定（推論，這次沒有實跑）。

台北時間 19:37:55 登入成功：whoami 印出 opc，/etc/os-release 是 Oracle Linux Server 10.2，uname -m 是 aarch64，sudo -n true 成功（opc 有免密碼的 sudo）。從送出建立到登入約 32 分鐘，大部分時間花在等 Bastion plugin，而它最後沒有出現。序列主控台輸出裡，cloud-init 在開機約 38 秒時印出 opc 的 authorized_keys 並完成（送出建立之後約 73 秒），所以直接走 port forwarding 的話，主機 RUNNING 之後一兩分鐘就可以連，不必等 plugin。建立時放了公鑰的主機，port forwarding 本身就是完整的登入路徑；managed SSH session 多給的是登入的公鑰只在工作階段期間放進主機、主機上不留常駐的金鑰，這台已經放了常駐的公鑰，這一點就沒有了。

• 沒做時（建立時沒放公鑰）：主機的 authorized_keys 是空的，而這台的 managed SSH session 又建不起來，結果跟 verify-a1 相同：兩種工作階段都登不進去，剩下的入口見〈這台主機剩下的登入入口〉。
• 替代做法：
  • 映像檔選 Ubuntu 加建立時放公鑰：port forwarding 同樣登得進去，managed SSH session 仍然受〈Known Issues for Bastion〉第一條限制（照 Known Issues 推出，這次沒有實跑）。
  • 映像檔選 Oracle Linux 9 加建立時放公鑰：available-plugins get 對 9 的回應跟查不到時相同，有沒有 Bastion 要建起來才知道；有的話 managed SSH session 與 port forwarding 兩種工作階段都可用，沒有的話跟這次一樣靠 port forwarding（推論，這次沒有實跑）。有 Bastion 時換到的是 managed SSH session 這一條不依賴常駐公鑰的路徑，付出的是用比較舊的大版本。日常登入想讓主機上不留常駐金鑰、只在工作階段期間放臨時公鑰時，才值得為此選 9；只要登得進去，10.2 加公鑰加 port forwarding 已經夠用。
  • 選有 Bastion plugin 的版本、不放公鑰、只靠 managed SSH session：plugin 一旦沒有運作（像 verify-a1 那樣狀態是 RUNNING 卻建不起工作階段），就沒有任何 SSH 的入口。建立時放公鑰，換到的是一條不依賴 plugin 的路徑。兩種工作階段最後都經過主機上的 sshd，所以 sshd 本身壞掉時兩種都連不上（從兩種工作階段的機制推論）；那時剩下序列主控台與重建，序列主控台在 Oracle Linux 上有官方從開機選單進維護模式的範例（〈這台主機剩下的登入入口〉），這次沒有實跑。

刪除這組資源的順序

實驗結束要清掉時，順序跟建立時相反，因為每一項資源被後面建的資源依賴著：

1. 終止兩台主機（verify-a1 與 verify-a1-ol），在終止對話框勾選「Permanently delete the attached boot volume」，開機磁碟才會一起刪掉。CLI 是 oci compute instance terminate --instance-id <主機的 OCID> --preserve-boot-volume false --force：--preserve-boot-volume false 對應那個勾選，--force 跳過確認提示。2026-10-25 用這一條終止了 verify-a1，約 67 秒後主機與它的開機磁碟都是 TERMINATED；用 oci bv boot-volume list -c <compartment 的 OCID> --availability-domain <可用區名稱> 確認開機磁碟的狀態。本機的 port forwarding 轉送用 Ctrl-C 結束，工作階段到了 --session-ttl 自己失效。
2. 刪除 Run Command 用的政策與 dynamic group（oci iam policy delete --policy-id <政策的 OCID>、oci iam dynamic-group delete --dynamic-group-id <dynamic group 的 OCID>）。政策建在 compartment 上，compartment 刪除之前要先刪；dynamic group 在 tenancy 層，不會隨 compartment 刪除，不刪的話它的比對規則仍然指著已經終止的主機 OCID。2026-10-25 終止 verify-a1 之後照這個順序刪了兩者，兩條都加 --force 跳過確認提示；刪完之後再 oci iam policy get 與 oci iam dynamic-group get，兩者都回 404 NotAuthorizedOrNotFound，代表已經不存在。
3. VCN 裡另外建了 NAT gateway 與 NSG 時，先刪它們：NSG 要先從網卡拿掉才刪得掉，NAT gateway 要先從路由表拿掉那一條路由（2026-10-27 實跑：順序反了時 NSG 回 412 PreconditionFailed，NAT gateway 回外層 400 InvalidParameter、訊息裡包著 409, Conflict），順序與指令見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈刪除這組資源的順序〉。
4. 刪除 Bastion（oci bastion bastion delete --bastion-id <Bastion 的 OCID>）。Bastion 的私有端點在目標 subnet 裡，Bastion 還在時 subnet 刪不掉；它的工作階段隨 Bastion 一起失效。
5. 刪除 subnet。subnet 裡還有主機或網卡時刪不掉。
6. 刪除 subnet 用過的路由表與 security list。
7. 刪除 service gateway。
8. 刪除 VCN。
9. 刪除 compartment。官方〈Deleting a Compartment〉寫明 compartment 要先清空所有資源（包括掛在它上面的權限政策）才能刪除，刪除是非同步的工作，狀態會先變成 Deleting。

這個順序實際跑過的是終止 verify-a1、刪除政策和 dynamic group，以及 2026-10-27 照私有子網路那篇刪掉 NAT gateway 與 NSG 的第 3 步；其餘各步還沒有實際跑過（截至 2026-10-27 verify-a1-ol 與網路都還在），各項刪不掉時，看錯誤訊息指出的那一項依賴、先刪它。

要讓這組資源可以重建、清掉也不心疼，改用 IaC 描述它們，見 IaC 工具選型與 state 地基；已經用主控台或 CLI 建好的資源要收進 IaC，做法見 Unmanaged Resource 批次 Import 工作流。

開機磁碟與區塊磁碟

雲端主機的磁碟跟主機本身是兩個獨立的資源。開機磁碟（Oracle Cloud 叫 boot volume）在建立主機時從映像檔複製出來，裝著作業系統；區塊磁碟（block volume）是另外建立、掛上去的資料磁碟，作業系統看到的是一顆新的空磁碟，要自己分割與格式化。兩種都是經由網路掛到主機上的虛擬磁碟，主機停止時資料保留，主機終止之後磁碟可以單獨存在，見 EBS 卡裡同一個概念在 AWS 上的說明。

實驗用的小主機只用開機磁碟就夠。資料要跟作業系統分開管理時（重裝系統而保留資料、把資料搬到另一台主機），資料放在區塊磁碟上。Oracle Cloud 的建立頁最多可以同時建立並掛載 10 顆區塊磁碟，也可以之後再掛。

開機磁碟的大小

開機磁碟的預設大小由映像檔決定，Oracle Cloud 的 Linux 平台映像預設是 50 GB。建立頁可以勾選自訂大小，範圍是 50 GB 到 32 TB，且不能小於映像檔的預設值。免費額度按磁碟容量計算時，加大開機磁碟會直接吃掉額度：Oracle Cloud 的 Always Free（不會到期的免費額度）給的是開機磁碟與區塊磁碟合計 200 GB，一台主機的開機磁碟加大到 200 GB，第二台主機的開機磁碟就超出額度。Oracle Cloud 在付費帳戶新建一顆開機磁碟時，判定免費與否的單位是整顆磁碟：放不進剩餘額度的那一顆整顆不算免費，不是只有超出的那幾 GB；把既有的免費開機磁碟線上加大到超過剩餘額度、或另建一顆超過額度的資料磁碟，結果相同：加大的那一顆整顆移出免費額度，另建的那一顆整顆在額度外。之後刪掉別的磁碟空出額度、剩餘額度放得下付費的那一顆時，它會自動轉成免費，而轉換不是當下發生：線上加大而移出額度的那一顆開機磁碟，一次實測等了 26 到 31 分鐘，這段時間照付費計；建立時就在額度外的磁碟會自動轉換是 Always Free 頁寫的行為，延遲沒有量（以上都是 2026-10-27 實測，預設效能等級、home region。見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉）。超出之後的結果依帳號狀態而定，見 Oracle Cloud 的帳號結構與 home region：tenancy、Always Free 的範圍與主控台登入欄位 的〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉；手上已經用掉多少，到區塊儲存服務的開機磁碟與區塊磁碟清單把每顆的大小加起來。

磁碟的大小只能加大、不能縮小。Oracle Cloud 支援在主機開著的時候線上加大，加大之後要在作業系統裡把分割區與檔案系統延伸到新的大小，作業系統才用得到新增的空間：一般 Linux 用 growpart 延伸分割區，再依檔案系統用 resize2fs（ext4）或 xfs_growfs（XFS）延伸檔案系統，Oracle Linux 的平台映像另附一支 oci-growfs 一次做完。所以建立時先用預設大小，空間不夠再加；一開始開得太大，之後想縮回去只能建新磁碟、把資料搬過去。

效能等級

磁碟的讀寫速度有兩種決定方式：獨立於容量另外設定，或依容量換算。Oracle Cloud 與 AWS 的 gp3 讓效能獨立於容量另外設定；Google Cloud 的 Persistent Disk 依容量換算，磁碟類型決定每 GB 的效能，容量越大效能越高。Oracle Cloud 用 VPU（volume performance unit，每 GB 配幾個效能單位）分級：

VPU 另外計費：Lower Cost 只收儲存費，其餘等級在儲存費之外加收效能費。開機磁碟不能選 Lower Cost，預設是 Balanced。官方的 Always Free 頁只寫了 200 GB 的容量，沒有寫這 200 GB 涵蓋哪個效能等級；建立頁在 Always Free 主機上預設給的是 Balanced，實驗機維持預設，建好之後到帳單的成本分析頁看區塊儲存有沒有出現費用，就能確認自己的帳號怎麼算。Oracle Cloud 的效能等級在磁碟建立之後可以修改，不必重建磁碟；主機上的磁碟延遲或 iowait 長時間偏高、資料庫查詢因為讀寫變慢時，就是該往上調的訊號。

加密

• 靜態加密（encryption at rest）：Oracle Cloud 與 Google Cloud 的磁碟預設就是加密的，金鑰由業者管理，不必另外設定；AWS 的 EBS 要在每個區域打開 EBS encryption by default，新磁碟才會預設加密。要自己掌握金鑰時（合規要求、要能撤銷金鑰讓資料失效），可以改用自己在金鑰管理服務（Oracle Cloud 的 Vault）建立的金鑰。Oracle Cloud 的區塊儲存只支援 AES 金鑰，不支援 RSA 金鑰。
• 傳輸中加密（in-transit encryption）：主機與磁碟之間經由網路傳送的資料也加密。Oracle Cloud 的虛擬機可以選擇開或不開，建立頁的預設是開啟（實測紀錄的 Storage 段，2026-10-24 建立 A1 Ubuntu 主機時）；支援的裸機主機則固定開啟。用自己的 Vault 金鑰時，同一把金鑰也用在傳輸中加密。

在 Oracle Cloud 上兩項都維持預設不會降低安全性，也不影響費用；在 AWS 上要先確認那個區域的預設加密有打開。

刪除（終止）主機時開機磁碟的預設去留

這一項三家的預設不同，而 Oracle Cloud 的預設是保留，刪了主機之後磁碟還在：

• Oracle Cloud：終止主機時，開機磁碟預設保留。主控台的終止對話框裡有一個「Permanently delete the attached boot volume」的勾選框，不勾就保留。跟主機一起建立的區塊磁碟同樣預設保留，另有一個勾選框控制。保留下來的開機磁碟可以拿來重建主機，或當成資料磁碟掛到另一台主機上。
• Google Cloud：開機磁碟預設跟著主機一起刪除，建立頁開機磁碟的 Deletion rule 預設是 Delete disk。
• AWS：建立主機時一起掛上的根磁碟預設跟著主機一起刪除（DeleteOnTermination 預設為 true，這個值來自 AMI 的設定）；之後另外掛上的資料磁碟預設保留。

在 Oracle Cloud 上刪除實驗機時，要嘛勾選刪除開機磁碟，要嘛在之後到區塊儲存服務的開機磁碟清單確認有沒有留下不要的磁碟。保留的磁碟是一個仍然存在的資源。官方的終止說明沒有寫它是否計費，而 Always Free 頁寫明 200 GB 算的是開機磁碟與區塊磁碟的合計，額度用完時要刪掉主機與它的開機磁碟才能空出空間；所以留下來的開機磁碟繼續佔著額度，之後再建的磁碟放不進剩下的額度時就整顆超出額度（判定以整顆磁碟為單位，實測連結在〈開機磁碟的大小〉）。

這類主機刪了、自己卻還存在而沒有人記得的資源，叫孤兒資源（orphaned resource），各家的帳單上都會出現，見 計費模式理解 的〈隱藏成本：帳單上的意外〉。Oracle Cloud 的這個預設最容易在反覆建刪實驗機時累積起來。用過 Google Cloud、AWS 的人，習慣刪了主機就等於刪了開機磁碟；在 Oracle Cloud 上每刪一台都留下一顆 50 GB 的開機磁碟，而主機清單上已經看不到它，它列在另一個選單（區塊儲存服務的開機磁碟清單），額度還沒用完時帳單上也不會出現任何費用。額度扣的是每顆磁碟以 GiB 進位的大小，預設的 50 GB 開機磁碟扣 47 GB（46.6 GiB 進位，2026-10-27 查用量推論，查法在 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉），建刪四輪之後這些磁碟佔掉 188 GB，第五台主機的開機磁碟就超出額度，這時才要回頭逐顆辨認哪些磁碟可以刪。刻意終止主機、保留磁碟以便之後重建的情形，什麼時候比停止主機或全部刪除划算，見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停時保留的範圍：只停服務、停止主機、終止主機、全部刪除〉。

各家的欄位名稱：開機磁碟、資料磁碟、效能等級與終止時的預設

延伸閱讀：磁碟之外的建立選項

• 機型與映像檔：開機磁碟的內容來自哪一個映像檔、停止主機時哪些資源還在計費
• Oracle Cloud 建立主機的實測紀錄 的 Management 段：Oracle Cloud 代理程式的 Block Volume Management plugin 與其他 plugin 的用途

事件說明：2026-10-26（本篇沒有標 UTC 的日期與時刻都是台北時間），在 Oracle Cloud 的 ap-batam-1 區域，從一台 macOS 開發機用 OCI CLI 操作。tenancy 以 Free Tier 註冊，2026-10-27 確認它已經是付費帳戶（升級的日期這次沒有記錄）。主機是 A1 機型（VM.Standard.A1.Flex，1 OCPU、6 GB），映像檔是 Canonical-Ubuntu-24.04-aarch64-2026.09.18-0，放在既有的私有子網路裡、沒有公開 IP，經由 Bastion 的 port forwarding session 登入。當時在做的操作是：在雲端主機上確認 Ubuntu 的自動更新預設與核心更新前後的重開機判斷，並實際連一次序列主控台。2026-10-27 凌晨另外跑了重建腳本，並終止了重建腳本建出的 verify-ubuntu-rebuild；接著把 verify-ubuntu 停止、啟動，在三種狀態下各跑一次重建腳本，用 oci limits 與 usage API 查區塊磁碟額度與帳務，凌晨最後照刪除順序收掉 verify-ubuntu 的 NAT gateway 與 NSG。2026-10-27 上午又做了三件事：對 verify-ubuntu 重跑重建腳本，讓它重建 NAT gateway 與 NSG；用重建腳本新建一台開機磁碟 60 GB 的 verify-ubuntu-60g，建立期間對同一個名稱再跑一份腳本；以及在網頁主控台的 Limits, quotas and usage 頁讀區塊磁碟的用量；中午前用 usage API 查到那一台開機磁碟的計費項目之後，終止了 verify-ubuntu-60g。2026-10-27 下午（13 時到 15 時）又做了五件事：不給 BOOT_GB 用重建腳本新建 verify-ubuntu-nb、設 compartment quota 試超額的建立、線上加大 verify-ubuntu 的開機磁碟並另建一顆資料磁碟、終止 verify-ubuntu-nb 之後觀察付費磁碟的額度用量與帳務明細怎麼變，最後照刪除順序把 verify-ubuntu 與它的出站設定整組收掉。

這篇記錄在 Oracle Cloud 的私有子網路裡建一台 Ubuntu 24.04 主機之後，讓它連得到套件來源、連上序列主控台，以及主機不見之後怎麼照原樣重建。各節依序是：

• 前置條件：沿用 Oracle Cloud 建立主機的實測紀錄：建立前的檢查、前置網路、主控台各分頁的 Always Free 設定值、等效的 CLI 指令、容量不足的重送、Bastion 工作階段逾時、Run Command 補公鑰的嘗試與重建後經由 port forwarding 登入（下文稱「建主機那篇」）建好的 compartment、VCN、私有子網路、service gateway、Bastion 與金鑰。
• 建 Ubuntu 24.04 主機，經由 port forwarding session 登入。
• 只接了 service gateway 的私有子網路裡，apt 連不到套件來源的錯誤原文與成因。
• 加上 NAT gateway、路由規則與只掛在這台主機上的出站 NSG（network security group：套在個別網卡上的一組防火牆規則）之後，apt-get update 成功。
• 序列主控台：產生 RSA 金鑰、建立序列主控台連線（instance console connection）、把官方的連線字串改寫成 ssh 的 ProxyJump 設定，以及看到的開機輸出。
• 主機被閒置回收、停止或刪除之後：怎麼發現、哪些資源會留下、主機與序列主控台連線的重建腳本（含用 BOOT_GB 指定開機磁碟大小）、每一步的讀法、同一個名稱同時跑兩份腳本的結果與會建出第二台主機的空窗、重建之後要重做的事與耗時。
• 費用與額度（A1 的免費量、開機磁碟從區塊磁碟額度扣掉多少與用量的查法、合計超過 200 GB 時放不進剩餘額度的那一顆磁碟整顆不算免費額度、用 compartment quota 擋下超額的建立與被擋下時的回應、線上加大開機磁碟與另建資料磁碟超過額度時的結果、空出額度之後付費磁碟自動轉成 Always Free 要等多久與帳務明細怎麼記、網頁主控台 Limits, quotas and usage 頁與 CLI 的對照、在價目表與帳務明細裡找 NAT gateway 收費項目的結果），以及刪除這組資源的順序與實際刪除時的錯誤訊息（NSG 還掛在網卡上時的 412，NAT gateway 還被路由表指著時外層 400、內含 409）與整組收掉的實跑。

主機上量到的自動更新預設、核心更新前後的 needrestart -b 與 reboot-required，寫在 長期上線主機的維護項目：會累積的資料、定期讀的 log、對外入口的盤點、安全更新、會到期的設定與檢查間隔的推算（下文稱「維護篇」）〈會老化的軟體：各條更新管道與更新後的重開機〉，這裡只寫在 Oracle Cloud 上建立與連線的操作。本篇自己的 OCID 與 IP 一律是佔位值：OCID 用 oci ... list 查，私有 IP 用 oci compute instance list-vnics 查；錯誤原文裡的位址是 Canonical 鏡像站的。

前置條件：沿用 Oracle Cloud 建立主機實測紀錄的網路、Bastion 與金鑰

這次沿用建主機那篇〈進建立頁之前：compartment、VCN、閘道與 private subnet〉建好的資源，沒有另建網路：

• compartment 與 VCN：放實驗資源的 compartment，以及裡面的 VCN。
• 私有子網路：這台主機要放的子網路。它的路由表一開始只有一條規則，目的地是 Oracle 服務網路，出口是 service gateway；security list 的出站規則也只放行 Oracle 服務網路與子網路內部。路由規則裡的目的地是一個名稱而不是位址範圍，這個名稱依區域而不同（這次的值是 all-hsg-services-in-oracle-services-network），用 oci network service list 查，名稱帶「All」的那一筆的 cidr-block 欄就是它。
• Bastion：目標子網路是上面那個私有子網路，client CIDR 是開發機對外的 IP（/32）。開發機的對外 IP 換了之後，來源不在 client CIDR 裡，經由 Bastion 的 ssh 連線建立不起來，要先改 client CIDR（從 client CIDR 的作用推論；這次開發機的 IP 沒有變過，沒有看到實際的錯誤訊息）。
• 兩把金鑰：登入主機用的金鑰（建立主機時放進去，重建腳本裡的檔名是 verify-a1-key），以及建 Bastion session 用的金鑰（檔名 session_key）。兩把都是建主機那篇建的：session 用的那一把照〈建立 Bastion 與 managed SSH session〉用 ssh-keygen 另產，登入主機的那一把是〈建主機：Oracle Linux 映像加 –ssh-authorized-keys-file〉另產、跟 session 那一把分開的一組，兩把分開的理由寫在那一節。
• OCI CLI 的登入：session token 登入，有效期約 1 小時，到期時重跑 oci session authenticate --region <區域> --profile-name DEFAULT，做法見 從本機用 OCI CLI 操作 Oracle Cloud：session token 登入、時效與 API 簽章金鑰。<區域> 填區域的識別碼（這次是 ap-batam-1），oci iam region-subscription list 列得出 tenancy 訂閱的區域（這一條沒有實跑）。

下文的 CLI 指令裡，<compartment 的 OCID> 這類佔位值換成自己的。這次把重建腳本要用的值存在一個 ids.env 裡，腳本開頭 source 一次；每個鍵與查法如下（值是建立資源時從回傳記下的，查法的子命令只確認過 --help 存在，沒有逐一實跑）：

建 Ubuntu 24.04 主機與經由 port forwarding 登入

建立指令跟建主機那篇〈等效的 CLI 指令〉相同，換成 Ubuntu 24.04 的映像檔，建立時放登入用的公鑰：

 1# 查 Ubuntu 24.04、相容 A1 的映像檔，取建立時間最新的那一個（實跑）
 2oci compute image list -c <compartment 的 OCID> --operating-system "Canonical Ubuntu" \
 3  --operating-system-version "24.04" --shape VM.Standard.A1.Flex \
 4  --sort-by TIMECREATED --sort-order DESC --query 'data[0].id' --raw-output
 5# 建主機（實跑；這次第一次送出就成功，容量不足時用建主機那篇的重送腳本）
 6oci compute instance launch -c <compartment 的 OCID> --availability-domain <可用網域> \
 7  --display-name verify-ubuntu --shape VM.Standard.A1.Flex --shape-config '{"ocpus":1,"memoryInGBs":6}' \
 8  --image-id <映像檔的 OCID> --subnet-id <私有子網路的 OCID> --assign-public-ip false \
 9  --ssh-authorized-keys-file <登入用公鑰的路徑> \
10  --agent-config '{"pluginsConfig":[{"name":"Bastion","desiredState":"ENABLED"}]}' \
11  --is-pv-encryption-in-transit-enabled true \
12  --instance-options '{"areLegacyImdsEndpointsDisabled":true}'
13# 查主機的狀態（重建腳本裡同一條查詢實跑過）：印 PROVISIONING 時隔一陣子再查，印 RUNNING 才往下做
14oci compute instance get --instance-id <launch 印出的主機 OCID> --query 'data."lifecycle-state"' --raw-output

這次的映像檔是 Canonical-Ubuntu-24.04-aarch64-2026.09.18-0。建立請求在送出之後約 4 秒回傳主機的 OCID，下一次查狀態時（約 20 秒後）已經是 RUNNING。建立指令裡各參數這次的取值與換掉之後的結果：

• --availability-domain：可用網域的完整名稱帶有 tenancy 專屬的前綴，用 oci iam availability-domain list 查；ap-batam-1 只有一個可用網域，沒有別的值可選。
• --shape-config：1 OCPU、6 GB。改大會多用 A1 的運算額度，合計超出免費量之後的結果依帳號狀態而定（〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉）；這次沒有比較其他規格。
• --assign-public-ip false：主機只有私有 IP，所以登入一定要經過 Bastion；換成公開 IP 的做法在下面的〈建主機與登入的其他做法：映像檔、公開 IP、VPN 與 managed SSH session〉。
• --agent-config 打開 Bastion plugin：plugin 是 managed SSH session 的前提，而這台只用 port forwarding session 登入，port forwarding 不經過 plugin，所以關掉它時登入照樣走得通（從兩種 session 的機制推論，這次沒有關掉 plugin 實跑）；打開它留著改用 managed SSH session 的可能，這台的組合為什麼用不了 managed SSH session 見下面的其他做法。
• --is-pv-encryption-in-transit-enabled true：開機磁碟在主機與儲存之間的傳輸加密。用這個值，沒有比較其他值；CLI 不給時預設是 false，跟網頁主控台的預設不同（建主機那篇〈等效的 CLI 指令〉）。
• --instance-options 的 areLegacyImdsEndpointsDisabled：主機只能用第二版的中繼資料服務（IMDSv2；中繼資料服務是什麼見 Instance Metadata Service（實例中繼資料服務），Oracle Cloud 的這個選項與第二版的差別見 代理程式、中繼資料服務、初始化腳本、維護行為與標籤〈中繼資料服務與 Authorization header〉）。用這個值，沒有比較其他值；這台主機的 cloud-init 在這個設定下照樣讀到了公鑰（下面登入那一段的 status: done）。

主機的私有 IP 由子網路配發，建立之後才知道。私有 IP 掛在主機的 VNIC（虛擬網路卡）（virtual network interface card：主機的虛擬網路卡，私有 IP 與後面〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉的 NSG 都掛在它上面）上，所以用列出 VNIC 的子命令查：

1oci compute instance list-vnics --instance-id <主機的 OCID> --query 'data[0]."private-ip"' --raw-output

接著建一個指向這個 IP、22 port 的 port forwarding session（實跑；建立 session 的 work request 約 1 分鐘後是 SUCCEEDED）：

1oci bastion session create-port-forwarding --bastion-id <Bastion 的 OCID> \
2  --target-private-ip <主機的私有 IP> --target-port 22 \
3  --ssh-public-key-file <session 用公鑰的路徑> --session-ttl 3600 --display-name verify-ubuntu-pf \
4  --wait-for-state SUCCEEDED --wait-for-state FAILED --max-wait-seconds 600 \
5  --query 'data.resources[0].identifier' --raw-output

這個 Bastion 建立時把 session 的最長時效（max-session-ttl）設成 3600 秒，--session-ttl 填更大的值時以 InvalidParameter 失敗，所以 session 最長 1 小時，過了要重建。自己的 Bastion 設了多少，用 oci bastion bastion get --bastion-id <Bastion 的 OCID> --query 'data."max-session-ttl-in-seconds"' 查（這一條沒有實跑）。上限可以用 oci bastion bastion update --bastion-id <Bastion 的 OCID> --max-session-ttl <秒數> 調高（--help 列得出這個選項，沒有實跑；可以調到多少這次沒有查證）：換到的是 session 少重建幾次，付出的是 session 用的私鑰外洩時，拿到的人能用比較久。登入用一份 ssh 設定檔，把 Bastion 當跳板（ProxyJump）：

 1# ssh-ubuntu.conf：<session 的 OCID> 是上一條印出的值，<…路徑> 換成自己的
 2Host verify-bastion-u
 3  HostName host.bastion.<區域>.oci.oraclecloud.com
 4  User <session 的 OCID>
 5  IdentityFile <session 用私鑰的路徑>
 6  IdentitiesOnly yes
 7
 8Host verify-ubuntu
 9  HostName <主機的私有 IP>
10  User ubuntu
11  IdentityFile <登入用私鑰的路徑>
12  IdentitiesOnly yes
13  ProxyJump verify-bastion-u
14  UserKnownHostsFile <這台專用的 known_hosts 路徑>
15  StrictHostKeyChecking accept-new

1ssh -F ssh-ubuntu.conf verify-ubuntu 'cloud-init status --wait; cloud-init status; uptime'

這次第一次連線印出 status: done 與 up 1 min：主機開機約 1 分鐘之後，cloud-init 的首次開機設定已經跑完，預設帳號 ubuntu 也有了公鑰。Ubuntu 映像檔的預設帳號是 ubuntu，Oracle Linux 是 opc，User 那一行要跟著映像檔改。UserKnownHostsFile 指向這台專用的檔案，主機重建之後 host key 會換，清掉這個檔就好，不必動 ~/.ssh/known_hosts。

StrictHostKeyChecking accept-new 讓 ssh 第一次連線時自動記下主機的 host key，之後 key 變了就拒絕連線。換到的是腳本裡的 ssh 不會停在「要不要信任這把 key」的提問；代價是第一次連線沒有比對指紋，那一刻連到的若不是這台主機，它的 key 也會被記下。要比對指紋時，照建主機那篇〈結果：停在 CREATING 約 15 分鐘後轉成 DELETED〉的做法用 console history 讀開機輸出，cloud-init 產生 host key 時把指紋印在裡面。預設值 ask 每台新主機第一次連線都要人回答，無人值守的腳本會停住（依 ssh_config 的說明，沒有實跑）。

設定檔的 ProxyJump 寫法以外，也可以在本機開一個轉送的 port 再連 localhost，兩種寫法的指令都在建主機那篇〈建 port forwarding session 並經由本機的轉送登入〉。

建主機與登入的其他做法：映像檔、公開 IP、VPN 與 managed SSH session

• 改用 Oracle Linux 映像檔：Oracle Linux 的套件庫在 Oracle 的服務網路裡，只接 service gateway 的私有子網路就更新得到（從映像檔的套件庫設定與這個子網路的路由推論，這次沒有在這個子網路的 Oracle Linux 主機上跑 dnf 對照），〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉那些設定就不需要。代價是 Oracle Linux 10 的代理程式沒有 Bastion plugin，managed SSH session 用不了，只能用 port forwarding session（建主機那篇〈重建：Oracle Linux 映像加建立時放公鑰，經由 port forwarding session 登入〉）。
• 給主機公開 IP：--assign-public-ip true 並把主機放進有 internet gateway 的公開子網路，主機自己就連得到套件來源，也可以直接 SSH，不需要 Bastion 與 NAT。代價是 22 port 對外暴露，要靠 security list 或 NSG 收窄來源（概念見 Security Group）；這次沒有實跑這種做法。只開給開發機的公開 IP（/32）也能把來源收窄到一個位址，Bastion 比它多給了三件事：誰能開 session 由 IAM 政策決定，不只看來源 IP；主機在網際網路上沒有位址可以連；session 到時效就自己失效。公開 IP 這條路另外有一個重建時的代價：主機被刪除重建之後，臨時配發的公開 IP 會換一個，ssh 設定與允許清單都要跟著改（依公開 IP 的配發方式推論，這次沒有實跑）。三層各自的做法與取捨見 伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口〈網路可達性的做法：管理 port 對誰開放〉。
• 改用 VPN 或 Tailscale 這類 overlay 網路登入：主機上裝 VPN 的用戶端，從開發機經由 VPN 連進來，不需要 Bastion session 的 1 小時時效。這台主機的 NSG 只開出站 TCP 80 與 443，Tailscale 這類需要 UDP 直連的工具，推論會退到經由 443 的中繼伺服器轉送，延遲比直連高；這一點沒有查證，也沒有實跑。網路可達性那一層的比較在同一篇〈網路可達性的做法：管理 port 對誰開放〉。
• managed SSH session 代替 port forwarding：Ubuntu 24.04 的代理程式有 Bastion plugin，但官方〈Known Issues for Bastion〉寫明，Arm 架構的 A1 機型上、作業系統不是 Oracle Linux 的主機不支援 managed SSH session（理由是這類主機上的 Bastion plugin 沒有正確啟用）。建主機那篇〈建立之後：Bastion managed SSH session 逾時的排查〉在 A1 加 Ubuntu 上實測三次都逾時，所以這次只有 port forwarding 行得通。

只接 service gateway 的私有子網路：apt 連到套件來源時的錯誤原文與成因

主機建好之後，apt 在這個子網路裡連不到套件來源。這次 apt-get update 失敗時的輸出沒有留下，下面附的是同一台主機上 apt-get install 下載套件時的錯誤原文（實跑；IPv6 位址那幾行省略）：

1E: Failed to fetch http://ap-batam-1-ad-1.clouds.ports.ubuntu.com/ubuntu-ports/pool/main/... Cannot initiate the connection to ap-batam-1-ad-1.clouds.ports.ubuntu.com:80 (2620:2d:4002:1::10a). - connect (101: Network is unreachable) ... Could not connect to ap-batam-1-ad-1.clouds.ports.ubuntu.com:80 (91.189.91.103), connection timed out
2E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

錯誤原文裡的兩種錯誤分別出自 IPv6 與 IPv4 兩條連線：

• Network is unreachable（IPv6）：主機的核心沒有任何通往網際網路的 IPv6 路由，connect() 立刻回錯誤碼 101（ENETUNREACH），封包沒有離開主機。序列主控台記下的開機輸出裡，cloud-init 印出的 IPv6 路由表只有 fe80::/64、local 與 multicast 三條，都只到這張網卡本身。
• connection timed out（IPv4）：封包送得出主機，回應沒有回來。這個子網路的路由表沒有任何一條規則把網際網路的位址送到出口，security list 的出站規則也沒有放行網際網路；兩項都沒有放行，是哪一項先擋下封包，這次沒有分開實測（推論）。

錯誤原文裡的主機名 ap-batam-1-ad-1.clouds.ports.ubuntu.com 是 Canonical 替雲端區域設的鏡像站；加上出站之後成功的輸出裡，-security 那幾行的來源是 ports.ubuntu.com。所以這個映像檔把一般的套件來源設成區域鏡像、把安全更新設成 ports.ubuntu.com（從兩份輸出與 Ubuntu 雲端映像檔的預設來源設定推論，這次沒有讀主機上的來源設定檔）。兩個主機都在 Oracle 的服務網路之外，而 service gateway 只轉送目的地是 Oracle 服務網路的封包，所以這台主機兩個都連不到。

這個失敗本身沒有訊號：apt-get update 的錯誤在背景排程裡只寫進 log，自動更新的 timer 照常觸發，什麼都裝不到。把 apt-get update 的輸出丟掉、只看 apt list --upgradable 時，連不到套件來源的主機會列出零個待裝的套件，看起來跟已經是最新的主機一樣；這次第一次探測就是這樣，加上出站之後同一台主機有 60 個安全更新待裝。所以私有子網路的主機上，讀自動更新的結果要讀它的 log（/var/log/unattended-upgrades/），不能只看有沒有待裝的套件。

加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG

要讓這台主機連得到網際網路上的套件來源而不給它公開 IP，出站要經過 NAT Gateway：主機送出的封包由 NAT gateway 換成它自己的公開 IP，回應的封包再換回來，網際網路上的主機連不進來。拿掉公開 IP 之後的出站需求怎麼處理（NAT，以及存取同一家業者的服務時不經過 NAT 的私有端點）、各自怎麼計費，寫在 伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口〈移除公開 IP 之後的出站路徑〉；這一節是其中 NAT 那一條在 Oracle Cloud 上的實作。加出站要動三項設定：NAT gateway、路由表與 NSG。路由規則要填 NAT gateway 的 OCID，所以 NAT gateway 先建、路由表後改；NSG 跟前兩項沒有依賴，放在哪個位置做都可以。

 1# 1. 建 NAT gateway（實跑）
 2oci network nat-gateway create -c <compartment 的 OCID> --vcn-id <VCN 的 OCID> --display-name verify-nat \
 3  --wait-for-state AVAILABLE --query data.id --raw-output
 4# 2. 路由表加 0.0.0.0/0 → NAT（實跑）；update 是整份替換，原本那條 service gateway 的規則要一起寫
 5oci network route-table update --rt-id <私有子網路路由表的 OCID> --force --wait-for-state AVAILABLE --route-rules '[
 6 {"destination":"<Oracle 服務網路的目的地名稱>","destinationType":"SERVICE_CIDR_BLOCK","networkEntityId":"<service gateway 的 OCID>"},
 7 {"destination":"0.0.0.0/0","destinationType":"CIDR_BLOCK","networkEntityId":"<NAT gateway 的 OCID>"}]'
 8# 確認路由（沒有實跑）：該看到兩條，0.0.0.0/0 指向 NAT gateway 的 OCID，service gateway 那一條也還在
 9oci network route-table get --rt-id <私有子網路路由表的 OCID> \
10  --query 'data."route-rules"[].{destination:destination,target:"network-entity-id"}' --output table
11# 3. 建只有出站 TCP 80、443 的 NSG，掛到這台主機的 VNIC（實跑）
12oci network nsg create -c <compartment 的 OCID> --vcn-id <VCN 的 OCID> --display-name verify-ubuntu-egress \
13  --wait-for-state AVAILABLE --query data.id --raw-output
14oci network nsg rules add --nsg-id <NSG 的 OCID> --security-rules '[
15 {"direction":"EGRESS","protocol":"6","destination":"0.0.0.0/0","destinationType":"CIDR_BLOCK","isStateless":false,"tcpOptions":{"destinationPortRange":{"min":80,"max":80}}},
16 {"direction":"EGRESS","protocol":"6","destination":"0.0.0.0/0","destinationType":"CIDR_BLOCK","isStateless":false,"tcpOptions":{"destinationPortRange":{"min":443,"max":443}}}]'
17# 確認規則（沒有實跑）：該看到兩列 EGRESS，port 分別是 80 與 443
18oci network nsg rules list --nsg-id <NSG 的 OCID> \
19  --query 'data[].{direction:direction,port:"tcp-options"."destination-port-range".min}' --output table
20# 查這台主機的 VNIC 的 OCID（實跑），再把 NSG 掛上去
21oci compute instance list-vnics --instance-id <主機的 OCID> --query 'data[0].id' --raw-output
22oci network vnic update --vnic-id <主機的 VNIC 的 OCID> --nsg-ids '["<NSG 的 OCID>"]' --force
23# 確認掛上（沒有實跑）：印出的 OCID 清單裡有 <NSG 的 OCID>
24oci network vnic get --vnic-id <主機的 VNIC 的 OCID> --query 'data."nsg-ids"'

• 路由表：決定封包往哪個出口送。規則依目的地比對，Oracle 服務網路的位址仍走 service gateway，其餘的（0.0.0.0/0）走 NAT gateway。<Oracle 服務網路的目的地名稱> 是原本那條規則的目的地，查法在〈前置條件：沿用 Oracle Cloud 建立主機實測紀錄的網路、Bastion 與金鑰〉的私有子網路那一項。route-table update --route-rules 會用給的清單取代整份規則，--force 略過取代之前的確認提示。只寫 NAT 那一條的話，service gateway 那一條就被刪掉，主機連 Oracle 服務網路的流量（Oracle Cloud Agent 的回報這類）改走 NAT gateway 到公開端點（從路由的比對方式推論，沒有實跑只寫一條的結果）。
• NSG：決定這張網卡（VNIC）放行哪些封包，概念見 Security Group。這個子網路的 security list 只放行 Oracle 服務網路與子網路內部的出站，有路由也送不出去，所以要再放行一條。這一條放在 NSG：security list 套在整個子網路上，同一個子網路裡的其他主機（這次有一台 Oracle Linux 主機）會一起多出網際網路的出站。NSG 只套在掛上它的 VNIC，影響範圍只有這一台。Oracle Cloud 對一張網卡取 security list 與 NSG 兩邊規則的聯集，任何一邊放行就放行（網路：subnet、私有 IP、公開 IP 與防火牆規則〈防火牆規則的位置與合併方式〉），所以「只開 80 與 443」成立的前提是這個子網路的 security list 一直不放行網際網路的出站；有人之後在 security list 加了全開的出站規則，這台主機的出站也跟著全開。規則裡的 "protocol":"6" 是 TCP 在 IANA 協定號碼表上的號碼；規則是有狀態的（isStateless: false），回應的封包自動放行，不必另寫入站規則。
• 只開 80 與 443：apt-get update 的輸出顯示 Ubuntu 的套件來源是 http://（80），套件的完整性由 apt 另外驗簽章；443 留給用 HTTPS 的來源（snap 與第三方套件庫這類）。只開這兩個 port 時 apt-get update 成功，名稱解析沒有另外放行；名稱解析走 VCN 內建的 DNS，在 VCN 裡面，不經過這兩條出站規則（從 VCN 的 DNS 設計推論，這次沒有讀主機上的解析設定）。

vnic update --nsg-ids 同樣是整份取代，--force 同樣略過確認提示：VNIC 原本掛著別的 NSG 時，要把原本的那幾個一起寫進清單。三樣都做完之後，同一條指令成功（實跑）：

1Get:55 http://ports.ubuntu.com/ubuntu-ports noble-security/multiverse arm64 c-n-f Metadata [456 B]
2Fetched 39.9 MB in 9s (4371 kB/s)

這一次下載 39.9 MB 花了 9 秒，速率 4371 kB/s。apt list --upgradable 列出 79 行，其中 60 個來自 -security，包括新的核心。這個映像檔建立之後公開的漏洞，在主機第一次開機時都還沒修補，所以新建的主機先手動跑一次更新並重開機：

1sudo unattended-upgrade   # 裝 -security 的更新（實跑，402 秒）
2sudo systemctl reboot     # 換上新核心（實跑）

unattended-upgrade 跑完升級了 64 個套件，比 -security 的 60 個多 4 個。這 4 個的來源這次沒有查；一個可能是新核心以新的套件名稱安裝，新安裝的套件不會列在 apt list --upgradable 裡（推論）。待裝的數量依映像檔建立的日期到建主機那一天之間公開了多少更新而變，換一個映像檔或換一天建，數字就不同。核心更新前後的重開機判斷在維護篇〈會老化的軟體：各條更新管道與更新後的重開機〉。

出站的其他做法：security list、建主機時就掛 NSG、限縮出站的目的地與不加出站

• 把出站規則加在 security list：效果是整個子網路的主機都能出站。同一個子網路只有這一台主機、或每一台本來就要更新時，這樣設定比較少；代價是之後放進這個子網路的主機也自動有網際網路出站（從 security list 套用的範圍推論，沒有實跑）。
• 建主機時就掛上 NSG：oci compute instance launch 有 --nsg-ids（--help 確認過，沒有實跑），建立時就把出站 NSG 掛在主機的 VNIC 上。換到的是主機首次開機時就有出站，重建腳本裡掛 NSG 那一步（第 6 步）也不必另外做；付出的是 NAT gateway、路由與 NSG 都要在建主機之前做好，順序從「先建主機、再加出站」變成「先加出站、再建主機」。
• 限縮出站的目的地：三種做法都把出站從「任何位址的 80 與 443」收窄。NSG 的規則只收 CIDR，可以只放行 Canonical 鏡像站的網段，代價是鏡像站的位址會變，位址換了之後更新又會逾時（推論，沒有查證）；在有出站的子網路自架一台 forward proxy，依網域篩選，私有子網路的主機只連它；或在 VCN 裡自建一台 apt 的快取代理（例如 apt-cacher-ng），私有子網路的主機只連那一台，另外還能控制更新的內容。後兩種適合主機多的環境，代價是多一台要維護的主機（推論，沒有實跑）。
• 不加出站：主機永遠裝不到套件更新，自動更新的 timer 照常觸發、什麼都裝不到；只適合用完即刪、不需要更新的實驗。

序列主控台：RSA 金鑰、建立連線、ProxyJump 設定與看到的開機輸出

序列主控台（Serial Console（序列主控台））讀的是主機的虛擬序列埠，不經過主機的網路與 sshd，sshd 設定改壞、防火牆擋住、新核心開不了機時，仍看得到開機輸出。Oracle Cloud 的做法是替主機建一個序列主控台連線（instance console connection），它只收 RSA 公鑰：

1# 產生 RSA 金鑰；序列主控台連線不收 ed25519（依 Oracle Cloud 文件〈Instance Console Connections〉，沒有拿 ed25519 實試）
2ssh-keygen -q -t rsa -b 3072 -N '' -C verify-console -f <序列主控台私鑰的路徑>
3# 建序列主控台連線（實跑，回傳時已是 ACTIVE）
4oci compute instance-console-connection create --instance-id <主機的 OCID> \
5  --ssh-public-key-file <序列主控台私鑰的路徑>.pub --wait-for-state ACTIVE
6# 取得官方的連線字串
7oci compute instance-console-connection list -c <compartment 的 OCID> --instance-id <主機的 OCID> \
8  --query 'data[0]."connection-string"' --raw-output

這次的序列主控台連線用完就刪，平時不留。序列主控台是救援入口，繞過平時登入主機的控制點，所以照 Serial Console（序列主控台）〈設計責任〉的「平時保持關閉、救援時才開啟、用完關回去」：要排查時跑〈被回收之後的重建：怎麼發現、留下與消失的資源、重建腳本〉裡序列主控台連線的重建腳本建一條（這次實跑約 15 秒），排查完用下面這條刪掉（腳本結尾會印出代入了連線 OCID 的同一條）：

1# 刪掉序列主控台連線（實跑）：--wait-for-state 等的是連線本身的狀態
2oci compute instance-console-connection delete --instance-console-connection-id <連線的 OCID> \
3  --force --wait-for-state DELETED

2026-10-27 對 verify-ubuntu 那條連線實跑這一條：CLI 印出 Action completed. Waiting until the resource has entered state: ('DELETED',)，exit 0，10 秒；之後 instance-console-connection list 只列出這一條，狀態是 DELETED，主機本身仍是 RUNNING。

ssh-keygen 的 -N '' 讓私鑰不設保護密碼（passphrase），重建腳本可以不經互動使用它；代價是拿到這個私鑰檔的人就連得上這台主機的序列主控台。這個代價跟上面「連線只在排查時存在」一起看：連線平時不存在，私鑰外洩時，拿到的人還要等下一次有人建連線、而且要在刪掉之前用它，能用的時間窗只剩排查那一段；連線一直留著的話，同一把沒有保護密碼的私鑰隨時都連得上。檔案仍然只給自己讀（ssh-keygen 產生的私鑰權限是 600）。設了保護密碼的話，每次連線要輸入它，或先把私鑰交給 ssh-agent，這次沒有比較這種做法。

官方的連線字串是一條 ssh 指令，外面再包一層 ssh 當跳板，形狀是 ssh -o ProxyCommand='ssh -W %h:%p -p 443 <連線的 OCID>@instance-console.<區域>.oci.oraclecloud.com' <主機的 OCID>。ProxyCommand 讓 ssh 在本機執行一條任意的指令，把它的輸入輸出當成連線；ProxyJump 由 ssh 自己經由跳板轉送連線，不在本機執行別的指令，效果相同。ProxyJump 這一欄只接受跳板的使用者、主機與 port，有人改寫這一欄時，改得到的只有跳板的位址；ProxyCommand 那一欄被改寫時，換上的是會在本機執行的指令。改寫成 ProxyJump 時：跳板主機是 instance-console.<區域>.oci.oraclecloud.com 的 443 port，使用者名稱是連線的 OCID；目的地的「主機名稱」是主機的 OCID，使用者名稱同樣是連線的 OCID。

 1# ssh-console.conf
 2Host verify-console-gw
 3  HostName instance-console.<區域>.oci.oraclecloud.com
 4  Port 443
 5  User <連線的 OCID>
 6  IdentityFile <序列主控台私鑰的路徑>
 7  IdentitiesOnly yes
 8  UserKnownHostsFile <序列主控台專用的 known_hosts 路徑>
 9  StrictHostKeyChecking accept-new
10  HostKeyAlgorithms +ssh-rsa
11  PubkeyAcceptedAlgorithms +ssh-rsa
12
13Host verify-console
14  HostName <主機的 OCID>
15  User <連線的 OCID>
16  ProxyJump verify-console-gw
17  IdentityFile <序列主控台私鑰的路徑>
18  IdentitiesOnly yes
19  UserKnownHostsFile <序列主控台專用的 known_hosts 路徑>
20  StrictHostKeyChecking accept-new
21  HostKeyAlgorithms +ssh-rsa
22  PubkeyAcceptedAlgorithms +ssh-rsa

1# -tt 讓 ssh 配一個終端機，序列埠的輸出才會照原樣顯示；離開時先按 Enter，再輸入 ~.
2ssh -tt -F ssh-console.conf verify-console

HostKeyAlgorithms +ssh-rsa 與 PubkeyAcceptedAlgorithms +ssh-rsa 兩行是預防性的：連線用 RSA 金鑰，新版 OpenSSH 預設不接受 ssh-rsa 簽章，這次沒有比較拿掉這兩行的結果。

連上之後先印出一段 Oracle Cloud 的說明，接著是主機目前的序列埠輸出。這次連著序列主控台讓主機重開機（在另一個終端機經由 Bastion 執行 sudo systemctl reboot），依序看到關機時 systemd 停止各個 unit、reboot: Restarting system、韌體的 Oracle AAVMF Version: 20260902 與載入的 UEFI 模組、核心的 Linux version 6.17.0-…-oracle，核心開始開機之後約 27 秒在 ttyAMA0 印出 Ubuntu 24.04.5 LTS verify-ubuntu ttyAMA0 與登入提示。只看開機卡在哪一步（核心、檔案系統、cloud-init）時，不必登入就看得到。

登入作業系統要一個設了密碼的使用者。這台主機的 ubuntu 帳號，passwd -S ubuntu 印出的狀態是 L（密碼鎖定），這次也沒有替任何使用者設密碼，所以登入那一步沒有做。

序列主控台的其他做法：在序列主控台登入作業系統、console history、Cloud Shell 與 VNC

• 事先設一個救援帳號的密碼：序列主控台出現登入提示時就能登入，sshd 壞掉時從這裡修。代價是主機多了一個密碼登入的帳號，要同時確認 sshd 不接受密碼登入（sshd -T 印 passwordauthentication no），密碼只在序列主控台上有效。GCP 上照這個做法實際登入過，步驟在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄：盤點、救援入口、IAP 規則與 IAM、停用舊規則驗證、OS Login 啟用與移除外部 IP〈準備救援入口：Serial Console 與本機救援帳號〉；三家業者的條件比較在維護篇〈會老化的軟體：各條更新管道與更新後的重開機〉。
• 只讀開機輸出的快照（console history）：oci compute console-history capture 擷取一份開機輸出的唯讀快照，不必建連線、不必產生 RSA 金鑰，也不能輸入；只要知道開機停在哪一步、或讀 host key 的指紋時夠用。建主機那篇〈結果：停在 CREATING 約 15 分鐘後轉成 DELETED〉用過這兩條指令。
• 從網頁主控台的 Cloud Shell 連：網頁主控台的主機頁面有「Launch Cloud Shell connection」，在瀏覽器裡開連線，不必在本機產生金鑰與設定檔（依 Oracle Cloud 文件〈Instance Console Connections〉，沒有實跑）。
• VNC 連線：同一個序列主控台連線另有 VNC 的連線字串，看的是圖形畫面，Linux 伺服器映像檔沒有圖形介面時跟序列埠看到的相同（依同一份文件，沒有實跑）。

被回收之後的重建：怎麼發現、留下與消失的資源、重建腳本

Always Free 的主機在連續 7 天內 CPU 使用率（取第 95 百分位）、網路使用率、記憶體使用率（只算 A1）三項都低於 20% 時，Oracle 可能回收它，規則與官方沒寫的部分在 Oracle Cloud 的帳號結構與 home region：tenancy、Always Free 的範圍與主控台登入欄位（下文稱「帳號篇」）〈Always Free 的額度與它綁在 home region 上的範圍〉。這台主機平常沒有負載，三項都落在條件裡；官方沒有寫這條規則對付費帳戶適不適用，這個 tenancy 已經是付費帳戶，所以無法確定這台是否會被回收。官方也沒有寫回收之後主機是停止還是刪除、會不會通知，所以重建的做法要兩種情形都涵蓋。

這次沒有做回收發生之前的對策，只準備了回收之後的重建。事前的對策有三種，這次都沒有實作：

• 維持負載：讓三項使用率之一一直高於 20%，主機就不落在回收條件裡。官方條款怎麼看待專門為了避開回收而製造的負載，這次沒有查證。
• 用 Events 或 Monitoring 告警：主機狀態改變時通知自己，回收發生的當下就知道。回收是否發出可以訂閱的事件，這次沒有查證。
• 定期備份開機磁碟：回收之後可以從備份還原，裝過的更新與設定都在。暫停、停止、終止主機各自會留下哪些資源，比較見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停時保留的範圍：只停服務、停止主機、終止主機、全部刪除〉；那一篇的〈恢復上線前要重新確認的漂移〉另外寫了主機不是照計畫暫停時（被閒置回收這類）要拿什麼當比對的基準。

發現主機不見了：經由 Bastion 登入失敗時（port forwarding session 建不出來、或 ssh 逾時），先查主機的狀態：

1oci compute instance get --instance-id <主機的 OCID> --query 'data."lifecycle-state"' --raw-output
2oci compute instance list -c <compartment 的 OCID> --display-name verify-ubuntu \
3  --query 'data[].{id:id,state:"lifecycle-state"}'

• 印 RUNNING：主機還在，問題在 Bastion、session 過期或開發機的 IP 換了（Bastion 的 client CIDR）。
• 印 STOPPED：主機被停止，開機磁碟、VNIC 與私有 IP 都還在，啟動之後回到 RUNNING；啟動也可能失敗，例如 A1 容量不足時（推論，這次沒有遇到）。
• 印 TERMINATED、或 get 回 404、list 找不到：主機被刪除，要重建。開機磁碟是否一起刪掉，官方沒有寫，到 Block Storage → Boot Volumes 查。舊磁碟還在時有兩種處理：拿它重建主機（oci compute instance launch 以 --source-boot-volume-id <開機磁碟的 OCID> 代替 --image-id，沒有實跑），裝過的更新與設定都還在；或刪掉它，釋放它佔的區塊磁碟額度。主機終止時開機磁碟的預設去留見 磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留〈刪除（終止）主機時開機磁碟的預設去留〉。

兩種情形各自留下與消失的資源。格內寫「實跑」的是主動操作時看到的，不是回收：停止那一欄的是 2026-10-27 主動停止 verify-ubuntu 再啟動時看到的，刪除那一欄的是主動終止 verify-ubuntu-rebuild 時看到的。格內沒寫「實跑」的，停止那一欄依停止主機的機制推論，刪除那一欄依終止主機的機制推論。回收實際做的是停止還是刪除，這次沒有遇到：

重建腳本：下面這支腳本把「停止就啟動、不見就重建」與之後要重新接上的每一項資源與設定寫在一起。每一步先查後建，重跑不會重複建立；例外是 port forwarding session，它最長 1 小時就失效，所以每次都新建一個。每一步至少印一行「已存在」「新建」「啟動」「重送」或「改寫」；任何一條 oci 指令失敗，腳本就停下來，印出那條指令寫在 stderr 的內容，不會把失敗當成「查無結果」往下走。它的每一個建立指令都是〈建 Ubuntu 24.04 主機與經由 port forwarding 登入〉與〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉兩節實跑過的那一條，先查後建與錯誤處理的部分是新加的。

這支腳本改過三個版本，雲端實跑與測試各自用的是其中一版：

• 沒有等待迴圈的版本：沒有 wait_state，也沒有等待 VNIC 的迴圈。
• 加上等待迴圈的版本：加上 wait_state 與等待 VNIC 的迴圈。
• 現在這一版：下面這一版。在加上等待迴圈的版本之外，加了依主機狀態分支、重送迴圈的改寫（只重送 500 與 429）、依主機是否為同一台決定 known_hosts 的去留、路由目的地改讀 ids.env 的 SGCIDR，以及每一條 oci 失敗就停下來的錯誤處理（含路由表裡有其他規則時停下來、NAT gateway 與 NSG 已存在時也記進 ids.env）。2026-10-27 上午另外加了指定開機磁碟大小的 BOOT_GB，只動到建立請求那一行（加上 BOOT_ARGS 的展開）、開頭變數區組 BOOT_ARGS 的一行，以及檔頭的用法註解（改寫一行、加兩行；單位的說明是實跑之後才補上的，執行的程式碼沒有變）；當天凌晨 STOPPED、STOPPING、STARTING 那幾次跑的是加 BOOT_GB 之前的版本，那幾條路徑不經過建立請求，下表一律算在現在這一版。

雲端實跑是 2026-10-27 在同一個 tenancy 上跑的；假的 oci 是一支依劇本回傳主機狀態與建立請求回應、也能讓單一種呼叫失敗的指令，搭配一支不等待、只記下秒數的假 sleep。兩者的結果都在腳本之後。序列主控台連線的重建腳本也列在同一張表；它在雲端跑的是訊息還寫「主控台連線」、還沒有錯誤處理與換金鑰處理的前一版：

  1#!/bin/bash
  2# 主機被回收、停止或刪除之後，把 verify-ubuntu 這一組恢復成可以登入、連得到套件來源的狀態：
  3#   主機（不存在就建、停止就啟動）→ 私有 IP 與 VNIC → NAT gateway → 私有子網路路由的 0.0.0.0/0 規則
  4#   → 出站 NSG 與它的兩條規則 → NSG 掛到這台的 VNIC → port forwarding session → ssh 設定與 known_hosts。
  5# 每一步先查後建，重跑不會重複建立（例外是 port forwarding session，每次都新建一個）；
  6#   每一步至少印一行「已存在」「新建」「啟動」「重送」或「改寫」。任何一條 oci 失敗就停下來，印出它的 stderr。
  7# 用法：./rebuild-ubuntu.sh [主機名稱]（預設 verify-ubuntu）。新建主機時，環境變數 BOOT_GB 指定開機磁碟大小，
  8#   單位跟 boot-volume list 的 size-in-gbs 相同（60 建出 60 GiB）；不給就用映像檔的預設大小
  9#   （Ubuntu 24.04 的 size-in-gbs 是 47）。需要 ids.env 的 C（compartment）、V（VCN）、
 10#   SG（service gateway）、SGCIDR（service gateway 路由規則的目的地名稱）、RT（私有子網路的路由表）、
 11#   SN（私有子網路）、B（Bastion）。
 12# 整個 VCN 共用的 NAT gateway 與 NSG 記在 ids.env；只屬於這一台的值（主機、session）記在 host-<名稱>.env，
 13#   ssh 設定與 known_hosts 也依名稱各一份，所以給不同名稱重跑不會蓋掉另一台的紀錄。
 14# 結束碼：0 完成；2 登入過期、查不到映像檔、主機停在無法處理的狀態或其他無法繼續的錯誤；
 15#   3 建立主機的回應讀不出回應碼（請求可能已經成功），重跑之前先用 instance list 確認沒有同名主機；
 16#   4 建立主機的回應碼不是 500、429、401（400 參數錯誤這類），照印出的訊息改好再跑。
 17set -uo pipefail
 18# OCI CLI 是 Python 程式；PYTHONWARNINGS=ignore 關掉 Python 直譯器印的警告，不讓警告行混進要解析的輸出
 19export OCI_CLI_AUTH=security_token PYTHONWARNINGS=ignore
 20D=$(cd "$(dirname "$0")" && pwd)
 21source "$D/ids.env"
 22NAME=${1:-verify-ubuntu}
 23AD="<可用網域>"
 24KEY="$D/verify-a1-key.pub"
 25NAT_NAME=verify-nat
 26NSG_NAME=verify-ubuntu-egress
 27HOSTENV="$D/host-${NAME}.env"
 28CONF="$D/ssh-${NAME}.conf"
 29KNOWN="$D/known_hosts_${NAME}"
 30BOOT_ARGS=(); [[ -n "${BOOT_GB:-}" ]] && BOOT_ARGS=(--boot-volume-size-in-gbs "$BOOT_GB")
 31NEW=0
 32ERR=$(mktemp "${TMPDIR:-/tmp}/rebuild-ubuntu.XXXXXX"); trap 'rm -f "$ERR"' EXIT
 33ts() { date +%m-%d\ %H:%M:%S; }
 34say() { echo "$(ts) [$1] $2"; }
 35die() { echo "$(ts) [錯誤] $1" >&2; exit "${2:-2}"; }
 36# 查詢與寫入用的包裝：stderr 存進 $ERR 那個暫存檔，濾掉兩種不是結果的提示行（Python 的 SyntaxWarning，
 37#   與 CLI 建議改用 `oci -i` 的 Interactive mode 那一行），結束碼照 oci 自己的回傳。
 38#   CLI 的 --query 結果是空的時候 stdout 什麼都不印，所以空字串要搭配結束碼 0 才代表查無結果
 39q() {
 40  local out rc
 41  out=$(oci "$@" 2>"$ERR"); rc=$?
 42  [[ -n "$out" ]] && grep -v -e SyntaxWarning -e 'Interactive mode' <<<"$out"
 43  return $rc
 44}
 45# q 失敗時停下來，印出 oci 寫在 stderr 的內容
 46fail() { die "${1}失敗：$(tr '\n' ' ' < "$ERR")"; }
 47# 把「鍵=值」記進 ids.env；已經有同樣的一行就不重複寫
 48record() { grep -qx "$1=$2" "$D/ids.env" || echo "$1=$2" >> "$D/ids.env"; }
 49# instance get 沒有 --wait-for-state，所以自己每 10 秒查一次狀態，最多等 900 秒
 50wait_state() {
 51  local want=$1 i cur
 52  for ((i = 0; i < 90; i++)); do
 53    cur=$(q compute instance get --instance-id "$IID" --query 'data."lifecycle-state"' --raw-output) || fail "查主機狀態"
 54    [[ "$cur" == "$want" ]] && return 0
 55    sleep 10
 56  done
 57  die "主機等了 900 秒仍是 ${cur:-查不到}，沒有變成 $want"
 58}
 59
 60# 0. 登入：session token 過期時後面每一條都會失敗，先擋下來
 61oci session validate --profile DEFAULT >/dev/null 2>&1 \
 62  || die "CLI session 過期，先跑 oci session authenticate --region <區域> --profile-name DEFAULT"
 63
 64# 1. 主機：依名稱找還沒終止的那一台，依狀態決定跳過、啟動或建立
 65LAST_IID=$(grep '^IID=' "$HOSTENV" 2>/dev/null | tail -1 | cut -d= -f2)
 66IID=$(q compute instance list -c "$C" --display-name "$NAME" \
 67  --query "data[?\"lifecycle-state\"!='TERMINATED'] | [0].id" --raw-output) || fail "查同名主機"
 68STATE=""
 69# 查詢成功而且結果是空的，才代表沒有同名主機；查得到主機而狀態讀不出來時，不當成「不存在」去建第二台
 70if [[ -n "$IID" ]]; then
 71  [[ "$IID" == ocid1.instance* ]] || die "查同名主機回了不是主機 OCID 的值：$IID"
 72  STATE=$(q compute instance get --instance-id "$IID" --query 'data."lifecycle-state"' --raw-output) || fail "查主機狀態"
 73  [[ -z "$STATE" ]] && die "查得到主機 ${IID}，卻讀不出它的狀態"
 74fi
 75case "$STATE" in
 76  RUNNING) say 已存在 "主機 ${NAME}（RUNNING）" ;;
 77  STOPPED)
 78    q compute instance action --instance-id "$IID" --action START --wait-for-state RUNNING --max-wait-seconds 900 >/dev/null \
 79      || fail "啟動主機（STOPPED → RUNNING）"
 80    say 啟動 "主機 ${NAME}（STOPPED → RUNNING）" ;;
 81  STARTING|PROVISIONING)
 82    wait_state RUNNING
 83    say 已存在 "主機 ${NAME}（等到 RUNNING）" ;;
 84  STOPPING)
 85    wait_state STOPPED
 86    q compute instance action --instance-id "$IID" --action START --wait-for-state RUNNING --max-wait-seconds 900 >/dev/null \
 87      || fail "啟動主機（STOPPING → RUNNING）"
 88    say 啟動 "主機 ${NAME}（STOPPING → RUNNING）" ;;
 89  "")
 90    # 找不到還沒終止的同名主機：只有這種情形才建立
 91    IMG=$(q compute image list -c "$C" --operating-system "Canonical Ubuntu" --operating-system-version "24.04" \
 92      --shape VM.Standard.A1.Flex --sort-by TIMECREATED --sort-order DESC --query 'data[0].id' --raw-output) || fail "查映像檔"
 93    [[ "$IMG" == ocid1.image* ]] || die "查不到 Ubuntu 24.04 的 A1 映像檔：${IMG:-查詢結果是空的}"
 94    IMGNAME=$(q compute image get --image-id "$IMG" --query 'data."display-name"' --raw-output) || fail "查映像檔名稱"
 95    say 新建 "主機 ${NAME}，映像檔 $IMGNAME"
 96    # 容量不足時重送：間隔從 120 秒起，429 加倍（上限 600），其他回應每次縮 10 秒、最低 60 秒，±15 秒抖動
 97    back=120 n=0 last_refresh=0                     # 0：開跑時先延長一次 token
 98    while :; do
 99      n=$((n+1))
100      # session token 一小時過期，每 30 分鐘（1800 秒）延長一次，重送跑得再久也不會在中途過期
101      if (( $(date +%s) - last_refresh >= 1800 )); then
102        oci session refresh --profile DEFAULT >/dev/null 2>&1 || die "token refresh 失敗，重跑 oci session authenticate"
103        last_refresh=$(date +%s)
104      fi
105      out=$(oci --no-retry compute instance launch -c "$C" --availability-domain "$AD" --display-name "$NAME" \
106        --shape VM.Standard.A1.Flex --shape-config '{"ocpus":1,"memoryInGBs":6}' \
107        --image-id "$IMG" --subnet-id "$SN" --assign-public-ip false ${BOOT_ARGS[@]+"${BOOT_ARGS[@]}"} \
108        --ssh-authorized-keys-file "$KEY" \
109        --agent-config '{"pluginsConfig":[{"name":"Bastion","desiredState":"ENABLED"}]}' \
110        --is-pv-encryption-in-transit-enabled true \
111        --instance-options '{"areLegacyImdsEndpointsDisabled":true}' \
112        --query data.id --raw-output 2>&1)
113      # 輸出前面可能夾著 CLI 的警告，所以在整段輸出裡找 OCID，不只比對開頭
114      id=$(grep -o 'ocid1\.instance\.[^" ]*' <<<"$out" | head -1)
115      if [[ -n "$id" ]]; then IID=$id; break; fi
116      status=$(grep -o '"status": [0-9]*' <<<"$out" | head -1 | grep -o '[0-9]*$')
117      # 設定檔錯誤、網路中斷這類失敗沒有回應碼；請求也可能已經在 Oracle 那一端成功，所以不重送
118      [[ -z "$status" ]] && die "讀不出回應碼，先用 oci compute instance list -c <compartment> --display-name $NAME 確認沒有同名主機再重跑：$out" 3
119      [[ "$status" == 401 ]] && die "401，重跑 oci session authenticate"
120      # 只有 500（容量不足）與 429（限流）等一段時間可能變好；400 這類代表請求本身有誤，重送也是同一個結果
121      [[ "$status" != 500 && "$status" != 429 ]] \
122        && die "建立請求回 ${status}，不重送：$(grep -o '"message": "[^"]*"' <<<"$out" | head -1)" 4
123      if [[ "$status" == 429 ]]; then back=$(( back * 2 > 600 ? 600 : back * 2 )); else back=$(( back - 10 < 60 ? 60 : back - 10 )); fi
124      wait=$(( back - 15 + RANDOM % 31 ))
125      say 重送 "第 $n 次 ${status}：$(grep -o '"message": "[^"]*"' <<<"$out" | head -1)，${wait} 秒後再送"
126      sleep "$wait"
127    done
128    echo "IID=$IID" >> "$HOSTENV"
129    # 新主機的 host key 是新的，舊紀錄留著的話 ssh 會因為 host key 不符而拒絕連線
130    : > "$KNOWN"; NEW=1
131    wait_state RUNNING
132    say 新建 "主機 $NAME 已 RUNNING（第 $n 次送出成功）" ;;
133  *)
134    # TERMINATING、MOVING、CREATING_IMAGE 這類狀態，或上面沒有列出的狀態：不猜下一步，停下來
135    die "主機 ${NAME} 的狀態是 ${STATE}，這支腳本不處理這個狀態；等它變成 RUNNING、STOPPED 或 TERMINATED 再重跑" ;;
136esac
137# 查到的主機跟 host-<名稱>.env 最後記下的不是同一台時（例如在別處重建過），舊的 host key 紀錄對不上，也清掉
138if [[ "$NEW" != 1 && "$IID" != "$LAST_IID" ]]; then
139  echo "IID=$IID" >> "$HOSTENV"; : > "$KNOWN"; NEW=1
140fi
141
142# 2. 私有 IP 與 VNIC：重建之後兩者都會換
143# 剛 RUNNING 的主機，VNIC 的掛載紀錄可能還沒出現，最多等 120 秒
144for ((i = 0; i < 12; i++)); do
145  VNIC=$(q compute instance list-vnics --instance-id "$IID" --query 'data[0].id' --raw-output) || fail "查 VNIC"
146  [[ "$VNIC" == ocid1.vnic* ]] && break
147  sleep 10
148done
149[[ "$VNIC" == ocid1.vnic* ]] || die "等了 120 秒仍查不到主機的 VNIC：$VNIC"
150IP=$(q compute instance list-vnics --instance-id "$IID" --query 'data[0]."private-ip"' --raw-output) || fail "查私有 IP"
151say 已存在 "VNIC 與私有 IP $IP"
152
153# 3. NAT gateway：VCN 裡同名而 AVAILABLE 的那一個；已存在或新建都記進 ids.env
154NAT=$(q network nat-gateway list -c "$C" --vcn-id "$V" \
155  --query "data[?\"display-name\"=='$NAT_NAME' && \"lifecycle-state\"=='AVAILABLE'] | [0].id" --raw-output) || fail "查 NAT gateway"
156if [[ "$NAT" == ocid1.natgateway* ]]; then say 已存在 "NAT gateway $NAT_NAME"
157else
158  NAT=$(q network nat-gateway create -c "$C" --vcn-id "$V" --display-name "$NAT_NAME" \
159    --wait-for-state AVAILABLE --query data.id --raw-output) || fail "建 NAT gateway"
160  [[ "$NAT" == ocid1.natgateway* ]] || die "建不出 NAT gateway：$NAT"
161  say 新建 "NAT gateway $NAT_NAME"
162fi
163record NAT "$NAT"
164
165# 4. 路由：私有子網路的路由表要有 service gateway 那一條與 0.0.0.0/0 → NAT；update 是整份替換，所以兩條一起寫。
166#   路由表裡還有這兩條以外的規則時，改寫會把它們刪掉，所以先數，有就停下來
167OTHER=$(q network route-table get --rt-id "$RT" \
168  --query "data.\"route-rules\"[?destination!='0.0.0.0/0' && destination!='$SGCIDR'].destination" --raw-output) || fail "讀路由表"
169OTHER=$(tr -d '[]" \n' <<<"$OTHER")
170[[ -n "$OTHER" ]] && die "路由表裡有 0.0.0.0/0 與 service gateway 以外的規則（目的地 ${OTHER}），先把它們加進這一步的 --route-rules 再跑"
171HAS=$(q network route-table get --rt-id "$RT" \
172  --query "data.\"route-rules\"[?destination=='0.0.0.0/0' && \"network-entity-id\"=='$NAT'] | length(@)" --raw-output) || fail "讀路由表"
173if [[ "$HAS" == 1 ]]; then say 已存在 "路由 0.0.0.0/0 → $NAT_NAME"
174else
175  q network route-table update --rt-id "$RT" --force --wait-for-state AVAILABLE --route-rules "[
176 {\"destination\":\"$SGCIDR\",\"destinationType\":\"SERVICE_CIDR_BLOCK\",\"networkEntityId\":\"$SG\"},
177 {\"destination\":\"0.0.0.0/0\",\"destinationType\":\"CIDR_BLOCK\",\"networkEntityId\":\"$NAT\"}]" >/dev/null \
178    || fail "改寫路由表"
179  say 改寫 "路由表加上 0.0.0.0/0 → ${NAT_NAME}（service gateway 那一條保留）"
180fi
181
182# 5. 出站 NSG：只有出站 TCP 80、443 兩條規則；已存在或新建都記進 ids.env
183NSGU=$(q network nsg list -c "$C" --vcn-id "$V" \
184  --query "data[?\"display-name\"=='$NSG_NAME' && \"lifecycle-state\"=='AVAILABLE'] | [0].id" --raw-output) || fail "查 NSG"
185if [[ "$NSGU" == ocid1.networksecuritygroup* ]]; then say 已存在 "NSG $NSG_NAME"
186else
187  NSGU=$(q network nsg create -c "$C" --vcn-id "$V" --display-name "$NSG_NAME" \
188    --wait-for-state AVAILABLE --query data.id --raw-output) || fail "建 NSG"
189  [[ "$NSGU" == ocid1.networksecuritygroup* ]] || die "建不出 NSG：$NSGU"
190  say 新建 "NSG $NSG_NAME"
191fi
192record NSGU "$NSGU"
193for port in 80 443; do
194  N=$(q network nsg rules list --nsg-id "$NSGU" \
195    --query "data[?direction=='EGRESS' && \"tcp-options\".\"destination-port-range\".min==\`$port\`] | length(@)" --raw-output) \
196    || fail "讀 NSG 的規則"
197  if [[ "$N" -ge 1 ]]; then say 已存在 "NSG 出站 TCP $port"
198  else
199    q network nsg rules add --nsg-id "$NSGU" --security-rules "[{\"direction\":\"EGRESS\",\"protocol\":\"6\",
200\"destination\":\"0.0.0.0/0\",\"destinationType\":\"CIDR_BLOCK\",\"isStateless\":false,
201\"tcpOptions\":{\"destinationPortRange\":{\"min\":$port,\"max\":$port}}}]" >/dev/null \
202      || fail "加 NSG 出站 TCP $port 的規則"
203    say 新建 "NSG 出站 TCP $port"
204  fi
205done
206
207# 6. 把 NSG 掛到這台主機目前的 VNIC；--nsg-ids 是整份替換，所以保留 VNIC 原本掛著的其他 NSG
208CUR=$(q network vnic get --vnic-id "$VNIC" --query 'data."nsg-ids"' --raw-output) || fail "讀 VNIC 的 NSG 清單"
209CUR=$(tr -d '[]" \n' <<<"$CUR")
210if [[ ",$CUR," == *",$NSGU,"* ]]; then say 已存在 "NSG 掛在 VNIC 上"
211else
212  LIST=$(echo "$CUR,$NSGU" | sed 's/^,//' | awk -F, '{for(i=1;i<=NF;i++) printf "%s\"%s\"", (i>1?",":""), $i}')
213  q network vnic update --vnic-id "$VNIC" --nsg-ids "[$LIST]" --force >/dev/null || fail "改寫 VNIC 的 NSG 清單"
214  say 改寫 "VNIC 的 NSG 清單加上 $NSG_NAME"
215fi
216
217# 7. port forwarding session：指向這台現在的私有 IP 與 22 port；session 最長 1 小時，每次重跑都開新的
218SPFU=$(q bastion session create-port-forwarding --bastion-id "$B" \
219  --target-private-ip "$IP" --target-port 22 \
220  --ssh-public-key-file "$D/session_key.pub" --session-ttl 3600 --display-name "$NAME-pf" \
221  --wait-for-state SUCCEEDED --wait-for-state FAILED --max-wait-seconds 600 \
222  --query 'data.resources[0].identifier' --raw-output | tail -1) || fail "建 port forwarding session"
223[[ "$SPFU" == ocid1.bastionsession* ]] || die "建不出 port forwarding session：$SPFU"
224echo "SPF=$SPFU" >> "$HOSTENV"
225say 新建 "port forwarding session（1 小時後失效）"
226
227# 8. ssh 設定：整份由範本產生；known_hosts 只在主機那一步（第 1 步）換了一台主機時清空（新建，
228#   或查到的主機跟 host-<名稱>.env 最後記下的不同），同一台主機還在時保留
229cat > "$CONF" <<EOF
230# 由 rebuild-ubuntu.sh 產生：經 Bastion 的 port forwarding session 登入 $NAME
231Host ${NAME}-bastion
232  HostName host.bastion.<區域>.oci.oraclecloud.com
233  User $SPFU
234  IdentityFile $D/session_key
235  IdentitiesOnly yes
236
237Host $NAME
238  HostName $IP
239  User ubuntu
240  IdentityFile $D/verify-a1-key
241  IdentitiesOnly yes
242  ProxyJump ${NAME}-bastion
243  UserKnownHostsFile $KNOWN
244  StrictHostKeyChecking accept-new
245EOF
246if [[ "$NEW" == 1 ]]; then say 改寫 "ssh 設定 ${CONF}；known_hosts 已清空（換了一台主機）"
247else say 改寫 "ssh 設定 ${CONF}；known_hosts 保留"; fi
248echo "下一步：ssh -F $CONF $NAME 'cloud-init status --wait; uptime'"

腳本放在跟 ids.env、金鑰同一個目錄執行。要依環境換或確認的位置：

• <可用網域>（oci iam availability-domain list 查）與兩處 <區域>（查法在〈前置條件：沿用 Oracle Cloud 建立主機實測紀錄的網路、Bastion 與金鑰〉的 CLI 登入那一項）。
• --profile DEFAULT：oci session authenticate 時取的 profile 名稱，另外取了名字就兩處都換。
• NAT_NAME 與 NSG_NAME：要跟〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉建 NAT gateway 與 NSG 時用的名稱相同。名稱不同的話，腳本依名稱找不到既有的那一份，會再建一份 NAT gateway 與 NSG。
• 規格與映像檔：--shape-config 的 1 OCPU、6 GB，以及查映像檔的 "Canonical Ubuntu"、"24.04"、VM.Standard.A1.Flex 三個篩選字串；換成別的作業系統時，產生 ssh 設定那一步的 User ubuntu 也要跟著換（Oracle Linux 是 opc）。
• BOOT_GB：只在新建主機時有作用，寫在指令前面（BOOT_GB=60 ./rebuild-ubuntu.sh <主機名稱>）。不給時開機磁碟是映像檔的預設大小，Ubuntu 24.04 扣區塊磁碟額度 47 GB；給了之後新主機的開機磁碟就是這個大小，60 實際建出 60 GiB（lsblk -b 讀到 64424509440 位元組，實跑）。--boot-volume-size-in-gbs、size-in-gbs 與額度用量寫的 GB，數值上都是 GiB（帳務明細與價目表的「GB」是哪一種沒有查）；映像檔預設的「50 GB」是十進位的 50.0 GB，也就是 46.6 GiB、size-in-gbs 47，所以 BOOT_GB=50 已經比預設大、扣 50（從 60 的實跑推論，50 沒有試）。主控台建立頁自訂大小的下限是 50 GB，出處見 磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留〈開機磁碟的大小〉；給小於 50 的值時 CLI 回什麼，這次沒有試。加大之後，Ubuntu 的根目錄在開機時自動延伸到整顆磁碟（df -h / 讀到 58G）；換成別的映像檔時，檔案系統可能要另外延伸（Oracle Linux 的 oci-growfs 這類工具），否則多出的容量用不到（沒有實跑）。加大之前先讀免費額度還剩多少（total-free-storage-gb-regional 的 available，額度算的是開機磁碟與區塊磁碟的合計，指令在〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉）：新磁碟比 available 大時，這一顆放不進剩餘額度，整顆不算免費額度。
• --session-ttl 3600：不能大於 Bastion 的 session 上限，查法在〈建 Ubuntu 24.04 主機與經由 port forwarding 登入〉。
• 金鑰的檔名：verify-a1-key（登入主機）與 session_key（Bastion session）；序列主控台連線的重建腳本另外用 console_rsa，不存在時以 RSA 3072 位元（-b 3072）產生。
• ids.env 裡七個鍵的值。

ids.env 的鍵與查法在〈前置條件：沿用 Oracle Cloud 建立主機實測紀錄的網路、Bastion 與金鑰〉的表，格式是一行一個 鍵=值（例如 C=<compartment 的 OCID>），腳本開頭 source 它。NAT gateway 與 NSG 不論是已存在還是腳本新建的，腳本都把它們的 OCID 以 NAT= 與 NSGU= 記進檔尾，已經有同樣的一行就不重複寫，所以跑過一次之後，〈刪除這組資源的順序〉要填的值都在這個檔裡。host-<名稱>.env 是這一台主機的紀錄：腳本每次新建主機或 session 就在檔尾多加一行 IID= 或 SPF=，同一個鍵出現好幾次時，最後一行才是現在有效的值。腳本只讀它最後一行的 IID=，拿來跟這次查到的主機比對：不是同一台時（新建，或主機在別處重建過），舊的 host key 紀錄對不上，腳本就清空 known_hosts 並補記這次的 IID=。檔案裡還沒有任何一行 IID= 時（主機不是重建腳本建的，例如照〈建 Ubuntu 24.04 主機與經由 port forwarding 登入〉手動建的，或是腳本較早的版本建的），腳本拿空字串比對，同樣判成不是同一台、清空一次。

兩支腳本都假設 CLI 用 session token 登入（〈前置條件：沿用 Oracle Cloud 建立主機實測紀錄的網路、Bastion 與金鑰〉的 CLI 登入那一項）。改用 API 簽章金鑰的話，拿掉三處：export 那一行的 OCI_CLI_AUTH=security_token、開頭的 oci session validate 檢查，以及重建腳本重送迴圈裡每 1800 秒跑一次的 oci session refresh；拿掉之後 CLI 改用設定檔裡的 API 簽章金鑰（沒有實跑）。

重建腳本改寫路由表時，--route-rules 只寫 service gateway 與 NAT gateway 兩條，前提是這張路由表原本只有 service gateway 那一條（加上之前跑腳本時加進去的 0.0.0.0/0 那一條）。改寫之前，腳本先列出這兩條以外的規則，列得出任何一條就停下來，印出那幾條的目的地：route-table update 是整份替換，沒寫進 --route-rules 的規則會被刪掉。這時把那幾條規則加進腳本裡的 --route-rules，再重跑。

輸出的讀法：主機那一步（第 1 步）依查到的狀態印不同的行：

• 主機已經是 RUNNING：印「已存在」。
• 主機被停止（STOPPED）：印「啟動」（STOPPED → RUNNING）。STOPPING 時先等到 STOPPED 再啟動，STARTING、PROVISIONING 時等到 RUNNING 再印「已存在」。啟動失敗時（例如容量不足，推論）印出 instance action 的錯誤並以 2 結束。STOPPED、STOPPING、STARTING、PROVISIONING 四條在雲端跑過（結果在下面「在雲端實跑的結果」的「名稱不存在、同時另一份腳本碰到 PROVISIONING」與「主機 STOPPED、STOPPING、STARTING」兩項）；啟動失敗只用假的 oci 測過。
• 找不到還沒終止的同名主機：印「新建」與映像檔名稱，容量不足（500）或被限流（429）時中間會有幾行「重送」（例：[重送] 第 1 次 500："message": "Out of host capacity."，112 秒後再送，這一行出自假的 oci）。建立請求回 500、429、401 以外的回應碼時（例如 <可用網域> 沒換掉而回 400），腳本印出回應碼與 message 就以 4 結束，不重送：這類回應代表請求本身有誤，重送幾次都是同一個結果，照訊息改好參數再跑。
• 主機停在其他狀態（TERMINATING、MOVING、CREATING_IMAGE 這類）：腳本不猜下一步，印出狀態並以 2 結束，等它變成 RUNNING、STOPPED 或 TERMINATED 再重跑。

之後的各步，「已存在」代表那一項不必動，「新建」與「改寫」代表腳本這一次在雲端建了或改了資源：

• VNIC 與私有 IP（第 2 步）：一律印「已存在」與私有 IP；主機重建過時這個 IP 是新的。
• NAT gateway（第 3 步）與 NSG 和它的兩條規則（第 5 步）：VCN 裡已經有同名的就印「已存在」；只有第一次跑、或有人刪掉了它們時才印「新建」。
• 路由（第 4 步）：已經有 0.0.0.0/0 指向 NAT gateway 那一條就印「已存在」；印「改寫」代表路由表被整份替換成 service gateway 與 NAT gateway 兩條，也就是先前少了 0.0.0.0/0 那一條，或它指向別的出口。
• NSG 掛到 VNIC（第 6 步）：印「改寫」代表 VNIC 原本沒有掛這個 NSG，主機重建之後的新 VNIC 一定走這一條。
• port forwarding session（第 7 步）：每次都印「新建」。
• ssh 設定（第 8 步）：每次都印「改寫」，並註明 known_hosts 是保留還是清空；清空代表這次的主機跟 host-<名稱>.env 最後記下的不是同一台，或那個檔案還沒有記下任何一台（主機不是重建腳本建的；實跑結果在下面的 STOPPED 那一項）。

任何一步印「錯誤」時腳本以 2 結束（建立請求被拒的 4 在上一項），錯誤那一行寫出是哪一步；oci 失敗時，冒號後面接的是那條指令寫在 stderr 的內容。修好之後重跑整支腳本即可，前面已經完成的步驟會印「已存在」。例外是建立請求的回應讀不出回應碼（exit 3）：設定檔錯誤、網路中斷都會走到這裡，而網路中斷時請求可能已經在 Oracle 那一端成功，所以重跑之前先用 oci compute instance list -c <compartment 的 OCID> --display-name <主機名稱> 確認沒有還在的同名主機。

在雲端實跑的結果（「主機已經是 RUNNING，沒有等待迴圈的版本」與「名稱不存在，較早的兩個版本」兩項跑的是上面三個版本裡較早的兩個，其餘都是現在這一版；各項用的版本寫在項目裡）：

• NAT gateway 與 NSG 都不存在（現在這一版，2026-10-27 09:32，跑的是 ./rebuild-ubuntu.sh，不給名稱就是 verify-ubuntu；它的 NAT gateway 與 NSG 已在凌晨照〈刪除這組資源的順序〉刪掉）。exit 0，全程 32 秒。主機那一步印「已存在」（RUNNING），NAT gateway 印「新建」，路由印「改寫」（加上 0.0.0.0/0 → NAT gateway verify-nat，名稱是腳本的 NAT_NAME；保留 service gateway 那一條），NSG 與它的出站 TCP 80、443 兩條規則都印「新建」，掛 NSG 那一步印「改寫」；新的 NAT gateway 與 NSG 的 OCID 以新的一行接在 ids.env 檔尾。登入之後 apt-get update 下載 3982 kB，curl https://archive.ubuntu.com/ubuntu/ 回 200，出站恢復。從 NAT gateway 那一行到掛 NSG 那一行共 14 秒，NAT gateway 與 NSG 的 create 帶的 --wait-for-state AVAILABLE 各約 3 秒（從 log 的時間戳推論）。

• 名稱不存在、同時另一份腳本碰到 PROVISIONING（現在這一版，2026-10-27 09:33，接在上一項之後，所以 NAT gateway 與 NSG 已經存在）。先在背景跑一份新建主機的腳本（下面稱「新建的那一份」），本機另開一個 shell 迴圈查同名主機的狀態，查到 PROVISIONING 就對同一個名稱再跑一份（下面稱「建立中才開跑的那一份」）。這個迴圈是測試用的，不屬於重建腳本：

   1# 迴圈裡的 oci 跟重建腳本一樣用 session token 登入
   2export OCI_CLI_AUTH=security_token
   3# 新建的那一份：放到背景跑，開機磁碟 60 GB；APID 記下它的程序編號
   4BOOT_GB=60 ./rebuild-ubuntu.sh verify-ubuntu-60g > new.log 2>&1 &
   5APID=$!
   6# 新建的那一份還在跑時，每次查完等 3 秒再查（這次實際約 4 秒一次）；
   7# 查到 PROVISIONING 就跑建立中才開跑的那一份。新建的那一份提早結束（例如建立請求回 400）時迴圈跟著結束
   8while kill -0 "$APID" 2>/dev/null; do
   9  st=$(oci compute instance list -c <compartment 的 OCID> --display-name verify-ubuntu-60g \
  10    --query 'data[?"lifecycle-state"!=`TERMINATED`] | [0]."lifecycle-state"' --raw-output 2>/dev/null)
  11  [[ "$st" == PROVISIONING ]] && { ./rebuild-ubuntu.sh verify-ubuntu-60g > provisioning.log 2>&1; break; }
  12  sleep 3
  13done
  14wait "$APID"

  新建的那一份開跑後第 6 秒，迴圈還查不到主機；第 10 秒查到 PROVISIONING，建立中才開跑的那一份隨即開跑。這一台讓區塊磁碟的合計變成 201，60 GB 那一顆整顆不算免費額度（〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉的「合計超過 200 GB 時」），所以照做這個測試會多出一顆不在免費額度裡的磁碟；這台在帳務明細出現它的計費項目之後，於 2026-10-27 11:58 終止，開機磁碟一起刪除（work request 65 秒 SUCCEEDED），區塊磁碟的兩條用量都回到 141；帳務的結果在〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉的「合計超過 200 GB 時」。

  • 新建的那一份：建立請求第一次送出就成功，exit 0，全程 87 秒。從印出「新建」主機（送出建立請求之前）到印出「已 RUNNING」約 50 秒。建立請求不帶 --wait-for-state，這段時間由 wait_state 每 10 秒查一次狀態，所以它輪詢了好幾次，建立中才開跑的那一份的 wait_state 在同一段時間也一樣（從時間戳與腳本推論，腳本不記每一次查詢）。這兩份腳本的 wait_state 是它的輪詢第一次在雲端實際等待，先前幾次都在第一次查詢就拿到目標狀態。網路那幾步都印「已存在」，掛 NSG 那一步印「改寫」（新主機的 VNIC），port forwarding session 從上一行到印出「新建」17 秒，ssh 設定印「known_hosts 已清空（換了一台主機）」。
  • 建立中才開跑的那一份：查到主機是 PROVISIONING，走進 STARTING|PROVISIONING 那一條等到 RUNNING；它的 log 第一行（主機那一步）在新建的那一份印出「已 RUNNING」之後 4 秒印出「已存在」（等到 RUNNING），沒有再送建立請求，tenancy 裡只有一台 verify-ubuntu-60g。之後各步都印「已存在」，連掛 NSG 那一步也是（新建的那一份在 3 秒前掛上了），exit 0，全程 80 秒。建立中才開跑的那一份開跑時，新建的那一份已經把新主機的 IID= 寫進 host-verify-ubuntu-60g.env，所以建立中才開跑的那一份判成同一台，印「known_hosts 保留」（從它印「保留」、這個檔只有一行 IID=，以及腳本在開頭讀上一次的 IID 推得）。兩份腳本各建了一個 port forwarding session，host-verify-ubuntu-60g.env 因此有兩行 SPF=，ssh 設定是後寫的這一份。
  • 登入之後：照產生的 ssh 設定登入，cloud-init status --wait 正常結束（輸出沒有留下），apt-get update 照常連到套件來源；df -h / 印出根目錄 58G。
  • 兩份同時跑的邊界：這次只驗了後一份在 PROVISIONING 出現之後才開跑的情形。新建的那一份查到沒有同名主機之後、新主機在 instance list 查得到之前有一段空窗（這次迴圈在新建的那一份開跑後第 6 秒還查不到，空窗本身多長沒有量），後一份的查詢落在這段空窗時，結果是空的，會再送一次建立請求，建出第二台同名主機，A1 用量與開機磁碟額度都多扣一台主機的量。NAT gateway 與 NSG 是整個 VCN 共用、同樣依名稱先查後建：兩份腳本（名稱不同也一樣）在它們還不存在時同時跑，會各建一份，ids.env 記下兩行、source 時取後一行，路由表的「改寫」互相覆蓋，路由可能指向沒有記下的那一份。這兩種都是依腳本邏輯推論，沒有實跑；這次實跑時 NAT gateway 與 NSG 已經存在。所以同一個 VCN 一次只跑一份重建腳本。
  • 建立中的主機沒有變成 RUNNING：wait_state 只比對 RUNNING，建立失敗、主機從 PROVISIONING 變成 TERMINATED 時，兩份腳本都會等滿 900 秒，再以「沒有變成 RUNNING」結束，訊息裡的狀態是最後一次查到的值（依腳本邏輯推論，沒有實跑）。
  • 不給 BOOT_GB 的新建（現在這一版，2026-10-27 13:04 實跑）：不給 BOOT_GB 時 BOOT_ARGS 是空陣列，建立請求那一行展開空陣列的寫法先前只用假的 oci 與本機的 bash 3.2 測過（寫法的理由在下面「腳本裡幾處寫法的理由」的 BOOT_ARGS 那一項）。在 tenancy 裡已有三台 A1、免費區塊儲存扣了 141 的狀態下，用 env -u BOOT_GB /bin/bash ./rebuild-ubuntu.sh verify-ubuntu-nb 跑（env -u 確保 shell 裡沒有殘留的 BOOT_GB）：建立請求第一次送出就成功，從印出「新建」到「已 RUNNING」37 秒，exit 0，log 第一行到最後一行 68 秒；網路那幾步都印「已存在」，掛 NSG 那一步印「改寫」。登入之後 cloud-init status --wait 回 done，df -h / 的根目錄是 45G；oci bv boot-volume list 列出這顆開機磁碟的 size-in-gbs 是 47，免費區塊儲存的用量從 141 變成 188，跟手動照預設大小建的主機相同。這台主機之後拿來測付費磁碟的自動轉換（〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉），測完已終止。

• 主機 STOPPED、STOPPING、STARTING（現在這一版，2026-10-27 對 verify-ubuntu 連跑四次，STARTING 試了兩次；每次之前用 oci compute instance action --instance-id <主機的 OCID> --action STOP 或 --action START 讓主機落在那個狀態）。四次都是 exit 0，網路設定那幾步都印「已存在」，port forwarding session 每次都印「新建」。各次全程的秒數不同，差在 API 回應的快慢：port forwarding session 那一行以外，log 各行的時間戳之間都不到 10 秒，沒有任何一步走進 sleep，而 port forwarding session 那一行就從 8 秒到 22 秒不等。下面的「從腳本開始到這一行」是用 log 最後一行的時間減去全程秒數推算的，時間戳只到秒，誤差約 1 秒：

  • STOPPED：先帶 --wait-for-state STOPPED 停機，6 秒回 STOPPED。腳本全程 28 秒，第一行印「啟動」（STOPPED → RUNNING），從腳本開始到這一行約 9 秒，instance action 的 START 等到 RUNNING 包含在內。登入時 uptime 是 up 0 min，cloud-init status --wait 回 done，apt-get update 照常連到套件來源。
  • STOPPING：送出 STOP 不帶 --wait-for-state，CLI 回傳時是 STOPPING，再查一次仍是 STOPPING，接著跑腳本。腳本查到 STOPPING，全程 35 秒，第一行印「啟動」（STOPPING → RUNNING），從腳本開始到這一行約 9 秒。這 9 秒裡有登入檢查、查主機、查狀態、wait_state 的查詢與 START 共五次 API 呼叫，wait_state 要是睡過一次 10 秒就不可能少於 10 秒，所以它第一次查時主機已經是 STOPPED，沒有進 sleep（從時間戳推論）。
  • STARTING：試了兩次，第二次才走到這條分支。兩次都是主機停好之後送出 START 不帶 --wait-for-state。第一次在送出 START 與跑腳本之間多查了一次狀態（回 STARTING），腳本開始時主機已經是 RUNNING，第一行印「已存在」（RUNNING），全程 21 秒，走的是主機已經是 RUNNING 的那一條；從腳本開始到第一行只有約 2 秒，所以 STARTING 在多查的那一次之後幾秒內就變成 RUNNING（推論，沒有量 STARTING 維持多久）。第二次送出 START 之後立刻跑腳本：腳本查到 STARTING，進 wait_state 之後第一次查就已經是 RUNNING，沒有進到兩次查詢之間的 10 秒 sleep（從腳本開始到第一行只有約 4 秒推論）；全程 55 秒，第一行印「已存在」（等到 RUNNING）。
  • VNIC 的等待迴圈：四次的 VNIC 那一行都在主機那一行之後 3 到 9 秒內印出，主機沒有換過、VNIC 一直掛著，迴圈第一次查就拿到，沒有進 sleep（從時間戳推論）。
  • known_hosts：STOPPED 那一次印「known_hosts 已清空（換了一台主機）」，而主機是同一台。verify-ubuntu 是手動建的，之後只跑過腳本較早的版本（那一版只在新建主機時記 IID），host-verify-ubuntu.env 裡只有 session 的紀錄、沒有 IID 那一行，腳本拿空字串跟查到的 OCID 比，判成不同，同時寫進這一行；之後三次都印「保留」。下面假的 oci 測試表裡「主機 STOPPED」那一列印「保留」，是因為那一組測試的 host-<名稱>.env 已經記著同一台的 IID。清空之後，ssh 設定的 StrictHostKeyChecking accept-new 讓下一次登入重新記下這台的 host key（Permanently added '<私有 IP>' (ED25519)），登入沒有受影響；主機沒有重裝，host key 應該沒換，但清空之前的紀錄已經是空的，沒有舊的 key 可以比對。

• 主機已經是 RUNNING，沒有等待迴圈的版本：exit 0，全程 34 秒；主機那一步到掛 NSG 那一步都印「已存在」，port forwarding session 的建立佔了其中約 17 秒，最後兩行是 session 的「新建」與 ssh 設定的「改寫」。照產生的 ssh-verify-ubuntu.conf 登入之後，apt-get update 照常連到 Ubuntu 的套件來源。

• 名稱不存在，較早的兩個版本（2026-10-27 凌晨建 verify-ubuntu-rebuild）：建立請求第一次送出就成功。沒有等待迴圈的版本在印出「已 RUNNING」之後，接著以「查不到主機的 VNIC」結束（exit 2）；加上等待迴圈的版本從主機已經是 RUNNING 的狀態接著跑，exit 0，80 秒：掛 NSG 那一步印「改寫」，替新主機的 VNIC 掛上出站 NSG；port forwarding session 這一次要 64 秒才變成 SUCCEEDED，比既有主機的那一次長。登入時主機已開機 3 分鐘，cloud-init status --wait 立刻回 done，apt-get update 9 秒下載 39.9 MB，速率 4468 kB/s。

用假的 oci 測的結果（現在這一版；假的 sleep 只記秒數，所以秒數是腳本算出來要等的值。重送前的等待依回應碼調整，再加減 15 秒的隨機抖動，每次跑的值不同）。主機那一步與建立請求的情形：

加 BOOT_GB=60 的那一列，假的 oci 記下的建立請求帶著 --boot-volume-size-in-gbs 60；沒有給 BOOT_GB 的那幾列，建立請求裡沒有這個選項。每一種會送出建立請求的情形，第一次送出之前都先延長了一次 token（last_refresh=0）；回 400 的兩種情形印出的 message 是假的 oci 自己編的，Oracle 實際回的訊息這次沒有看過。查不到映像檔時，錯誤那一行是「查不到 Ubuntu 24.04 的 A1 映像檔：查詢結果是空的」。

網路設定那幾步的情形，以及讓單一種 oci 呼叫失敗的情形（主機都已經是 RUNNING）：

這幾種失敗，腳本在加上錯誤處理之前都照樣往下走：查同名主機失敗時當成找不到主機，再建一台；啟動或寫入失敗時照樣印「啟動」「改寫」「新建」；讀路由表或 VNIC 失敗時照樣整份替換，刪掉原本的規則或 NSG（審查時用同一支假的 oci 重現過）。假的 oci 測的是腳本的分支與結束碼，測不到雲端的回應格式與等待時間。

序列主控台連線的重建腳本（下面那一支）用同一支假的 oci 測了這幾種情形：主機已有 ACTIVE 的連線時印「已存在」、不呼叫 create，設定檔填的是那條既有連線的 OCID（exit 0）；沒有時呼叫一次 create、印「新建」（exit 0）；金鑰不存在、而主機已有 ACTIVE 的連線時，產生新金鑰、刪掉舊連線、再建一條（exit 0）；以上三種結束時印出的「用完就刪」那條 delete，代入的都是這次設定檔裡用的那條連線的 OCID；找不到 RUNNING 的同名主機時印「找不到 RUNNING 的 verify-ubuntu，先跑 rebuild-ubuntu.sh」並以 2 結束；查主機、查連線、建連線任一條失敗時印出錯誤並以 2 結束。

腳本裡幾處寫法的理由：

• q 保留結束碼與 stderr：OCI CLI 3.95.1 在 --query 的結果是空的時候，stdout 沒有輸出、結束碼是 0，只在 stderr 印 Query returned empty result, no output to show.（讀 CLI 套件的 cli_util.py 確認的）；查詢失敗時 stdout 同樣是空的。所以空字串本身分不出「查無結果」與「查詢失敗」，要看結束碼：q 把 stderr 存進暫存檔、照原樣回傳 oci 的結束碼，呼叫的地方失敗就以 fail 停下來並印出 stderr。主機那一步只有在查詢成功、結果又是空的時候，才進建立分支。
• 主機的狀態由 wait_state 自己查：oci compute instance get 沒有 --wait-for-state，帶了這個選項時 CLI 印出 Error: No such option '--wait-for-state'. 就結束；沒有等待迴圈的版本把 stderr 丟掉，這個錯誤沒有印出來，腳本在主機還沒 RUNNING 時就往下走。哪些子命令有這個選項用 oci <子命令> --help 查，這次查到有的是 compute instance launch、compute instance action、compute instance terminate、network nat-gateway create、network route-table update、network nsg create、network vnic update、bastion session create-port-forwarding 與 compute instance-console-connection create；沒有的是 compute instance get、compute instance list-vnics、network nsg rules add 與 network nsg rules list。VNIC 另外等最多 120 秒：剛送出建立請求約 5 秒的主機，list-vnics 在雲端實跑時回過空值（那一版的等待沒有作用，當時主機可能還沒到 RUNNING）。
• 變數後面直接接中文的位置寫成 ${NAME}：macOS 的 /bin/bash（3.2.57）把變數名後面緊接的全形字元讀成變數名的一部分，"主機 $NAME（RUNNING）" 在 set -u 之下以 NAME�: unbound variable 結束。訊息裡的 � 不是文章的亂碼：bash 把全形括號「（」的 UTF-8 編碼（三個位元組）的第一個位元組當成變數名的一部分，照原樣印出那一個位元組，終端機顯示不出單獨一個位元組，就印成 �。用 LC_ALL=C grep -n '\$[A-Za-z_][A-Za-z0-9_]*[^ -~]' <腳本> 找得出這類位置，這一版跑這條是 0 行。
• BOOT_ARGS 展開成 ${BOOT_ARGS[@]+"${BOOT_ARGS[@]}"}：同一個 bash 3.2.57 在 set -u 之下展開空陣列 "${BOOT_ARGS[@]}" 時，以 BOOT_ARGS[@]: unbound variable 結束（實跑）。沒有給 BOOT_GB 時陣列是空的。展開寫在 out=$(oci …) 的命令替換裡，照一般寫法，命令替換印出 BOOT_ARGS[@]: unbound variable 之後回傳空字串，腳本照樣往下走、讀不出回應碼，以 3 結束，訊息要讀者去查同名主機，看起來像網路中斷（依腳本結構與本機 bash 3.2 的最小重現推得，整支腳本沒有用一般寫法跑過）。重建既有主機的路徑走不到那一行，只測既有主機時看不出來。${A[@]+…} 在陣列有元素時才展開後面那一段，空陣列就什麼都不印。

序列主控台連線的重建腳本：主機沒有 ACTIVE 的序列主控台連線才建，並產生跟〈序列主控台：RSA 金鑰、建立連線、ProxyJump 設定與看到的開機輸出〉相同寫法的 ssh-console.conf：

 1#!/bin/bash
 2# 替主機建序列主控台連線（instance console connection），並產生 ssh-console.conf。
 3# 主機已經有 ACTIVE 的連線就沿用；沒有就用 console_rsa.pub 建一條（金鑰不存在時先產生 RSA 3072，
 4#   這時既有的連線登記的是舊的公鑰，先刪掉再建）。
 5# 官方給的連線字串在 ssh 外面再包一層 ssh 當跳板；這裡寫成等價的 ProxyJump 設定，不在本機執行任意命令。
 6# 連線只在排查時存在：要排查時跑這支建一條，用完以結尾印出的 delete 指令刪掉。
 7# 用法：./rebuild-console.sh [主機名稱]（預設 verify-ubuntu）。連線：ssh -tt -F ssh-console.conf verify-console
 8# 結束碼：0 完成；2 登入過期、找不到主機、oci 失敗（印出它的 stderr）或建不出連線。
 9set -uo pipefail
10# OCI CLI 是 Python 程式；PYTHONWARNINGS=ignore 關掉 Python 直譯器印的警告，不讓警告行混進要解析的輸出
11export OCI_CLI_AUTH=security_token PYTHONWARNINGS=ignore
12D=$(cd "$(dirname "$0")" && pwd)
13source "$D/ids.env"
14NAME=${1:-verify-ubuntu}
15REGION=<區域>
16CONF="$D/ssh-console.conf"
17KNOWN="$D/known_hosts_console"
18ERR=$(mktemp "${TMPDIR:-/tmp}/rebuild-console.XXXXXX"); trap 'rm -f "$ERR"' EXIT
19ts() { date +%m-%d\ %H:%M:%S; }
20say() { echo "$(ts) [$1] $2"; }
21die() { echo "$(ts) [錯誤] $1" >&2; exit 2; }
22# 查詢與寫入用的包裝：stderr 存進 $ERR 那個暫存檔，濾掉兩種不是結果的提示行（Python 的 SyntaxWarning，
23#   與 CLI 建議改用 `oci -i` 的 Interactive mode 那一行），結束碼照 oci 自己的回傳。
24#   CLI 的 --query 結果是空的時候 stdout 什麼都不印，所以空字串要搭配結束碼 0 才代表查無結果
25q() {
26  local out rc
27  out=$(oci "$@" 2>"$ERR"); rc=$?
28  [[ -n "$out" ]] && grep -v -e SyntaxWarning -e 'Interactive mode' <<<"$out"
29  return $rc
30}
31# q 失敗時停下來，印出 oci 寫在 stderr 的內容
32fail() { die "${1}失敗：$(tr '\n' ' ' < "$ERR")"; }
33
34oci session validate --profile DEFAULT >/dev/null 2>&1 \
35  || die "CLI session 過期，先跑 oci session authenticate --region $REGION --profile-name DEFAULT"
36
37IID=$(q compute instance list -c "$C" --display-name "$NAME" \
38  --query "data[?\"lifecycle-state\"=='RUNNING'] | [0].id" --raw-output) || fail "查 RUNNING 的主機"
39[[ "$IID" == ocid1.instance* ]] || die "找不到 RUNNING 的 ${NAME}，先跑 rebuild-ubuntu.sh"
40
41# 序列主控台連線只收 RSA 公鑰
42NEWKEY=0
43if [[ ! -f "$D/console_rsa" ]]; then
44  ssh-keygen -q -t rsa -b 3072 -N '' -C verify-console -f "$D/console_rsa" || die "產生 RSA 金鑰失敗"
45  NEWKEY=1; say 新建 "RSA 金鑰 console_rsa"
46else say 已存在 "RSA 金鑰 console_rsa"; fi
47
48CID=$(q compute instance-console-connection list -c "$C" --instance-id "$IID" \
49  --query "data[?\"lifecycle-state\"=='ACTIVE'] | [0].id" --raw-output) || fail "查序列主控台連線"
50# 剛產生新金鑰時，既有的連線登記的是舊的公鑰，用新私鑰連不上：先刪掉它，再用新的公鑰建一條
51if [[ "$NEWKEY" == 1 && "$CID" == ocid1.instanceconsoleconnection* ]]; then
52  q compute instance-console-connection delete --instance-console-connection-id "$CID" --force \
53    --wait-for-state DELETED >/dev/null || fail "刪掉用舊公鑰建的序列主控台連線"
54  say 改寫 "刪掉用舊公鑰建的序列主控台連線"
55  CID=""
56fi
57if [[ "$CID" == ocid1.instanceconsoleconnection* ]]; then say 已存在 "序列主控台連線"
58else
59  CID=$(q compute instance-console-connection create --instance-id "$IID" \
60    --ssh-public-key-file "$D/console_rsa.pub" --wait-for-state ACTIVE --query data.id --raw-output | tail -1) \
61    || fail "建序列主控台連線"
62  [[ "$CID" == ocid1.instanceconsoleconnection* ]] || die "建不出序列主控台連線：$CID"
63  say 新建 "序列主控台連線"
64fi
65
66cat > "$CONF" <<EOF
67# 由 rebuild-console.sh 產生：$NAME 的序列主控台。官方連線字串的跳板改寫成 ProxyJump。
68Host verify-console-gw
69  HostName instance-console.$REGION.oci.oraclecloud.com
70  Port 443
71  User $CID
72  IdentityFile $D/console_rsa
73  IdentitiesOnly yes
74  UserKnownHostsFile $KNOWN
75  StrictHostKeyChecking accept-new
76  HostKeyAlgorithms +ssh-rsa
77  PubkeyAcceptedAlgorithms +ssh-rsa
78
79Host verify-console
80  HostName $IID
81  User $CID
82  ProxyJump verify-console-gw
83  IdentityFile $D/console_rsa
84  IdentitiesOnly yes
85  UserKnownHostsFile $KNOWN
86  StrictHostKeyChecking accept-new
87  HostKeyAlgorithms +ssh-rsa
88  PubkeyAcceptedAlgorithms +ssh-rsa
89EOF
90: > "$KNOWN"
91say 改寫 "$CONF 與 known_hosts_console"
92echo "連線：ssh -tt -F $CONF verify-console（離開：先按 Enter，再輸入 ~.）"
93# 序列主控台連線是救援入口，平時不留：排查完就刪
94echo "用完就刪：oci compute instance-console-connection delete --instance-console-connection-id $CID --force --wait-for-state DELETED"

<區域> 換成自己的區域識別碼；ids.env 只用到 C。這支腳本每次都清空 known_hosts_console，下一次連線時由 StrictHostKeyChecking accept-new 重新記下跳板與目的地的 host key；代價跟〈建 Ubuntu 24.04 主機與經由 port forwarding 登入〉那一段寫的相同，第一次連線沒有比對指紋。這份檔案不依主機名稱分檔，給不同主機跑時共用同一份。console_rsa 不存在而這次新產生時，主機上既有的 ACTIVE 連線登記的是舊的公鑰，新私鑰連不上，所以腳本先刪掉那條連線再用新公鑰建一條。對新建的 verify-ubuntu-rebuild 實跑的是前一版：訊息還寫「主控台連線」、還沒有錯誤處理與換金鑰處理，建連線的步驟跟現在相同。結果是 exit 0，15 秒，印「已存在」（RSA 金鑰）、「新建」（序列主控台連線）與「改寫」（設定檔）。照設定檔連上之後印出 Oracle 對序列主控台連線的說明文字；本機用 alarm 讓 ssh 在 25 秒後結束，這段時間裡沒有按 Enter，所以登入提示沒有出現。

重建之後要重做的事，依順序：

1. ssh -F ssh-verify-ubuntu.conf verify-ubuntu 'cloud-init status --wait; uptime'（設定檔名依主機名稱）：等首次開機設定跑完（這次約 1 分鐘）。
2. 主機被刪除重建時，映像檔又是建立那一天的版本：照〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉最後那兩條，sudo unattended-upgrade 之後 sudo systemctl reboot（這次 402 秒、升級 64 個套件），才把映像檔之後的安全更新補上。只是被停止再啟動時，更新還在，不必重做。
3. 序列主控台連線平時不留，重建之後不必另外建。要排查時才跑序列主控台連線的重建腳本，再 ssh -tt -F ssh-console.conf verify-console；排查完用腳本結尾印出的那條 delete 刪掉。

耗時：這次量到的是單步的時間，建立請求送出到回傳約 4 秒，約 20 秒後的下一次查詢時主機已經是 RUNNING，cloud-init 約 1 分鐘，port forwarding session 約 1 分鐘，unattended-upgrade 402 秒，核心開始開機到登入提示約 27 秒。重建腳本在主機還在時 34 秒跑完，主機停止、停止中、啟動中三種狀態各 28、35、55 秒（差在各步 API 的回應與 port forwarding session 的快慢）；名稱不存在的那一次，那一版沒有等待主機的狀態，建立請求到 RUNNING 的確切時間沒有量到（2 分 30 秒後重跑時已經是 RUNNING），之後接上網路與登入的部分 80 秒，其中 port forwarding session 佔 64 秒；這一版從建主機那一步一次跑到底的時間沒有量。A1 容量不足時，建立那一步要重送，時間取決於區域當時的容量，重送的間隔與限流門檻在建主機那篇〈重送建立請求：CLI 自己的重送、限流門檻與重送腳本〉。

重建的其他做法：用 IaC 描述這組資源、建立時交給 cloud-init 升級、只靠手動

• 用 Terraform 描述主機與網路：主機被刪除之後 terraform apply 就重建，plan 也會列出被刪掉的資源；回收這種狀況剛好是 Infrastructure as Code (IaC) 擅長處理的 Drift（設定漂移）：宣告的狀態與實際不一致。代價是要先把已經用 CLI 建好的資源匯入 state（做法見 Unmanaged Resource 批次 Import 工作流）；這次沒有做。
• 建立時交給 cloud-init 升級套件：oci compute instance launch 的 --user-data-file 放一份 cloud-config，讓 cloud-init 在首次開機時就跑套件升級（cloud-config 的 package_upgrade: true），重建之後不必再手動跑 unattended-upgrade。前提是主機首次開機時已經有出站，所以要搭配上面〈出站的其他做法：security list、建主機時就掛 NSG、限縮出站的目的地與不加出站〉的「建主機時就掛上 NSG」。官方提醒初始化腳本裡不要放會觸發重開機的指令，否則可能讓主機建立失敗（代理程式、中繼資料服務、初始化腳本、維護行為與標籤〈初始化腳本〉），所以 cloud-config 只升級、不重開機，換上新核心的那一次重開機留到登入之後手動做，或由重建腳本在主機變成 RUNNING、cloud-init 跑完之後再觸發。這一項沒有實跑。
• 只靠手動照〈建 Ubuntu 24.04 主機與經由 port forwarding 登入〉與〈加出站：NAT gateway、路由規則與只掛在這台主機上的 NSG〉兩節重做：步驟都在本篇，不需要腳本；代價是每一步的 OCID 要重查，漏掉 NSG 掛到新 VNIC 這一步時，主機看起來建好了，apt-get update 卻又回到逾時，而且沒有任何錯誤訊息指出原因。

費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway

• A1：帳號篇記錄的 Always Free 額度是每月 1,500 OCPU 小時與 9,000 GB 小時（相當於 2 OCPU、12 GB 整月開著）。2026-10-26 讀到的 Oracle 的 Compute 價目頁（頁名這次沒有記下）寫的是「Each paid tenancy gets the first 3,000 OCPU hours and 18,000 GB hours per month for free」，對象是付費 tenancy，相當於 4 OCPU、24 GB 整月開著。這個 tenancy 是付費帳戶：重建腳本實跑之前，同一個 tenancy 已經有三台各 1 OCPU、6 GB 的 A1 主機在跑（2026-10-27 用 oci compute instance list 查到 verify-a1-ol、verify-origin、verify-ubuntu 三台是 RUNNING），腳本建出的第四台讓合計變成 4 OCPU、24 GB，剛好等於付費 tenancy 每月的免費量，建立沒有被擋下。試用結束那一刻、A1 合計超過 2 OCPU、12 GB 就全部停用的規則，只管沒有升級的帳號（帳號篇〈Always Free 的額度與它綁在 home region 上的範圍〉）；付費帳戶超出免費量的部分照一般價格計費（帳號篇〈超出 Always Free 額度時：試用中、未升級與付費帳戶各自的結果〉）。免費量是帳務的規則，能建出幾個 OCPU 由 compute 的 service limit 決定，兩者是分開的：查法跟下面開機磁碟那一項同一組，A1 的 OCPU 與記憶體的限制名稱是 standard-a1-core-count 與 standard-a1-memory-count，用 oci limits resource-availability get -c <tenancy 的 OCID> --service-name compute --limit-name <名稱> --availability-domain <可用網域> 查（2026-10-27 實跑，寫法見 Oracle Cloud 主機的暫停與恢復上線實測紀錄：暫停前的基準、收窄入口、停止主機、停止期間的計費與 Cloudflare 的回應、恢復上線的每一步與耗時，以及收尾時 DNS 紀錄與主機的刪除順序〈暫停前記下的基準：接聽的程式、服務、待裝的更新、憑證效期與公開 IP〉）；其他限制的名稱用 oci limits definition list -c <tenancy 的 OCID> --service-name compute 列（沒有實跑）。超出免費量時，停止主機對 OCPU 與記憶體費用的影響見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停期間仍在計費的資源〉；停止的主機的開機磁碟照樣佔著區塊磁碟額度。

• 開機磁碟：每台的開機磁碟從 Always Free 的 200 GB 區塊磁碟額度裡扣；放不進剩餘額度的那一顆整顆在額度外（下面「合計超過 200 GB 時」）。這顆磁碟有三種寫法：序列主控台記下的開機輸出寫 [sda] 97677312 512-byte logical blocks: (50.0 GB/46.6 GiB)；oci bv boot-volume list 對 verify-ubuntu 回 size-in-mbs 47694，正好是 97677312 × 512 位元組換成 MiB；同一條回的 size-in-gbs 是 47，是 46.6 GiB 進位。另外兩台 Oracle Linux 主機的 size-in-mbs 是 47719，換成 GiB 同樣是 46.6，size-in-gbs 同樣是 47。每顆磁碟的大小與額度的用量用下面三條查（2026-10-27 實跑）。<tenancy 的 OCID> 是最上層 compartment（root）的 OCID，~/.oci/config 裡 tenancy= 那一行就是它。這次的 compartment 直接建在 root 底下，所以 oci iam compartment get --compartment-id <compartment 的 OCID> --query 'data."compartment-id"' --raw-output 印出的上一層也是 tenancy 的 OCID（實跑，跟 tenancy= 的值相同）；compartment 是巢狀的時候，這條印出的是另一個 compartment，要讀 ~/.oci/config。

   1# 列出每顆還沒終止的開機磁碟與它的大小；<可用網域> 是建主機時用的那一個
   2oci bv boot-volume list -c <compartment 的 OCID> --availability-domain <可用網域> \
   3  --query 'data[?"lifecycle-state"!=`TERMINATED`].{name:"display-name",gb:"size-in-gbs",mb:"size-in-mbs"}' --output table
   4# 列出區塊儲存的限制名稱；區域層的免費額度叫 total-free-storage-gb-regional，
   5# 可用網域層另有一個 total-free-storage-gb，這個 tenancy 兩者的上限都是 200。
   6# 付費 tenancy 合計超過 200 時兩者都沒有擋下建立，放不進的那顆磁碟不算進兩者的 used（下面「合計超過 200 GB 時」）
   7oci limits definition list -c <tenancy 的 OCID> --service-name block-storage --all \
   8  --query 'data[].{name:name,desc:description,scope:"scope-type"}' --output table
   9# 查用量：used 是已經扣掉的量，available 是還剩的量。
  10# 查可用網域層那一個時，--limit-name 換成 total-free-storage-gb，並加 --availability-domain <可用網域>
  11oci limits resource-availability get -c <tenancy 的 OCID> --service-name block-storage \
  12  --limit-name total-free-storage-gb-regional

  2026-10-27 終止 verify-ubuntu-rebuild 之後查，剩三台主機時回 "used": 141、"available": 59，可用網域層那一個查出來的數字相同。這個 tenancy 裡只有這一個 compartment（oci iam compartment list -c <tenancy 的 OCID> --compartment-id-in-subtree true --all 只列出它），它與 root 底下都沒有開機磁碟以外的區塊磁碟（兩處的 oci bv volume list -c <…的 OCID> 都列不出任何一顆，root 底下也沒有開機磁碟；都是實跑），而 141 正好是三顆 size-in-gbs 47 的合計；三顆的 MiB 加起來是 139.8 GiB，總和進位會是 140，所以進位是每一顆各自做的。由此推論額度扣的數字就是每顆磁碟的 size-in-gbs：照預設大小建的主機，每台扣 47（額度以 GB 標示，數值是 46.6 GiB 進位），不是 50。照這個推算，終止 verify-ubuntu-rebuild 之前四台同時存在時合計扣 188，額度還剩 12（四台同時存在時沒有查用量，那台照同一個映像檔與預設大小算 47）。

  合計超過 200 GB 時（2026-10-27 09:33 實跑）：在扣了 141 的狀態下，用重建腳本以 BOOT_GB=60 建 verify-ubuntu-60g（建出 60 GiB，size-in-gbs 60；這裡的 GB 數值上都是 GiB，見〈被回收之後的重建：怎麼發現、留下與消失的資源、重建腳本〉的 BOOT_GB 那一項），三顆 47 加一顆 60 合計 201。建立請求沒有被擋下，主機照常建好（當時這個 tenancy 沒有設 compartment quota；設了 quota 之後超額的建立被擋下，見下面「用 compartment quota 擋下超額的建立」）。之後免費額度的用量與全部區塊磁碟的合計（total-storage-gb，上面的指令沒有查的第三條限制）不再相同：

  限制	範圍	上限	used	代表的量
  total-free-storage-gb-regional	區域	200	141	算進 Always Free 額度的磁碟合計
  total-free-storage-gb	可用網域	200	141	同上，以可用網域計
  total-storage-gb	可用網域	61,440	201	全部區塊磁碟的合計，含付費的磁碟

  表裡的可用網域是 availability domain，區域裡的一個資料中心（跨業者的概念見 Availability Zone（可用區） 卡）；主控台的 Scope 選單在這個區域只列出一個可用網域，兩條免費額度的數字因此相同（推論）。免費額度的 used 停在 141：60 GB 那一顆整顆算在免費額度之外。假如只有超出的 1 GB 在額度外，used 會是 200。主機 RUNNING 之後 4 分鐘起，每 2 分鐘查一次、共 6 次（約 10 分鐘），免費額度每次都是 141，而同一批查詢裡的 total-storage-gb 每次都是 201、已經算進這一顆，所以 141 不是還沒更新的值（推論）。Oracle 的 Always Free Resources 頁（2026-10-27 讀）對區塊磁碟的寫法跟這個結果一致：它舉的例子是四顆 50 GB 的 Always Free 磁碟加一顆 50 GB 的付費磁碟，刪掉其中一顆 Always Free 磁碟、空出額度之後，服務會自動把那顆付費磁碟轉成 Always Free（原文「When you have available Always Free capacity, Block Volume automatically tries to transition an existing paid resource to an Always Free resource」）。原文描述的轉換對象是整顆資源（paid resource），所以免費與否以整顆判定（從這一句推得，頁面沒有逐字寫；例子裡的剩餘額度是 0，單看例子分不出整顆與超出量兩種算法）。照這一句，這次的狀態下刪掉一顆 47 的免費磁碟，剩餘額度從 59 變成 106，放得下 60，這顆就可能轉成免費；同一天下午實測了這個轉換：轉成免費的是線上加大到 60 GB 而移出額度的那一顆開機磁碟，轉換發生在空出額度之後 26 到 31 分鐘；同時另建、一開始就在額度外的 50 GB 資料磁碟放不進剩下的額度，沒有轉換，所以建立時就在額度外的磁碟要等多久沒有量到（下面「付費磁碟自動轉成 Always Free」）。這次被判在額度外的是建立時放不進的那一顆；之後刪掉磁碟、重新分配時會選哪一顆轉成免費，頁面沒有寫。同一頁也寫了「Although it is possible to mix paid and Always Free resources, Oracle does not recommend this」，所以合計快到 200 時，先刪掉不用的舊磁碟再建，比讓一顆磁碟落到額度外單純。帳務明細也是整顆計費（2026-10-27 實跑）。用 usage API 依 skuName、skuPartNumber、resourceId 分組、逐小時（--granularity HOURLY）讀，這顆磁碟在 UTC 02 時那一小時記成兩個付費的項目：Block Volume - Storage（數量 0.0806）與 Block Volume - Performance Units（數量 0.806）。0.0806 正好是 60 GB 乘上 1 小時、除以一個月 744 小時，代表整顆 60 GB 都照價計費，不是只有超出的 1 GB；0.806 是同一顆磁碟的 60 GB 乘上 Balanced 等級的每 GB 10 個效能單位（VPU）再除以 744。同一小時其他三顆免費的開機磁碟記在 Block Volume - Free，數量各 0.0632（47 ÷ 744），金額 0，而且沒有效能單位的項目。兩個付費項目一小時合計約 0.0047，幣別是這個帳戶的 SGD（新加坡幣）。所以合計快到 200 時，下一顆放不進剩餘額度的磁碟是整顆照價計費：剩 59 時建一顆 60 GB，付費的是 60 GB 不是 1 GB。

  這筆項目出現的時間也量到了：磁碟在 UTC 01:33 建立，01 時那一小時的明細裡沒有它（那一小時只存在 27 分鐘；之後有沒有補上，這次沒有再查）；02 時那一小時的明細，UTC 03:27 查還沒有，03:57 查已經有了，也就是那一小時結束後 1 到 2 小時之間出現。每 30 分鐘查一次時，查到的最新一筆依序是 00、01、01、02 時那一小時，逐小時明細大約落後 2 小時。

  用 compartment quota 擋下超額的建立（2026-10-27 13:06 實跑）：付費帳戶合計超過 200 GB 時建立請求照常通過，要讓超額的建立被擋下，可以在 compartment 上設 quota。quota 是 policy，建在 tenancy（root）上、指名要限制的 compartment；這次限制的是區塊儲存的合計與 A1 的核心數，兩者都以可用網域為單位，所以用 where request.ad 指定可用網域：

  1# <compartment 的名稱> 是名稱不是 OCID；<可用網域> 是建主機時用的那一個，這個區域只有一個
  2oci limits quota create --compartment-id <tenancy 的 OCID> --name verify-quota \
  3  --description "cap block storage and A1 cores" \
  4  --statements "[\"set block-storage quota total-storage-gb to 200 in compartment <compartment 的名稱> where request.ad = '<可用網域>'\", \"set compute-core quota standard-a1-core-count to 4 in compartment <compartment 的名稱> where request.ad = '<可用網域>'\"]"

  回應的 lifecycle-state 是 ACTIVE。當時免費區塊儲存扣了 188（四顆 47）、A1 用了 4 OCPU（四台各 1），A1 已經到 4 的上限，區塊儲存剩 12、放不進 50 GB：

  • 區塊儲存：建立後約 35 秒，oci bv volume create -c <compartment 的 OCID> --availability-domain <可用網域> --display-name verify-data-50 --size-in-gbs 50 建一顆 50 GB 的資料磁碟（合計會變成 238），回 400，code 是 LimitExceeded，訊息是 You have reached your service limit in this Availability Domain for volumes. …。Oracle 的 API Errors 頁（2026-10-27 讀）把兩者分開：超過管理員設定的 compartment quota 是 400 QuotaExceeded，超過 Oracle 設定的 tenancy 上限是 400 LimitExceeded。這次區塊儲存那一條實際回的是 LimitExceeded，訊息也寫成 service limit，沒有提到 quota；total-storage-gb 的 service limit 是 61,440，用量只有 188，所以擋下它的是 quota。拿掉 quota 之後同一條指令建立成功（下一項），也對得上這個判讀。只看回應碼與訊息的排查會往 service limit 去查，查到的是用量遠低於上限。
  • A1 核心數：重建腳本建第五台（verify-ubuntu-q），建立請求回 400，訊息直接寫出被超過的 quota：The following compartment quotas were exceeded: standard-a1-core-count in policy '<quota 的 OCID>' by 1.。重建腳本只重送 500 與 429，回 400 就不重送、以 4 結束，instance list 查不到這台主機。

  quota 用 oci limits quota delete --quota-id <quota 的 OCID> --force 刪掉（<quota 的 OCID> 是 quota create 回應裡的 data.id，或用 oci limits quota list -c <tenancy 的 OCID> 查），quota get 回 NotAuthorizedOrNotFound。這兩條 quota 擋得住的範圍比免費量窄，有四個缺口：

  • 記憶體：A1 的免費量是 4 OCPU 與 24 GB 兩項，這次只限了核心數，沒有限 standard-a1-memory-count；1 OCPU 配 32 GB 的 A1 會通過 quota 而超出記憶體的免費量。要擋，再加一條 set compute-memory quota standard-a1-memory-count to 24 …（家族名稱與寫法照 Quota Policy Syntax 推，沒有實跑）。
  • 其他 compartment：quota 寫的是 in compartment <名稱>，只管那一個 compartment；免費量是整個 tenancy 一份，root 或別的 compartment 裡建的磁碟與主機不受這兩條限制。Quota Policy Syntax 的範例有 in tenancy 的寫法（2026-10-27 讀，沒有實跑）。
  • 多個可用網域：同一頁寫明可用網域層的 quota「is allocated to each AD」，每個可用網域各有一份 200；這個區域只有一個可用網域，所以這次的 200 就是全區的 200。可用網域有好幾個的區域，每一個都要用 where request.ad 各設一條，加起來不超過 200。
  • 加大磁碟：下一段線上加大是在拿掉 quota 之後做的，quota 擋不擋 boot-volume update 這次沒有測。

  在這幾個範圍裡，建立請求在超出免費量的那一刻就被拒，不會像上面那顆 60 GB 一樣整顆照價計費；代價是要建更大的磁碟時得先改 quota。quota 剛建好之後多久生效沒有量，這次建立後約 35 秒送出的請求已經被擋下。quota 的上限怎麼依最大花費速度訂，在 租用雲端主機之前的費用規劃：費用訊號的延遲、停止之前的最大超支、扣款的信用卡額度、配額與預算門檻的計算，以及停損停到哪一層〈平台上的上限：擋下建立、停止用量與只發通知〉。

  線上加大開機磁碟與另建資料磁碟，合計超過 200 GB 時（2026-10-27 13:08 實跑）：拿掉 quota 之後，在免費區塊儲存扣了 188 的狀態下做了兩件事。磁碟只能加大、不能縮小（Oracle 的 Resizing a Volume 頁：「You can only increase the size of the volume. You cannot decrease the size.」，2026-10-27 讀），所以合計接近 200 時加大的那一顆移出免費額度之後，要回到免費只能等別處空出放得下它的額度，或另建一顆小的磁碟搬資料：

  動作	免費額度的 used（兩條相同）	total-storage-gb 的 used	讀法
  建 50 GB 的資料磁碟（oci bv volume create … --size-in-gbs 50）	188	238	50 GB 整顆在免費額度外
  verify-ubuntu 的開機磁碟從 47 線上加大到 60	141	251	加大的那一顆整顆移出免費額度，不是只有超出的 13 GB

  開機磁碟的 OCID 用 oci compute boot-volume-attachment list -c <compartment 的 OCID> --availability-domain <可用網域> --instance-id <主機的 OCID> --query 'data[0]."boot-volume-id"' --raw-output 查。加大用 oci bv boot-volume update --boot-volume-id <開機磁碟的 OCID> --size-in-gbs 60 --wait-for-state AVAILABLE，主機開著時 34 秒回 AVAILABLE。另一種做法是先停止主機再加大（離線加大）：不必 rescan，啟動時作業系統直接讀到新的大小，代價是停機（依 Oracle 的磁碟加大文件推論，沒有實跑，也沒有比較兩種做法對免費額度的判定）。加大之前那顆 47 是免費的，加大到 60 之後，另外三顆 47（141）加上這顆 60，合計 201、超過 200，結果是那一顆整顆從免費額度裡拿出來（188 減 47），跟建立時放不進剩餘額度的情形相同。主機裡的作業系統要 rescan 才看到新的大小：加大之後 lsblk -b 讀到的仍是 50010783744 位元組，echo 1 | sudo tee /sys/class/block/sda/device/rescan（sda 是這台主機的開機磁碟名稱，自己的主機用 lsblk 確認）之後變成 64424509440（60 GiB），dmesg 印 sda: detected capacity change from 97677312 to 125829120；分割區與檔案系統的擴大這次沒有做（根目錄仍是 45G）。

  付費磁碟自動轉成 Always Free（2026-10-27 13:11 實跑）：上表之後，終止 verify-ubuntu-nb、刪掉它的 47 GB 開機磁碟（work request 65 秒 SUCCEEDED），免費額度從 141 降到 94，total-storage-gb 從 251 降到 204。之後每 5 分鐘讀一次兩個用量，共 90 分鐘：

  時刻（UTC）	免費額度的 used	total-storage-gb 的 used	讀法
  05:12:55	94	204	終止之後立刻讀；60 GB 與 50 GB 兩顆都還在免費額度外
  05:38:45	94	204	終止之後 26 分鐘，還沒轉換
  05:43:50	154	204	終止之後 31 分鐘，多出的 60 是加大的那顆開機磁碟
  06:39:40	154	204	之後每次都相同；50 GB 那顆放不進（154 加 50 是 204）

  帳務明細對得上這個轉換。查法是下面 NAT gateway 那一項的 usage-api 指令改成逐小時、看用量，並依資源分組（2026-10-27 實跑）：

  1# 起訖填要看的 UTC 整點；res 欄對回磁碟的 OCID
  2oci usage-api usage-summary request-summarized-usages --tenant-id <tenancy 的 OCID> \
  3  --time-usage-started 2026-10-27T04:00:00Z --time-usage-ended 2026-10-27T09:00:00Z \
  4  --granularity HOURLY --query-type USAGE --group-by '["skuName","skuPartNumber","resourceId"]' \
  5  --query 'data.items[].{hour:"time-usage-started",sku:"sku-name",res:"resource-id",qty:"computed-quantity"}' \
  6  --output table

  加大的那顆開機磁碟在 UTC 05 時那一小時分成兩段記：Block Volume - Storage 0.0394 與 Block Volume - Performance Units 0.3944（60 GB 付費約 29 分鐘），加上 Block Volume - Free 0.0384（加大之前的 47 GB 約 10 分鐘，加上轉換之後的 60 GB 約 21 分鐘）；換算回去，轉換大約在 05:39，跟用量在 05:38 到 05:43 之間跳動一致。06 時整小時記成 Block Volume - Free 0.0806（60 ÷ 744），沒有付費項目。50 GB 的資料磁碟 05 時記 Block Volume - Storage 0.0572 與 Performance Units 0.5725（建立之後約 51 分鐘）、06 時 0.0672 與 0.672，一直是付費。

  所以空出額度之後，付費磁碟會自動轉成免費，但不是當下：這次等了 26 到 31 分鐘，這段時間照付費計。剩餘額度放不下的那一顆不轉換。轉換沒有任何通知，要自己讀免費額度的 used 確認；哪一顆還在額度外，用上面那條逐小時的查詢看那顆磁碟記在 Block Volume - Storage 還是 Block Volume - Free。兩顆都放得下時選哪一顆先轉、轉換的延遲是否固定，這次沒有量。

  total-storage-gb 要帶 --availability-domain 查，寫法跟上面查可用網域層免費額度那一條相同，只換 --limit-name：

  1# 全部區塊磁碟的合計（含付費的磁碟）；跟免費額度的 used 相減，就是不在免費額度裡的 GB 數
  2oci limits resource-availability get -c <tenancy 的 OCID> --service-name block-storage \
  3  --limit-name total-storage-gb --availability-domain <可用網域>

  網頁主控台的同一組數字：Governance & Administration → Tenancy Management → Limits, quotas and usage 頁（路徑在 Oracle Cloud 主控台導覽：頂端列、導覽選單的分類、清單頁的 compartment 篩選器與常用頁面的路徑），篩選條件的 Service 選 Block Volume 之後，2026-10-27 10 時前後讀到的數字跟 CLI 相同。這次開啟時篩選條件的 Scope 是區域（ap-batam-1，沒有試過換瀏覽器或換使用者時是否相同），這時只列出 total-free-storage-gb-regional（頁上的描述是 Free Tier Volume Quota (GB) in the Region）與兩項備份數量的限制（backup-count、free-backup-count），前者的 Service Limit、Usage、Available 三欄分別顯示 200、141、59；全部區塊磁碟的合計要把 Scope 換成可用網域才列出來，total-free-storage-gb（Free Volume Size (GB)）顯示 200、141、59，total-storage-gb（Volume Size (GB)）顯示 61,440、201、61,239。只看區域範圍時，看不到不在免費額度裡的那 60 GB。

• 出站流量：每月前 10 TB 免費（Oracle〈Virtual Cloud Network Pricing〉），這台只拿來下載套件。

• NAT gateway：Oracle 的 Cloud Price List（2026-10-27 讀）在 Networking 那一節只列入站流量與出站流量，沒有 NAT gateway 這一項；Virtual Cloud Network Pricing 頁同樣只寫區域內的流量、對外的出站流量、Dedicated connectivity 與 site-to-site VPN。實際的帳務用 usage API 依服務與 SKU 分組讀（2026-10-27 實跑）。usage API 讀的是網頁主控台 Cost Analysis 頁（Billing & Cost Management → Cost Management → Cost Analysis）背後同一份用量資料，CLI 的服務名是 usage-api；SKU 是帳務明細上的計費品項，例如 Standard - A1。--query 收的是 JMESPath 運算式，上一項 boot-volume list 的篩選也是：

   1# COST 換成 USAGE 時印的是用量。要看每一項記在哪個資源上，--group-by 加 "resourceId"，
   2# --query 的投影也要加 res:"resource-id"，否則表格裡不會多出資源那一欄（兩處都改過的版本實跑過）
   3# 起訖填要看的那幾天（UTC），這次只用過日界的整點
   4# tenancy 的 OCID 跟上一項 oci limits 用的是同一個。這次 CLI 設定的區域就是 home region，
   5# 沒有試從其他區域呼叫 usage API 的結果
   6oci usage-api usage-summary request-summarized-usages --tenant-id <tenancy 的 OCID> \
   7  --time-usage-started 2026-10-24T00:00:00Z --time-usage-ended 2026-10-27T00:00:00Z \
   8  --granularity DAILY --query-type COST --group-by '["service","skuName"]' \
   9  --query 'data.items[].{day:"time-usage-started",service:service,sku:"sku-name",cost:"computed-amount",qty:"computed-quantity"}' \
  10  --output table

  verify-nat 在 2026-10-26 13:18（UTC）建立，同一天 19:11（UTC，台北時間 10-27 03:11）前後刪除，存在約 6 小時，整段都落在明細的 2026-10-26 那一天裡（區間延長到 10-28 重查，明細也只到 10-26）。那一天的明細只有四項：Compute 的 Standard - A1 與 Standard - A1 - Memory、Block Storage 的 Block Volume - Free、Virtual Cloud Network 的 Outbound Data Transfer Zone 2，金額都是 0，沒有 NAT gateway 的項目。出站流量那一項以 resourceId 分組時有四筆，都記在 VNIC 上；用 oci network vnic get 對回去，其中一筆是 verify-ubuntu 的 VNIC（它只經 NAT gateway 出站），一筆是有公開 IP 的 verify-origin，另外兩筆的 VNIC 已經隨主機刪掉、查不到。所以經 NAT gateway 出去的流量記在送出流量的那台主機的 VNIC 上、照出站流量計，算進每月 10 TB 的免費量（從這一天的明細推論）。verify-ubuntu 那一筆是一整天的合計，NAT gateway 建立之前它也經 service gateway 送封包到 Oracle 服務網路，這次沒有把兩段分開，所以沒有確認這一筆裡經 NAT 的流量佔多少，也沒有確認 service gateway 那段是否計入出站流量。這只涵蓋 NAT gateway 存在的那約 6 小時；查詢是在 2026-10-26 19:3x（UTC）做的，那一天還沒結束；逐小時的明細大約落後 2 小時（上面開機磁碟那一項 2026-10-27 量到的），所以那一天最後幾小時的明細當時還沒出來，可能還不完整。verify-nat 已經刪除（〈刪除這組資源的順序〉），沒有讀完一個帳單週期的 Cost Analysis；隔幾天用同一條查詢、起訖涵蓋 10-26 重查一次，就能確認那一天的明細補齊之後有沒有多出 NAT gateway 的項目。Outbound Data Transfer Zone 2 的 Zone 是帳務替出站流量分的區；價目表依流量的出發地分成北美歐洲英國、亞太日本南美、中東非洲三組，三組的前 10 TB 都免費，Zone 2 對應哪一組這次沒有查。

  所以就兩份價目頁與建立當天的明細來看，NAT gateway 本身沒有收費項目，開一個 NAT gateway 多出的費用只有經它出去的流量，而流量照一般的出站流量計、先扣每月 10 TB 的免費量。這是推論：證據只涵蓋約 6 小時、而且那一天的明細可能還不完整，也沒有讀完一個帳單週期；這次也沒有查 Oracle 的 NAT gateway 文件是否明文寫了收費規則。