一、前言：為何要將主機搬遷上 GCP？

其實將主機搬遷上雲的理由和好處很多，這裡提供三個最重要的理由如下：

(一) 降低成本

GCP 是每月依使用量計費，每月付款，企業可以從一次性大額採購的「資本支出」，轉變成每月的「費用支出」，減低現金流的壓力。

此外，實體機要考慮機房、水電相關設備的建置和維護成本，在管理上也是耗費不少心力。

而公司採用雲端，等於就是把基礎建設外包給專業的 Google，你可以省下許多寶貴的時間，然後專注在開發公司產品或提供服務，為公司創造更大的價值。

(二) 彈性擴充

在地端，你的機器數量是固定的，如果碰到活動期間，需要緊急擴充機器，往往要走採購流程包含詢價、議價、選商，以及後續的安裝建置，等到機器準備好了，活動都結束了。

而在雲端上有所謂的自動擴充 (Autoscale)，你可以在 GCP 主控台上設定擴充的功能，指定要擴充的數量，接著 GCP 會依照當前主機的負載，如果主機太過於忙碌，GCP 會立即增加主機來對外服務。當活動結束，人潮退去時，機器也能自動縮減，不會讓它閒置導致額外的花費。

(三) 創新整合

和其他公有雲相比，Google 的強項就是大數據分析與人工智慧。如果你的系統在 GCP 上運作，可以輕易導出資料到 BigQuery 來分析，發現洞察。你也可以將資料用來訓練模型，開發 AI 應用程式。不需要尋找外部工具，從頭到尾都在 GCP 做完。

當你開發完成，也可以直接在 GCP 上部署 AI 應用，或是做為  API 讓外部來呼叫，這些都是 GCP 內建的功能，讓你從收集資料、開發模型、測試模型到部署 AI 應用，都可以透過 GCP 來達成。

從商業的角度來看，就是加速你回應市場的速度，當市場上有新的技術或是新的商機出現，你就可以快速的在 GCP 取得各種創新資源，讓你可以快速的開發出應用程式，提供給廣大的使用者。 

以上只列出常見的上雲理由，如果你想知道更多，可以參考《企業上雲的10大理由、15個評估面向與6大好處》和《上雲比較貴？雲端和地端的成本詳細比較》這兩篇文章。

二、主機搬遷類型

將主機搬遷上雲有很多方法，我們可以依照系統的狀況 (例如好不好搬遷)，和公司的時間表 (有沒有急迫性或是足夠的人力) 來選擇適合的搬遷類型，這裡分別介紹如下： 

(一) 更換主機 (Rehost)：照原來樣子搬遷 (Lift And Shift)

這種搬遷方式就像是單純的搬家，把所有東西從舊環境搬到新環境，期間只做最少必要的調整。就像是把傢俱從舊房子搬到新房子，只需要因應新房子的格局做一些微調而已。

當你的系統可以直接在新環境運作，或是當業務上沒有需要對系統做太多更改，又或者當你需要快速完成搬遷時，這種方式就特別適合。

這種方式的優勢在於執行起來最簡單，團隊可以繼續使用熟悉的工具和技能，而且支援現成的軟體，最重要的是搬遷速度最快。

但這種方式也有其侷限性，系統無法充分發揮雲端環境的優勢，也無法善用 GCP 的特殊功能，包括自動擴充的能力、更靈活的計費方式。這就像是把老房子整棟搬到新地點，雖然可以快速入住，但無法享受新社區提供的現代化設施。

不過企業會因為各種因素，不得不採用這種方式，例如程式碼太老舊或複雜而不容易修改，或是重新編譯程式很困難，又或者必須持續維持系統運作而沒辦法停機重做。

(二) 更換平台 (Replatform)：重新優化 (Lift And Optimize)

想像一下，這不只是單純的搬家，而是搬家時順便整修。就像是搬到新房子時，不只是搬運傢俱，還會順便更換一些老舊的設備，或是重新規劃空間跟裝潢，讓新家更好用。

把主機內的系統搬到 GCP 上，讓它能用上更新、更有效率的工具和服務。這種搬遷方式最適合那些希望充分運用雲端核心功能的組織，包括彈性運算能力、系統備援、提升效能和加強安全性等優勢。

舉例來說，你可以將應用程式轉移到 GCP，以便使用 Google Kubernetes Engine 提供的微服務架構或容器服務。這樣一來，系統在雲端運行時就能發揮更好的效能和效率。

不過呢，這種搬家方式當然會比單純搬家麻煩許多。因為新環境的設備和系統都不太一樣，所以需要多花時間測試、調整，確保所有東西都能完美運作。就像是要學習使用新家裡的各種 AI 電器，需要一段適應期一樣。

(三) 重構 (Refactor)：徹底改造升級 (Move And Improve)

重構這種搬遷方式就像是趁搬家時，不只是簡單改裝，而是徹底翻新改造，讓系統能充分運用雲端的各種優點，已經不是針對「主機」來搬遷了。你可以針對效能、功能、成本和使用體驗，把每個部分都改造得更好。

這個改造工程可以選擇在搬到雲端時一起進行，也可以提前先做好。就像是裝修房子，如果你是第一次做大規模裝修，可能會想等搬家時再一起處理。但如果你有經驗，就能提前規劃好需要改造的部分，讓系統更好地運用雲端的功能。

有時候你會被迫選擇重構，因為舊系統的架構可能無法直接在新環境中運作。又或者是趁這個機會，你想要對系統做一次大規模的更新和改進。

重構的好處是你的系統可以充分運用雲端平台的特色，例如自動擴充 (Autoscale) 的功能，或是提高系統的穩定性。你還可以讓系統變得更容易在不同平台間轉移。

不過呢，重構需要花比較多時間，畢竟要把整個系統重新改造一番。而且你的團隊可能需要學習新的技術和工具，就像是要學習使用全新的裝修工具和材料一樣。

(四) 重新設計架構 (Re-architect)：全面改頭換面 (Continue To Modernize)

這種搬遷方式和前面說的重構有點像，但更加徹底。它不只是改變系統程式碼的運作方式，而是完全重新設計整個系統的運作模式。

這就像是不只是翻修房子，而是把整棟房子拆掉重建，讓它能充分運用新環境的優點，像是更好的擴充性、安全性和靈活度。

最經典的例子就是從單體式架構（Monolithic）轉換成微服務（Microservices）架構。單體式架構就像是一間大型百貨公司，所有部門（功能）都在同一棟大樓裡，所有服務都綁在一起，任何一個小改動都要動到整個系統。並且擴充時必須整個系統一起擴充，如果有一個地方出問題可能影響整個系統。

而當我們改成微服務架構後，就像是把大百貨拆分成許多專賣店，每個服務都是獨立的小系統，可以個別更新和維護，當需要擴充時，可以只擴充需要的服務。

某個服務出問題時不會影響其他服務，不同的服務可以使用最適合的技術，不一定都要使用虛擬機器，有的可以用 Cloud Run，有的可以用 GKE。

不過要注意的是，這種全面改造比一般的重構更複雜，需要投入更多時間和心力。而且在重建的過程中，可能會不小心引入一些程式錯誤或安全漏洞。

因此，需要進行多次測試，確保新系統的每個部分都能完美運作，就像是新蓋好的房子需要仔細檢查每個管線和設備是否安全可靠。

(五) 重建 (Rebuild)：完全推倒重來 (Remove and Replace or Rip and Replace)

重建就是重寫，就是先把現有的系統停用，然後重新設計並開發一個完全針對雲端優化的全新系統。

什麼時候會選擇重建呢？通常是在這些情況：

• 當你覺得舊系統已經不值得繼續維護
• 當其他改造方式的成本太高
• 當舊系統根本無法在 GCP 上運作

重建的好處是，新系統可以完全發揮 GCP 的優點，像是自動擴充、完整的雲端服務支援，以及超高的系統穩定性。而且因為是從頭開始，你不用被舊系統的技術包袱拖累。就像蓋新房子可以使用最新的建材和設計，不用被舊房子的格局限制。

但是呢，重建需要最多的時間，比其他方式都久。而且因為要重寫整個系統，所以不適合用在現成的軟體上。你需要把重新設計和重寫的時間都算進整個專案的生命週期裡。

另外，你的團隊可能需要學習全新的技術和工具，因為要用新的工具來設定環境並部署系統。這就像是要學習使用全新的建築工法和工具來蓋房子一樣。

(六) 重新購買 (Repurchase)

這種方式最簡單，就像是不想修理舊電器，直接去買新的雲端服務來用，其實就是不搬遷了，直接買新的來用。

舉例來說，與其維護公司自己的郵件系統和檔案系統，不如直接改用 Google Workspace (就是 Google 的企業版 Gmail、雲端硬碟等服務)。

從資源投入的角度來看，這種方式比重構、重建或重新設計架構簡單多了。就像是比起修理老舊的冰箱，直接去買一台新的智慧冰箱來用比較不費心。

不過要注意的是：

• 這種方式的花費可能比較高，因為要持續付費使用服務
• 你可能無法完全掌控系統，因為是用人家現成的服務，就像是租用別人的設備，雖然方便，但無法像自己的設備那樣隨意改造和調整，自由度比較低。而且有可能會被綁住，沒有辦法輕易更換系統，或是匯出資料。

綜上所述，我們可以把各種搬遷類型整理如下：

如果想完整了解搬遷類型，可以參考這份文件。

三、主機搬遷步驟

根據 GCP 官方部落格提到，搬遷的步驟如下圖：

(一) 盤點 (Assess)

在進行搬遷之前，請評估您的應用程式以及它們對 GCP 的適合程度。

需要考慮的事項包括 (但不限於) 硬體和效能需求、使用者、授權、合規性需求和應用程式相依性。

一般來說，應用程式大概分種三種：很好搬、很難搬和不能搬。通常建議先選最好搬的，或是測試中的系統，或是較不重要的應用程式，因為搬遷中碰到問題，畢竟不是核心系統，對公司影響較小。

(二) 測試 (Pilot)

這步驟主要是讓你在搬遷過程中熟悉整個操作流程和 GCP 的搬遷介面，對於複雜的系統也可以測試，尤其是有授權議題的主機，如果搬遷有問題也可以試著回溯 (Roll Back)，確保到時候正式搬遷會有一個 (Plan B) 備用計畫。

(三) 搬遷資料

根據Google官方的說法，建議先搬遷資料到 GCP，再搬遷應用程式，因為你的應用程式要能正常運作，必須要先存取到資料，否則應用程式即使搬上去，因為它撈不到後端的資料，還是會出問題。

在下一段會先分享搬遷主機的方法，你可以先試著搬遷不需要連接外部資料庫的主機，確認都沒問題的話，再搬遷資料庫，最後再搬遷應用程式。

(四) 搬遷應用程式

正式搬遷的時候，盡量保持用最簡單的流程和方法，並且執行最少的操作。 

(五) 優化

在搬遷完成之後，你可以考慮讓你的系統運作的更好。例如增加可用性 (HA)，或是使用自動擴充 (Autoscale) 以及使用監控程式 (OPs Agent)，或是把靜態資料放在 Cloud Storage。

而在實務上，我們通常不會等到搬遷完成才開始優化，而是在搬遷之前，就會依照應用程式的特性，來判斷他適合在什麼樣的 GCP 服務上面運作。前面規劃的越多，後面花在調整的時間越少。 

如果想完整了解搬遷步驟，可以參考這份文件。

四、主機搬遷具體方法

由於大多數使用者在地端運作的系統，都是單台虛擬機器的形式，本段針對大家最常用的「更換主機」 (Rehost) 這一類型，依照使用的工具，分成 Migrate to Virtual Machines 和 VMware HCX 來說明如下。

