AWS 可以細(xì)分如下：

截至 2017 年，AWS 擁有：

有關(guān)相關(guān)信息，請參閱 AWS 全球基礎(chǔ)設(shè)施簡介。

假設(shè)每個數(shù)據(jù)中心平均有 臺服務(wù)器，每個 AZ 平均有 1.5 個數(shù)據(jù)中心，那么服務(wù)器總數(shù)為 409.5 萬臺?？偨Y(jié)一下，假設(shè) AWS 總共有 410 萬臺服務(wù)器。

（42 個可用區(qū) x 1.5 個數(shù)據(jù)中心）* 65,000 臺服務(wù)器 = 4,095,000

2014年，Tech做過類似的計算（不過是基于28個AZ，但邏輯是一樣的），最終估計的服務(wù)器數(shù)量在280萬到560萬之間。在他們的估計中，每個 AZ 包含三個數(shù)據(jù)中心，如果這個假設(shè)準(zhǔn)確，AWS 在全球可能擁有超過 800 萬臺服務(wù)器。

凈服務(wù)器容量

就凈服務(wù)器容量而言，基于上述（可能不準(zhǔn)確的）計算，AWS 是 5 倍大小。

附加說明：以上計算未考慮 AWS 當(dāng)前的容量限制。AWS 為日常運(yùn)營保留了多少容量？AWS 是否有 20% 的預(yù)留容量可供分配？我們打算忽略這些問題，并簡單地假設(shè) AWS 可以完全滿足當(dāng)前需求網(wǎng)站建設(shè)，但可能會犧牲靈活性。

為了滿足未來對服務(wù)器的需求，AWS和AWS都在不斷的對服務(wù)器基礎(chǔ)設(shè)施進(jìn)行投資，所以可以認(rèn)為未來的AWS也足以承載未來。

在服務(wù)器凈容量方面，F(xiàn)acebook?有可能托管在?AWS?上嗎？

最有可能的是。

服務(wù)器硬件性能

不能直接假設(shè)服務(wù)器性能與 AWS 相當(dāng)網(wǎng)站優(yōu)化，因此需要考慮服務(wù)器性能問題。數(shù)十億美元已投資于服務(wù)器基礎(chǔ)設(shè)施，隨著規(guī)模的擴(kuò)大，他們經(jīng)歷了筆記本電腦充當(dāng)服務(wù)器、從第三方租用服務(wù)器以及建立自己的數(shù)據(jù)中心的過程。當(dāng)他們開始設(shè)計和構(gòu)建自己的數(shù)據(jù)中心時，開箱即用的解決方案不再適用。

沃思堡（Fort）數(shù)據(jù)中心正在建設(shè)中服務(wù)器運(yùn)行php文件，來源：

七個數(shù)據(jù)中心旨在以各種方式最大限度地提高性能和效率。從數(shù)據(jù)中心的整體設(shè)計到服務(wù)器機(jī)架和芯片等細(xì)節(jié)，一切都是定制的。

“為了優(yōu)化成本，我們消除了您在標(biāo)準(zhǔn)服務(wù)器上看到的大部分組件，”服務(wù)器設(shè)計師 Amir 在 2009 年表示。

“我們拆掉了所有沒用的東西，只保留最必要的?！?/pre>

