區域（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：免費額度綁在區域上時，申請帳號那一刻就決定了位置；配額表列出某個機型、而那一區沒有那種硬體時，建立會失敗而錯誤碼分不出原因

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 段。

虛擬網路與 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 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務。

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 段。

開機磁碟與區塊磁碟

雲端主機的磁碟跟主機本身是兩個獨立的資源。開機磁碟（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 的用途

代理程式與 plugin：業者裝在主機裡的程式

業者的平台映像預先裝了業者自己的代理程式（agent）：Oracle Cloud 的叫 Oracle Cloud Agent，Google Cloud 的平台映像預先裝了 guest environment（裡面的 guest agent 負責同步中繼資料、建使用者），AWS 的多數 AMI 預先裝了 SSM Agent。另外收集指標與日誌的代理程式（Google Cloud 的 Ops Agent、AWS 的 CloudWatch agent）要另外安裝。代理程式在主機裡執行，替業者的雲端服務做需要在作業系統裡完成的事：回報 CPU 與記憶體用量、收集日誌、執行遠端指令、替區塊磁碟建立連線、替管理通道服務把臨時的登入金鑰放進主機。

Oracle Cloud 把每一項功能做成一個 plugin，在建立頁上個別開關。判斷要開哪些，看會不會用到它背後的那個服務：

• 要用 Oracle Cloud 的 Bastion 服務、以 managed SSH session 登入：一定要開 Bastion plugin，主機有沒有放自己的公鑰都一樣；沒開時 managed SSH session 建不起來，主機放了自己的公鑰的話，還能走不經代理程式的 port forwarding session。開了是必要條件、不是充分條件：映像的作業系統版本不提供 Bastion plugin 時，開著也沒有這個 plugin（2026-10-25 的 Oracle Linux 10.2 就是這樣），建立之前用 oci instance-agent available-plugins get 依版本查，見 Oracle Cloud 建立主機的實測紀錄 的〈建立之前查映像檔版本與它可用的 plugin〉。
• 要在主控台看主機的 CPU、記憶體圖表：維持 Compute Instance Monitoring 開啟。
• 要掛區塊磁碟、想讓代理程式替主機設定連線：開 Block Volume Management。
• 其餘：維持建立頁的預設。官方說明一台主機支援哪些 plugin 依 Oracle Cloud Agent 的版本與映像而定，所以預設清單也隨映像不同。預設關閉的 plugin 背後的服務（作業系統修補、弱點掃描這類）都要在各自的服務裡另外啟用，用到時再回來打開。

Plugin 建立之後可以在主機頁面的 Oracle Cloud Agent 分頁開關，官方說明變更最多要 10 分鐘生效，所以建立時漏開的 plugin 不必重建主機。Plugin 本身是代理程式的一部分，官方的 plugin 說明頁沒有寫它的費用；費用來自它背後的服務，例如 Logging 服務依收進來的日誌量計費。Oracle Cloud 全部 plugin 的用途與一台 A1 Ubuntu 主機上的實際預設值，整理在 Oracle Cloud 建立主機的實測紀錄 的 Management 段。

中繼資料服務與 Authorization header

每台雲端主機都能從一個只有主機自己連得到的位址（169.254.169.254）查詢自己的資訊：主機 ID、所在區域、建立時放進去的公鑰與初始化腳本。這個服務叫實例中繼資料服務（instance metadata service，IMDS），cloud-init（多數 Linux 雲端映像預先裝好、開機時讀中繼資料做初始設定的程式）開機時就是從這裡讀出 SSH 公鑰。知識卡見 Instance Metadata Service（實例中繼資料服務）。

Oracle Cloud 的中繼資料服務有兩個版本。第一版的路徑是 /opc/v1，請求不必帶任何標頭；第二版的路徑是 /opc/v2，每個請求都要帶 Authorization: Bearer Oracle 這個標頭。建立頁上的「Require an authorization header」打開之後，主機只接受第二版的請求，送到第一版路徑的請求回 404、沒帶標頭的請求被拒絕。這個限制防的是 SSRF（伺服器端請求偽造）：主機上的網頁應用程式有漏洞、被誘導去讀某個網址時，攻擊者可以讓它讀 169.254.169.254 而取得主機的資訊；多數這類漏洞只能控制網址、加不了自訂的標頭，所以要求標頭能擋掉這條路。