(一) Migrate to Virtual Machines

Migrate to Virtual Machines 是一個代管的服務，就是一個網頁介面，讓你可以直接在網頁上操作並監控整個搬遷的過程，操作起來非常簡單。

你可以直接匯入主機的映像檔，也可以讓主機平行運作，就是讓地端主機還在運作的同時，複製主機的資料到 GCP 上，複製並確認完後再進行切換動作。

如果你有大量主機要搬遷，你不用一台一台機器手動設定搬遷，你可以把多台主機設定為同一批次，讓他們同時複製資料到 GCP。

不過要注意的是，並非任何作業系統的主機都可以搬遷，目前支援各種 Linux 和 Windows Server 作業系統的 64 位元 x86 虛擬機器，另外也支援 Oracle Linux 作業系統。

但是要注意版本，像是太舊的版本像是 CentOS 6 雖然可以搬上 GCP，但是主機有問題，GCP 是無法提供技術支援的喔！對於支援的作業系統完整清單，可以參考這份文件。

以下分別描述 Migrate to Virtual Machines 各種搬遷方法：

1. 匯入主機檔案

(1) 匯入虛擬機磁碟映像檔 (Virtual Disk Images)

如果你手上有現成的虛擬機磁碟映像檔，可以直接匯入，完成之後可以馬上用這個映像檔，在 GCP 建立和地端一樣的虛擬機器。

虛擬機磁碟映像檔支援的格式包含：VMDK、VHD、VHDX、VDI、QCOW、QCOW2、QED 等，也支援 .tar.gz 檔案，你要確保壓縮檔案包含名為 disk.raw 的單一檔案。

不過要注意的事，這個虛擬機磁碟映像必須要先儲存在 Cloud Storage，所以你必須要先上傳檔案，然後再去 Migrate to Virtual Machines 的主控台上匯入它。

而在匯入之前，由於 Migrate to Virtual Machine 這個服務背後是有一個 Service Account 在運作，而它目前沒有權限去 Cloud Storage 存取任何檔案，所以我們就先去給它賦予權限。

我們進入「IAM 與管理」=>「身分與存取權管理」=>再勾選「包含 Google 提供的角色授予項目」：

接著視窗往下滑，會你看到像這樣的 Service Account：

service-xxxxxxxxxx@gcp-sa-vmmigration.iam.gserviceaccount.com

接著點擊 VM Migration 服務代理右邊的鉛筆圖示：

接下來就可以把你準備好的 VMDK 檔案上傳到 Cloud Storage：

上傳完成之後，你就可以點擊 Compute Engine 的 Migrate to Virtual Machines。接下來可以點擊「映像檔匯入作業」：

接著再點擊「建立映像檔」：

接著它就會進入建立映像檔的畫面，首先就是在 Cloud Storage 選擇要匯入的檔案，接著由於虛擬機映像檔會轉換成 GCP 格式的映像檔，所以我們要另外選擇儲存的位置，看你要多區域 (例如 Asia) 或是單一區域 (例如 asia-east1) 都可以：

當我們選好檔案跟儲存位置後，再選擇要儲存映像檔的專案，因為你手上可能有不只一個專案，它讓你不一定只能使用現有的專案，可以選擇匯入到其他你有權限的專案。

但你點擊下拉選單之後，你會發現沒有目標專案可以選，因為它必須要事先勾選起來，才會在這個畫面看到可以選擇的專案。但是沒關係，我們也可以在這裡直接設定，點擊「管理目標專案」：

點擊之後，它會開啟新的視窗，我們再點擊「新增目標專案」：

接下來它會彈出一個視窗，讓你勾選目標專案，我們勾選後就按下新增：

接著畫面會跳轉到目標專案，你可以再確認一次：

再回到原來的分頁，按下「重新整理」：

等待幾秒之後，專案就秀出來了，選擇這次要建立映像檔的目標專案：

上述相關欄位設定好之後，會看到像這樣的結果。其中還有兩個選項需要注意。

(1) 略過 OS 調整作業：

指的是為了讓你在地端的主機可以在雲端上運作，它需要做一些調整，才能讓它在 GCP 上開起來。包含：

・Serial Console (讓你在SSH無法連線時還能操作主機)

・網路設定 (讓主機可以連到 VPC 內的主機、其他 API 和上網) 

・Cloud SDK (讓你可以下 gcloud 指令操作 GCP的資源)

如果你匯入的映像檔不是拿來當作開機碟，那可以勾選「略過 OS 調整作業」，如果是，就不能勾選，要不然主機會無法在 GCP 成功開啟。更多細節可以參考這份文件。

(2) 一般化：

通常是針對 Windows 作業系統，因為 Windows 作業系統會有一些「針對該主機的識別資訊」，例如 SID (Security Identifier)，勾選「一般化」可以將其識別資訊洗掉，以便部署到其他地方，才不會有識別碼衝突的問題，而 Linux 沒有這方面的問題，不用勾選。更多細節可以參考這份文件。

如果都沒問題的話，可以按下「建立」：

接下來畫面跳轉到 Migrate to Virtual Machines 主頁，看到正在匯入映像檔的訊息：

我們等待一下，因為這個動作都在 GCP 上進行，我們可以關掉視窗，稍後再回來查看即可。

接著我們就看到 VMDK 檔案已經匯入成功，看到它已經成為 Compute Engine 的 Image 了。

接下來我們可以直接點擊箭頭圖示，直接轉到 Image 的頁面：

然後點擊「建立執行個體」，把它開成一台 GCP 的主機：

就跟一般建立機器的步驟一樣，我們給主機取名字，並選定規格：

其他參數可依照你的需求設定，沒問題就可以按下「建立」。

過幾秒後看到主機建立完成，我們點擊 SSH 按鈕：

看到 SSH 視窗成功開啟，代表我們從地端匯入 VMDK 檔案成功囉！

如果你的機器能開機，但是連不進去的話，先不要慌，你還是可以透過 Serial Console 調整一下主機，可以參考這份文件。

(2) 匯入機器映像檔 OVF, OVA

這個方法跟前一個幾乎一樣，都是先把檔案上傳到 Cloud Storage。但不同的地方是，前段的映像檔只有開機磁碟而已，如果你的主機有加掛磁碟的話，你就必須再匯入另一個映像檔，等到兩個映像檔都匯入完成，再用第一個映像檔來開機，再手動掛載另一個映像檔的磁碟。

機器映像檔則是直接包含一台主機所有的磁碟，如果你匯入機器映像檔，你就不用手動匯入多個檔案了。

首先我們點擊「建立機器映像檔」：

我們一樣設定作業名稱、來源、部署區域、目標專案等等，沒問題就按下建立：

接著就等它開始作業，我們可以在畫面上確認機器映像檔匯入的進度：

確認匯入成功後，一樣進入機器映像檔管理控制台，用機器映像檔來建立機器：

我們在主機列表看到機器成功建立，接著點擊 SSH 按鈕：

接下來就看到 SSH 連線成功的畫面，確認匯入成功。

關於匯入映象檔或是機器映象檔，還有一個更簡便的方法，不過它是使用 gcloud 指令來操作 你可以參考這份文件。 

上述方法最容易卡住的地方，就是我們要匯入的檔案有問題，可能是作業系統或是檔案格式的問題，造成匯入失敗的機率很高，所以請再匯入之前多確認映像檔的內容。

2. 從地端 VMware 環境搬遷主機或 Disk

這個方法的前提是你在地端必須要有一個 vSphere 資料中心，然後再搬遷之前會有一系列的前置作業，讓你的地端和雲端可以連接在一起，之後才能開始搬遷，如下圖：

雖然比較麻煩，但是它可以針對大批的主機一口氣快速搬遷，而不是像上述方法一台一台操作。

此外，因為主機是在 VMware 環境，搬遷到 GCP 有比較高的相容性，所以這個方法成功率高很多。 如果你在地端有大量的主機需要搬遷，強烈推薦使用這種方法。

搬遷的前置作業分述如下：

(1) 挑選一個主要專案 (Host Project)

如上圖，我們在雲端上有多個 GCP 的專案，你可以挑選一個主要的專案 (Host Project) 來負責執行搬遷工作，但是你搬上來的主機不一定要部署在這個專案上，你也可以部署到另外一個專案上去。

(2) 啟用相關的 API
由於搬遷過程中會呼叫 GCP 各種不同的 API，所以我們要事先啟用，這裡提供一個快速的指令，讓你可以直接複製貼上，然後在 Cloud Shell 或是你有安裝 gcloud CLI 的電腦執行：

gcloud services enable vmmigration.googleapis.com servicemanagement.googleapis.com servicecontrol.googleapis.com iam.googleapis.com cloudresourcemanager.googleapis.com compute.googleapis.com

(3) 授權給相關人員

如果有許多人員要參與搬遷，你可以授權這兩個角色給相關的人員：

VM Migration Administrator：是給執行搬遷的人員使用。

VM Migration Viewer：如果其他的人想要查看搬遷的相關資訊，不直接動手操作。

(4) 在 vCenter 建立使用者帳號

因為我們會在 vSphere 建立一台主機，並且安裝 Migrate Connector，而這個 Migrate Connector 需要有一個使用者的帳號，並且要擁有相關權限，才能夠呼叫  vCenter的API，去把 VMware 主機的資料拉出來並且搬到雲端上。

(5) 在 GCP 準備一個使用者帳號和服務帳戶

這個使用者帳戶必須要有權限，才能註冊 VMware 上的 Migrate Connector 主機到 GCP。它只有在註冊的那一刻需要相關的權限，只須執行一次性的註冊動作。

而在 GCP 上面也要有一個服務帳戶，用來存取 19 項 GCP 資源，來完成搬遷的動作。 如下圖：

(6) 設定網路存取

在 GCP 這邊，因為都是開放的 API，比不需要特別再去設定，反而是地端那台 Migrate Connector 主機，要確保網路流量可以存取得到 vCenter、vSphere 和上網存取 GCP 相關服務。如下圖：

如果防火牆也有限制，要記得開放存取到 *.googleapis.com 和 gcr.io 這兩個網域喔！

(7) 建立連線到 Migrate Connctor 所需的 Key

為了要安全的連到 Migrate Connctor ，你必須建立一組金鑰，等到這台機器建立完成，你就要透過這個金鑰連線進去操作。你可以在任何地方使用 ssh-keygen -t rsa 這個指令來建立金鑰，如下圖我們是用 Mac 本機電腦來建立的：

(8) 安裝 Migrate Connctor
接下來環境切換到 vSphere，點擊 Deploy OVF Template 然後貼上 Migrate Connector 機器映像檔的網址：

接下來等它安裝完成，看到主機的資訊如下：

(9) 連線到 Migrate Connector 主機並註冊到 GCP 

我們使用 SSH 連到 Migrate Connector 主機之後，輸入 m4c register 開始註冊，經過一連串的互動操作，可以看到註冊成功的畫面：

我們回到 Console 上就會看到地端的機器列表，這時我們就可以選定要搬遷的主機：

雖然是將主機一模一樣的搬到 GCP，但是我們並不一定要使用一模一樣的規格，我們可以設定部署的規格跟環境：

接下來就開始進行資料複製的動作，等到複製完成，我們可以先點擊「Test-Clone」，來觀察資料是否都複製完成，它會建立一台測試機，讓你進去檢查。如果確定都沒問題的話，我們再點擊「Cut-Over」 ：

最後我們可以在 Console 上看到主機切換完成的相關訊息：

這裡要注意的是，它的「切換」會把原來的地端主機「直接關機」，如果你不希望機器被關，目前的方法就是再手動把它開起來。 

