雲端費用的省錢-運用RI與CUD

30 min readMar 22, 2022

RI(Reserved Instance)是FinOps的本質。它為財務與技術部門的鴻溝搭起了一種橋梁，把這兩種不同類型的部門對準在一起可能能很實現。然而，當這兩個部門可以契合時，RI可以用改進後的雲端單位經濟（Cloud Unit economics）的形式帶來顯著的競爭優勢，以很低的價格為我們提供相同的運算能力。

預購的介紹

RI與CUD(Committed Use Discount)統稱為預購(reservation)或承諾(commitments)，這是一種在雲端上很普遍的省錢方式，就是預先付費。這只是一部分是因為雲端平台商(以下簡稱CSP)的行銷說帖經常能夠來說服我們通過雲端運算可以節省大量費用，但也因為 FinOps 平台使我們能夠計劃、管理並從這些優化中受益。

每個CSP的產品略有不同，其作業方式和提供的折扣都有自己的一套規則。我們還必須根據企業的需求考慮企業使用的實行模型，以及整個過程應如何在企業內作業。因為我們承諾在一定時間內使用特定類型的資源，我們將有很大的折扣。這個想法似乎很簡單。但正如我們將看到的，有許多細微差別(眉眉角角-台語)需要學習。

幾年前在一個Webianr(介紹RI)的場合中，其中有AWS, Cloudability與Adobe， Adobe展示了下圖來顯示他們公司用了在EC2購買RI之後節省了 60%的費用。

像Adobe這種成功使用了預購(reservation)/承諾(commitments)的效益看來是顯而易見的。但是，對許多公司來說要一個良好的RI覆蓋率(coverage)是一個需要大量內部教育和調整的過程。

一個購買RI的故事

有一家零售業每月有數百萬美元的雲端支出，但 RI 為零。他們知道，即使購買少量的 RI，他們也可以節省很多錢。事實上，通過分析該公司的基礎設施，可以發現如果購買RI他們可以在未來三年內節省數百萬美元。因為他們是零售業，所以利潤很低，購買 RI 可以幫助他們實現C-Level們規定的關鍵成本降低目標。

然而，儘管如此，他們仍然花了整整 9 個月的時間來購買他們的第一個 RI。發生了什麼？儘管top-down的成本削減目標非常激進，但為什麼企業在採用如此明顯的成本節約措施方面卻如此緩慢？答案是因為他們必須就購買 RI 的含義對企業中的許多利害關係人進行教育和調整，並在此過程中消彌多年來資料中心硬體採購過程中形成的許多誤解。

首先，他們必須讓財務部門參與進來，了解如何對 RI 進行財務核算。 RI 的預付款(Upfront payments)似乎是資本支出 (CapEx)，財務應作為實物資產折舊。但是，RI 是營運支出 (OpEx) 的無形預付款，需要在其使用期間進行攤提。

接下來，他們必須讓他們的技術團隊適應當前的基礎設施。雲端的優勢在於我們能夠只使用需要的東西並調整基礎架構以適應工作負載的態勢。然後引入新的方法，比如serverless或容器化，以及在一組新的雲端服務上完全重構基礎設施。更改基礎架構的風險使團隊不願在一年或三年的預購中承諾他們當前的技術堆棧。這些團隊基於改善基礎設施的具野心的計劃而拖延時間，導致購買預購出現多次延遲。

可惜的是，這樣的故事很常見。隨著公司實施他們的首次預購，讓所有團隊參與可能需要很長時間，而失去的節省機會可能會增加數百萬美元。如果這家零售業在這九個月期間對業務進行培訓時購買了一些 RI，他們將實現可觀的節省 — 並避免數百萬不必要的雲端On-Demand spending。

預購/承諾的使用(Usage)

雖然每個CSP的產品細節都不同，但所有三大CSP都為我們提供了相同的簡單能力，可以在一段時間內承諾特定資源的使用。我們的承諾可確保CSP繼續開展業務，作為回報，他們會以較低的費率獎勵我們（費率優化）。折扣可能相當可觀 — — 在某些情況下，可能打2.5折( 75% off)。