這個選項成立的前提是主機上讀中繼資料的程式都會用第二版，在不支援第二版的映像上只允許第二版時，cloud-init 讀不到公鑰，主機會連不上。官方〈Getting Instance Metadata〉把映像分成三類：支援第二版的平台映像是 Oracle Linux 與 Oracle Autonomous Linux（Oracle Linux 7.x 與 8.x 要 2020 年 7 月（含）以後發佈的映像，Oracle Autonomous Linux 7.x 要 2020 年 6 月（含）以後，8.x 全部支援）；自訂的 Linux 映像在 cloud-init 更新到 20.3 以上、Oracle Cloud Agent 更新到 0.0.19 以上時可能支援；其他平台映像、多數自訂映像與多數市集映像不支援。Ubuntu 的平台映像因此落在不支援的那一類，雖然 Ubuntu 24.04 內附的 cloud-init 版本高於 20.3、符合官方給自訂映像的版本條件；兩種說法對不上。2026-10-26 在一台建立時放了公鑰、只允許第二版的 Ubuntu 24.04 A1 主機上實際驗過：cloud-init 讀到了公鑰，首次開機之後就用那把金鑰登得進去（Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈建 Ubuntu 24.04 主機與經由 port forwarding 登入〉）。這是一個映像檔版本（Canonical-Ubuntu-24.04-aarch64-2026.09.18-0）上的一次結果，官方的分類沒有因此改變，換了映像檔版本時仍以建好之後實際登入為準。Oracle Cloud 的建立頁在 Ubuntu 24.04 的 A1 主機上把這個選項預設開著（實測紀錄的〈Management：Oracle Cloud Agent 與其他進階選項〉，2026-10-24）。實測紀錄裡的那台主機在 2026-10-25 建成，開著這個選項時代理程式照常回報各 plugin 的狀態；Bastion 的 managed SSH session 建立請求約 15 分鐘後逾時、工作階段轉成 DELETED，暫時改成允許第一版也一樣逾時，所以那次失敗跟這個選項無關，成因是官方列出的 A1 加 Ubuntu 不支援 managed SSH session（排查經過在同一篇的〈建立之後：Bastion managed SSH session 逾時的排查〉）。它選的是 No SSH keys、主機裡沒有放公鑰，所以開著這個選項時 cloud-init 是否把公鑰寫進主機，是由後來另一台放了公鑰的 Ubuntu 24.04 主機驗的，結果在上一段。

在 Oracle Cloud 上的做法：

• 用 Oracle Linux 或 Oracle Autonomous Linux 平台映像：維持開啟。
• 其他平台映像（包括 Ubuntu）：官方列為不支援。建立頁預設開著時，要嘛先關掉、建好之後確認登得進去再開，要嘛開著建立，登不進去時照「開著建立之後懷疑出了問題」那一條改回來。Ubuntu 24.04 的一個映像檔版本開著建立時登得進去（上一段的實測）。
• 自訂或市集映像：先不開，建好之後在主機上用 cloud-init --version 與代理程式的版本確認符合官方條件，再開。
• 開著建立之後懷疑出了問題：公鑰沒寫進 authorized_keys、初始化腳本沒執行、代理程式的 plugin 狀態異常，這三件都是讀中繼資料才做得到的事。這個設定建立之後可以改：在主機頁面的 Instance metadata service 旁按 Edit，改回允許第一版與第二版，再重開主機（官方〈Getting Instance Metadata〉的步驟）；公鑰沒寫進去而登不進主機時，要從序列主控台或其他救援入口進去，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈建立之後加金鑰與金鑰遺失時的入口〉。

AWS 的 IMDSv2 同樣可以在建立後切換，多數近年的 AMI 都支援；Google Cloud 的中繼資料伺服器固定要求 Metadata-Flavor: Google 標頭，沒有這個選項。

初始化腳本

建立頁的進階選項裡可以放一段初始化腳本（Oracle Cloud 的主控台欄位叫 Initialization script，經由中繼資料的 user data 傳進主機），常用來安裝套件、建立使用者、寫入設定檔。Oracle Cloud 的限制是使用者資料與其他中繼資料合計不超過 32,000 bytes；官方提醒腳本裡不要放會觸發重開機的指令，否則可能讓主機建立失敗。