2011 年，他將數(shù)據(jù)中心和服務(wù)器的整個設(shè)計開源，表達(dá)了他對高效設(shè)計的熱愛。此后，許多其他人為該項(xiàng)目做出了貢獻(xiàn)，包括。這些措施也進(jìn)一步壓低了硬件成本，第三方廠商開始生產(chǎn)相關(guān)組件，進(jìn)一步降低了定制數(shù)據(jù)中心的建設(shè)成本。您可以訪問數(shù)據(jù)以獲取服務(wù)器硬件的完整列表。
因此，現(xiàn)有的服務(wù)器基礎(chǔ)架構(gòu)已得到顯著優(yōu)化，以幫助盡可能高效地運(yùn)行。例如，他們在服務(wù)器場中為不再查看的照片和視頻（通常在 10 年前上傳）開辟了一個單獨(dú)的“冷存儲”。僅當(dāng)有人想要查看這些照片或視頻時，此存儲設(shè)備才會“喚醒”。
多年的專業(yè)化運(yùn)營與AWS有很大的不同，AWS的存儲需要在設(shè)計上考慮不同用途（高負(fù)載）的使用。但與 和 類似，也在內(nèi)部設(shè)計硬件。
“是的，我們將構(gòu)建我們的服務(wù)器，”首席技術(shù)官說?！拔覀儗⑹褂梦覀儍?nèi)部構(gòu)建的自定義存儲和服務(wù)器來滿足這些（重量級）工作負(fù)載的需求。我們還將合作構(gòu)建我們自己的以更高時鐘頻率運(yùn)行的處理器?！?/p>
雖然 AWS 可能看起來更通用，但其服務(wù)器的實(shí)際性能不太可能更差。但是，對于專業(yè)化和效率，眾說紛紜。這些大型科技騰云網(wǎng)為什么要這么做？假設(shè)進(jìn)行真正的遷移，為了獲得與您自己的 AWS 數(shù)據(jù)中心相似的性能，您很可能需要更多服務(wù)器。考慮到這一因素并在沒有實(shí)際數(shù)據(jù)的情況下進(jìn)行比較，我們假設(shè)遷移后所需的服務(wù)器數(shù)量將比當(dāng)前水平增加 10%，因此服務(wù)器數(shù)量將增加到 913,000 臺。
830,000 * 1.1 = 913,000
在 () 數(shù)據(jù)中心內(nèi)，來源：
另請注意，我們計劃從 IBM 平臺遷移到在我們自己的服務(wù)器上運(yùn)行。目前有 700 臺裸機(jī)（類似）高端 IBM 服務(wù)器在使用，基本提供與自家硬件相近的性能。但與我們之前討論的所有內(nèi)容相比，這個數(shù)字（700?。┦侨绱酥。梢钥隙ǖ丶僭O(shè)該領(lǐng)域的未來增長可以完全包含在他們未來的擴(kuò)張計劃中。
遷移？
實(shí)際上，遷移到 AWS 是完全不可能的。所以，這個腦洞大開的過程沒有考慮遷移的具體過程，我們只是想探索一下這樣做的可行性。事實(shí)上，整篇文章都基于這樣一個假設(shè)，即從構(gòu)建自己的基礎(chǔ)設(shè)施的第一天起就選擇在 AWS 上進(jìn)行托管。
假設(shè)我們在一個平行宇宙中，遷移到 AWS 是否會順利進(jìn)行，需要多長時間？2013-2014年從AWS遷移到自己的服務(wù)器，整個過程花了一年時間，沒有人注意到?？紤]到這一點(diǎn)，我們還應(yīng)該能夠在沒有最終用戶注意的情況下進(jìn)行反向遷移。
然而......我們正在遷移整個，包括服務(wù)器運(yùn)行php文件，所以整個過程肯定會花費(fèi)更長的時間。與這一理論遷移相比，遷移規(guī)模為. 別忘了，他們花了八年時間才完全遷移到 AWS。8年！
基于這些假設(shè)和猜測，遷移過程應(yīng)該很順利，但可能需要數(shù)年才能完成。
服務(wù)器硬件性能
AWS 和兩者都在自定義數(shù)據(jù)中心、服務(wù)器設(shè)計和實(shí)施方面進(jìn)行了大量投資。由于所有設(shè)計都是開源的，這兩款服務(wù)器可能具有相當(dāng)?shù)姆?wù)器性能。
我們認(rèn)為 AWS 可以輕松提供所需的計算能力和性能。但是，由于 AWS 無法滿足某些特殊需求，因此仍有一定的余量需要預(yù)留。您可以使用自己的 830,000 臺服務(wù)器做什么，可能需要 913,000 臺才能切換到 AWS。
AWS?能提供?Facebook?所需的服務(wù)器性能嗎？

很可能沒有問題。
軟件
它是（現(xiàn)在仍然是）使用 OSS（開源軟件）開發(fā)的。與其他騰云網(wǎng)絡(luò)類似，它們的增長速度如此之快，以至于在這樣的規(guī)模下，它們通常需要自己開發(fā)自定義工具，或者對現(xiàn)有工具進(jìn)行大量修改以滿足他們的需求。
他們?nèi)匀皇褂?PHP 來開發(fā)應(yīng)用程序代碼，但為了提高性能，他們開發(fā)了 (HHVM)，即通過即時編譯 (JIT) 編譯 PHP 代碼。這意味著代碼可以與 HHVM 和 . 的整個網(wǎng)站在開發(fā)和生產(chǎn)中都運(yùn)行在 HHVM（桌面、API、移動）上。這正是定制軟件的意義所在。
AWS 與 PHP 和 HHVM 的關(guān)系讓人感到擔(dān)憂。但是在它自己的 HHVM 代碼庫中，有一個指向 AWS 服務(wù)器的 HHVM 的鏈接。所以我們可以假設(shè)我們可以在 AWS 上成功運(yùn)行 HHVM 來運(yùn)行我們自己的網(wǎng)站。
但是數(shù)據(jù)庫呢？在數(shù)據(jù)存儲方面，在 SQL vs.  中有一個臭名昭著的例子：存儲自己的時間線數(shù)據(jù)的巨大變化，同時依賴于快速交付。對于縮放，建議閱讀High上的相關(guān)文章?？梢栽诖颂幷业皆撘?guī)范的自定義版本。
RDS( ) 能否滿足要求？有許多科技巨頭在使用 RDS，其中最引人注目的是。也許可以說，如果他們的騰云網(wǎng)絡(luò)視頻都可以通過RDS成功運(yùn)行，那么也可以嗎？答案無法確定，但集群非常龐大，簡單的遷移可能根本滿足不了需求。為了處理自己的負(fù)載，他們甚至創(chuàng)建了自己的分叉！
還構(gòu)建了一個非常全面的技術(shù)棧。他們的代碼庫足以證明這一點(diǎn)。這不可避免地讓人們更加關(guān)注他們的基礎(chǔ)設(shè)施與 AWS 的兼容性。
這個過程有多困難也許是他們在遷移到分布式云環(huán)境時需要如何重建大部分技術(shù)組件的最好例子。
AWS?能夠支持?Facebook?龐大的軟件環(huán)境和復(fù)雜的數(shù)據(jù)需求嗎？