很多使用者會藉由這個功能，執行雲地資料同步的動作，不過不算正規方法，所以沒有備份的保證喔！只是因為做起來很方便，單純分享給各位參考！

(二) VMware HCX 

GCP 本身可以建立一個純粹的 VMware 環境在雲端，叫做 VMware Engine，而這個環境可以和地端的 VMware 環境連結在一起。既然兩邊都是 VMware，就可以使用 VMware 本身的 HCX 將地端的主機無縫的搬遷到雲端上，但不是 Compute Engine 主機的形式，而是 VMware 格式的主機。

所以它具體的搬遷方法是由 VMware 所發展的， GCP 就只是提供基礎建設，讓 VMware 可以在 GCP 上面順利運作，整合概念圖如下：

而這樣的服務要在 GCP 上開起來，必須要使用通過 VMware 認證的主機，我們可以從「VMware Engine」進入「私有雲」，然後點擊「建立私有雲」 ：

接下來你會發現台灣 (asia-east1) 並沒有提供這樣的環境，VMware Engine 離台灣最近的資料中心在新加坡 (asia-southeast1)：

另外我們在設定節點數量的時候，系統會要求至少要三個節點以上，而每個節點的規格是 72 個 vCPU和 768 GB 的記憶體，以及1.92 TB 的 Disk 空間，可以知道它的費用不低，有一定規模的跨國企業才有機會使用這樣的服務：

我們在 YouTube 看到有人示範 HCX 操作的畫面，功能和 Migrate to Virtual Machines 很像，首先就是勾選要搬遷的主機：

接著我們就設定主機要搬遷的目的地：

在設定的過程當中，也可以設定目的地的主機規格和環境參數，你還可以設定搬遷的排程，例如在幾月幾號的幾點開始搬遷。

開始搬遷之後，你也可以在畫面上看到搬遷的進度：

關於更多 HCX 的操作細節，可以參考這份文件。

另外這樣的規模通常都不小，我們可以聯絡代理商或是 Google 原廠，來提供相關的技術服務喔！

五、結論

最後我們總結從地端搬遷主機到 GCP 的方法，整理比較表如下：

不管你是哪一種企業規模或是場景，都建議你先從匯入映像檔的方式開始，不是真的要你在正式搬遷都用這個方法，而是要你藉由這個動作，去熟悉整個搬遷的流程、細部操作和相關的注意事項，讓你了解搬遷過程的全貌。

這樣才能在正式搬遷之前，做好完整的評估和規劃，和搬遷失敗的處理方式，讓你確保在公司系統照常運作，影響最小的前提之下，讓搬遷順利成功。

本文同時刊登於：

【東東老師 X 思想科技】地端主機如何搬上 GCP？（上）

【東東老師 X 思想科技】地端主機如何搬上 GCP？主機搬遷具體方法（下）

The post [GCP 教學] 地端主機如何搬上 GCP？各種方法和步驟詳解 first appeared on 東東 GCP 教學 - GCP 實戰講師.

大家最常用的 Compute Engine，也就是所謂的 VM 虛擬機器平台，也是這樣計算的。

我們在每個月使用過後，在下個月初會收到 GCP 的帳單，再自動扣款繳費即可。

本文先介紹 VM 最基本的計費方式，再針對短期和長期折扣詳細說明，最後教大家操作 GCP 費用計算機，讓大家可以完全掌握整個費用。

對了，先確認你已經用過 $300 美金的試用了嗎？如果還沒，可以參考這支影片來申請喔！

一、GCP VM 基本計費方式

主要分成主機規格、作業系統、硬碟大小、網路流量和 IP 位址五種計費項目。

這邊先提醒主機的記憶體、硬碟大小和網路流量的單位是 GiB 而不是 GB 喔！

而 1 GiB 約等於 1.07 GB，所以 GiB 是比較大的單位，可參考維基百科說明。

(一) 主機規格

主機規格包含型號、vCPU 數量和記憶體的大小。

VM 的型號非常多種，例如 N1、N2、M1、M2、到 Z3 等等，但是計費方式都一樣，不同型號有不同的 vCPU 和記憶體單價。

我們以在台灣 (asia-east1) 這個 Region 的 N1 為例，n1-standard-1 配的是 1 個 vCPU 和 3.75 GiB 的記憶體，每小時費用是 0.055 美金，如下表：

要注意的是，雖然表格是寫 Hourly，但它是以秒計費的，也就是說，你今天這台機器只開半個小時，那它就是 0.0275 美金而已。

但是它的最低消費是 1 分鐘。

就是說如果你的機器只開 30 秒就刪掉了，那它會計 1 分鐘的費用。

但如果你開了 1 分 30 秒的話，那它就會計成剛好 90 秒的費用。

我們也可以點擊右上角的開關，切換為每月的費用：

你會看到 n1-standard-1 是 40.15 元，它是 0.055 * 每月 730 小時得出來的數字。

為什麼要用 730 小時呢？

因為每年的天數不同，每年又有分大月和小月，所以 Google 把 730 小時做為平均每個月的小時數，避免每次都要考慮到底是 31天、30 天甚至 28 天的問題。

而同樣是 N1 的主機，還分成高 CPU 使用率和高記憶體使用率的機器類型，所以請直接參考表格來估算價格。

另外，GCP 不是只有配好的規格而已，你可以自訂想要的 vCPU 和記憶體的用量比例，例如你可以用拉 Bar 拉一個 1 vCPU 和 6.5 GiB 的規格，這是其他公有雲做不到的。

要注意的是，自訂規格的價格會有所不同，如下表：

甚至，我們還可以加開擴充記憶體，如下圖我們開到 624 GiB 這種非常特殊的規格：

而擴充的記憶體，單價也是有所不同：

上述提供的都是持續存在的 VM，另外還有 Spot VM，指的是 GCP 閒置的資源，如果你有「不那麼緊急」的工作要處理，你可以用非常便宜的價格使用 Spot VM，大約在 60%~91% 的折扣範圍，如下表：

但要注意它 Spot VM 的價格是浮動的，每 30 天就會更新一次，所以在使用之前，務必確認一下當前的價格。

還有 Spot VM 是隨時都會被 Google 收回去的，相關注意事項請看這份文件。

(二) 作業系統

如果你用的是免費，應該說是 Open Sourced 的 Linux 版本，例如 Debian、Ubuntu、CentOS、Fedora 或 OpenSUSE，是不用任何作業系統授權費的。

如果你是使用 Windows、Radhat、SUSE Linux Enterprise，或 SAP 相關的作業系統，就要額外付授權費。

我們以最常用的 Windows 為例：

1. 如果你只用 Windows Server 

它是每個 vCPU 小時在計費的，一個 vCPU 每小時是 0.023 美金，例如你用 n1-standard-4 跑 24 個小時，授權費就是 ：

4 個 vCPU * 0.046 * 24 = 4.416 美金。

那如果是所謂的共用核心 (Shared Core) 呢？

像是 f1-micro 和 g1-small 都算每小時 0.023 美金。

低消部分跟主機規格一樣，不到 1 分鐘算 1 分鐘費用，超過則以秒計費。

2. 如果你使用 Windows Server 和 SQL Server

那就是除了上述的費用之外，再另外加 SQL Server 的授權費，而 SQL Server 還有分版本：

SQL Server Enterprise 每核心每小時 $0.399 美金；

SQL Server Standard 每核心每小時$0.1200 美金；

SQL Server Web 每核心每小時 $0.011 美金；

SQL Server Express 不計費。

注意低消部分跟上述不同，不到 10 分鐘算 10 分鐘費用，超過則以分計費喔。

另外要注意，你的主機必須開 4 個 vCPU 以上，如果開不到 4 個 vCPU，還是算 4 個 vCPU 的授權費喔！！

3. 自帶授權 (Bring Your Own License; BYOL)

如果你原本就有向微軟的代理商購買授權的話，你可以透過自帶授權的方式，在 GCP 上使用自己購買的微軟授權。

但要注意，一般的 Windows Server 授權本身不足以讓你在 GCP 上使用 BYOL，你需要有 Software Assurance（SA）- 這是微軟的一個額外服務計劃，給予你「License Mobility through Software Assurance」的權利，這才允許你將授權移轉到公有雲使用，不管是 GCP 或 AWS。

如果確定有購買 Software Assurance 的話，你在 GCP 只要花費主機費用，就不會被額外收取授權費喔！關於微軟授權的注意事項，可以參考這份文件。

(三) 硬碟大小

目前 Disk 分成 Standard、Balanced、SSD、Extreme 和 Hyperdisk Extreme 五種，

依照他們的用途，分成一般用途和高 IOPS 用途的 Disk 來分開說明：

1. 一般用途的 Disk

依照 IOPS 效能最低到最高依序為 Stardard、Balanced 、SSD 和 Extreme Disk，主要是依照空間大小以秒計費，最小使用空間為 10 GiB。

但要注意，主機只是關機，Disk 還在的話，仍然會計費喔！

而它們又分成 Zonal 和 Regional，Zonal 就是在 Regional 內其中一個 Zone 的 Disk。

Regional 則是有 2 個 Disk，因為虛擬機會同時把資料寫入兩個 Zone 的 Disk，所以費用是 2 倍金額。

另外 Extreme Disk 則沒有 Regional，最小使用空間為 2500 GiB。

而且除了空間計費之外，它可以額外增加 IOPS 而不增加空間，每秒增加一次 IOPS 為 0.078 美金。

2.  高 IOPS 用途的 Hyperdisk

Hyperdisk 是 GCP 中最新一代的網路區塊儲存服務 (Block Storage)，專門用來針對企業最關鍵任務的應用程式而設計出來的。

它的類型很多，包含 Hyperdisk Throughput、Hyperdisk Balanced、Hyperdisk Balanced HA、Hyperdisk、Hyperdisk Extreme 等。

除此之外，針對 Throughput 和 Balanced 這兩種 Hyperdisk，可以使用 Storage Pool，它可以簡化你的 Disk 管理。

你可以一次建立一個很大的 Disk 空間，統一設定效能，再把 Disk 分配給每一台主機，還有一些效能上的免費額度。

詳情可以參考這份文件，未來有機會再專門討論。

目前在台灣 (asia-east1) 的價格如下表：

你會看到有幾個是灰色底的數字，雖然價格文件上有提到 Throughput 和 Balanced HA，但另一份關於 Hyperdisk 可用性的文件指出，台灣其實還沒有提供。

所以 Hyperdisk Storage Pool 的部分，台灣也只有 Hyperdisk Balanced 的 Pool，Hyperdisk Throughput 的 Pool 也還不可用。

因為今年 (2024) Hyperdisk 才剛出來，未來可能還有變動，所以請持續追蹤官方文件是否有更新。

(四) 網路流量

流量依照進出主機的方向分為 Ingress (流入/上傳) 和 Egress (流出/下載) 兩種，其中 Ingress 不計費，只有 Egress 計費。

而 Egress 又依照你的流出的目的地有不同的價格，以下依照費用從最高到最低依序說明：

1. Egress 到 Google 外部

我們在建立主機時，在 Network Interface 有給你選擇 Service Tier，看你要用 Preimum 還是 Standard，如果沒選預設就是 Premium。

(1) 主機 Egress 到外部 (Premium)

你可以看到，主機流出到世界各地的流量單價都不同，還有各種例外狀況，所以要看你服務的對像在哪裡，決定你主機流量的單價。

(2) 主機 Egress 到外部 (Standard)

Standard Tier 的流量費用單純許多，如下表：

但是無論如何，我建議一律使用 Preimum，要不然可能會去失去一些重要的網路功能，兩者詳細差異可以參考這份文件。

2. 主機 Egress 到 VPC 外部，但仍在 Google 內部