腳本什麼時候執行，看主機裡由哪個程式執行它。Oracle Cloud 與 AWS 的 Linux 主機由 cloud-init 執行初始化腳本，預設只在第一次開機時執行一次，之後修改中繼資料不會重新執行；Google Cloud 的 startup script 由 guest agent 從中繼資料讀出來執行，每次開機都執行，腳本要寫成重複執行也不出錯。要讓同一份設定能在新主機上重現，腳本本身要放在版本控制裡；主機與網路這些資源本身改用 IaC 管理，見 IaC 工具選型與 state 地基。

硬體維護時的行為

業者要維修主機底下的實體硬體時，上面的虛擬機只有兩種處理方式：搬到另一台實體主機上（業者叫遷移，不中斷的叫即時遷移，要重開一次的叫重開機遷移），或是原地停機、等硬體修好再開。Oracle Cloud 與 Google Cloud 的建立頁上有維護欄位，決定業者優先用哪一種、以及硬體恢復之後主機要不要自動啟動。Oracle Cloud 有兩個欄位：

• Live migration：預設是讓 Oracle 選擇遷移方式。選「盡量用即時遷移」時，Oracle Cloud 先嘗試即時遷移，失敗時改用重開機遷移；選「送出維護通知」時，Oracle Cloud 在維護前通知，主機在期限前沒有自己重開的話，就由 Oracle Cloud 做即時遷移。部分機型不支援即時遷移，開了安全開機（shielded instance）的主機也不支援即時遷移與重開機遷移，見 安全開機。
• Restart after infrastructure maintenance（2026-10-24 主控台上的名稱，官方文件寫作 Restore instance lifecycle state after infrastructure maintenance）：預設勾選，維護事件影響到主機時，主機在硬體恢復之後自動重開。不勾的話，主機恢復後維持停止狀態，要手動啟動。

Google Cloud 對應的欄位是 On host maintenance（遷移或終止）與 Automatic restart，AWS 由 scheduled events 通知維護時間。一般用途維持預設。在 Oracle Cloud 上，服務不能接受沒有預警的重開時，選送出維護通知，收到通知後在期限前、挑服務離峰的時間自己重開主機，或先把流量切到另一台。

標籤

標籤（tag）是附在資源上的鍵值對，用來分類資源、分攤費用、寫自動化腳本時篩選資源。Oracle Cloud 有兩種：自由格式標籤（有建立資源權限的人都能加）與預先定義的標籤（要有那個標籤命名空間的權限）。標籤可以在建立之後再加。成本分攤與標籤規範見 Tagging 規範與 Secrets 不進 code。

各家的欄位名稱：代理程式、中繼資料、初始化腳本與維護行為

不放 SSH 金鑰、改用 Bastion 登入時 plugin 要怎麼配合，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉。

Secure Boot、Measured Boot 與 TPM 各自的作用

• Secure Boot：開機時韌體逐一驗證開機載入程式與核心的數位簽章，簽章不屬於受信任的發行者就拒絕載入。效果是只有作業系統廠商簽過的開機程式跑得起來。
• Measured Boot：開機過程中，每一個階段的程式（韌體、開機載入程式）在載入下一個元件之前先量測那個元件，量測值寫進 TPM 的平台設定暫存器（PCR）。它不阻擋任何元件載入，只留下紀錄。Oracle Cloud 把第一次開機的量測值存成基準（golden measurements），之後每次開機時，新的量測值跟基準比對（官方〈Shielded Instances〉沒有寫比對在主機裡還是在業者那一端執行），結果顯示在主控台主機詳細資料頁的盾牌圖示上：開機順序跟基準不符時是紅色，多出新的 PCR 值時是黃色，兩種情形主機都照樣開機。官方提醒更新作業系統之後可能要重設基準，重設的步驟在同一頁。Google Cloud 對應的比對功能叫 integrity monitoring。
• TPM（Trusted Platform Module）：存放開機量測值與金鑰的安全晶片，雲端主機上是虛擬的。Measured Boot 的紀錄寫在這裡，作業系統也可以用它保存磁碟加密金鑰這類秘密。