在所有三個主要的CSP中，我們實際上並沒有保留特定的server instance或承諾特定的資源。請記住，我們已經拋棄了地端機房單一實體設備的概念。 CSP在計費時套用折扣。事實上，RI 本質上是一種計費結構。 AWS RI 可以在帳單折扣之外提供一些容量功能，我們將在後面專節介紹AWS。

RI或CUD套用在單一資源是一種非確定性的做法。CSP套用這些折扣是基於一種鬆散的規則，並且他們計費去向的原因和計費去向的細節是相當不透明的。CSP會將預購隨機分配給帳號中的資源。這種隨機套用的方式會產生多種的策略與chargeback的考量，這類的策略與考量我們將會在專門的文章中介紹。對於提供resource level計費資料的CSP，我們可能不會看到折扣直接套用在我們的資源，或者至少不會套用在我們預期的資源。

一個比喻可能有助我們更好地理解預購/承諾的概念。假設一家大型的租車公司正在進行一項活動，我們可以購買一本的優惠券。每張優惠券都可以讓我們在這家租車公司的特定營業處租車。這本優惠券一共有30張(類似月票的概念)。當我們在指定營業處租車時，我們使用優惠券支付租車費。決定在其他營業處租車意味著我們放棄當天的優惠券並在另一個營業處支付全額。

假設這本優惠券的價格為 3萬台幣，包含 30 張券，每張券可以為您提供一整天的租車時間(24小時)，如果在沒有優惠券的情況下租車，則需要 2000元。分開計算，每張 1000的租車券可以租2000元的車，每天為我們節省 1000元。如果你每天都在這個營業處租車，我們可以節省 50%，如果你只在那裡租車2天，我們其實什麼都沒有省到。如果我們使用超過一半的優惠券，哪我們最好買這本優惠券。

如果我們將這個概念套用在 RI，一旦我們決定了要購訂的時間區間，我們就可以從CSP哪邊進行預訂（整本優惠券），匹配特定的資源類型和區域（特定營業處的特定車輛）。此預購將允許我們每小時（或每秒）運行一次匹配資源。如果我們沒有運行任何與預購匹配的資源，我們將失去節省的費用。只要我們在預購期內有足夠的資源使用量，我們就可以從折扣中受益 — — 並且可以省錢。

這裡的重點是:

我們對預購進行付費，不管我們有沒有使用到它
預購會花錢，但它們抵消了帳號中的資源成本
對於預購的資源，我們不用把使用率操到爆。因為對RI這件事來說操到爆也不會省錢。

每個CSP的預購的具體購買選項以及它們可以申請的資源都不同。某些產品允許我們在承諾期限內修改承諾參數。

Instance Szie的彈性

CSP提供了幾百種不一樣的server instance, 而預購(Reservation)會匹配一些特定的資源使用參數。意思是我們可能必須購買數百種可能的特定資源。但為了讓這個過程不要哪麼複雜，CSP會提供一種instance szie的彈性。

在特定類型的雲端資源使用中，我們可以選擇一個範圍的 server instance(基本上是一個vCPU/memory的總量)，隨著Size的每次增加，成本都會成比例的增加。例如，在AWS中，兩個相同size 的instance加起來的價格如果等同於另一個大的insatnce(2個m5.large換一個 m5.xlarge)就可以換成大的instance。相反的我們也可以將大的insatnce拆分成較小的。

但有一個問題我們需要注意:就是軟體授權問題。兩台insatnce 的軟體授權不等同一台，可以讓我們用相同的價錢交換的只有instance本身。因此，一些 CSP(如AWS) 將instance size的靈活性排除在具有軟體授權的服務器之外，而其他CSP(如Azure) 的預購方式只有對硬體規格有打折，而將軟體授權排除在外。

