AWS運算資源的節費
在本文中我們將聚焦AWS不同的運算資源價格模型，同時我們也需需要思考根據這些價格模型我們的系統或是workload適合使用哪一種。我們也探討適當調整運算資源大小的方法，以最大限度地減少與過度配置資源的相關浪費。
固定折扣
雲端資源的使用本質是pay-as-you-go，一種On-demand的即時取用。將企業的IT的費用從CapEx轉變成OpEx。這是一種權衡，因為如果我們的系統是長期且穩定的運算需求(例如ERP系統)，哪麼On-demand的運算資源對企業來說就是一種浪費錢的資源使用模式。
不過這跟我們租車是同一個道理，租車公司對客戶的臨時租、短租、長租與租很長的客戶一定是不一樣的價錢。租越長每個單位時間就越便宜。所以絕大多數的雲端公司(包含AWS)都會推出這種長短租方案。差別在於AWS應該是三大公有雲在這一類方案花樣最多，彈性最大的CSP了。
AWS針對EC2這一個服務推的租賃方案有:
- On-Demand
- Spot
- RIs(Reserved Instance)
- SPs(Saving Plans)
本文只聚焦討論RI與SP。不論上述的哪一種，EC2上的商業版OS的折扣幾乎很少或不會有。其他CSP也一樣，因為這些商業版的OS License都擁有權都不是AWS的。所以也不會有很特別的折扣，當然另外大量的去跟AWS談可能又是另一回事。但是從商業競爭的角度來看，在AWS上使用Windows license會比在Azure上使用還便宜嗎?如果你是微軟你會這麼做嗎?
所以我們在計算各家CSP的各項VM折扣時需要特別注意OS的計價部分，因為哪通常都不會在長期租賃的折扣中。
RIs(Reserved Instance)
RI(一種長租方案)可以分為兩種，standard與convertible。這兩種不一樣的方式在於standard的機器大小是固定的並限制在某個Region/AZ，但折扣比較大。convertible則是可以讓我們換機器規格跟換Region，例如一台大的VM換成兩台運算能力相等的小VM，同時也可以換到另一個Region。但我們需要特別注意的是，大的VM換成多個小VM可能會讓我們花更多錢，因為OS license的費用增多了。
另外RI的付款方式則有:
- All upfront(全部先預付)
- Partial upfront(部分的預付)
- No upfront(沒有預付)
預付越多便宜，因為對所有企業來說來說(包括AWS)對可以先收到的客戶當然要給予比較高的優惠，否則客戶幹嘛先預付。客戶這一筆費用的機會成本搞不好在別的地方可以發揮更大的效益。
All upfront的費用就很像是我們買機器的財務操作(CapEx而不是OpEx)。Partial upfront則是預付一部分費用，但其餘費用按月攤銷。另外Partial upfront的預付比例是固定的，客戶無法選擇預付比例。若要這麼做則要選用Sps這一個方案。No upfront就很好理解，就是純粹的分期付款。不管是哪一種，這一輛車(機器)一旦開始長期租賃，不管我們有沒有使用(開機)AWS都會要收錢。
另外我們如果要了解我們整個RI的使用情況，也就是On-Demand與RI的比例，我們可以使用Cost Explorer來進行比較。Cost Explorer會幫我們總結實際與On-Demand比起來到底節省的多少錢（以下是一個糟糕的範例）。
我們可以從上圖中看到RI使用的比例非常低，最好的理想狀況應該要有80%以上。至於為什麼不是100%，有興趣的讀者可以去查閱本部落格FinOps相關的文章。
剛剛我們提到Standard RI一開始就要買在一個特定的Region或AZ中。這有另一個好處，就是當該AZ或Region資源不夠時，如果我們有購買RI在該區域，AWS會優先讓我們使用該資源。可以把它看成，我們租停車場的車位時保證是有車位可以停的。
雖然我們上面提到Standard RI是不可以讓我們更換其他類型的Instance，但是還是有特例，就是我們使用的Instance是 Linux/UNIX OS。每個 RI 都有一個instance size footprint，用於定義其規範化大小。 例如，small instance的標準化因子(normalization factor)為 1，而medium instance的標準化因子為 2。所以如果我們一開始使用的是medium size Linux/UNIX RI instance，我們就可以換成兩個small size Linux/UNIX RI instance。以下是一個從t3.micro Regional RI換成兩個t3.nano的例子。
但這樣還是讓我們的RI使用率很低的話，哪麼我們可能一開始可能就買太多RI了。AWS還提供我們另一個方法就是RI的二級市場 — RI Marketplace，我們可以看成AWS開了一個他們自己的Ｙ拍或蝦皮賣場，讓我們去兜售多餘的資源。當然，也可以直接退租。不過這一個選項的罰款就可以要算一筆帳了。
如果一開始我們真的不確定組織的固定使用量是多少，卻也很想做省錢。哪convertible RIs也是可以達到這一個目的，雖然沒有Standard RI這麼省，但是總比用On-Demand來得省(如果想長期使用的話)。
SPs(Saving Plans)
SP 提供與 RI 相同的折扣，但不需要花太多時間去管理，例如需要交換或修改 RI。 SP 仍有兩種類型：EC2 Instance SPs與Compute SPs，折扣率分別相當於standard RI 和convertible RI。
需要記住的是，Standard RI的instance 類型是被固定住的。 使用 EC2 Instance SP，我們只是租賃了一個範圍內(Region與instance family)長期租賃。 這意味著我們可以更改OS、tenancy和instance大小，但仍然可以獲得折扣。Compute SP跟convertible RI 折扣率相同，但提供更大的靈活性。 Compute SP 甚至不需要選擇Region或Instance類型。
RI與SP不同的地方在於，EC2的使用區域與類型。以租車的比喻來說，RI就像是我們在一個租車場只有某些車型才有則扣。而SP則像是，我們在這個公司的所有租車場的所有車輛都有租賃折扣。
再來我們說一下RI與SP在整個組織中的分配規則。如果我們使用Management(payment) Account購買RI與SP，AWS首先會將折扣套用在這個account(如果有運算資源開啟且符合的話)。如果沒有，AWS才會將折扣套用到其他account。
但如果我們希望組織中有某個Account優先享受折扣，哪麼應該在該Account購買RI/SP。如果該Account有沒用完的折扣，AWS會幫我們平均分配到其他的Account中。另外我們可能有些Account是不需要享受其折扣的，也可以選擇在帳單主頁中將其排除(如下圖所示)。
Compute SPs的折扣可以用在比RI更多的AWS運算服務，例如Lambda與Fargate。使用這兩種服務一樣不需要管要用哪一個Region的哪一個instance type。不過當我們不確定我們要購買的SP hourly commitment時，Cost Explorer可以給我們建議(基於過去的用量資料)，如下圖所示。
正確的運算資源
在地端機房的時代，我們幾乎都會看到所有的Server平均使用率過低的狀況。這是因為技術人員為了要保護系統(同時也是保護自己)，在流量高峰期間期不會有任何的效能過慢問題。但是這個高峰期間卻不適經常性的，所以對組織來說資源浪費的問題就產生了。
不論地端機房或是私有雲的各項資源，包含運算資源。它們的資源都是固定的，既不能處裡高峰流量(如果超出硬體能力)，也不能處理資源使用效率過低的問題，因為軟硬體都已經買下去了。
在這個不斷變動的商業時代，要隨時去調整地端機房的使用效率實在是難上加難。但是公有雲的特性，讓我們不用去猜測未來需要的使用資源如何。而是讓我們去動態調整當下應該需要多少資源對應。
AWS的Cost Explorer 可以提供正確的運算資源建議(根據我們EC2的歷史用量)，協助我們有效率地運作資源。 當資源滿足運算需求時，這有助於減少整體浪費。 與推薦 RI 和 SP 的方法類似，Right-Sizing recommendations將分析歷史 EC2 使用情況並識別空閒和未充分利用的Instance(如下示意圖)。
另一個工具則是" Compute Optimizer"。與Cost Explorer不同的是，Cost Explorer的right-sizing recommendation 只會看資源使用率過小的instance並建議調整成較小的資源。而Compute Optimizer則還會視識別資源過載的instance。以下是一個從Management Account觀看(In AWS Compute Optimizer )，個別account的資源使用情況。AWS Compute Optimizer沒有提拱一個整個組織所有AWS account的統一的視圖。
Compute Optimizer也會建議在我們使用Auto Scaling groups時，其EC2的EBS的大小應該為何。
Lambda的優化
Lambda是一個serverless的服務，名詞是無伺服器。但是其底層還是AWS來管理，只是我們不再需要管理再運作代碼時所需要的各項基礎設施資源。
雖然是Serverless服務，但其實我們還是需要對其優化，並不是都不管了。因為如果是這樣做的話，哪我們收到Lambda的帳單可能還會比運作EC2更加的昂貴。Lambda的收費方式是基於代碼執行的時間，以MS(milliseconds)為單位。所以執行時間越端，費用就收得越少。
通常經過編譯的語言，如C++、Rust與Go的執行時間就會很快(因為不需要初始化)。所以通常選擇經過編譯的語言放在Lambda上跑就會比較有效率，不然就是要跑一些整合語言的簡單函式，如Python或Node。
我們也可以使用provisioned concurrency與編譯語言結合使用，以減少其運行時間。 Provisioned concurrency是一項功能，可使函數保持初始化（或預熱）以快速回應。 當我們呼叫 Lambda 函數時，Request將被路由到執行環境。 當函數有一段時間沒有被呼叫時，AWS需要建立一個新的執行環境， 這需要時間。 而且函數的依賴項（例如必須安裝代碼和套件）可能會延長運行時間，這稱為Cold Start。 Provisioned concurrency旨在透過初始化請求數量的執行環境來減少Cold Start問題，以便它們做好快速回應的準備。
以下是我們如何在Lambda中設定Provisioned concurrency的示意畫面。
另一個會影響Lambda費用的問題就是Memory的設定。給太多跟太少都會產生問題，類似EC2的memory配置。但Lambda的memory配置過多會浪費錢，但過少也會浪費錢，因為執行的時間變長了。如果我們有使用Lambda一段時間，哪麼Compute Optimizer會根據歷史用量給出我們Memory的最佳配置建議。雖然Compute SPs可以讓我們跑長時間的Lambda可以享有折扣，但我們還是需要做好相應的資源管理作業。