Secure Boot 是事前攔截，Measured Boot 是事後偵測。TPM 是 Measured Boot 存放量測值的地方；官方說明裡 Secure Boot 的簽章驗證由 UEFI 韌體完成，沒有寫它用到 TPM。Oracle Cloud 上哪幾項要一起開依作業系統而定：Windows 虛擬機三項必須一起開，勾選其中一項時主控台會自動勾上另外兩項；Linux 虛擬機可以只開 Secure Boot、只開 TPM 加 Measured Boot，或三項全開。

Oracle Cloud 上 shielded instance 的限制

Oracle Cloud 的官方〈Shielded Instances〉寫明，shielded instance 建好之後編輯主機時只能改名稱：機型不能改、遷移的設定也不能改，三項安全開機的設定同樣不能事後開關。所以開了安全開機的主機，核心數與記憶體要在建立時就定好，要改就重建。同一頁另外列了下面這些限制：

• 不支援自訂映像，只能用業者的平台映像建立。
• 不支援即時遷移與重開機遷移：業者維護底層硬體時，不會替這台主機做自動遷移，官方寫的是要遷移就由使用者手動遷移，搬到新硬體之後 Secure Boot 的金鑰與開機量測值會在新主機上重新取得。官方〈Infrastructure Maintenance〉的手動遷移做法是終止主機、再用保留下來的開機磁碟建一台新的，開了 TPM 的主機另有額外步驟；維護事件發生時 shielded 虛擬機要停機多久、業者是否事先通知，兩頁都沒有單獨寫。其他主機的維護行為見 代理程式、中繼資料服務、初始化腳本、維護行為與標籤 的〈硬體維護時的行為〉。
• 跟機密運算（confidential computing，CPU 在運算時也把記憶體裡的資料加密）互斥，一台主機只能選其中一種。

這幾條是 Oracle Cloud 的規則。Google Cloud 的 Confidential VM 本身就是 Shielded VM，兩者不互斥。

實驗主機開啟安全開機的取捨

官方〈Shielded Instances〉沒有提到開啟這三項會另外收費；要確認自己的帳號，建好之後到帳單的成本分析頁看有沒有出現新的計費項目。開啟的代價在相容性：Secure Boot 會拒絕沒有簽章的核心模組與自己編譯的核心，要裝第三方驅動程式（部分 GPU、虛擬化或網路驅動）或自訂核心時會開不了機或載入失敗。業者的平台映像本身是簽過的，只跑一般套件時開著不會有感。在 Oracle Cloud 上另有一個代價在彈性：開了之後機型不能改，實驗機「先開小、不夠再加」的做法就走不通。

• 跑一般服務、使用平台映像：開或不開都可以；有合規要求（要求開機鏈可驗證）時開。
• 要裝自訂核心或沒有簽章的驅動程式：不開，或先確認那個驅動程式支援 Secure Boot 的簽章流程。在 Linux 上，這個流程是用自己的金鑰簽驅動程式、再把那把金鑰登錄進開機鏈信任的清單（Machine Owner Key，MOK）；合規要求開機鏈可驗證、又要裝這類驅動程式時，就要走這條路，做法以那個驅動程式與發行版的文件為準。這一組條件最容易在主機建好幾個月之後才遇到：用 DKMS（套件更新時自動重新編譯核心模組的機制）安裝的驅動程式，編譯與套件安裝都會成功，到 modprobe 載入模組時才被拒絕，錯誤訊息是 Key was rejected by service；而 Oracle Cloud 上安全開機的設定建立後不能關，只能登錄 MOK 或重建主機。官方另外寫明，主機終止時登錄過的 MOK 會一起刪除，重建的主機要先用標準簽章的核心開機、再重新登錄 MOK。
• 實驗與學習用的主機：維持建立頁的預設即可，要測試這個功能時另外建一台開啟的。Oracle Cloud 建立 A1 Ubuntu 主機時建立頁上三項預設都關閉（實測紀錄的 Security 段）；Google Cloud 的 Shielded VM 預設開啟 vTPM 與 integrity monitoring。

各家的欄位名稱：開機保護的總稱、Secure Boot、開機量測與 TPM