而GCP 的收費方式，是用同一系列產品中組合(例如 VM的N2系列)圈一個總量pool。例如， 60個vCPU/ 640G memory，看我們要拆分幾個instance，實現instance大小的靈活性。保留適用於組合的總數量，而不是針對單個大小實例。

轉換和取消

預購的方式還有一種方式是能夠轉換(convert)預購或將其交換(exchange)為另一種類型。 “可兌換預購的費率通常低於無法交換的預購”。轉換預購的能力降低了最終預購與我們的資源使用不匹配的風險。如果資源更新後不再匹配，我們可以將預購的資源換成匹配的資源。交換或轉換預購的能力通常僅限於最初購買的Region。

一般來說，我們進行的轉換必須具有相同或更高的價值。因此，如果我們降低對CSP的資源使用率，那麼如果這樣做會導致整體承諾(commitment)降低，我們就無法交換預購。除了轉換之外，一些CSP（例如 Azure）提供取消某些預購的，不過通常是收錢的。

三大CSP的雲端資使用承諾概覽

下圖為三大CSP的資源使用承諾比較表:

我們可以看到三大CSP的產品非常相似，具有相同的期限長度和size的靈活性。折扣費率的不同之處主要取決於它們應用預購的特定方法和雲端資源的打折計費方法。

Amazon Web Services

AWS是第一個(在2009年)提供這種預購方式的CSP．之後這種預購方式在 AWS這邊變得越來越複雜．然而，這也代表了AWS提供最大的彈性與可配置性． AWS的的預購產品有: EC2/ RDS/ Redshift node/ ElastiCache node與DynamoDB的capacity．

DynamoDB的 capacity預購不同於其他產品．DynamoDB的預購是對資料的read/write capacity來計算的．其他的產品每一個有一些些不同的feature，但共通點就是這個預購是要承諾一年或三年的．我們可以分期付，或這先付一部分的租金，或者是一次預付所有的款項，基本上預付的部分愈多折扣就會越高．購買 RI 時，我們會購買一個或多個具有相同參數在AWS稱為lease(租約)。

RI 的命名很容易混淆，因為我們實際上是沒有保留insatnce。也不能保證預購(reservation)適用於特定資源。我們要記住的是，RI 更像是我們購買的整本優惠券，並且不確定地針對相關資源來套用。

RI 通常被認為是套用於一定百分比折扣的資源成本。但是，說 RI 的固定費率比購買當下哪個時刻的On-Demand便宜一定數量也是正確的。雖然這聽起來可能是一回事，但重要的是要了解，如果 AWS 降低On-Demand費率，我們已經有的 RI 費率在一年或三年期限內是不變的，有就是on-demand降價不代表我們的RI也會一起降價。價格下降可能會影響我們對購買哪種 RI 配置的決定 — — 我們將在本文後面討論。值得注意的是，對AWS歷史上的on-demand價格調降的分析表明，AWS 通常不會將on-demand 費率降低到足到降低三年 RI 價格的程度。

RI提供了些什麼？

AWS的預購分為兩個部分：價格的優惠與我們購買特定資源類型的capacity的保留．絕大部分當然是批發折扣費率．但在某些狀況下，當組織預計某種特定類型資源在CSP的某個region的容量不足時，他們也可能需要容量預購，以保證組織一定用得到這一類的資源．也就是AWS不會有機位超賣的狀況．

多年來，隨著 AWS 擴展了他們的基礎設施，我們已經看到容量預購成為採購RI的一個不太重要的部分。然而，一些運行大規模、彈性基礎設施的客戶仍然在優化容量。而AWS 也提供了On-Demnd 容量預留，允許我們與 RI 分開執行容量預留。當我們將on-dmeand容量預留與 RI 結合使用時，必須將我們的 RI 設定在某個Region，以便 RI 可以折扣容量預購(capacity reservation)。

AWS RI的參數(使用範圍)