因為 Google 不是只有 GCP，很多人也使用 Gmail、YouTube、雲端硬碟等等，還有 GCP 之內其他非 VM 的服務，像是 Cloud SQL、GKE 等等。

各種目的地的計費方式如下表：

3. 主機 Egress 到同一個 VPC 內，但不同 Region 的主機

不同 Region 因為 Google 在當地的建置成本或其他因素，而有不同的費用如下：

4. 主機 Egress 到同一 Region 內的其他主機

例如主機會 Zone A，傳輸流量到同一 Region 也是 Zone A 的主機，免費。

如果是傳到同一 Region 但是到 Zone B 的主機，每 GiB 是 0.01 美金。 

這部分因為 Google 中文版的網頁是錯誤的，

在此提供英文版的網頁截圖：

(五) IP 位址

如果你的主機有透過 Cloud NAT 上網，或是透過 Load Balancer 接收進來的流量，

那你其實不需要 IP 位址的，除非你是需要單獨對外連線，才需要用，

所以我們在估價時，如果其他 SKU (產品細項) 金額非常大，不然我有時會直接忽略這個費用。

因為 IP 位址屬於稀缺資源，所以你會看到，

如果主機是開機的，IP 位址比較便宜 (0.005 美金/小時)，

如果主機關機，代表你的 IP 是閒置的，IP 位址反而比較貴 (0.01 美金/小時)，

因為你「佔用稀缺資源」，所以會被收取更高的費用。

而 Preemptible 和 Spot VM 是屬於「隨時會被 Google 收回去的主機」，主機被收回去就表示 IP 也隨之釋放掉了，所以是最便宜的。

二、續用折扣 (Sustained Usage Discount; SUD)

續用折扣是在同一個月內，使用某一個型號到達某個時數的時候，可以享受到的折扣，而且它是會自動套用的。

類似現在電子商務的「滿額折扣」，例如結帳金額「滿千送百」，或是購物滿多少錢免運費的概念。而不同型號會有不同的折扣深度，例如：

使用 N1、M1、M2，以及除了 NVIDIA H100, A100, and L4 以外的所有 GPU，最高可達 30% Off 折扣，就是打七折。

使用 N2、N2D、C2 最高可達 20% Off 折扣，就是打八折。

另外要注意，E2 沒有 SUD 喔！

我們以 n1-standard2 型號為例，原價每小時 0.55 美金，以 2025 年 2 月是 28 天(方便計算)，如果機器一直開著不關，我們來看它的折扣狀況：

我們再看這張圖，可以得知，用越多省越多：

上面的例子是假設你的主機都不關的情況下，可以獲得的折扣。

那如果機器中途關機，會不會失去折扣？

如果你機器在2月初開了一個禮拜，最後一周也開一個禮拜，因為第一周的開機時數已滿 (25%)，最後那周開機的費用，就滿足 20% Off 的條件，也就是打八折。

再跟第一周的原價平均起來，就是打九折。

那如果是中途升級呢？Google 官網有個範例：

為了讓你可以跟 Google 官網正確對照，我們沿用官網的價格，以及每月時數 730 小時來計算。

我們本來用 n1-standard-4，用了半個月，再升級成為 n1-standard-16。

原本的費用是：

n1-standard-4 使用半個月的費用 + n1-standard-16 使用半個月的費用。

照理來說，使用半個月就是打九折。

但 Google 的算法是：

n1-standard-4 使用一個月的費用，增加的規格 (12vCPU, 45GB) 使用半個月的費用。

就是 n1-standard-4 打七折，增加的規格才打九折。

具體算法如下圖：

但要注意，如果你是自訂規格，你的 vCPU 和記憶體是自己指定的，它們的續用折扣會獨立計算，不會跟原本配好的機器類型合併計算喔！

三、承諾使用折扣 (Committed Usage Discount; CUD)

如果你確定有些機器要長期持續運作，Google 提供一年到三年的 CUD。

這裡分為以資源為基礎的 (Resource-Based) CUD 和運算彈性的 (Flexible) CUD。

接下來我們一邊說明折扣計算方式，一邊操作下單的畫面給大家看。

(一) 以資源為基礎的 (Resource-Based) CUD

指的是特定 Region、特定型號 (例如 N1)、特定期間 (例如一年) 還有特定數量等等。

因此你在美國開的 CUD，就不能用在台灣，或是你開 N1 的 CUD，就不能用在 N2。

這裡提供 CUD 的資源包含 vCPU、記憶體、GPU、Local SSD、Sole-tenant nodes 和作業系統授權 (其實只有 SUSE)。

常見的機器型號如 E2、N1、N2、N2D、M1、M2、M3、C2、C2D、C3D、G2、T2D 都有提供。

但要注意，共用核心（f1-micro、g1-small、e2-micro、e2-small、e2-medium）無法套用 CUD 喔，千萬不要衝動買下去！

1. 購買 Resourced-Based CUD

我們直接進到購買 CUD 的畫面：

我們可以針對每一個承諾 (Commitment) 來命名，接著選擇要在哪一個 Region 使用資源，以及使用的型號和時間長度 (一年或三年)。

例如我要用 N1 的 10 個 vCPU 和 20 GB 的記憶體，它會直接在右邊列出預估的每月費用，並且告訴你會省下多少錢：

你會看到它有顯示折扣金額，如果你把 213.46 除以 338.82 是 0.63，就是 63 折的金額，你可以再切成三年，看它有什麼變化：

你會看到它的每月費用就是 152.48 除以 338.32 等於 0.45， 就是打 45 折。

我也有試著把大部分型號拉出來看，如官方文件所說，除了「記憶體最佳化」(Memory) 的主機，一年打 59 折，三年打 3 折。(你沒看錯是 3 折)。

其他用途的主機都是一年打 63 折，三年打 45 折。整理如下表：

2. CUD 要下多少才對？

其實這沒有絕對的答案，主要是取決於你平常使用量的變動性，你可以先從帳單的選單找到 Commitments，再點擊 Compute Engine Commitment Analysis。

(Commitments 現在改版叫 Committed Used Discounts，圖片是較舊的版本)

接下來你會看到一個月內某個型號機器資源的使用量，如果你還沒買過 CUD，你看到的應該都呈現灰色的長條圖。

如果你很固定每個月都是 N1 的 30 vCPU，那你就很適合直接下單 CUD。

但如果你每個月的用量忽大忽小，例如這個月 20 vCPU，下個月只有 8 個 vCPU，一種方式是抓中間值，例如買 14 個 vCPU，

但是 CUD 在合約期間內，每個月都會出帳給你，不管你有沒有用滿 14 個 vCPU，當你某個月只用  8 個 vCPU，你還是要多付 6 個 vCPU 的費用。

那你可以買少一點，例如只買 8 個或 10 個 vCPU，其餘的就享受不到折扣嗎？

這點不用擔心，超過 8 個的 vCPU 數量，會自動套用 SUD。

3. GPU 的 CUD

再下來再看 GPU，要注意不是所有型號都機器，都可以配任何型號的 GPU，

要查詢主機型號和可用的 GPU，可以參考這份文件。

而且每個 Region 和 Zone 提供的 GPU 都不同，請以這份文件為準。

在操作查看 GPU 的 CUD 折扣時要注意，單純指定 GPU 數量是看不到折扣的：

你必須要先選擇 Create Reservations，並且要指定使用的 Zone 有提供 GPU 型號，

網頁才能正確顯示折扣和費用，例如我們在官方文件查到 asia-east1-a 有提供 P100，

就它提供的來選擇：

接著在 Reservation 的部分，也要填寫正確的 Region 和 Zone，

尤其主機型號和 GPU 的型號跟數量要相同，才能顯示 CUD 折扣資訊如下圖。

關於 Reservation 的各項細節，未來有機會再專門討論。

經過確認 GPU 也是和一般機器類型的 CUD 相同，一年 63 折，三年 45 折。

4. CUD 何時生效

很多用戶都在詢問購買 CUD 之後，想說怎麼還沒生效，

根據 Google 官方文件，CUD 生效是在 Pacifitc Time 的 00:00，

也就是「隔天的 UTC-8 或 UTC-7 的 00:00」(而台灣是 UTC+8)，

這個時間點就是 Google 的帳務系統，切換到隔天的時間點，

而這個時間在美國，又有所謂的「日光節約時間」，就是夏天會調快一小時，冬天會調回來。

而且夏令和冬令的切換時間，每年都不一樣。

以今天 (2023) 為例，10月27日會從夏令時間改回冬令時間

如果你是在 11 月 5 日以前購買 CUD，它的生效時間就是 UTC-7 00:00，即台灣時間下午 15:00。

如果你是在 11 月 5 日後前購買 CUD，它的生效時間就是 UTC-8 00:00，即台灣時間下午 16:00。

我們來看下面這兩個例子：

如果你剛好是在 10/31 的 14:30 下單，那你運氣很好，在美國剛好是 10/30 23:30，

代表半個小時後，就進入隔天了，你下單的 CUD 在 15:00 就生效了。

但如果你超過你是 10/31 的 15:00 以後才下單，那抱歉了，美國才剛過凌晨 00:00，

你要等到 11/1 的 15:00，就是幾乎要等一整天，才會看到生效。

如果你剛好是在 11/3 的 15:30 下單，那因為是冬令時間，在美國剛好是 11/2 23:30，

代表半個小時後，就進入隔天了，你下單的 CUD 在 16:00 就生效了。

但如果你超過你是 11/3 的 16:00 以後才下單，一樣美國才剛過凌晨 00:00，

你要等到 11/4 的 16:00，就是幾乎要等一整天，才會看到生效。

這裡再補充一 下，Local SSD 也是同樣的道理，

要 Create Reservation 才能下單，它的折扣一樣是一年 63 折，三年 45 折喔！

5. 作業系統授權也有 CUD

以資源為基礎的 CUD，除了硬體，也有軟體的 CUD，

一樣是從 CUD 的選單進入：

但是進來之後你會發現，只有 SUSE Linux 系列的作業系統才有提供 CUD，

我們最常用的 Windows 是沒有 CUD 的喔！

6. CUD 套用範圍與共享

當你下完 CUD 訂單後，預設它只會給同一個專案內的資源使用，

但你也可以分享給同一個帳單帳戶底下，其他的專案一起使用。

接下來跳出一個小視窗，你可以輸入 Enable，讓同一個帳單帳戶的其他專案，可以共用 CUD。

但要注意，如果原本購買 CUD 的專案，移到另一個帳單帳戶的話，

那 CUD 還是會跟著原本的專案一起離開喔，其他專案就用不到這個 CUD 了。

7. CUD 重要提醒

既然它叫「以資源為基礎的 CUD」，代表它綁定的就是特定 Region 或型號，

這一點要非常注意，因為非常容易操作錯誤，很多用戶都是錯在 Region 或是型號，

並且下錯就完全不能修改，唯一的辦法是發現下錯的當下，馬上去聯絡 GCP 的代理商，

請他們開立技術支援單 (Support Ticket)，聯絡原廠的人員來處理，非常麻煩。

後來 Google 推出另一種運算彈性的 CUD，比上面這種單純又方便很多喔！

(二) 運算彈性的 (Computed Flexible) CUD

它的名字取得不好，其實就是「以費用為基礎的」Spent Based CUD，

它不管你用在哪個 Region、哪個 Zone、什麼型號、vCPU、記憶體還是 GPU，

你只要設定一個每小時的費用，購買之後就套用到所有 Compute Engine 的資源上，

所以使用 Flexible CUD，就不會那麼容易下錯單囉！

要注意的是，你不是在 Compute Engine 頁面購買，