映像檔的三種來源與架構相容的規則見 機型與映像檔；Oracle Cloud 的 shielded instance 只能用其中的平台映像。

建好就改不了的設定：補救的代價與查法

建立頁上的設定依建立之後的處置分成三種：可以直接改（Oracle Cloud 的 plugin 開關、磁碟的效能等級）、改的時候要停機或重開（核心數與記憶體）、只能重建（CPU 架構與作業系統）。只能重建的設定，代價出現在發現選錯的那一刻：重建主機會換掉臨時公開 IP（私有 IP 沒有在建立時指定也會換）、開機磁碟上的資料要另外搬，機型容量難取得時還要再搶一次容量。所以建立之前要逐項找出只能重建的設定，替每一項寫出選錯時的補救路徑與代價。

同一項設定在三家的處置不同，所以這份清單要對著業者查，不能從另一家的經驗推過來。以 SSH 公鑰為例：

• Oracle Cloud：公鑰與初始化腳本存在主機的中繼資料裡，oci compute instance update --help 對 --metadata 的說明寫明 ssh_authorized_keys 與 user_data 在主機建立之後不能改，送出修改的請求會被拒絕。cloud-init 只在第一次開機時把公鑰寫進 authorized_keys，所以建立時選了不放金鑰，之後就沒有經由中繼資料補公鑰的方式；剩下的入口（代理程式臨時放公鑰、Run Command、把開機磁碟掛到另一台主機）各有前提，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈建立之後加金鑰與金鑰遺失時的入口〉。
• Google Cloud：公鑰存在專案或主機的中繼資料裡，建立之後可以再加。Google 的映像預先裝了 guest environment（業者裝在主機裡的一組程式），其中的 guest agent 持續依中繼資料同步金鑰，加進去的公鑰會寫進主機。
• AWS：EC2 Instance Connect 每次連線前把一把公鑰暫時推送到主機的中繼資料，不依賴建立時選的 key pair。條件是主機上裝了 EC2 Instance Connect 的套件、登入者有對應的 IAM 權限，以及連線到得了主機：官方〈Prerequisites for EC2 Instance Connect〉寫明主機要有公開 IP，或經由 Direct Connect、Site-to-Site VPN、VPC peering 這類私有連線，沒有公開 IP 時另一個選擇是 EC2 Instance Connect Endpoint。

其他類設定的處置寫在各自的那一篇：架構與映像檔見 機型與映像檔：CPU 架構、核心與記憶體、計費模式與作業系統（換作業系統要用新的映像檔重建；Oracle Cloud 可以替換開機磁碟，官方〈Replacing a Boot Volume〉限定只能換成同一個 Linux 發行版，Ubuntu 換不成 Oracle Linux），主要網卡所在的 subnet 與公開 IP 的種類見 網路：subnet、私有 IP、公開 IP 與防火牆規則，Oracle Cloud 的安全開機見 安全開機：Secure Boot、Measured Boot 與 TPM，區域與可用區見 位置：區域、可用區與故障域。

哪些設定只能重建，業者自己的工具也查得到。修改主機的 API 與 CLI 說明會寫哪些欄位不能改（上面 Oracle Cloud 那一條就是從 --help 讀到的）；用 Terraform 管理主機時，terraform plan 把只能重建的屬性標成 forces replacement，在 plan 上改一次那個屬性，就看得到它屬於哪一種（見 terraform plan / apply）。

登入路徑上各服務的支援組合：支援清單、Known Issues 與元件狀態

登入一台沒有公開 IP 的主機，連線要經過幾個業者服務：哪個服務負責網路可達性、通道授權與主機登入驗證，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉。每一個服務都只在一部分機型與作業系統上成立，而這份範圍寫在服務自己的文件裡，不寫在建立頁上：建立頁讓任何映像檔配任何相容架構的機型，建立會成功，登入在之後才失敗。

所以建立之前，對路徑上每一個服務讀下面三種文件，業者另外提供查詢工具時再查一次：