我們在某個Region購買特定的resource type．AWS會在我們買的這一本優惠券上家賞一些使用條件，我們稱之為參數，而參數如下：

Region
優惠券可以用在哪個區域．例如，日本或美國．

Scope
我們的預購是zonal 或 regional的？如果是zonal，哪它就會使用在某一個特定的AZ(availability zone)，例如： US-East-1A．如果是regional，哪RI就可以套用在所有該Region的 AZ中．要注意的是，只有zonal RI 會有容量預留(capacity reservation)，但可以為regional RI 購買容量預留。

AZ(availability zone)
如果是zonal RI，哪一個AZ是我們要套用的．

Instance characters
Type: instance的系列(例如：m5, c4, t2)與大小．每個系列的instance size會不太一樣，不過通常會分為 large/xlarge/2xlarge等

Tenancy: 底層的硬體資源是專用還是shared

OS: 哪一種OS是我們要用的(因為這要算錢的)

如果我們在run insatnce沒明定這些參數上去，我們購買的優惠券就無法使用．所以這些參數對我們使用 RI的優惠很重要．AWS 隨機的將折扣套用於隨機選擇的資源，例如優惠券是用在參數都是正確的地方。雖然insatnce大小的靈活性將適用於從最小到最大的insatnce，但目前沒有辦法確保將折扣套用於特定資源而不是任何其他匹配的資源。

關聯帳號的連結

AWS Organizations 提供了一項稱為合併計費的功能，該功能允許關聯帳號並將成本合併到單一個主要付款人賬號中。一個 AWS Organization內只能有一個主要付款人帳號，並且帳號只能鏈接到一個 AWS Organization。

當我們購買 RI 時，您可以在主要付款人帳號或任何關聯帳號中執行此購買。 RI 可以在同一 AWS Organization內的帳號之間分享他們提供的折扣。但是，它們與其所屬的本身的帳號具有關聯性，意思是在特定帳號中購買的 RI 將首先可供該帳號中的資源使用。

如果本身的帳號沒有任何匹配的reservation instance，則reservation將對屬於同一 AWS Organization的任何其他 AWS 帳號的匹配使用量套用折扣。可以在每個 AWS 帳號的基礎上停用 RI 共享。如果停用 RI 共享，則該帳號內的任何 RI 將不會在這個本身的帳號分享給其他帳號使用，並且當 RI 與這個帳號內的任何雲端資源使用不匹配時，它也不會套用任何折扣。

如果RI不共享對於各部門或BU的預算目的至關重要，則停用共享有效地將 RI 固定到特定帳戶，但也可能導致浪費，因為折扣在不使用時不會共享給其他人。此外，同一 AWS Organization中的這個停用RI的帳號也不無法享有其他帳號有購RI的折扣。也就是說如果沒有停用RI分享，各部門或BU之間的優惠券就可以互通，若其中有一個部門或BU(aws account)停用RI共享，哪它只能用自己的優惠券．

大家通常會誤解 RI 共享的工作原理。為確保我們做對了，請看下圖的範例。

上圖顯示了一個典型的帳號結構：一個主要付款人(Master Payer Account)和幾個關聯帳號(Linked Account)。我們可以在圖中看到三個 RI 購買：在主要付款人中、在關聯帳號 A 中和在關聯帳號 C 中。帳號關聯性會導致賬號內的 RI 首先對本身帳號套用折扣。如果在同一帳號內沒有資源使用與 RI 匹配，則 RI 可以通過 RI 共享對另一個鏈接帳號中的雲端資源使用套用折扣。

在上圖中的範例佈局中，可能會出現以下情況：

RI在主要付款人的account可以套用到Account A與 B，因為他們都有RI共享的設定．
Account A 可以使用本身帳號中購買的 RI 和主要付款人帳號中的 RI ，但會優先選擇本身帳號內的 RI。
Account B 可以使用Account A 和主要付款人帳號的 RI 。
由於Account C 停用了 RI 共享，因此該帳戶內的 RI 不會在Account C 之外分享這個折扣，並且在沒有雲端資源使用匹配時將不使用。
Account D 將不會收到任何 RI 折扣，因為它已禁用 RI 共享並且沒有在該帳號內購買任何 RI。

