在 Azure 上面要運行網站的應用程式，除了使用虛擬機器之外，就不能不提到 App Service 這一個 PAAS 服務了，可以很方便的部署和管理網站，因此第一個可以最佳化成本的服務就先來說明 App Service，本文就針對 App Service 計費方式和選擇建議等做介紹和說明。
說明
計費的範圍
首先第一個要提的是 App Service 的費用，基本上主要會有兩個部分組成，一個是運算資源，一個是流量費用，流量部分就不在本文的探討範圍內，後面介紹和說明主要是針對運算資源的費用來說明如何選擇和最佳化成本。
App Service 的運算資源的計費並非以 App Service 的站台個數來計算*，而是以 App Service Plan (App Service 方案) 作為計費的範圍，可以把一個 App Service Plan 看做是一台 VM 的，在上面可以同時運行多個 App Service 站台，這時候計費依舊會是 1 個 App Service Plan 的費用，雖然可以同時運行多個站台，但是還是會依據不同定價層，可以運行的站台個數是有限制的，不過除了免費和共用這兩個比較特殊的定價層以外，是沒有限制的，也就是只要你選擇的定價層可以撐的住所有的站台運行，就可以使用同一個 App Service Plan 來運行站台的，這樣也就可以達到第一個最佳化費用的選擇。
共用方案是以站台來計費
| 方案類型 | 免費 | 共用 | 基本 | 標準 | 進階(v1~v3) | 隔離 |
|---|---|---|---|---|---|---|
| 每一方案站台執行個數 | 10 | 100 | 無限制 | 無限制 | 無限制 | 無限制 |
定價層的分類
在定價層的分類維度上可以分成兩個：
- 作業系統：Windows、Linux
- 運算資源：免費、共用、基本、標準、進階、隔離
作業系統
按照底層運行的作業系統來分類的話可以分為 Windows 和 Linux 兩個，這兩種類型方案在功能上和價格上也會有所落差， Windows 類型的方案會有絕大部分的 App Service 提供的供能，而 Linux 類型的也沒有共用定價層，免費的定價層在每個資料中心也僅能開 1 個 (Windows 則為 10 個)，但是在費用上，同樣運算資源 Linux 類型方案是相對便宜的。
在功能上的差異 Windows 基本功能多了以下的項目：
- WebJob：可以執行排程的程式
- 推送：結合通知中樞 (notification hubs)推送跨平台的推播訊息。
- MySQL in App：一個免費的 MySQL，可以參考之前文章「App Service 中使用 MySQL in App 和 phpMyAdmin」
在開發工具上差異則為：
| 複製應用程式 | 主控台(Console) / SSH | 進階工具 (Kudu) | App Service 編輯器 | 擴充功能 | |
|---|---|---|---|---|---|
| 功能說明 | 可快速複製出一個 App Service 站台 | 執行指令碼 | 管理和察看更細部的設定等 | 線上編輯程式碼和文字檔 | 可額外安裝一些擴充功能或是自行開發外掛的功能上架到擴充功能上 |
| Windows | 有 | 主控台 | 有 | 有 | 有 |
| Linux | 無 | SSH | 有 (但功能較 Windows 少) | 無 | 無 |
在選擇上除了功能上的差異，另一個考量的點就是要運行的站台是用哪種程式語言開發的，部分程式語言 (Go、PHP、Python、Ruby) 預設上是無法選擇在 Windows 類型的。
運算資源
依照運算資源可以分做六大類的方案，而在根據比較常見的資源以及費用相關的比較，我整理成下表，主要分做幾個面向去看：
- 計算執行個體類型：針對虛擬化出來的運算資源可分為共用和專用，共用指的是會和其它 Azure 使用者共用虛擬化的出來的同一運算資源，所以是有機會被其它人影響到效能，而專用則是方案有獨立的完整運算資源可以使用，影響效能的因素會限制在自己部署的站台，而隔離方案的專用資源又更進階，會再專屬的硬體上部署，可以將環境切割的更乾淨。
- 頻寬：除了免費的有額度限制以外，其它方案都沒有限制，免費額度超過 165 MB 之後站台就會被暫時停用到下一個付費週期，其它方案雖然沒有限制，但是費用是獨立計算的，會根據頻寬的一般定價去計費。
- 磁碟空間：存放網站檔案的空間，因為每個方案是有上限，通常建議有上傳需求的功能，會另外將檔案存放在儲存體，而不建議都放在 App Service 儲存空間上。
- ACU / 核心數：首先要提到 ACU 這一個名詞，是微軟用來判斷單一核心的運算資源的計量單位，數值越高代表運算能力越強，未來談到虛擬機器時候也會再提到，而比較特別的是免費和共用的計算上和一般方案不同，因為他是共用資源，所以計費方式是用 CPU 運算的時間來計算，而他不是指開機的時間，而是 CPU 有運算的時間來計算，超過限制的時候網站就會暫時停用，所以通常免費和共用比較適合低負載或是測試站台來使用。
- 記憶體：就是記憶體，沒特別的額外說明。
- 保留 / 節省方案：在節省費用上最重要的兩個方式，主要就是承諾一年或三年的運算資源，月繳或是一次繳，可以有更大的折扣，對於長期運行的站台或服務，運算資源固定下，就適合考量購買這樣方案來達到節費，而比較要說明的是隔離方案 v1 的保留方案僅針對隔離方案特有的 Stamp Fee，這是 ASE v2 建置好之後就會開始產生的費用，就算上面還沒開始部署站台也會固定有的費用，但是現在 ASE v2 也沒辦法直接開立，新建立的就會是新架構的 ASE v3 版，就會適用隔離方案 v2 就不會有這一個 Stamp Fee 費用了。
| 免費 | 共用 | 基本 | 標準 | 進階 | 隔離 | |||
|---|---|---|---|---|---|---|---|---|
| v2 | v3 | v1 (ASE v2) | v2 (ASE v3) | |||||
| 計算執行個體類型 | 共用 | 共用 | 專用 | 專用 | 專用 | 專用 | 專用 | 專用 |
| 頻寬 | 165 MB | 無限制 | 無限制 | 無限制 | 無限制 | 無限制 | 無限制 | 無限制 |
| 磁碟空間 | 1 GB | 1 GB | 10 GB | 50 GB | 250 GB | 250 GB | 1 TB | 1 TB |
| Azure 計算單位 (ACU) | 3 分鐘 / CPU 時間 (5 分鐘) 60 分鐘 / CPU 時間 (天) | 3 分鐘 / CPU 時間 (5 分鐘) 240 分鐘 / CPU 時間 (天) | 100 | 100 | 210 | 195 | 210 | 195 |
| 核心數 | - | - | B1：1 B2：2 B3：4 | S1：1 S2：2 S3：4 | P1v2：1 P2v2：2 P3v2：4 | P1v3：2 P2v3：4 P3v3：8 | I1：1 I2：2 I3：4 | I1v2：2 I2v2：4 I3v2：8 I4v2：16 I5v2：32 I6v2：64 |
| 記憶體 | 1 GB | 1 GB | B1：1.75 GB B2：3.50 GB B3：7 GB | S1：1.75 GB S2：3.50 GB S3：7 GB | P1v2：3.50 GB P2v2：7 GB P3v2：14 GB | P1v3：8 GB P2v3：16 GB P3v3：32 GB | I1：3.50 GB I2：7 GB I3：14 GB | I1v2：8 GB I2v2：16 GB I3v2：32 GB I4v2：64 GB I5v2：128 GB I6v2：256 GB |
| 保留 (Reservation) | 無 | 無 | 無 | 無 | 無 | 有 | 有* | 有 |
| 節省方案 (Saving Plan) | 無 | 無 | 無 | 無 | 無 | 有 | 無 | 有 |
隔離方案 v1 僅針對 Stamp Fee 費用可以購買保留
定價層的選擇
前面主要是針對單純運算相關的資源來考量的，那有那麼多的選項又該如何去選擇適合的方案？下表是針對一些常見功能的比較：
- 執行個體上限：基本以上的定價層是可以透過手動或自動來增加執行個體數量，想成就是多產生一台虛擬機器來運行網站，當然每多一個執行個體也代表需要多付出一份的費用。
- 自訂網域：綁定自己的網域。
- 自動調整規模 (Auto Scale)：可以透過設定來自動調整執行個體數目，以便在網站負載增加時候可以自動增加資源來提供服務，避免網站或服務異常。
- 虛擬網路連線：可以整合虛擬網路再連線到特定的資源或是公司內部環境，但是基本和標準定價層如果為舊架構的 App Service 可能會無法正常使用此功能，可以參考之前文章「解決 App Service 無法在基本和標準定價層整合虛擬網路問題」說明。
- 應用程式架構：32 位元 / 64 位元，可以在組態中設定執行的程式架構類型。
- Always On：針對網站或是需要定時執行的 WebJob 就會需要啟用此功能，避免因網站閒置而回收資源，導致下次啟動會較花時間，WebJob 則會無法在排程時間內自動執行。
- 備份：會針對 App Service 儲存空間內的檔案進行備份，可以透過此功能還原或下載備份的檔案。
- 預備位置個數：App Service 一個很棒的功能就是支援預備環境，可以將站台先部署到預備環境測試之後和正式環境進行切換，或是設定流量，可以參考之前文章「使用 Azure DevOps 部署到 App Service 預備環境 (Slot) 並進行切換」中說明。
- 在生產環境中測試：同上。
- SLA：需要注意的是免費和共用是沒有 SLA 的。
| 免費 | 共用 | 基本 | 標準 | 進階 | 隔離 | |
|---|---|---|---|---|---|---|
| 執行個體上限 | - | - | 3 | 10 | 30 | 100 |
| 自訂網域 | - | 支援 | 支援 | 支援 | 支援 | 支援 |
| 自動調整規模 | - | - | - | 支援 | 支援 | 支援 |
| 虛擬網路連線 | - | - | 支援 | 支援 | 支援 | 支援 |
| 應用程式架構 | 32 位元 | 32 位元 | 32 位元 / 64 位元 | 32 位元 / 64 位元 | 32 位元 / 64 位元 | 32 位元 / 64 位元 |
| Always On | - | - | 支援 | 支援 | 支援 | 支援 |
| 備份 | - | - | 支援 (每兩小時備份，一天最多12次備份) | 支援 (每兩小時備份，一天最多12次備份) | 支援 (每小時備份，一天最多50次備份) | 支援 (每小時備份，一天最多50次備份) |
| 預備位置個數 | - | - | - | 5 | 20 | 20 |
| 在生產環境中測試 | - | - | - | 支援 | 支援 | 支援 |
| SLA | - | - | 99.95% | 99.95% | 99.95% | 99.95% |
| 建議使用情境 | 測試用站台 | 測試或是低負載的站台 | 正式或 UAT 環境 | 正式或 UAT 環境 | 較高負載的正式環境 | 企業專用的站台，需完全隔離 |
部分方案間是無法切換或升級的，比如進階 v2 目前是無法直接轉換成 v3 ，或需要針對服務或資源重建，隔離的方案的架構和建置方式也有所不同，也是無法切換到隔離以外的方案。
免費 SSL 憑證
在 App Service 功能裡面，針對憑證提供了受管理的憑證，可以針對綁定的網域申請免費的憑證，對於一些站台需要 SSL 憑證，又不到需要申請等級更高的憑證，僅需要讓網站有 SSL 憑證可以跑 https 增加安全性的時候就可以考慮使用，這也可以剩下一筆額外的憑證費用。
結論
整理一下以上的說明，可以將 App Service 的費用最佳化列出以下幾點：
- 在運算資源許可下共用同一個 App Service Plan：如果多個站台運算資源需求不高，或是不會同時間有高負載就會很建議把他放在同一個 App Service Plan 來共用資源，就不需要一個站台開一個 App Service Plan，就可以節省不少費用。
- 善用免費和共用定價層：雖然每個訂閱可以建立的免費和共用定價層有個數上限，但是可已針對一些測試用的臨時站台使用這兩種方案，就算不小心超過 CPU 上限也不影響正式營運的站台就會很適合使用，也是節省費用的方式。
- 選擇適合的方案作業系統和定價層：前面針對作業系統和運算資源介紹了很大的篇幅，可以針對自己的需求和功能去挑選出最適合的方案，避免對於功能不熟悉就開到太大且不需要的方案。
- 購買保留 (Reservation) 或節省方案 (Saving Plan)：針對長期運算的站台或是服務，像是官網或是產品站台，就可以考慮購買保留或節省方案，預先承諾一年或三年的運算資源來達到折扣，這可以節省下來的費用會是相當可觀的。
- SSL 免費憑證：針對一般站台需要 SSL 憑證讓網站支援自己網域就可以考慮使用，或是在測試階段先使用免費的憑證，等到網站或服務正式上線快上線再去購買正式一點的憑證，這也是可以剩下一些成本費用。
本文介紹了 App Service 的各種定價層比較和挑選的策略，希望對於想最佳化 App Service 費用的朋友有幫助，或是還有想知道哪部分的議題都可以提出來討論。
