（一篇博文分兩段發，系統限制請原諒）
二、典型雲計算實例的成本構成
在討論雲計算成本構成之前，首先通過Amazon EC2的計費項目，分析典型的IaaS雲計算的成本構成 [2]。
· 計算實例的費用
首要的計費對象是按需使用的計算實例，即服務器資源。這本來是需要花費巨大的IT資源，通過實例可以靈活的按需支付的方式進行計費。計算實例的費用包括了綁定的操作系統的費用，即硬件+操作系統的價格，如表1，計費方式從實例建立到終止進行全時計費。
|
表1 計算實例的計費
EC2同時提供另一種計費方式，即包租實例，同樣的計算實例，預付一定的包租費用，之後按照每實際工作小時進行計費，費用遠低於上一種租用模式，如表2。
| ||||||||||||||||||||||||||||||||
表2 計算實例的包租計費
· 數據傳輸的費用
對於通過Internet網絡傳輸的數據，數據的上載“in”和下載“out”分別進行計費，如表3。
|
Data Transfer In |
|
|
All Data Transfer |
$0.10 per GB |
|
Data Transfer Out |
|
|
First 10 TB per Month |
$0.17 per GB |
|
Next 40 TB per Month |
$0.13 per GB |
|
Next 100TB per Month |
$0.11 per GB |
|
Over 150 TB per Month |
$0.10 per GB |
表3 數據上載/下載計費
同一地區內部（如歐洲或者北美）的兩個AWS(Amazon Web Service)之間的數據傳輸不進行計費，跨地區，如歐洲和北美之間，則進行雙向Internet傳輸計費。此外，Amazon還定義了有效區域(Availability Zone)的概念，有效區域內部的數據傳輸不計費，相同地區的不同有效區域之間的數據傳輸則按照每GB $0.01對上載和下載數據進行計費。如果使用用戶自己的公開或者彈性 IP地址，或者在EC2網絡內部使用彈性負載均衡，則也需要按照跨地區方式計費，無論是否運行於有效區域內，爲了解決這個問題，如果有可能，有效區域內部的數據傳輸可以採用私有IP。
· 存儲的費用——Amazon Elastic Block Store
如果需要額外的數據存儲，可以採用EBS，計費標準爲每月每GB數據$0.10，以及每1M(百萬次)I/O請求$0.10。
· 彈性IP地址的費用——Elastic IP Addresses
正在使用的彈性IP地址不計費。未使用的IP地址每小時$0.01。每個月的頭100次IP的Remap不計費，額外的Remap每次$0.10。
· 系統監測的費用——Amazon CloudWatch
EC2系統監測的費用是每實例小時$0.015。
· 彈性負載均衡的費用
每個彈性負載均衡工作小時計費$0.025。通過彈性負載均衡處理的每GB數據計費$0.008。
從上面Amazon EC2計費情況可以看出，計算實例的費用，以及數據傳輸的費用是雲計算費用或者說成本的最主要也是最基礎的部分。計算資源的費用主要涉及到硬件設備，如服務器，以及與之相關的散熱成本。數據傳輸的成本主要是需要分擔帶寬的成本。可見，計算資源和帶寬是最核心的組成部分。
計算實例本身附帶了存儲空間，但是用戶仍然有可能需要更多的存儲空間，或者用戶的主要需求就是存儲空間，因此就會涉及到Amazon S3的使用，在EC2中提供簡單的存儲雲服務，EBS，來提升EC2的彈性。
此外，IP資源也可以作爲收費項目。EC2還提供增值服務，例如系統監測和負載均衡，這些高附加值的服務，一方面提升了雲計算平臺的服務質量，另一方面提升了雲運營商的利潤空間。
三、 帶寬與硬件的均衡對成本的影響
根據在該文前面部分的論述，雲計算的三個必要條件是網絡帶寬、大規模硬件資源以及成本。網絡帶寬和大規模的硬件資源會反映到成本上，本小節將分析論述通過帶寬與硬件資源的性能均衡，來節省成本的必要性。
以典型的Web訪問類型的雲計算爲例，影響雲中Web類應用用戶體驗的因素，也是衡量Web效用的因素，包括：
o 用戶連接數
o 響應時間
o 頁面平均大小
而限制雲計算平臺服務能力的主要因素包括：
o 計算能力（CPU）
o 網絡能力（帶寬）
o 如果是存儲服務器，還包括存儲能力（容量，速度）
網頁理論平均最大處理量：平均頁面大小300KB（2008年數據[22]），網頁平均載入時間2.8秒，1000Mbps網口，則可以得到平均每秒9000個點擊。
o (1000Mbps/8bit)*2.8s/300KB≈9000次/s
在上面的舉例情況中，從單臺服務器的角度，如果達到網絡流量的峯值，設典型的業務邏輯中，300K的頁面處理需要CPU指令1MOps條，可以推算出所需的計算能力爲：
o 9000次/s*1Mops=9Gops
則每秒9Gops的處理能力，即可以與網絡帶寬的峯值相匹配。考慮到CPU佔用率不宜超過30%，則9Gops/30%=30Gops的CPU處理能力，可以滿足需求。當前的CPU，每個時鐘週期平均可以處理4個指令，則1個1.7GHz的四核處理器，即可滿足要求。當然，不同的應用對計算資源的要求不同，不同的SLA或者用戶需求，對於網絡帶寬和計算能力的要求也不相同。但是通過上面的計算可知，單純的提升某種能力，都將面臨另一種能力的制約，這將造成投資的浪費。
對於最主要的網絡帶寬和計算能力這二者來說，達到一個均衡的性能，比單純的性能提升更爲科學。隨着用戶的增加，以及新業務的加入，保持均衡的性能提升，將有助於提升雲計算平臺的成本效用。
三、不同SLA對成本的影響
無論雲計算資源在哪裏提供，對於用戶來說，都期望有明確的服務質量保證。服務等級協議（SLA）可以明確指出用戶能夠對雲供應商報有一個什麼樣的實際的服務質量期望，以及決定和某種服務質量（QoS）相聯繫的付費模式。
SLA包含了對服務有效性的保障，譬如對故障解決時間、服務超時等的保證。在互聯網與雲計算領域，可用性和性能的要求更高，響應時間、正常服務時間比率等指標更常被使用。例如，Amazon EC2的SLA承諾每個服務年度的正常運行時間在99.95%以上，沒有滿足SLA則需要對用戶進行賠償。
SLA中約定的服務質量QoS的主要實現方法是超量部署，也就是提供比平均應用量或者最高應用量還要多的容量。許多資源一般都採用超量部署，如計算機CPU和磁盤空間等。超量部署會帶來額外的成本支出。例如前文GFS爲了滿足存儲可靠性的要求，則採用了3份冗餘數據，這樣，雲計算平臺的部署規模需要是實際數據規模的3倍。國內一些IaaS運營商，在一定SLA約束下，爲了保證用戶虛擬機的可靠性，也需要定期對虛擬機快照進行備份，這些都是由於爲了滿足QoS而帶來的額外的成本指出，而這些成本支出最終會由用戶支付。當然，如果用戶使用自己的數據中心，爲了滿足QoS的需求，可能需要付出的成本還會更高。
參考文獻
[1] GRAY, J. Distributed Computing Economics. Queue 6, 3 (2008), 63–68.
[2] Amazon. Amazon Elastic Compute Cloud (Amazon EC2). 2009. http://aws.amazon.com/ec2/