標準與可轉換的RI

在AWS採購RI時，我們可以在一次的租約中購買多個RI。標準RI(Standard Reserved Instance)的意思是，它只能套用在一開始我們就在RI採購中設定好的那些參數區域上使用。

不過SRI還是可能改變某些參數的，例如AZ 與Scope(regional / zonal)。如果是 Linux/UNIX RI，部分的RI還可以分離或合併(兩個 mediums變成一個大的)。不過SRI在購買後能改的參數不多，像租約期間，OS，insatnce 系列(m5, c5)，tenancy(專用或共享)。SRI只能專款專用，並且租約期是一或三年。

而對EC2的部分則有更多的彈性，可轉換RI(Convertible Reserved Instance以下簡稱CRI)就可以在EC2上使用。作為較低折扣百分比的回報，我們可以在期限內將 RI 預購(reservations)交換為不同的預購。但一些限制條件仍然適用於預購間的交換。

無論如何，我們都不能減少對 AWS 的總體批發購買。例如，如果預購間的交換導致較低的批發價格，我們不能將貴的 RI 預購換成更便宜的預購。在這種情況下，需要進行費用校正，以此修改包括更多的 RI 或更昂貴的參數。當 RI 交換導致更多費用時，AWS 將按比例向我們收取任何應付預付款的差額。也就是說，AWS這類的RI交換只讓我們換貴的不能換便宜的。

有一個過程讓我們拆分 CRI 預購，以便我們可以就轉換部分的RI，而不是單個 RI 租約中的所有 RI。我們也可以將多個 CRI 預購合併在一起的過程，讓我們將它們全部合併成一個新的 CRI 購買。但是，在租約期間內無法修改 CRI 的某些參數：

CRI的租約一樣是限制在某個Region，而不能更改到其他Region
CRI只針對EC2 insatnce並且不能被換成其他的AWS服務;例如 EC2 CRI 換成 RDS RI
一般來說CRI租約期不能改，除非我們合併其他CRI時延展合併後的租約。也就是原來的CRI租約中有一份的效期較長。

除了這些限制之外，整體 CRI 對組織的風險要低得多。除非我們可能會在租約期間內減少 EC2 的總體使用量，否則我們可以在租約期限內更改我們的 EC2 使用參數並將我們的 CRI 交換為我們想要的。

EC2 RI 還包含一項稱為capacity reservation的功能。配置為zonal RI 將保持可用的服務器容量。這容量只適用於與 RI 相同的 AWS 帳號，並且只有適用於所選的AZ。如果我們在帳號中有未使用的 RI，並且這個AZ有開始資源不夠的狀況，哪我們有優先權在這個AZ開啟與我們參數匹配的 EC2 insatnce。就像 RI 折扣一樣，我們不能將capacity reservation分配給任何特定的instance，因此在該帳號中運行的第一個匹配insatnce將消耗此capacity reservation。

設置為Regional EC2 RI 將對同一region中的任何AZ套用折扣，但不包括任何capacity reservation。但是，Regional RI 可以與on-demand capacity reservation相結合，以實現跨Region的 RI 折扣。但他們保留了在特定AZ capacity reservation的能力，然後讓我們的regional RI 的折扣套用於capacity reservation。

Instance Size的彈性

EC2 RI的購買是要符合特定的instance size(small/medium/large/xlarge等)．然後這些 RI就會套用到匹配的resource．然而，對於regional Linux/UNIX RI，我們可以從前面提到的稱為instance size flexibility(ISF) 的功能中受益。我們當前擁有或計劃購買的具有 Linux、regional和shared tenancy屬性的預購將自動成為 ISF RI。