它是以帳單帳戶為基礎，所以在這個帳單帳戶底下的專案都可以共享這個 CUD。

進來之後，你會看到很多產品都有各種 CUD，

那我們就選 Compute Flexible Commited Use Discounts：

然後我們就根據過去經驗，輸入每小時大概花費多少錢，

以及設定一年或三年的承諾。

你會看到它在下方會自動秀出折扣後的價格，

原本每小時 10 美金，現在變成 7.2 美金，代表打 72 折了。

然後原本整個月是 7200 美金，節省了 2016 美金，只要  5184 美金。

那如果選三年的承諾，就直接打 46 折。

這邊比較奇怪的是，為什麼它不用一個月 730 小時來算，而是用 1000 小時？

所以各位試算的時候，還是注意一下，用 730 小時來算比較精準。

另外關於生效時間，你也不用像前段提到的 UTC-7 或 UTC-8，

你只要下單後的一個小時內就會生效喔！

四、GCP 價格計算機 (Pricing Calculator)

因為 GCP 的產品太多，各種產品的計費方式都不同，

所以提供價格計算機，方便大家來估算自己的費用。

目前有兩個版本，分別帶大家來看：

(一) 新版 GCP 價格計算機

新版首頁像這樣，我們就直接點擊 Add To Estimate：

接著我們再點擊 Compute Engine：

點擊之後，會展開主機的各種計費參數，並帶入一些預設值，

第一個 Service Type 包含 Instances、Sole-Tebant Nodes、Machine Images，保持預設即可。

第二個 Instances Configuration，旁邊的 Advanced Settings 開關就只問要不要估 IP 位址，

要開不開都可以，只要注意，你有幾台機器，就只能帶上相同數量的 IP 位址。

主機的部分就是問你數量，以及開機的時間，例如每周或每月開幾小時，保持預設即可。

再來作業系統的部分，要記得如果是 Windows 的話，你是只有 Windows Server，

還是也有 SQL Server 資料庫，以及它的版本，它們之間的費用差異極大，要看清楚。

在此我們選擇 SQL Server Standard 版本 (已包含 Windows Server 的授權)。

Provisioning Model 就保持 Regular，代表我們主機是要保持開著，不要隨時被 Google 收回去。

Machine Type 可依照你的需求去選擇需要的規格，我們保持預設的 n1-standard-4 就好。

要注意下方的拉 Bar，如果我們移動的話，導致 vCPU 和記憶體的組合，

不屬於它配好的 (Predefined) 規格，那就會變成自訂 (Custom) 規格，單價會比較高。

Threads Per Core 指的是一個實體 CPU 要跑幾個執行緒，也就是 vCPU 的數量。

如果你是免授權費的 Linux，調整這個沒有影響，但如果是 Windows，

因為它的授權費取決於 vCPU 的數量，如果調成 1 Thread，你會發現整體的費用降低了。

當然少一個 Thread，就是少一個 vCPU 在跑，所以運作效率也會受到影響喔！

接下來選擇要使用的 Disk，首先你會看到只有 Standard、Balanced 和 SSD 可以提供選擇，

Extreme 和 Hyperdisk 目前還選不到。

比較需要注意的是，有一個 SUD 的開關，預設沒有打勾，

我們大部分機器都是一直開著的，所以建議直接勾起來，才能得到比較精準的費用。

而 Local SSD 是高 IOPS 和低延遲的 Disk，但是當主機重開，資訊會消失，

所以平常比較少用，就不需要勾選。

下方 Region 的部分要記得勾選，因為不同 Region 的上述價格都會不同，

然後再依照你的機器是否為長期使用的，來選擇適合的 CUD，

如果還不確定，或是機器都是短期測試，就可以先選 None。

到這邊少了一個計費項目，就是網路流量，我們要再點擊右上方 Add To Estimate：

它會跳出各產品給你選，你可以輸入關鍵字來找到 Networking。

當你剛進來的時候，它預設是 IP 位址的選項，要先切換成 Data Transfer。

接下來會看到 Internet Data Transfer，就是流出 Ergess 到 Google 外部的流量。

Network Service Tier 建議選擇 Premium，

資料量的部分就依照你的預估，如果是新的網站，那就抓個 10 GB，

如果是電子商務網站，建議先抓 100GB。

下面則是問你，從哪個 Region 的主機出去的流量，而用戶都從哪裡存取到你的主機，

像我們都在台灣的話，Source 選台灣，Destination 就選 Asia。

最後一部分就是在 Google 內部，從主機流出的流量，

我們的主機如果都是以台灣為主，就選 Inter-Region 即可，

這部分因為單價很低，如果根本無法預估流量，你可以就給它 10 GB，或改成 0 GB 也可以。

最後我們在右邊就會看到各個服務的費用加總，我們可以從各服務計三個小點按鈕，

點擊展開該服務的所有細項：

費用加總下方的各個按鈕依序說明：

我們把 CSV 上傳到 Google 試算表，打開會像下圖這樣，

記錄得很詳細，還包括這份估價單的連結，

別人點擊之後會看到相同的 GCP 價格計算機網頁。

點擊之後，它會產生另一個連結，假如你要針對相同的主機規格，

分別估算無 CUD、一年CUD、三年 CUD 的方案，就可以把規格設定好之後，

複製新的一版，再更改 CUD 設定就好了。

你可以點擊 Share，複製連結給別人，你自己也可以將此連結貼到新的視窗，

你可能會擔心，任何人都可以編輯這個估價單，

但是不用擔心，不管是你或別人，只要異動過任何計費項目，它的連結網址會自動改變。

代表你的連結永遠都是最初的版本，別人改好再分享給你的話，

它會是另一個連結，不會改到你原本的估價單，這樣分享就很方便。

這裡再提醒一下，操作的時候，注意數字是否有變化，

或是參考官方價格文件，畢竟是新版，很多功能都還在優化中，可能會有些小小的 Bug。

(二) 舊版的 GCP 價格計算機

目前 Google 還保有舊版的計算機，我們可以點進來看看：

https://cloudpricingcalculator.appspot.com/

你會看到內容其實差不多，只是操作的界面長得不太一樣：

但是它在 Disk 的部分，有 Extreme Disk 和 Hyper Disk，是比較完整的：

比較需要注意的是，舊版計算機要手動點擊 Add To Estimate 才會出現估價結果：

但它有一個好處，是它有一個寄信功能，點擊之後可以輸入收件人的 Email，

像我通常都是寄給自己留個記錄，

你可以只要輸入 Email 就好，其他都不是必填：

接著它就會馬上把估價內容寄到信箱，這是在信箱收到的畫面，非常方便。

但沒有 CSV 格式的估價單那麼詳細，主要是方便給自己留底。

其餘部分和新版的操作都差不多，就不再贅述，建議你可以兩種都試試看，選擇適合的來用。

五、結論

總結我們在整個估價的過程中，需要注意以下幾點：

1. Windows 的作業系統授權，要不要包含 SQL Server，每個版本價格都不同。

2. Hyperdisk 不是每個 Region 都有提供，以及 IOPS 和 Throughput 參數要額外設定。

3. SUD 和 CUD 兩種折扣的計算方式，對估算結果影響較大。

4. CUD 的下單方式要多注意，Resource-Based 的 CUD 注意不要下錯。

5. 如果怕太複雜，或者使用的資源不固定，就直接選擇 Flexible CUD 就好。

最後提醒，因為 GCP 各項服務不斷推陳出新，新推出的東西通常都有優惠，

過一段時間就會恢復原價，或著原本不收費的，突然開始要收費了，

你可能會不定期收到 Google 寄出的，關於價格變動的 Email 通知。

其至本文發布之後沒多久，某些服務的價格又變動了。

務必查看清楚，或是多看看 GCP 官網的價格資訊喔！

本文同步刊登於思想科技官方網站：

【東東老師 X 思想科技】Google Cloud VM 基本計費方式

【東東老師 X 思想科技】Google Cloud VM 永續折扣與承諾使用折扣

【東東老師 X 思想科技】Google Cloud VM 價格計算機 (Pricing Calculator)

The post GCP VM 費用如何計算？有哪些折扣和申請方式？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

Google 的 Compute Engine，簡稱 GCE，就是 Google 的虛擬機器平台。

類似 AWS 的 EC2，或是微軟的 Azure Virtual Machine。

一、Google VM 平台 – Compute Engine 的功能

1. 提供各種作業系統映像檔 (Image)

你可以使用免費的 Linux Server，

如 Debian、Ubuntu、CentOS、Fedora ，

也可以使用付費授權的 Windows、Redhat、SUSE 等等。

目前 Console 上看到可用的作業系統如下：

Google 提供這些作業系統的映像檔 (Image)，

你可以想像它是給你安裝作業系統的光碟片。

另外，你看到它上面有 Windows Server 和 SQL Server on Windows Server。

代表除了你可以建立 Windows Server 的 VM，

你也可以開好一台「已經裝好 SQL Server」的 VM。

如果你裝過 SQL Server 就會知道，

它的安裝非常耗時，可能要好幾個小時才能裝好，

但 Google 已經有準備好「內含 SQL Server」的 Windows 映像檔，

讓你省去好幾個小時的安裝時間，不是很方便嗎？

更多作業系統版本可以參考這份文件。

2. 提供各種效能的硬碟類型

(1) 永久硬碟 (Persistent Disk)

早期 GCP 只提供一般的硬碟 (Standard Disk) 和固態硬碟 (SSD)，

因為 SSD 價格較為昂貴，大家為了省錢都使用一般的硬碟。

後來就推出 Balanced SSD，它不像 SSD 那麼貴，

但效能又比一般的硬碟好很多。

所以 Balanced SSD 漸漸成為大家比較常用的選項。

後來 Google 又推出 Extreme Disk，提供給有高速 IOPS 存取硬碟需求的用戶。 

今年再推出最新的 Hyperdisk，

提供比 Extreme 更高的 IOPS (讀寫次數) 和 Throughput (吞吐量)。

還可以單獨調整 IOPS 和 Throughput，更多資訊可以參考這份文件。

(2) 臨時儲存資料的本機 SSD (Local SSD)

如果你有臨時的、低價值的資料要暫存，

同時又要有很高的 IOPS，就可以使用 Local SSD。

與永久磁碟和 Hyperdisk 相比，

Local SSD 提供更高的每秒輸入/輸出操作（IOPS）和非常低的延遲。

這是因為 Local SSD 是「實體連接」到你的虛擬機器上喔，

就像你在操作的個人電腦一樣。

但要注意，只要你重開機，資料會全部消失喔！

它的 IOPS 很快是為了輔助你暫存資料，而不是永久儲存，

如果你要永久儲存，還是要選上面的永久硬碟喔！

更多資訊可以參考這份文件。

3. 備份功能 – 快照 (Snapshot) 

你可以隨時使用快照功能來備份你的主機，也可以設定排程來自動備份。

它是使用增量備份的方式，也就是說第一次做快照，可能會有較大的資料量，

但是從第二次開始，都只會針對變動的部分做備份，如下圖：

而且它可以做排程自動備份，你可以選擇離峰的時間，

讓它自動幫你的主機做備份，萬一主機運作中出現問題，導致機器壞掉的話，

可以使用快照來還原主機喔！更多資訊可以參考這份文件。

4. 自訂主機內容的映像檔 (Image) 和執行個體範本 (Instance Template)

除了上述 GCP 供各種作業系統映像檔 (Image)，你也可以做自己的映像檔，

這樣有什麼好處呢？

你可以想像，通常你都會有習慣使用的作業系統，例如 Ubuntu 或 CentOS，

你也會安裝你常使用的軟體像是 Apache、Nginx 或 MySQL 等等。

