譯者序
AWS用戶廣泛，產品線複雜，AWS發佈的白皮書《Architecting for the Cloud-AWS Best Practices》介紹了常見場景下雲架構的最佳實踐，不僅對於使用AWS的用戶，對於廣大使用雲的用戶都有參考意義，新鈦雲服工程師特意翻譯了本白皮書，供廣大使用雲的用戶參考。
本手冊分為兩部分
第一部分 傳統環境和雲環境的差異
第二部分 雲架構設計原則
4. 設計原則
AWS 包含許多可應用於各種用例的設計模式和體系結構選項。AWS的一些關鍵設計原則包括可擴展性，可支配資源，自動化，用松耦合管理服務，以及靈活的數據存儲選項。
4.1 可擴展性
預計隨著時間的推移而增長的系統需要建立在可擴展的架構之上。這樣的體系架構可以支持用戶，流量或數據大小的增長，而不會降低性能。應該以線性方式按比例提供資源，添加額外資源至少導致成比例增加提供額外負載的能力。增長應引入規模經濟，成本應遵循從該系統產生商業價值的相同維度。雖然雲計算提供幾乎無限的按需容量，但你的設計需要能夠無縫地利用這些資源。
通常有兩種擴展IT架構的方法：縱向擴展和橫向擴展。
4.1.1 縱向擴展
縱向擴展通過增加單個資源的規模來實現，例如升級具有更大硬盤驅動器或更快CPU的服務器。使用Amazon EC2，你可以停止實例並將其調整為具有更多RAM，CPU，I/O或網絡功能的實例類型。這種縮放方式最終將達到極限，並且它並不總是具有成本效益或高度可用的方法。但是，它很容易實現，並且對於許多用例來說已經足夠了，特別是在短期內。
4.1.2 橫向擴展
通過增加資源數量來橫向擴展，例如向存儲陣列添加更多硬盤驅動器，或添加更多服務器以支持應用程序。這是構建利用雲彈性的互聯網規模應用程序的好方法。並非所有體系結構都旨在將其工作負載分配給多個資源，因此讓我們檢視一些可能的情況。
1) 無狀態應用
當用戶或服務與應用程序交互時，通常會執行一系列形成會話的交互。會話是用戶在使用應用程序時在請求之間保持不變的唯一數據。無狀態應用程序是不需要先前交互知識，且不存儲會話信息的應用程序。例如，給定相同輸入，向任何最終用戶提供相同響應的應用程序是無狀態應用程序。無狀態應用程序可以橫向擴展，因為任何可用的計算資源（例如EC2實例和AWS Lambda函數）都可以為任何請求提供服務。如果沒有存儲會話數據，可以根據需要添加更多計算資源。當不再需要該容量時，可以在運行任務耗盡後安全地終止這些單獨的資源。這些資源不需要知道同伴的存在，所需要的只是將工作負載分配給它們的方法。
2) 將負載分配給多個節點
要將工作負載分配到環境中的多個節點，可以選擇推模型或拉模型。
使用推模型，可以使用Elastic Load Balancing（ELB）來分配工作負載。ELB跨多個EC2實例路由傳入的應用程序請求。在路由流量時，網絡負載均衡器在開放系統互連（OSI）模型的第4層運行，以處理每秒數百萬個請求。通過採用基於容器的服務，還可以使用應用程序負載均衡器。應用程序負載均衡器提供OSI模型的第7層，並支持基於應用程序流量的基於內容的請求路由。或者，可以使用Amazon Route 53實施DNS輪詢。在這種情況下，DNS響應以循環方式從有效主機列表中返回IP地址。雖然易於實施，但這種方法並不總能很好地適應雲計算的彈性。這是因為即使你可以為DNS記錄設置低生存時間（TTL）值，緩存DNS解析器也不在Amazon Route 53的控制範圍內，並且可能並不總是遵循你的設置。
可以為異步，事件驅動的工作負載實現拉模型，而不是負載平衡解決方案。在拉模型中，需要執行的任務或需要處理的數據可以使用Amazon Simple Queue Service（Amazon SQS）作為消息存儲在隊列中，也可以作為流數據解決方案存儲
比如亞馬遜Kinesis，多個計算資源可以提取和使用這些消息，以分佈式方式處理它們。
3) 無狀態組件
實際上，大多數應用程序都維護某種狀態信息。例如，Web應用程序需要跟蹤用戶是否已登錄，以便可以基於先前的操作呈現個性化內容。自動化的多步驟過程還需要跟蹤先前的活動，以確定其下一步應該是什麼。仍然可以通過不在本地文件系統中存儲需要多於一個請求的任何內容，來使這些體系結構的一部分無狀態。
例如，Web應用程序可以使用HTTP cookie在Web客戶端緩存中存儲會話信息（如購物車項目）。瀏覽器在每個後續請求時將該信息傳遞迴服務器，以便應用程序不需要存儲它。但是，這種方法有兩個缺點。首先，HTTP cookie的內容可能會在客戶端被篡改，因此你應始終將其視為必須經過驗證的不可信數據。其次，HTTP cookie隨每個請求一起傳輸，這意味著你應該將其大小保持在最小，以避免不必要的延遲。
考慮僅在HTTP cookie中存儲唯一的會話標識符，並在服務器端存儲更詳細的用戶會話信息。大多數編程平臺都提供以這種方式工作的本機會話管理機制。但是，默認情況下，用戶會話信息通常存儲在本地文件系統中，從而形成有狀態架構。此問題的常見解決方案是將此信息存儲在數據庫中。Amazon DynamoDB是一個很好的選擇，因為它具有可擴展性，高可用性和耐用性特徵。對於許多平臺，有一些開源替代庫，允許你在Amazon DynamoDB中存儲本機會話。
其他方案需要存儲較大的文件（例如用戶上載和批處理的中間結果）。通過將這些文件放在共享存儲層（如Amazon Simple Storage Service，Amazon S3；或Amazon Elastic File System，Amazon EFS））中，可以避免引入有狀態組件。
最後，複雜的多步驟工作流是另一個必須跟蹤每個執行的當前狀態的示例。可以使用AWS步驟功能集中存儲執行歷史記錄，並使這些工作負載無狀態。
4) 有狀態組件
不可避免地，你的架構層將不會變成無狀態組件。根據定義，數據庫是有狀態的。有關更多信息，請參閱後面的“數據庫章節"。此外，許多遺留應用程序設計為依靠本地計算資源在單個服務器上運行。其它用例包括可能需要客戶端設備長時間保持與特定服務器的連接。例如，實時多人遊戲必須以非常低的延遲為多個玩家提供一致的遊戲世界視圖。在非分佈式實現中實現這一點要簡單得多，其中參與者連接到同一服務器。
仍然可以通過將負載分配到具有會話親緣關係的多個節點來水平擴展這些組件。在此模型中，將會話的所有事務綁定到特定的計算資源。但是，這個模型確實有一些侷限性。現有會話不會直接受益於新啟動的計算節點的引入。更重要的是，無法保證會話親和力。例如，當節點終止或變得不可用時，綁定到該節點的用戶將斷開連接並遇到特定於會話的數據丟失，這些數據不會存儲在共享資源，如Amazon S3，Amazon EFS或a數據庫。
5) 實現會話親和性
對於HTTP和HTTPS流量，你可以使用應用程序負載均衡器的粘性會話功能，將用戶的會話綁定到特定實例。使用此功能，應用程序負載均衡器將嘗試在該持續時間內為該用戶使用相同的服務器會議。另一個選項，如果你控制在客戶端上運行的代碼，是使用客戶端負載平衡。這會增加額外的複雜性，但在負載均衡器不符合你的要求的情況下非常有用。例如，你可能正在使用ELB不支持的協議，或者你可能需要完全控制如何將用戶分配給服務器（例如，在遊戲場景中，可能需要確保遊戲參與者匹配並連接到相同的服務器）。在此模型中，客戶端需要一種方法來發現有效的服務器端點以直接連接。可以使用DNS，或者你可以構建一個簡單的發現API，以便將該信息提供給客戶端上運行的軟件。在沒有負載均衡器的情況下，還需要在客戶端實現健康檢查機制。應該設計客戶端邏輯，以便在檢測到服務器不可用時，設備重新連接到另一臺服務器，而對應用程序幾乎沒有中斷。
6) 分佈式處理
涉及處理大量數據的用例，無法及時處理單個計算資源的任何事物，需要採用分佈式處理方法。通過將任務及其數據劃分為許多小的工作片段，可以跨一組計算資源並行執行它們。
7）實施分佈式處理
通過使用AWS Batch，AWS Glue和Apache Hadoop等分佈式數據處理引擎，可以水平擴展脫機批處理作業。在AWS上，可以使用Amazon EMR在一組EC2實例之上運行Hadoop工作負載，而無需運維複雜性。對於流數據的實時處理，Amazon Kinesis將數據分成多個分片，然後由多個Amazon EC2或AWS Lambda資源使用，以實現可擴展性。
有關這些類型工作負載的更多信息，請參閱《Big Data Analytics Options on AWS 》和《Core Tenets of IoT》白皮書。
4.2 一次性資源而不是固有服務器
在傳統的基礎架構環境中，由於引入新硬件的前期成本和前置時間，必須使用固定資源。這推動了諸如手動登錄服務器以配置軟件或修復問題，硬編碼IP地址以及按順序運行測試或處理作業等實踐。
在為AWS設計時，可以利用雲計算的動態配置特性。可以將服務器和其他組件視為臨時資源。可以根據需要啟動任意數量實例，並且只在需要時使用它們。
長期運行的服務器的另一個問題是配置偏差。隨時間推移應用的更改和軟件修補程序可能會導致跨不同環境的未經測試和異構配置。可以使用不可變的基礎架構結構模型模式解決此問題。使用這種方法方式，服務器一旦啟動永遠不會更新。相反，當出現問題或需要更新時，問題服務器將替換為具有最新配置的新服務器。這使資源始終處於一致（和測試）狀態，並使回滾更容易執行。使用無狀態體系結構更容易支持這一點。
4.2.1 實例化計算資源
無論是部署新環境進行測試，還是增加現有系統的容量來應對額外負載，你都不希望使用其配置和代碼手動設置新資源。重要的是，你要使其成為一個自動化且可重複的過程，以避免較長的交付週期，並且不會出現人為錯誤。有幾種方法可以實現這一目標。
1）引導
啟動AWS資源（如EC2實例或AmazonRelational Database Service（Amazon RDS）數據庫實例）時，將啟動默認配置。然後，可以執行自動引導操作，這些操作是安裝軟件或複製數據以將該資源帶入特定狀態的腳本。可以參數化在不同環境（例如生產或測試）之間變化的配置詳細信息，以便可以重複使用相同的腳本而無需進行任何修改。
可以使用用戶數據腳本和cloud-init指令設置新的EC2實例。可以使用簡單的腳本和配置管理工具，例如Chef或Puppet。此外，通過自定義腳本和AWS API，或AWS AWS支持的自定義資源的AWS CloudFormation支持，可以編寫幾乎適用於任何AWS資源的配置邏輯。
2）黃金鏡像
某些AWS資源類型（例如EC2實例，AmazonRDS數據庫實例和Amazon Elastic Block Store，Amazon EBS）可以從黃金鏡像啟動，黃金鏡像是該資源的特定狀態的快照。與引導方法相比，黃金鏡像可以縮短啟動時間並消除對配置服務或第三方存儲庫的依賴性。這在自動擴展環境中非常重要，在這種環境中，你希望能夠快速可靠地啟動其他資源，以響應需求變化。
可以自定義EC2實例，然後通過創建Amazon Machine Image（AMI）來保存其配置。可以根據需要從AMI啟動任意數量的實例，並且它們都將包括這些自定義項。每次要更改配置時，都必須創建一個新的黃金鏡像，因此必須具有版本控制約定來管理你的黃金鏡像。建議你使用腳本為你用於創建的EC2實例創建引導程序的AMI。這為你提供了一種靈活的方法來測試和修改這些鏡像。
或者，如果你具有現有的本地虛擬化環境，則可以使用AWS的VM導入/導出將各種虛擬化格式轉換為AMI。你還可以查找和使用AWS或AWS中的第三方提供的預封裝共享AMI。
雖然啟動新EC2實例時最常使用黃金鏡像，但它們也可以應用於Amazon RDS數據庫實例或Amazon EBS卷等資源。例如，當啟動新的測試環境時，你可能希望通過從特定的Amazon RDS快照實例化數據庫來預填充其數據庫，而不是從冗長的SQL腳本中導入數據。
3）容器
開發人員喜歡的另一個選擇是Docker，一種開源技術，允許你在軟件容器內構建和部署分佈式應用程序。Docker允許你將一個軟件封裝在Docker鏡像中，這是一個軟件開發的標準化單元，包含軟件運行所需的所有內容：代碼，運行時，系統工具，系統庫等。AWS Elastic Beanstalk，Amazon ElasticContainer 服務（Amazon ECS）和AWSFargate允許你跨EC2實例集群部署和管理多個容器。你可以構建黃金Docker鏡像並使用ECS容器註冊表來管理它們。
另一種容器環境是Kubernetes和Kubernetes的亞馬遜彈性容器服務（Amazon EKS）。藉助Kubernetes和Amazon EKS，你可以輕鬆部署，管理和擴展容器化應用程序。
4）混合
你還可以使用這兩種方法的組合：配置的某些部分在黃金鏡像中捕獲，而其他部分則通過引導操作動態配置。
不經常更改或引入外部依賴項的項目通常是你的黃金鏡像的一部分。一個好的候選者的例子是你的Web服務器軟件，否則每次啟動實例時都必須由第三方存儲庫下載。
可以通過引導操作動態設置在不同環境之間經常更改或不同的項目。例如，如果要經常部署應用程序的新版本，則為每個應用程序版本創建新的AMI可能不切實際。你也不希望將數據庫主機名配置硬編碼到AMI，因為測試和生產環境之間會有所不同。用戶數據或標籤允許你使用可在啟動時修改的更通用的AMI。例如，如果你為各種小型企業運行Web服務器，則它們都可以使用相同的AMI，並從啟動時在用戶數據中指定的S3存儲桶位置檢索其內容。
AWS Elastic Beanstalk遵循混合模型。它提供預配置的運行時環境，每個環境都是從其自己的AMI11啟動的，但允許你通過ebextensions配置文件運行引導操作，並配置環境變量以參數化環境差異。
4.2.2 基礎架構即代碼
我們討論的原則的應用不必限於單個的資源水平。由於AWS資源是可編程的，因此你可以應用軟件開發中的技術，實踐和工具，使你的整個基礎架構可重用，可維護，可擴展和可測試。
AWS CloudFormation模板為你提供了一種簡單的方法來創建和管理相關AWS資源的集合，並以有序和可預測的方式提供和更新它們。你可以描述運行應用程序所需的AWS資源，以及任何關聯的依賴項或運行時參數。你的CloudFormation模板可以與你的版本控制存儲庫中的應用程序一起使用，這樣你就可以重用架構並可靠地克隆生產環境以進行測試。
4.3 自動化
在傳統的IT基礎架構中，你通常必須手動對各種事件做出反應。在AWS上部署時，你可以進行自動化。
為了提高系統的穩定性和組織的效率，考慮將一種或多種這類自動化引入你的應用程序體系結構，以確保更高的彈性，可伸縮性和性能。
4.3.1 無服務器管理和部署
採用無服務器模式時，操作重點是部署自動化流水線。AWS管理基礎服務，規模和可用性。AWS CodePipeline，AWS CodeBuild和AWS CodeDeploy支持這些流程部署的自動化。
4.3.2 基礎架構管理和部署
AWS Elastic Beanstalk：你可以使用此服務在熟悉的服務器（如Apache，Nginx，Passenger和服務器）上部署和擴展使用Java，.NET，PHP，Node.js，Python，Ruby，Go和Docker開發的Web應用程序和服務。IIS開發人員可以簡單地上傳他們的應用程序代碼，該服務自動處理所有細節，例如資源配置，負載平衡，自動擴展和監視。
Amazon EC2自動恢復：你可以創建監控EC2實例的Amazon CloudWatch警報，並在其受損時自動恢復。恢復的實例與原始實例相同，包括實例ID，私有IP地址，彈性IP地址，和所有實例元數據。但是，此功能僅適用於適用的實例配置。有關這些前提條件的最新說明，請參閱Amazon EC2文檔。此外，在實例恢復期間，實例將通過實例重新引導進行遷移，並且內存中的所有數據都將丟失。
AWS Systems Manager：你可以自動收集軟件清單，應用操作系統補丁，創建系統鏡像以配置Windows和Linux操作系統，以及執行任意命令。提供這些服務簡化了操作模型並確保了最佳的環境配置。
Auto Scaling：你可以根據你定義的條件自動維護應用程序可用性，並自動擴展Amazon EC2，Amazon DynamoDB，Amazon ECS，適用於Kubernetes的Amazon Elastic Container Service，（Amazon EKS）容量。你可以使用Auto Scaling幫助確保跨多個可用區運行所需數量的健康EC2實例。Auto Scaling還可以在需求峰值期間自動增加EC2實例的數量，在不太繁忙的時期保持性能並降低容量以優化成本。
4.3.3 警報和事件
Amazon CloudWatch警報：你可以創建CloudWatch警報，當特定指標超過指定閾值達指定數量的時段時，該警報會發送AmazonSimple Notification Service（Amazon SNS）消息。這些Amazon SNS消息可以自動啟動執行訂閱的Lambda函數，將通知消息排入Amazon SQS隊列，或者對HTTP或HTTPS端點執行POST請求。
Amazon CloudWatchEvents：提供近乎實時的系統事件流，描述AWS資源中的變更.使用簡單規則，你可以將每種類型的事件路由到一個或多個目標，例如Lambda函數，Kinesis流和SNS主題。
AWS Lambda預定事件：你可以創建Lambda函數並配置AWS Lambda以定期執行它。
AWS WAF安全自動化：AWS WAF是一種Web應用程序防火牆，使你能夠創建自定義的特定於應用程序的規則，以阻止可能影響應用程序可用性，危及安全性或消耗過多資源的常見攻擊模式。你可以通過API完全管理AWS WAF，從而簡化安全自動化，實現快速規則傳播和快速事件響應。
4.4 松耦合
隨著應用程序複雜性的增加，IT系統的理想屬性是可以將其分解為更小，松耦合的組件。這意味著IT系統的設計應該能夠減少相互依賴性，一個組件中的更改或故障不應該級聯到其他組件。
4.4.1 定義明確的接口
減少系統中相互依賴性的一種方法是允許各種組件僅通過特定的，與技術無關的接口（例如RESTful API）相互交互。通過這種方式，隱藏了技術實現細節，以便團隊可以修改底層實現而不影響其他組件。只要這些接口保持向後兼容性，差異組件的部署就會分離。這種粒度設計模式通常被稱為微服務架構。
Amazon API Gateway是一種完全託管的服務，使開發人員可以輕鬆地以任何規模創建，發佈，維護，監控和保護API。它處理接受和處理多達數十萬個併發API調用所涉及的所有任務，包括流量管理，授權和訪問控制，監控和API版本管理。
4.4.2 服務發現
部署為一組較小服務的應用程序取決於這些服務相互交互的能力。因為每個服務都可以跨多個計算資源運行，所以需要有一種方法來解決每個服務。例如，在傳統基礎結構中，如果你的前端Web服務需要與後端Web服務連接，則可以對運行此服務的計算資源的IP地址進行硬編碼。雖然這種方法仍然適用於雲計算，但如果這些服務是松耦合的，那麼它們應該能夠在不事先了解其網絡拓撲細節的情況下使用。除了隱藏複雜性之外，這還允許基礎架構細節隨時更改。如果你想利用雲計算的彈性，可以在任何時間點啟動或終止新資源，那麼松耦合是一個至關重要的因素。為了實現這一目標，你需要一些實現服務發現的方法。
實施服務發現
對於Amazon EC2託管的服務，實現服務發現的一種簡單方法是通過Elastic LoadBalancing（ELB）。由於每個負載均衡器都有自己的主機名，因此你可以通過穩定的endpoint使用服務。這可以與DNS和私有Amazon Route 53區域結合使用，以便可以隨時抽象和修改特定負載均衡器的endpoint。
另一種選擇是使用服務註冊和發現方法來允許檢索任何服務的endpoint IP地址和端口號。由於服務發現成為組件之間的粘合劑，因此高度可用且可靠性非常重要。如果未使用負載平衡器，則還應該進行服務發現允許健康檢查等選項。Amazon Route 53支持自動命名，以便更輕鬆地為微服務配置實例。自動命名允許你根據定義的配置自動創建DNS記錄。其他示例實現包括使用標籤組合的自定義解決方案，高可用性數據庫，調用AWSAPI的自定義腳本，或Netflix Eureka，AirbnbSynapse或HashiCorp Consul等開源工具。
4.4.3 異步集成
異步集成是服務之間松耦合的另一種形式。此模型適用於任何不需要立即響應的交互，以及已經註冊請求的確認就足夠了。它涉及一個生成事件的組件和另一個消耗它們的組件。這兩個組件不通過直接的點對點交互進行集成，而是通過中間持久存儲層進行集成，例如SQS隊列或流式數據平臺（如Amazon Kinesis），級聯Lambda事件，AWS步驟功能或AmazonSimple Workflow服務。
圖1：緊耦合和松耦合
這種方法將兩個組件分離，並引入了額外的彈性。因此，例如，如果正在從隊列中讀取消息的進程失敗，則仍可以將消息添加到隊列中並在系統恢復時進行處理。它還允許你保護不太可擴展的後端服務免受前端尖峰的攻擊，並找到正確的成本和處理滯後之間的權衡。例如，你可以決定不需要擴展數據庫以適應偶爾的寫入查詢峰值，只要你最終以一些延遲異步處理這些查詢。最後，通過從交互式請求路徑中刪除慢速操作，你還可以改善最終用戶體驗。
異步集成的示例包括：
- 前端應用程序將作業插入隊列系統（如Amazon SQS）。後端系統檢索這些作業並按照自己的進度處理它們。
- API生成事件並將其推送到Kinesis流中。後端應用程序批量處理這些事件以創建存儲在數據庫中的聚合時間序列數據。
- 多個異構系統使用AWS步驟函數來傳達它們之間的工作流，而無需直接相互交互。
- Lambda函數可以使用來自各種AWS源的事件，例如Amazon DynamoDB更新流和Amazon S3事件通知。你不必擔心實現排隊或其他異步集成方法，因為Lambda會為你處理此問題。
4.4.4 分佈式系統最佳實踐
增加松耦合的另一種方法是構建以優雅方式處理組件故障的應用程序。你可以確定減少對最終用戶的影響的方法，並提高你在脫機過程中取得進展的能力，即使在某些組件發生故障時也是如此。
實踐中優雅的應對失敗
失敗的請求可以使用指數退避和抖動策略重試，也可以存儲在隊列中以供以後處理。對於前端接口，可以提供替代或緩存的內容，而不是完全失敗，例如，你的數據庫服務器變得不可用。Amazon Route 53 DNS故障轉移功能還使你能夠監控你的網站，並在主站點不可用時自動將訪問者路由到備份站點。你可以將備份站點作為Amazon S3上的靜態網站託管，也可以作為單獨的動態環境託管。
4.4.5 服務，而不是服務器
開發，管理和運維應用程序，尤其是大規模應用程序，需要各種各樣的底層技術組件。對於傳統的IT基礎架構，公司必須構建和運行所有這些組件。
AWS提供廣泛的計算，存儲，數據庫，分析，應用程序和部署服務，可幫助組織更快地移動並降低IT成本。
不利用這種廣度的架構（例如，如果它們僅使用AmazonEC2）可能無法充分利用雲計算，並且可能錯失了提高開發人員生產力和運營效率的機會。
4.4.5.1 管理服務
AWS託管服務提供開發人員可以使用的構建塊來為其應用程序供電。這些託管服務包括數據庫，機器學習，分析，排隊，搜索，電子郵件，通知等。例如，使用Amazon SQS，你可以減輕運維和擴展高可用性消息傳遞群集的管理負擔，同時僅為你使用的內容支付低價。Amazon SQS本身也具有可擴展性和可靠性。這同樣適用於Amazon S3，它使你可以根據需要存儲儘可能多的數據，並在需要時訪問它，而無需考慮容量，硬盤配置，複製和其他相關問題。
為你的應用程序提供支持的託管服務的其他示例包括：
- 用於內容交付的AmazonCloudFront
- 用於負載平衡的ELB
- 用於NoSQL數據庫的Amazon DynamoDB
- 用於搜索工作負載的AmazonCloudSearch
- 用於視頻編碼的Amazon ElasticTranscoder
- 用於發送和接收電子郵件的AmazonSimple Email Service（Amazon SES）
4.4.5.2 無服務器計算架構
無服務器計算架構可以降低運行應用程序的操作複雜性。無需管理任何服務器基礎架構，就可以為移動，Web，分析，CDN業務邏輯和物聯網構建事件驅動和同步服務。這些體系結構可以降低成本，因為你無需管理或支付未充分利用的服務器，也無需配置冗餘基礎架構來實現高可用性。
例如，你可以將代碼上載到AWS Lambda計算服務，並且該服務可以使用AWS基礎結構代表你運行代碼。使用AWS Lambda，你需要為代碼執行的每100毫秒以及觸發代碼的次數付費。通過使用Amazon API Gateway，你可以開發由AWS Lambda支持的幾乎無限可擴展的同步API。與Amazon S3結合使用以提供靜態內容資產時，此模式可以提供完整的Web應用程序。
在移動和Web應用程序方面，你可以使用Amazon Cognito，這樣你就無需管理後端解決方案來處理用戶身份驗證，網絡狀態，存儲和同步。Amazon Cognito為你的用戶生成唯一標識符。
可以在訪問策略中引用這些標識符，以基於每個用戶啟用或限制對其他AWS資源的訪問。Amazon Cognito為你的用戶提供臨時AWS憑證，允許設備上運行的移動應用程序直接與受AWS身份和訪問管理（IAM）保護的AWS服務進行交互。例如，使用IAM，你可以將對S3存儲桶中的文件夾的訪問權限限制為特定的最終用戶。
對於物聯網應用，組織傳統上必須配置，操作，擴展和維護自己的服務器作為設備網關，以處理連接設備與其服務之間的通信。AWS IoT提供完全受管理的設備網關，可根據你的使用情況自動擴展，無需任何操作開銷。
無服務器計算架構還使得在邊緣計算運行響應式服務成為可能。
說明：
本文由新鈦雲服運維工程師傅雨斌翻譯，新鈦雲服擁有八名認證的AWS工程師，在AWS使用和維護方面擁有豐富的經驗，已經為多家用戶提供AWS上雲支持。
原文鏈接：
https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf
閱讀更多 新鈦雲服 的文章