ISF 允許 RI 對同一系列（m5、c5、r4 等）中不同大小的insatnce套用折扣。單一大型 RI 可以對應多個較小的insatnce套用折扣，單一小型 RI 可以對應大型insatnce套用部分折扣。 ISF 讓我們可以靈活地更改insatnce的大小，而不會失去 RI 原有的折扣。因為我們不需要具體說明 RI 的確切大小(而是一個總數)以涵蓋所有不同大小的insatcne，所以我們可以將購買的 RI 捆綁成小的參數變體。

下圖說明了如何應用 ISF 的一種思維．

上圖中，每column代表在特定小時內運行的insatnce。對於 r5s 和 c5s，large (代號L) 是最小的insatnce大小。如果我們在此範例中以 100% 的 RI 利用率為目標，我們將購買 29 large RI。可以將其視為以instance 系列中最小的szie購買“積分(point)”。這意味著我們只有一個與我們的使用情況非常匹配的實際 RI 預購。如果insatnce size波動但正規化的使用量保持不變或整體增加，則我們的 RI 將保持最好的使用率。

AWS 使用正規化因子(normalization factor)來確定特定 RI 如何與 ISF 一起應用。使用它可以計算出特定大小的instance有多少標準化單位。 RI 使用相同的正規化因子來確定每小時可以應用多少正規化折扣單位。

下表中的正規化因子顯示如何在一個系列中的insatnce大小之間進行轉換。例如，如果我們擁有一個 4xlarge（32個單位）的 RI，則該 RI 可以改為應用於兩個 2xlarge（每個 16個單位）或四個xlarge（每個 8個單位)的insatnce。

ISF RI 的計費取決於我們運行的insatnce size（相對於我們有的 RI）。在下圖，我們有四個small reservations，它們將涵蓋四個small instance。如果我們沒有任何具有insatnce size靈活性的small insatnce，這個reservation將適用於兩個Medium insatnce。在沒有任何Medium insatnce的情況下，我們可以套用到large insatnce、xlarge 的一半或 2xlarge insatnce 的1/4。較大的instance可以由較小size的 RI 部分的覆蓋，哪麼這個2XLarge insatnce剩餘未被RI cover的地方就會按比例(剩的3/4)被收取on0-demand的費用。

Savings Plans

AWS還提供了稱為Savings Plans的預購，這是一種更大型的預購量．收費方式跟RI一樣(All upfront/ partial upfront/ No upfront)，也是分一年與三年．

Savings Plans分成三種類型：Compute Savings Plans, EC2 Instance Savings Plans, 與 Amazon SageMaker Savings Plans. 三種不同的採購方式可以參閱 AWS的文件說明．

Saving Plans與RI不同之處在於：

Saving Plans去掉了RI的一些參數限制條件(tenancy/OS/instance family/instance size)提供更大的彈性空間．而Compute Savings Plans可以套用在所有的Region，這可以讓我們在最大程度上對資源進行轉換．
使用 RI，我們可以購買與我們帳號中的insatnce相匹配的預購。 Savings Plans 是按承諾的每小時購買的。重要的是，我們承諾的支出金額是折扣後的。例如，如果我們開啟 1000 美元/小時的On-Demand EC2 並且 Savings Plan 提供 50% 的折扣，則我們只需要購買 500美元/小時的 Savings Plan。

Google Cloud Platform

GCP 基礎架構和服務與其他 CSP 不同，具有兩種獨特的計費結構，能夠簡化雲端成本。

在討論CUD(Committed Use Discount)之前，我們可以先看一下對使用者來說什麼都不用做的SUD(Sustained Use Discount)． SUD是一種以時間為單位的費率折扣．我們在這一篇付更少的雲端成本 — 費率優化有提到，這種費率是以我們機器的開了一整個月來進行費率折扣(現行是打七折)．不過SUD的費率還是沒有 CUD來得高．

如果要有最好的費率， GCP提供了 CUD的選項．針對 CUD，GCP提供了一年與三年的租約．如果是三年的租約最高可以接進到打四折(57% off,包含 custom instance)，而memory優化的機器最高可打到三折(70% off)．