你就可以把常用的軟體裝好之後，做成你的映像檔，就類似燒光碟的概念， 

以後你要開新的機器，你可以直接用自訂的 Image 開成新的機器，

這樣你就不用每次都要重新安裝和設定環境了，主要就是減少你的重覆工作。

那範本又是什麼呢？

它的全名叫「執行個體範本」，就是幫你記住所謂的中介資料 (Metadata)，

更白話一點，就是主機除了 Image 之外，它在 GCP 的設定資訊，

像主機要開在哪一個 Region 和 Zone、規格大小、用多大的 Disk、

用哪一個 Service Account (主機的身份)、防火牆標籤、

用哪一個 VPC 網路 (GCP 內網)、要不要外部 IP、

開機要不要自動執行什麼指令 (Startup Script) 等等。

讓你的開新機器可以更方便，詳情可以參考這份文件。

所以你可以：

(1) 用 Image 開新機器，自動包含已經安裝的軟體

(2) 用 Template 開新機器，自動包含已經安裝的軟體，再加上主機在 GCP 的設定。

另外，如果你想要做到雲端的重要功能 – 負載平衡和自動擴充 (Autoscale)，

也是要用到 Image 和 Template 喔，詳情可以參考這份文件！

5. 機器映像檔 (Machine Image)

機器映像檔和上面提到的 Image 加 Template 很像，

可以想像成是一個「完整的電腦備份包」。

這個備份包含了：

作業系統、所有已安裝的軟體和設定、磁碟設定和儲存的資料和網路設定等。

但還是有一些重要差異：

(1) 備份範圍不同

• Machine Image：可以同時備份多個磁碟，包括開機磁碟和資料磁碟。
• Instance Template + Image：只能備份單一開機磁碟。

(2) 增量備份能力

• Machine Image：支援增量備份，如果資料只改一點點，下次備份只會儲存變更的部分。
• Instance Template + Image：每次都是完整備份，不管改了多少。

(3) 磁碟配置彈性

• Machine Image：可以保留完整的磁碟設定，包括多磁碟之間的關聯。
• Instance Template：需要額外設定來處理多磁碟設定。

6. OS Patch Management 統一管理系統更新 

現在網路上駭客很多，隨時在到處入侵各個系統，

而作業系統如果不保持更新，就容易被發現漏入，

導致駭客入侵，因此保持作業系統更新非常重要。

但如果你手上有很多機器，要手動更新每台機器，是非常麻煩而且耗時的，

GCP 提供 VM Manager，就是要讓你可以一口氣更新多台主機，

你就不用一台一台連進去手動更新。更多詳細的介紹可以參考這份文件。

二、Compute Engine 的特色

以下是幾個 Compute Engine 的關鍵特色：

(一) 想用就用 (On-demand) ：

當你有臨時要使用主機的需求，你可以在幾分鐘內就開始使用一台虛擬機器，不需要實際購買硬體。

如果你是傳統地端環境，你是無法即時擴充的。

因為你要走採購流程包含詢價、議價、選商，以及後續的安裝建置。

和雲端相比之下，早就喪失了先機。

這是地端環境遠遠比不上雲端的一大因素。

(二) 任意調整規格

你可以選擇這台虛擬機器的規格，比如說要多少記憶體、多強的處理器等，

就像是在組裝一台符合你需求的電腦。

其他雲端廠商如 AWS 和 Azure，

它們的機器規格 (vCPU 和記心憶體) 都是配好的，不能自己拉。

但 GCP 給你一個拉 Bar，你想拉多少就拉多少。

你可以拉 1 vCPU 配 5GB 的記憶體，甚至極端一點，

你使用擴充記憶體，可以拉出 1 vCPU 配 624 GB 的記憶體，如下圖：

目前 GCP 提供的型號很多，包含以下幾種：

1.通用型 (General-purpose)

對於各種用途來說，這種類型的性價比最高。適合大多數人日常使用，效能和價格都很平衡。

像是一般的官方網站，直接使用這類型的機器就好。

2. 儲存優化型 (Storage-optimized) 

最適合那些不需要太多運算能力，但需要大量儲存空間的工作。

這類型的機器就像是一個大容量的倉庫，可以存放大量資料，但不需要太多的處理能力。

但要注意它是隨帶著 Local SSD，是做為資料處理暫存的用途，

萬一主機重開，Local SSD 資料會不見！

所以資料處理完要記得轉到一般的 Persistent Disk 喔！

3. 運算優化型 (Compute-optimized) 

在整個 Compute Engine 上，每個核心的效能是最強的，

為運算密集型工作而優化。

如果你要做大數據分析、影片編碼或轉碼、

大流量的電子商務網站、天氣模擬運算等等，

都很適合用這種機器。

4. 記憶體優化型 (Memory-optimized) 

這種主機非常適合需要大量記憶體的工作，

每個核心配備的記憶體比其他類型都多，最高可達 12 TB。

像是社群網站需要大量讀寫資料庫、新聞網站大量快取內容、

把大數據放在記憶體做分析等等，

記憶體夠大的話，可以確保系統穩定運作而不當機。

5. 加速器優化型  (Accelerator-optimized) 

最適合大規模並行的 CUDA 計算工作，

例如機器學習、自動駕駛汽車處理多個即時影像來判斷怎麼開車、

3D 動畫影片渲染、金融業使用蒙特卡洛模擬來評估風險、

DNA 基因序列分析、大量視訊串流 (Video Streaming) 等等。

如果你的工作需要用到 GPU，最適合用這種機器。

(三) 按需付費：你只需要為你使用的資源付費。

不用的時候，可以關機，就不用付錢了。

例如假設你使用最小規格的 GCP 主機 f1-micro ，它一個月的費用只要 5 美金。

如果你只用 2 個禮拜就不用了，那你只要 2.5 美金，

根本不到台幣 100 塊，太便宜了。

(四) 擴展性強

當你需要更多運算能力時，你可以輕鬆地增加更多虛擬機器，或者升級現有的機器。

如何升級呢？你只要把現在的機器關機，你就可以更改它的規格，

像我本來是 f1-micro 的機器，我可以改成 N1 其他規格的機器，

甚至其他型號的機器都可以！

此外，Compute Engine 有個「執行個體群組」的功能，就是一次可以開很多台機器，

還可以設定當現有機器忙碌的時候，例如 CPU 使用率 60%以上，

讓它自動長出新的機器，也就是所謂的自動擴充 (Autoscale)。

(五) 全球部署

你可以選擇在世界各地的資料中心運行你的虛擬機器，讓你的服務更接近用戶。

這是台灣的 IDC 機房做不到的，因為 Google 在全世界已經有 40 個資料中心，

最近還在柏林 (德國)、杜哈 (卡達)、達曼 (沙烏地阿拉伯) 和約翰尼斯堡 (南非) 興建新的資料中心。

代表你可以把主機開在世界各地。

尤其是對方國家當地法規比較嚴格，要求資料只能存放在當地的時候，

你就不用親自到那邊租個辦公室、請員工、建置機房、買機器和安裝軟體。

大部分工作都可以遠端完成，非常方便。

(六) 安全可靠

Google 的資料中心已經通過各種國際或特定國家的認證，

確保資料中心的穩定跟安全，除了資料中心本身實體的防護之外，

也嚴格控管出入的人員，即使是 Google 的員工，也無法自由進出機房。

我們存在雲端的資料，就是屬於我們的，Google 人員也無法存取，

只有在我們申請技術支援的時候，授權給他們才能存取。

所以你只需要專注於你的應用程式，其他底層的維護運作，交給 Google 就好了。

而且 Compute Engine 有提供 SLA (Service Level Agreement；服務水平協議)，

如果你只在一個 Zone 開一台機器，它可以確保 99.9% 的可用性，

如果在兩個 Zone 以上開機器，它可以確保 99.99% 的可用性，

萬一服務中斷超過 SLA 的範圍，它會賠償下個月的抵免額 (Credit)。

當然它不是賠現金啦！

是下個月使用 GCP 的費用，它讓你可以減免。

三、常見問題 – 為什麼一定要用 Compute Engine？

有人覺得用地端 VM 就好了、或是 VPS，或是 AWS，為什麼要用 Compute Engine，有什麼獨特的地方嗎？

讓我們來看看 Compute Engine 相比其他選擇的一些獨特優勢：

(1) 整合 Google 生態系統

如果你已經在使用其他 Google 服務，

如大數據分析平台 BigQuery、無限大儲存空間 Cloud Storage 等，

Compute Engine 可以無縫整合，讓你的工作流程更順暢。

例如，你可以輕鬆地讓 Compute Engine 使用機器學習服務，

如 Vision AI 或 Natural Language AI。

(2) 網絡效能

Google 擁有全球最大的私有網絡之一。

使用 Compute Engine，你的數據可以通過這個高速網絡傳輸資料到全球其他 Region，大大減少延遲。

對於需要跨區域或全球部署的應用來說，這是一個巨大的優勢。

你也可以參考這份圖表 – 全球各 GCP Region 之間的 Latency。

(3) 定價模式

Compute Engine 提供每秒計費 (最少 1 分鐘)，而不是按小時計費。

這對於短期運行的工作負載可以節省不少成本。

還有持續使用折扣 (Sustained Use Discount)，

使用時間越長，折扣越多，不需要預先承諾或預付。

如果你想要預先承諾也可以，

它能提供一年或三年的承諾使用折扣，最低可以到 43 折。

關於價格的細節可以參考這份文件。

(4) 自訂機器類型 (Custom Machine Type)

像上面提到的，你可以自訂 vCPU 和記憶體的組合，

而不是被限制在預先定義的機器類型中，避免資源浪費。

(5) 即時遷移 (Live Migration)

因為主機實際上還是在硬碟上運作，硬碟終究會有老舊的可能，

而 Google 可以在不停機的情況下，

將你的主機即時移動 (Live Migration) 到新的底層硬體上，

代表你的服務可以保持高可用性。

(6) 預先或自動擴展 (Autoscale)

你可以設置執行個體群組 Instance Group，

根據負載自動增加或減少機器數量，

這比傳統的地端 VM 或一些 VPS 供應商更靈活部署資源。

(7) 強大的安全功能

例如屏蔽虛擬機（Shielded VM）技術，像是一個加強版的防護罩，把你的虛擬機器保護得更安全。

它主要提供三個重要的安全功能：

a. 開機檢查 (Secure Boot)：

每次開機時都會檢查，確保沒有惡意程式偷偷混進去。

b. 韌體防護 (vTPM, virtual Trusted Platform Module)：

像是一個加密的保險箱，存放重要的金鑰和憑證，讓駭客很難偷到或是篡改。

c. 完整性監控 (Measured Boot)

像是裝了一個行車記錄器，會記錄並檢查開機過程中的每個步驟，

如果發現異常，會立即通知你。

如果是金融相關，或是要處理個人資料的系統，

可以使用 Shield VM 來保護你的主機。

(8) 創新技術

Google 經常推出新的硬體，如 TPU (張量處理單元)，可以加速 AI 的運算。

這些都可以通過 Compute Engine 使用。

(9) 永續性

如果環保是你的考慮因素之一，Google 資料中心的能源效率，

以及可再生能源的使用率，都處於業界領先水平。

完整的永續發展資訊，可以參考這份文件。

你甚至可以使用區域挑選工具，依照碳足跡、價格和延遲時間 (Latency) 來選擇適合的 Region。

四、Compute Engine 結論

總結來說，Compute Engine 結合了大型雲端供應商的優勢 (如全球基礎設施、先進技術)，

和更靈活的費用及設定選項。

對於需要高效能、高可用性，同時又希望保持靈活和成本效益的企業來說，

Compute Engine 是一個適合你的選擇。