• 支援的作業系統與映像檔清單：例如 Oracle Cloud 的 Run Command 列出的是 Oracle Autonomous Linux、Oracle Linux、CentOS、Windows Server 與以它們為基礎的自訂映像，沒有 Ubuntu。不在清單上代表官方不保證，不代表一定不能執行：2026-10-25 在一台 A1 Ubuntu 主機上實測，Run Command 的 plugin 確實執行了指令，而能做到哪些事還要看下面的前置條件。AWS 的 EC2 Instance Connect 要主機用預先裝好它的 AMI，或在官方列為支援的 AMI 上自己安裝。
• Known Issues：支援清單寫的是作業系統，機型與作業系統的組合不支援的情形常常只寫在這一頁。Oracle Cloud〈Known Issues for Bastion〉的第一條是 Arm 架構的 A1 機型加非 Oracle Linux 的主機不支援 managed SSH session；這個組合在建立頁上建立會成功，A1 是 Always Free 的機型、Ubuntu 是建立頁列出的平台映像，兩者放在一起時 managed SSH session 才不支援。這一條只寫到作業系統，沒有寫版本。
• 可以查詢的支援清單：文件寫到作業系統為止時，作業系統的版本之間仍然可能不同，而有些業者提供依版本查詢的工具。Oracle Cloud 的 oci instance-agent available-plugins get 依作業系統名稱與版本列出代理程式可用的 plugin：2026-10-25 查到 Oracle Linux 10 確定沒有 Bastion plugin，所以同樣是 A1 加 Oracle Linux，選 10 的主機少了 managed SSH session 需要的 plugin（從 plugin 清單推論，沒有在那台主機上實際建工作階段）。這類工具查不到對應時可能回傳不分版本的全部項目而不是報錯：這支工具填不存在的版本或作業系統名稱，回傳的都是同一份全部清單，裡面有 Bastion。所以版本要照抄映像檔的作業系統版本欄位，先拿一個不存在的值查一次當對照；查到的清單跟對照不同才算查到這個版本的資料，跟對照相同時分不出來，這次的 Oracle Linux 9 與 8 就是這樣，要建起來看主機上的 plugin 清單，或另找逐版本列出的文件。查法與重建的經過在 Oracle Cloud 建立主機的實測紀錄 的〈建立之前查映像檔版本與它可用的 plugin〉。
• 前置條件：服務在主機上用哪個使用者執行、要什麼權限。Oracle Cloud 的 Run Command 以 ocarun 這個使用者執行，要寫其他使用者的檔案得先替它設 sudo；官方列的做法有兩種，建立時用 cloud-init 放 sudoers 檔，或建好之後登入主機設定。主機登不進去時才想用 Run Command 救援，只剩前一種，而初始化腳本是建立後不能改的欄位，所以這件事要在建立之前決定。AWS 的 Session Manager 要主機上有 SSM Agent，並讓 Systems Manager 取得操作這台主機的權限。

元件的狀態欄顯示的是元件啟動了，這個組合能不能完成登入，寫在支援清單與 Known Issues 裡，兩者描述的是不同的事。Oracle Cloud 的主機頁面上，A1 Ubuntu 主機的 Bastion plugin 顯示 RUNNING，Bastion 的工作階段照樣在約 15 分鐘後逾時。缺了前置條件時，狀態欄也一樣顯示正常：同一台主機的 Run Command plugin 也是 RUNNING，指令確實執行了，而 ocarun 沒有 sudo，寫不了 authorized_keys。

演練能驗到的，只有演練主機與正式主機相同的那些條件。演練主機與正式主機在機型、映像檔、服務三者都相同時，演練才驗得到組合不支援的情形；上面那一條 Known Issue 只針對 A1，在 x86 機型上用同一版 Ubuntu 的 x86 映像演練，照 Known Issues 的寫法不在不支援的範圍裡（這個推論沒有實跑），演練成功只代表 x86 加 Ubuntu 這個組合支援。機型本身就是要驗的條件時，演練換不了機型，只剩讀文件這一條路。

兩條登入路徑：各自依賴的元件與仍然共用的部分