也許吧，但它幾乎肯定會影響性能，甚至可能構(gòu)建一個新系統(tǒng)。
在 AWS 上托管需要多少費(fèi)用？
注意：這可能是本文最不準(zhǔn)確的內(nèi)容。雖然 AWS 提供了豐富的成本計算方法，但我們無法了解數(shù)據(jù)存儲和計算的實(shí)際需求。同樣，這些數(shù)字純粹是猜測。
我們好奇的最后一個問題：成本。盡管 AWS 幫助無數(shù)騰云網(wǎng)絡(luò)快速且廉價地擴(kuò)展，但其中絕大多數(shù)永遠(yuǎn)無法實(shí)現(xiàn)擴(kuò)展。就規(guī)模而言，構(gòu)建自己的基礎(chǔ)設(shè)施可能更便宜（這正是他們所做的，但我們只是想弄清楚^.^）。
在使用AWS自帶的成本計算器之前，我們先來看看一些全球化產(chǎn)品在云計算方面的成本。
Snap 的 IPO 文件中提到，Snap 騰云網(wǎng)絡(luò)計劃在 5 年內(nèi)向 AWS 支付 20 億美元，同時向 AWS 支付 10 億美元。也就是說，每月 5000 萬美元。如此龐大的數(shù)字讓科技界大吃一驚，甚至有人編造了“支付高額費(fèi)用存儲和處理即將被銷毀的內(nèi)容”之類的笑話。文字、圖片等內(nèi)容被收件人查看后立即銷毀）。
如上所述，它仍然托管在 IBM 的公共云服務(wù)器上，但計劃盡快遷移。然而，目前的托管成本仍然高達(dá)每月 200 萬美元。對于只使用 700 臺服務(wù)器的應(yīng)用來說，這個成本有點(diǎn)高。
我們可以假設(shè)使用需求遠(yuǎn)高于總和。
成本計算
以下計算較為簡單，基于 1,000,000 臺服務(wù)器運(yùn)行 EC2 計算、S3、RDS，以及照片和視頻等數(shù)據(jù)的存儲和傳輸任務(wù)，每月傳輸 1,256.5PB（1,256）的數(shù)據(jù)。
計算中的假設(shè)：
這些計算既不精確也不嚴(yán)謹(jǐn)。如果您有更好的計算方法，歡迎您自己嘗試！原始 AWS 成本計算結(jié)果可在此處找到。
然后開始計算：
EC2
計算：EC2 實(shí)例（用于運(yùn)行 PHP 代碼之類的東西）
S3
存儲（照片和視頻）
數(shù)據(jù)傳輸
RDS
RDS On-DB 實(shí)例（運(yùn)行時間線）
數(shù)據(jù)傳輸
總額
理論上，如果托管在?AWS?上，F(xiàn)acebook?每年的成本高達(dá)?59.7?億美元。

巨大的
年收入超過280億美元，總市值4340億美元，全球用戶群超過19.4億，無疑擁有龐大而復(fù)雜的基礎(chǔ)設(shè)施。自有服務(wù)器基礎(chǔ)設(shè)施，據(jù)一些人估計，在 2012 年價值 40 億美元，今天可能已經(jīng)增長了兩倍，達(dá)到 120 億美元。
然而，每年 59.7 億美元的托管成本遠(yuǎn)遠(yuǎn)超過了 2017 年的“收入成本”（37.89 億美元），其中包括數(shù)據(jù)中心和其他運(yùn)營成本。
另請注意，可能無法支付假定的估計 AWS 價格。和 和 類似，也是一個有很大影響力的重量級用戶，因此具有談判和獲得更低價格的能力。
Facebook?能夠支付?AWS?托管費(fèi)用嗎？

是的，但它更貴。
是否可以在 AWS 上托管？
我們永遠(yuǎn)不會知道這個令人大開眼界的假設(shè)是否準(zhǔn)確，但方法如下：
毫無疑問，這些結(jié)論是錯誤的，因?yàn)槲覀儫o法獲得計算所需的數(shù)據(jù)。但……
根據(jù)本文得到的計算和結(jié)果，理論上是否可以在 AWS 上托管？是的，一點(diǎn)沒錯。
閱讀英文原文：是在 AWS 上托管嗎？