如果你想使用 GCP，可以先參考這個影片來申請免費試用。

如果你己經有了 GCP 的環境，可以看這影片，

來試著建立你第一台 Google VM，慢慢進入 GCP 的世界喔！

如果想要完全掌握 Compute Engine，來上課吧！

小白變專家 – Google VM 從入門到實戰

https://dongdonggcp.kaik.io/courses/google-vm

The post Google VM 平台 – Compute Engine 是什麼？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

通常必須要讓防火牆規則，開放所有的 IP 來源的 Port 22，

像這樣：Allow 0.0.0.0/0 Port 22

代表不是只有你，

全世界的駭客都可以連到你的主機 Port 22。

如果要安全地連，必須自己做 SSH Key，從本機 SSH 來連，

才可以設定防火牆只允許自家 IP，然後擋掉其他 IP，有點麻煩。

但是現在 GCP 改善了，你不用再做自己的 SSH Key了，

你可以只允許 Cloud IAP 的 IP Range 35.235.240.0/20，

不用 Allow 全世界的 IP，也不用 Allow 自家的 IP。

Cloud IAP 的技術原理可以直接看這篇，本文直接實作給你看。

以下是我新建一條防火牆，

只允許 Cloud IAP 的 IP 範圍：

你只要點擊 SSH 按鈕，就可以直接連線了。

連上之後，從 Linux 查看連線的來源 IP 為 35.235.244.82，果然是 Cloud IAP 的範圍。

也從防火牆 Log 來看，也是一樣。

以後再也不用自己做 SSH Key了，實在是非常方便呢！！

最後提醒一下，原本那條 default-allow-ssh 防火牆規則，記得要停用喔！不然駭客還是會找到你喔！

The post Cloud IAP 簡單介紹和實作, 防火牆不用全開，讓你安全又方便連線到虛擬機器 first appeared on 東東 GCP 教學 - GCP 實戰講師.

一、帳號管理

1.公司是否使用 Google Workspace？

如果是，管理使用者帳號就比較單純。

2.如果公司使用 M365 或其他的 Email 方案，

代表有在用 Windows AD 或其他 LDAP 來管理使用者，

那勢必要申請 Cloud Identity，

讓使用者使用公司建立的帳號操作 GCP，

不要讓他們用自己的 Gmail 操作公司的東西。

3.同時還要安裝 GCDS 來同步使用者和群組，

確保使用者帳號變動時，在 GCP 跟著連動調整。

二、專案架構

1.公司的 GCP Project 是否都在 Organization 底下？

並且在使用 Org Policy 強制實施政策到所有專案？

2.還是屬於「無機構」狀態？這代表公司管不到此專案。

如果使用者用個人 Gmail 來管理「無機構」專案，

那他就有可能突然消失，順便把專案帶走，

這是 Google 原廠都無法幫你救回來的。

三、使用者登入驗證

1.使用者是否啟用兩步驟驗證？

2.使用者的 Session 是否有限制時間？

例如太久沒操作就要重新登入。

3.公司內部系統如果架設在 GCP 上，是否啟用 OS Login 或 Cloud IAP？

還是只要帳號加密碼就可以登入？

4.最高管理員，有沒有跟平常工作的帳號分開？

是否啟用兩步驟驗證，要不要使用 Security Key 來登入？

四、使用者權限

1.公司是否採用分層權限管理，

例如授予不同部門主管 Folder 權限，

管理 Folder 底下的專案，

並建立 Group 來納入各部門成員。

而不應該每個使用者帳號都一個一個加進 IAM。

2.每個使用者是否用 Pre-defind Role 來授權？

而非直接授權 Owner、Editor 這種超大權限，

3. Service Account 是否給予剛好必要的權限？

4. Service Account Key 是否有保管好，

以及是否會定期換 Key？(駭客最喜歡你的 Key 了)

五、彈性

1.公司對外的系統是否有達成 Autoscale？

2.以及是否有執行過壓力測試，

這可以確保在尖峰時間滿足用戶端的需求。

3.規模如果夠大，可以購買 CUD (Committed Use Discount)，

以及 Reservation，可以享受優惠折扣，

更重要的是，可以避免高峰期的時候，

機器被其他客戶搶光了。

六、備份

1.公司是否有定義 RTO 和 RPO？

這會影響到公司有多少預算來達成目標。

2.主機多久做一次 Snapshot？

3.重要檔案是否定期複製到 Cloud Storage？

4.資料庫是否也有備份排程？

七、備援

1.主機是否都放在 Managed Instance Group？

這可以確保任何主機掛掉都會立馬重建完成。

2.非常重要的資料，是否使用 Regional Persistent Disk？

因為主機掛了，新的主機可以立即掛載舊主機最新的資料。

3.資料庫是否有啟用 HA (High Availability)？

以上都是需要足夠預算的，因此務必確認公司的 RTO 和 RPO。

八、應用程式部署流程 (CI/CD)

1.針對容器映像檔 (Container Image)，是否有啟用 Binary Authentication？

2.Image 是否有經過弱點掃描？

3.測試環境是否有效區隔，改版上線是否有嚴謹的 SOP？

4.以及上線失敗是否能夠立刻 Rollback？

九、維運與效能監控

1.針對營運的系統，是否設定好各種效能監控和 Alert？

例如 CPU 使用率、RAM 使用率、Disk 用量、每秒 Request 數量等等。

2.主機是否安裝 OPs Agent，把重要的 Log 匯出到外部進一步分析？

3.資料庫 Loading 是否過重？

是否採用 Read Replica 或是 Memorystore 來緩解讀取的流量？

4.圖片和影片

是否放在 Cloud Storage 來緩解 Web Server 的流量，

以及是否啟用 Cloud CDN 來加速媒體發布？

5.任何一個系統斷線，是否有準備切換的 SOP？

6.有沒有啟用帳單警示？

因為每100個人就有99個人忘記關機，我也在內。

十、攻擊防禦

1.Cloud DNS 是否啟用 DNSSEC？

Cloud Armor 是否採用 OWASP 各種規則？

3.是否有限制來源的 IP？

4.主機是否停用外部 IP，統一使用 Load Balancer 對外？

5.防火牆是啟只允許剛好用到的 Port？還是內網全開？

6.Cloud SQL 是否只允許內網 IP 連線？

十一、加密

1.公司所在的產業，是否有加密合規要求？

2.針對 Disk、Cloud Storage 或 BigQuery 如何加密，

使用 Google 預設加密、KMS 的 Key，還是外部的 Key？

3.往來的資料是否使用 Cloud DLP 來掃描個資？

4.掃描到個資後，如何處理後續流程？遮蓋、加密還是刪除？

5.處理機密資料的機器是否採用 Confidential VM？

6.是否有啟用 Service Control 來規定資料存取的範圍？

十二、混合雲

1.不管使用 Cloud VPN 或 Cloud Interconnect，

有沒有採用 HA 架構？

2.使用者的流量是否從混合雲內網存取 GCP？

還是它依然走 Internet？

3.最後，你只有用 GCP 嗎？

萬一，我是說萬一，GCP 全斷了，

或是 Google 資料中心碰到地震，

你能立馬切地端，或是切 AWS、Azure 嗎？

什麼都有可能發生，只是機率問題，

也不用說 GCP 100% 完美無懈可擊，

任何事都要有 Plan B。

以上分享，希望能對你有幫助。

The post [GCP 教學] 如何為公司做好 GCP 健檢？12 大面向與48個檢查項目分享 first appeared on 東東 GCP 教學 - GCP 實戰講師.

剛開始通常經費不足，

但還是必須要架設一個網站，

來宣傳你的服務和內容。

如果你是資訊背景，可以自行架設網站的話，

使用 GCP 架設網站是最划算的。

為什麼？

以下分四點說明 GCP 的功能、架構和好處：

1. 費用節省

GCP 是 Pay-as-you-go 依照使用量計費，

剛開始流量不大，

你可以建立最小規格的機器 – N1系列的 f1-micro，

每月費用大約 5~6 美金，折合台幣不到200元，

如果不用機器時，可以直接刪掉，

那根本就不會有費用發生。

不覺得超便宜嗎？

網站流量還不高時，用這個最划算。

當然這裡必須提醒一下，

因為它是共用核心，和其他機器共用同一個 CPU，

所以它的效能會有突發 (Burst) 效果，

代表有時候可以免費用到”額外”的CPU資源。

反過來說，效能有時候突然會「非常好」，

但大多數時間還是原有的效能。

如果要避免效能不穩定，

那還是建議選用例如 e2-medium 的機器，

(2 vCPU 和 4 GB 記憶體)

每月費用約 26 美金，約台幣 800 元左右(也不算太貴)。

2. 使用 Cloud Storage 減輕主機負載

通常網頁會有大量圖片或影片，

每當使用者存取網頁時，

Client 端對網頁讀取，會造成主機很大的負擔。

其實你可以把圖片和影片放在 Cloud Storage (GCS)，

而網頁 HTML 的圖片和影片超連結指向 GCS 公開網址，

這樣主機只要負責載入純文字的 HTML 和相關網頁原始碼，

負擔直接少減 90% 以上，

你也就省下很多維護主機、調校效能的時間。

3.免費自動更新的 SSL 憑證

自架網站通常也要處理憑證的問題，

到期還要手動更新，很麻煩。

但如果搭配 Google Load Balancer，

除了防禦大流量的 DDoS 攻擊之外，

免費自動更新的憑證，非常方便。

4. 加速媒體發佈的 Cloud CDN

除此之外，在 Load Balancer 上可一鍵勾選 CDN 功能，

除了幫你把媒體暫存在靠近使用者的位置，

加速媒體發佈以外，

也能更進一步減輕主機負擔，

因為 Client 端就不用去源頭主機拉圖片和影片了，

尤其是以影音串流的網站來說，更是必備的工具。

以上分享 4 個使用 GCP 的好處，

希望可以對 IT 自媒體創業者有所幫助。

順便置入一下，關於更多 GCP VM、Cloud Storage、Load Balancer 的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post [GCP 線上課程] GCP – 對 IT 自媒體最友善的雲端平台 first appeared on 東東 GCP 教學 - GCP 實戰講師.

 還帶著質問的口氣，好像是我們的錯。

每次回答，我都要寫一整篇來跟他解釋這件事情發生的原由，很累。 

我就在這裡分享給大家，到底為什麼主機被重開機 。

先講結論，因為 Google 在維護你的主機。

為什麼 Google 那麼雞婆？

畢竟你用的是 GCP，Google 還是要讓你的主機可以好好運作啊！

維護的原因有三個：

1.基礎建設維護：主機所在的硬體、網路、電源、作業系統和BIOS。 

2.安全更新：安全補丁、root 分割區更改。

3.硬體錯誤：記憶體、CPU、網卡和磁碟。

你可以在官方文件看到他詳細的說明。 

其實所有的公有雲都要維護的，

你可以查詢其他的公有雲，

他們會特別安排一個維護時間，讓你的主機在那個時候維護，

而且不只是主機被重開機，有一些情況是是完全無法使用機器的，

GCP 最多只是幫你重開，他們是有可能完全不給你用的。

好，就給 Google 維護，那維護都會被重開機嗎？

不一定。

它會先遷移，把機器移到其他比較適合運作的地方，

這樣並不會重開你的主機，主機效能也不會有太大影響。

除非是硬體完全故障或其他原因，

無法遷移的情況下，才會重開。

而這其實是有地方可以設定的，

當你在建立新機器的時候，

你會看到主機規格下方有一個「可用性政策」， 

再往下一點你會看到「 VM 佈建模式與進階設定」，

當你展開之後，會看到：

「在主機維護期間」，你要：