登入路徑上的每一個元件都可能失效：代理程式沒有啟動、服務不支援這個組合、權限漏給、出站路徑被收緊、sshd 的設定改壞。只有一條路徑時，那條路徑上任何一個元件失效，主機就沒有入口；這個代價在重建昂貴時才成立（主機上有狀態、機型容量難取得、第一次用這個機型加作業系統的組合）。主機不存狀態、重建便宜時，重建本身就是那一條備用路徑，見 伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口 的〈不可變基礎設施下的臨時授權：通道平時關閉〉。備用路徑能不能當退路，看它跟原本那條路徑共用哪些元件：共用的元件失效時兩條一起斷，例如 Oracle Cloud 的 managed SSH session 與 Run Command 都經由主機上的 Oracle Cloud Agent，代理程式停掉時兩者一起失效。所以要把兩條各自依賴的元件逐項列出來，確認建立之前最沒有把握的那一項（這次的機型加作業系統是否在支援範圍、代理程式會不會正常運作）只出現在其中一條上。

列的時候要把整條路徑走完，不只看名字裡的服務。Oracle Cloud 的 managed SSH session 名字裡只有 Bastion，而 plugin 做的是把公鑰臨時放進 authorized_keys，登入照樣經過主機的 sshd；官方〈Managed SSH Session Creation Failed〉把 sshd 設定與 authorized_keys 列在成因裡。三家常見的組法與它們實際依賴的元件：

• Oracle Cloud：managed SSH session 依賴 Bastion plugin、機型與作業系統在支援範圍、代理程式連到服務端點的出站路徑；SSH port forwarding session 不經過 plugin，依賴建立時放進中繼資料、由 cloud-init 寫進 authorized_keys 的公鑰。兩條仍然共用 Bastion 服務與它允許連入的來源位址、建工作階段的權限、security list 放行 22 port 的規則、主機的 sshd。所以這一組擋得住 plugin 與支援範圍出錯，擋不住 sshd 改壞或 Bastion 允許的來源位址過期。
• Google Cloud：IAP TCP forwarding 加 OS Login 依賴 IAM 角色、防火牆放行 IAP 的來源位址 35.235.240.0/20、guest environment 處理的 OS Login，以及主機的 sshd。OS Login 啟用之後主機忽略中繼資料裡的公鑰，OS Login 開著時同一台主機上沒有另一條不經過 OS Login 的 SSH 路徑；對單台主機把中繼資料設成 enable-oslogin=FALSE 會恢復 guest agent 同步公鑰的路徑（主機層級的設定蓋過專案層級），組織政策強制 OS Login 時這條用不了，而且它仍然共用 IAP、防火牆、guest agent 與 sshd，算不上獨立的備用路徑。所以常備的備用路徑是序列主控台（serial console）加事先建好的救援帳號：它經由 Google 的序列埠閘道連線，用中繼資料裡的 SSH 公鑰驗證連線者，不經過主機自己的網路設定與 sshd，在登入提示用救援帳號的密碼登入。
• AWS：Systems Manager Session Manager 依賴 SSM Agent、Systems Manager 操作這台主機的權限與出站路徑，不經過 sshd；EC2 Instance Connect 或建立時選的 key pair 依賴 sshd、security group 放行 22 port，以及連得到主機的網路（公開 IP、私有連線或 EC2 Instance Connect Endpoint），EC2 Instance Connect 另外要登入者的 IAM 權限。這兩條共用的元件最少。官方另有 EC2 Serial Console，支援 Nitro 系統上的主機，要先完成存取設定、主機裡要有設了密碼的帳號。

三家都有一條不經過 sshd 的救援入口：序列主控台加設了密碼的救援帳號。這個帳號要在主機還登得進去時建，或建立時用初始化腳本建；Oracle Cloud 與 AWS 的平台映像，預設使用者只用金鑰登入、沒有密碼。救援帳號怎麼建、序列主控台平時為什麼關著，見 Serial Console（序列主控台） 卡。

兩條路徑都要在停用公開 IP 的 SSH 這類其他入口之前，各自實際登入過一次。只寫在設定裡、沒登入過的路徑，登入時才會發現少了哪一項條件；這跟切換管理通道時救援入口要先準備好並登入過是同一件事，見 伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口 的〈救援入口：管理通道斷掉時的備用路徑〉。