CUD的採購是類似買一個pool的概念，我們必須跟GCP買一個總量(vCPU/memory)．這一類折扣不是套用在某個特定的insatnce，而是套用在整個月底的計費帳單上．

這一類的預購在採購時是需要明定在哪一個project的哪一個region． GCP沒有像 AWS哪麼細分到AZ，它最多套用在某一個Region．

CUD不是用VM運行的小時來計費

這似乎很明顯，但 GCP 不對VM insatnce的使用時間收費這一事實與其他CSP存在巨大差異，並且具有許多含義。 Google 中的 VM 產品稱為 Google Compute Engine (GCE)，其 SKU 單一性為 CPU core、RAM 和locallized disk。毫無疑問，這源於這樣一個事實，我們可以根據自己的意願建立具有任意數量CPU core和memory 比例的完全客製化的機器。以下是一些影響：

當 GCP在計費資料中拋出resource-level info時，我們應該會看到的是每個insatnce在每一個小時都有一筆row，對應於不同的部分。這將提供更細緻化資源成本的能力
在購買 CUD 時，我們專門承諾 CPU core或memory（但不包括local storage）。因為採購是按照我們選擇的比例（在一個範圍內）進行的，所以很有可能偶數個潛在的錯誤不會被覆蓋。例如，可以覆蓋 5 個 insatnce 的 CPU core，但不能覆蓋 4 個 insatnce 的memory。因此，CUD 規劃應該針對CPU core與memory個別完成

有了這種明確的劃分，容器資源和成本分配就變得更簡單了，因為底層組件(vCPU and Memory)已經被拆分出來了。相比之下，當基礎成本是一個 VM insatce時（如 AWS 的情況），則需要特殊的數學式來拆分成本。

CUD的計費與共享

讓我們看看 CUD 計費和應用程式如何在 GCP 概念 Organizations, folder, 與projects中作業。下圖顯示了GCP Organization的層次結構。

這個方式其實很類似AWS的主要付款人的結構．不過即使是 Organizational account採購CUD，付款的方式與採購還是計算在GCP的billing account level．而CUD這種總量(cpu/memory)的彈性組合只禁限於project level．

不過現在CUD也可以進行共享了．只要這些要共享的project都掛在同一個billing account．更多的資訊可以參考GCP的Turing on committed use discount sharing．

Organization 與Billing accounts間的關係

兩種類型的關係管理著 billing accounts、organizations和projects之間的交互：ownership和payment linkage。下圖顯示了project的ownership和payment linkage之間關係。 Ownership是指從主Organization的IAM繼承而來的權限。 Payment Linkage定義了哪一個billing account用在哪一個projects。在下圖中，Organization對Project A、B 和 C 有ownership，billing account負責支付這三個projects所產生的費用。

在Project中使用 CUD

CUD不能使用在短期間的資源爆衝使用量．例如，我們如果買了100 vCPU, 我們不能買前半個月用了200 vCPU然後後半個月什麼都沒用，最後就收到100 vCPU的折扣．這個意思跟我們之前提到的優惠券的道理是一樣的，這張優惠券你不可以“同時”套用在多個resource上．

CUD在 GCE的購買有兩類，一種是general-purpose另一種是memory-optimized 的預購．而且都是專款專用，我們不可以把這兩種不同的CUD套給另一種使用．而且並不是所有的insatnce type都有 CUD.

不管是一年或三年期 CUD，它們都不會自動續訂。所以要到期時我們要自己再去買新的commitment。其他折扣方案（例如SUD）不適用於 CUD 涵蓋的 vCPU/memort。 CUD 應用於 vCPU 和memory的總和。 6個 vCPU 的預購量可以對更多 vCPU 的insatnce套用部分折扣。例如，使用 16 個 vCPU 運行的insatnce將以 CUD 費率套用 6個 vCPU，其餘 10 個 vCPU 以正常費率收費。因為沒有套用 CUD，所以 SUD 可以套用到剩餘的 10 個 vCPU。