1.遷移 VM 執行個體 (建議做法)

2.終止 VM 執行個體

當然還是讓它遷移啊！

不然，它就把你主機關機了耶！

不過也還好啊，只是遷移，主機影響不大。

再往下這個選項 「自動重新啟動」：

1.啟用 (建議)

2.停用

就是如果主機發生錯誤，連遷移都不行的時候

要不要讓Google幫你重開機？

當然，你可以拒絕。

但是這台主機可能會累積一些潛在的問題，

導致你的主機運作效能很差。 

當這台主機硬撐到一個極限之後，完全死當，

就算你重開機也連不進去， 

讓你想要救援機器的機會都沒有，更麻煩。 

所以我們還是乖乖的接受它的選項，

保持讓它自動重新啟動。 

當然你可能會想，

你的主機這麼重要，難道不能24小時永不停機嗎？ 

不可能。

你對雲端似乎有點誤會， 

對你來說是雲端服務，但是對 Google 來說，

它還是硬體設備在那邊跑， 

機器也是會老舊的。

那這樣還要用雲端嗎？ 

是，當然要用。

不過，你用雲端的方法需要調整。 

雲端可以讓你達到「高可用、永遠不停的服務」

但是你必須要設定出來。 

你從頭到尾都是只有一台機器對外，

根本就沒有「高可用」。 

你必須要透過「執行個體群組」(Instance Group)，

至少設定兩台機器同時對外，

然後透過負載平衡器來幫你分散流量。 

你的機器有可能因為流量太大撐不住，

導致機器有問題，執行個體群組會幫你刪機器，

再重建新的機器，同時你另一台機器還是能持續對外服務。 

同樣的，你的機器如果是本身硬體發生問題，

也會被判定為不健康，執行個體群組也會幫你重建，

所以你使用虛擬機器，

你還是要有這樣的心理準備，

不可能單台機器永遠對外，

然後期待它不會有任何狀況發生。 

你可能會覺得，這樣成本不是很高嗎？

那你乾脆讓群組只有一台機器，

只要有問題，它還是會被刪除重建，

只是對外中斷的時間比較長，

因為你的主機需要時間重新開機，

這就是一個勉強可以接受的選項。

不過話說回來，

若要建立執行個體群組，

你得先找一台範本機器做出映像檔，再做範本，

又是另一個浩大的工程啊。

之後有機會再分享～

順便置入一下，關於更多 GCP 相關的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post [GCP 線上課程] 天啊？為什麼我的 GCP 主機被重開？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

從我待在 GCP 經銷商開始，一直到現在，

我常常收到客戶或網友留言反應 GCP 很貴，

而我每次回覆時，都要花很大的篇幅來跟對方解釋 GCP。

首先要確認一下，「貴」是跟誰比？

一、跟地端實體機比

的確，GCP 的虛擬機器是每月依使用量付費，

在經濟學上是屬於變動成本。

而實體機是一次性採購，如果你機器買來用個 5~10 年，

長期攤提成本下來，是很有可能比 GCP 的主機便宜。

但如果你的機器故障了呢？

你要叫修的話，需要等廠商來檢查，

或是請廠商搬機器回去原廠檢測修理，
(這裡還不考慮系統中斷帶來的商機損失)

一來一回至少一到兩個禮拜跑不掉，

這段時間你都不能使用機器。

等到機器修好了，還要重新設定網路、安裝系統、
軟體、資料備份和資訊安全等等。

如果你用 GCP 的話，這個流程變超短，

機器有問題，你可以把 Disk 留著，用新的主機掛載起來，

或是做一個 Snapshot，用 Snapshot 還原成新的主機，

裡面的作業系統、軟體各項設定幾乎不用調整，

是5分鐘內就可以完成的事情。

而且 GCP 提供方便的備份功能，滑鼠點幾下就好了，

你不需要花時間執行備份工具的安裝設定，

你省下了大量的人力維護時間，你還會覺得 GCP 比較貴嗎？

二、跟 VPS (Virtual Private Server)比

很多中小企業或是創業者，都會使用 VPS，

廠商提供一個管理介面，讓你直接在網頁上操作，

但是它提供的規格是固定的，無法隨時調整，

系統底層參數也無法輕易修改。

如果你是電子商務網站，流量有尖峰和離峰時間，

突然因為行銷活動帶來大量的用戶流量時，

你沒有辦法及時擴充資源。

因為 VPS 通常是月租或年租的方案，

無法短期擴充用個 2～3 天，待人潮退去再縮減機器。

但在 GCP 則是很彈性的，你可以隨時調整規格，

並且整台機器都是你完全掌控的，

你可以調整底層參數，安裝任何想要的軟體，

系統流量大時，可以設定擴充，不需要再找廠商加購。

當你用不到機器了，你可以直接刪除，不必支付後續的費用。

而 VPS 需要先付一個月或一年的費用，

即使不再使用機器，仍然要付完合約期間的費用。

所以彈性這件事情，是 VPS 無法比較的。

再把比較層級拉高

其實我們應該從整個產品的定位來看，

VPS 只提供虛擬機器給你使用而已，

並沒有像 GCP 一樣提供負載平衡、自動擴充等等，因應網路流量變化的功能。

更不用說，VPS 也沒有辦法提供像是：

無伺服器、容器服務、代管資料庫、資料倉儲、機器學習或高階資訊安全等等企業等級的服務。

所以你使用 GCP 並不是純粹使用虛擬機器，

而是使用整個雲端的解決方案，來運作你公司的整個商業模式應用系統。

你可以用到非常多的功能，替代地端工具，

你以前可能要跟很多家廠商購買，

但以後大部分功能都可以在 GCP 上找得到。

三、跟 AWS (Amazon Web Services) 比

對於使用過 AWS 的用戶來說，估且不論雙方功能上的細部差異，

我們很明顯可以看出，AWS 的主機是比 GCP 還貴的，

但是對於還沒接觸公有雲的用戶來說，他們是不知道的。

以 2vCPU 和 4GB 記憶體的規格，比較價格如下：

AWS t3.medium，每月 205.65 USD，價格試算連結：
https://calculator.aws/#/estimate?id=36146c0902e064177cb1aa72383df13a89be9cf3

GCP N2 自訂規格，每月 71.12 USD，價格試算連結：

除此之外，AWS 目前在台灣沒有機房，

所以在網路速度(或網路延遲 Latency) 上，GCP 一定是快得多。

這樣比起來，你不覺得 GCP 便宜得多嗎？

以上的資訊給你參考，下次有客戶問你為什麼 GCP 這麼貴的時候，你就知道怎麼回覆他了。

The post 很多人嫌 GCP 的主機價格很貴？真的貴嗎？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

建立一個 非代管執行個體群組

取一個 Port 80 的名字 “http”，按下建立：

完成。

去建 Load Balancer 以及 SSL 憑證，但是要注意，DNS要解析 Load Balancer 的 IP，憑證才會有作用，那我先故意把憑證做好，再去改名稱解析，看看是否也會成功。此外，主機本身的SSL，等 Load Balancer 都弄好，我再去停用。

建立 Load Balancer

對外的，全域 LB

前端取 lb-1，使用 HTTPS

建立一個新的 IP

IP取名字 lb-1

也建立 Google 代管的憑證

取名字，把兩個網域都打進去

設好看起來像這樣

建立後端服務

取名字，設 HTTP Port，接到剛剛建立的群組

CDN 可以不用管，設定 Health Check

設定檢查 HTTP Port 80

Log 打勾

後端確認

lb 的名字也取一下，然後轉送規則先不要動。

整個都沒問題，按建立

LB 建好了

有 IP 可以連

看不到網頁是正常的，要處理 DNS 解析和憑證

點憑證會看到

趕快去改 DNS

原本這樣

改成這樣

然後 VM 也有 443，現在去把相關設定取消看看。

把那 2 個有憑證的設定檔，改成 .bak 讓 443 失效

重啟一下

現在網站是這樣

點網址 (HTTPS) 直接不能連，改用 HTTP 則顯示不安全，這樣應該是對的？接下來就等 Google Load Balancer 的憑證生效吧！

現在如果打網域是這樣，反正就再等

順便檢查一下新的 IP 有沒有解析成功

web2也成功了

再等等，30分鐘應該就差不多

剛重新整理，看到web1好了，web2還沒？真神奇，不會一起好嗎？

再等 2 分鐘，2個都好了

那打網址看看

憑證好了，但 Apache 可能再等一下

它的憑證還是 VM 的耶？

給它重開機好了

說被重新導向

查一下設定檔

sudo vim web1.humorousaaron.com.conf

原來有這三行

處理一下

web2也改

sudo systemctl reload apache2

再回去打網域

確認憑證

web2是同一個憑證

注意，它已經是 Google 頒發的憑證了喔，

所以算是更改成功！

現在是用 Google LB 的憑證，而不再是 VM 本身的 Letsencrypt 的憑證了！

The post [GCP 教學] 把主機的 443 Port 改成 GCP Load Balancer 443 Port first appeared on 東東 GCP 教學 - GCP 實戰講師.

參考《Debian/Ubuntu 環境申請和套用 Let’s Encrypt 免費​ SSL ​​憑證教學》的申請方式

安裝 Certbot

sudo apt-get install certbot python3-certbot-apache -y

申請憑證, 兩個網域同時申請

sudo certbot --apache --email aaronlee0618@gmail.com --agree-tos -d web1.humorousaaron.com -d web2.humorousaaron.com

其實我之前有先把網站設定檔改成 Port 443，它說要先用 Port 80

Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.

好，那我先回去改

cd /etc/apache2/sites-available

sudo vim web1.humorousaaron.com.conf

sudo vim web2.humorousaaron.com.conf

sudo systemctl reload apache2

80 port 開了，順便測名稱解析

第二個

再一次

sudo certbot --apache --email aaronlee0618@gmail.com --agree-tos -d web1.humorousaaron.com -d web2.humorousaaron.com

過關了，開始回答問題

它好貼心，還問要不要從 HTTP redirect 到 HTTPS

我按 2，它一口氣跑完

去檢查一下設定檔，看它改了什麼？

先 ls 一下，它是給這兩個網站多增加 ssl 的設定檔

原來的檔案 web1.humorousaaron.com.conf 沒改

那去看 web1.humorousaaron.com-le-ssl.conf

上半部有 443 Port 的設定，下半部有 SSL 憑證的設定

web2也確認一下，注意它的憑證檔，跟web1是存在一起的喔！

它有說儲存憑證的地方，我們也去看一下

它要有 root 權限才進得去

打開 cert.pem 檔案，可以看到只有一個憑證資料，不太懂，不是有兩個網站嗎？

對了，剛剛申請憑證的訊息，還有提供測試網址

點進去看看

哇！它還會幫你檢查憑證，也太貼心了吧！(需要等它跑完)

跑完之後會看到：

Web2 也是如下：

現在當我在瀏覽器輸入 http://web1.humorousaaron.com/ 按下 Enter 後，它會自動跳轉到 https://web1.humorousaaron.com/ 並且出現鎖頭的圖示，點擊後可查看憑證資訊：

Web2也是，但它秀的是 Web1的憑證

兩個一起看，所以是2個網域使用同一組憑證，原來如此啊，回答了上面的問題。

接下來準備要取消主機的 443 憑證加密，改用 Load Balancer 的 SSL 憑證，但是怕過程中出什麼差錯，我先把 IP 直接改成靜態的，並且對主機先做一個快照。

取名字

主機做快照，臨時用的選即時快照就好了。

確認完成了！

The post [GCP 教學] 把2個 Apache Virtual Host 網站申請憑證 first appeared on 東東 GCP 教學 - GCP 實戰講師.