不放公鑰減少了主機裡長期有效的金鑰，代價是在 Oracle Cloud 上拿掉了不經過代理程式的那一條路徑。放在私有 subnet、沒有公開 IP 的主機，網路可達性這一層已經擋住外部的連線，用得了這把公鑰的只剩持有私鑰、而且有建工作階段的權限或已經在同一個 subnet 裡的人，增加的暴露很小，換到的是代理程式失效時的入口；代價是這把金鑰要管理、人員離開時要收回，而在 Oracle Cloud 上，中繼資料裡的公鑰建立後不能換。同時滿足「主機裡沒有長期有效的使用者公鑰」與「不依賴代理程式」的做法是 SSH 憑證：建立時用初始化腳本放 CA 的公鑰，登入時用 CA 簽的短效憑證，代價是要維運一個 CA；在 Oracle Cloud 上 CA 的公鑰同樣經由建立後不能改的初始化腳本放入，換 CA 要登入主機改或重建，做法見 伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口 的〈主機登入驗證的做法：SSH 金鑰怎麼發、怎麼收回〉。所以第一次在某個機型加作業系統的組合上建主機時，放一把自己的公鑰。這把公鑰之後要不要從 authorized_keys 拿掉，取決於另一條不共用代理程式的入口在不在：拿掉之後只剩代理程式那一條，回到單一路徑；先建好序列主控台的救援帳號並登入過，拿掉公鑰時才仍然有兩條，而救援帳號的密碼同樣是長期有效的憑證，要逐台輪替（見 Serial Console 卡的〈設計責任〉）（Oracle Cloud 上的做法與前提見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉最後一段）。

容量稀缺時設定的取捨：補救代價與最嚴格設定的驗證位置

機型的容量難取得時（免費額度裡的熱門機型、GPU 機型），建好就改不了的設定選錯的代價，除了重建，還多了一次重新取得容量。Oracle Cloud 的 Always Free A1 在 ap-batam-1 實測時，同一個帳號 2026-10-24 整天的建立請求都回容量不足，2026-10-25 用重送腳本送了 16 次才建成（重送的做法與限流的量測見 Oracle Cloud 建立主機的實測紀錄 的〈重送建立請求：CLI 自己的重送、限流門檻與重送腳本〉）。

這時的取捨是選補救代價低的設定：作業系統與版本選登入服務完整支援的那一個、建立時放一把之後可以移除的公鑰、兩條登入路徑都備齊。最嚴格的設定（不放任何金鑰、只靠代理程式）要拆成兩部分驗：跟機型無關的那一部分（代理程式的設定、登入權限、防火牆規則）可以先在容易重建的機型上測；跟機型有關的支援範圍，照〈登入路徑上各服務的支援組合：支援清單、Known Issues 與元件狀態〉讀文件對這次的機型確認，演練驗不到這一部分。必須在某個時間點拿到容量的情境，可以改用預留容量（capacity reservation），見 機型與映像檔：CPU 架構、核心與記憶體、計費模式與作業系統 的〈計費模式：隨用隨付、可被收回、預留容量與專屬主機〉。

搶容量的重送腳本把建立參數寫死在腳本裡，所以腳本送出的設定，是寫腳本那一刻的判斷。從寫好腳本到建成主機可能隔了好幾個小時，這段時間裡查到的新資訊（Known Issues 的一條、某個服務的前置條件）不會自己進到腳本裡；腳本裡的參數要在兩個時間點再對過這一篇的檢查（建好就改不了的設定、各服務的支援組合、兩條登入路徑各自依賴的元件）：重新啟動腳本的那一刻，以及腳本還在跑時查到會改變建立參數的新資訊的那一刻（這時先停掉腳本，改完參數再啟動）。一開始就選補救代價低的參數時，判斷過期的代價也跟著變小。

各家查建立後不能改的欄位、登入服務支援組合與代理程式狀態的位置

「代理程式與 plugin 的執行狀態」那一列查到的是元件有沒有啟動；〈登入路徑上各服務的支援組合：支援清單、Known Issues 與元件狀態〉那一節的支援清單與 Known Issues，仍然要另外讀。設定也不等於實際：Oracle Cloud 主機的 agent-config 寫著 Bastion 是 ENABLED 只是期望的狀態，plugin list 裡根本沒有 Bastion 這一項時，代表這個映像版本不提供這個 plugin（2026-10-25 的 Oracle Linux 10.2 主機就是這樣）。