最後，值得注意的是，CUD 以非常特定的順序分配給最昂貴的機器類型，順序為：

Custom machine types
Sole-tenant node groups
Predefined machine types

Microsoft Azure

微軟於 2017 年底加入了雲端批發採購的派對，並在 AWS 在拉斯維加斯舉行的 re:Invent 大會之前發布了公告。他們的產品主要在與 2017 年 AWS RI 的許多改良相匹配，這些改良增加了insatnce大小靈活性和更多可轉換交換選項等功能。

Azure RI 是按 Azure region、VM類型和期限（一年或三年）購買的。OS和AZ不像在 AWS 中那樣具體。當工作負載或應用程式需要變動時，RI可以跨任何region和任何系列交換來 Azure RI。根據租約剩餘時間按比例退款，以套用於作為交換一部分的新 RI。

Azure RI 交換目標的價錢必須等於或大於原來的RI。沒有“充值(top-up)”的概念，但如果新預購的價錢更高，則需要在貸記金額(the credited amount)之外進行一些額外的金錢。此外，“交換(exchange)”可以簡單地是取消整個 RI 預購並收取違約金。如果不再需要購買的容量，可以取消 Azure RI 以獲得調整後的退款。細則確實規定取消有 12% 的提前終止費，並且取消的最高費用為每年 50,000 美元。

有capacity priority，但不能保證。這意味著當沒有足夠的容量來滿足對資源的請求時(Azure經常發生某個region沒有resource的狀況)，那些有預購的人將在其他沒有預購的人之前優先獲得capacity。但是，如果沒有保證，如果 Azure 超出該特定資源類型的容量，就不會讓我們開啟該資源。

Azure RI 可以在enrollment/account或subscriptions level分配，因此我們可以在Organization或單一部門的層級管理 RI usage 。這讓我們能更好地控制如何使用 RI 以及誰應該從它們中使用它，並且它解決了 AWS 中的“RI float”困境，即幾乎無法控制使用 RI 的位置。

如果目標是在整個組織範圍內省錢，則可以簡單地在enrollment/account層級分配 RI。如果特定的業務單位想要預購來使用，則可以將 RI 分配給subscriptions，只有該部門可以省到錢。此功能的缺點是沒有在subscriptions的機器無法使用沒使用到的 RI，這可能比使用 AWS 造成更多浪費，在 AWS 中，如果購買RI的這個帳號不使用，RI 會自動級聯到其他linked account。enrollment或subscriptions 層級的指定RI可以在購買後根據需要進行變更。

預設情況下，RI 是基於 Linux 的，但可以通過 Azure Hybrid Use Benefit（將地端的license分配給insatnce）或使用以小時計費的 Windows license（類似於 AWS 的模型），計費的大小具體取決於用了多少個cpu。

Azure RI 適用於 A 系列、A_v2 系列或 G 系列以外的所有 VM 系列，但並非在所有Region都提供 VM 系列。

Azure RI 只有“All upfront”，需要在開始時支付整個租約期間的費用。沒有像 AWS 中那樣有“Partial upfront”或“No upfront”的選項，這兩種方法都可以讓我們以較少的初始現金支出來省錢。

Instance Size的彈性

Azure ISF 的作業方式與 AWS 幾乎完全相同：只需將 Azure VM“size group”替換為“instance families”，將“ratio unit”替換為“normalized unit”。

無論預購的大小如何，相同size series group中的instance都可以套用預購。較小的預購大小可以對較大的instance套用部分折扣，較大的預購可以對多個較小的instance進行折扣。每個size series group都有一個針對每個特定size instance的ratio unit。同樣，它的作業原理與 AWS 的normalized units完全相同。使用這些ratio unit，我們可以確定需要多少單位才能覆蓋我們需要的 VM instance。

以下是一個例子來說明這是如何作業的：