本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL01-BP03 透過架構調節固定服務配額和限制
請注意不可變更的服務配額、服務限制和實際資源限制。設計應用程式和服務的架構以防止這些限制影響可靠性。
範例包括網路頻寬、無伺服器函數調用承載大小、API閘道的限流爆量速率，以及與資料庫並行的使用者連線。
預期成果：在正常和高流量條件下，應用程式或服務會如預期般執行。它們已設計為在該資源的固定限制或服務配額內運作。
常見的反模式：
-
選擇使用一項服務的一項資源的設計，但未注意到擴展時會導致此項設計失效的設計限制。
-
執行不切實際的基準並且在測試期間達到服務固定配額。例如，以爆量限制執行測試，但是進行擴充的時間量。
-
選擇若超過固定服務配額時無法擴展或修改的設計。例如，SQS承載大小為 256KB 。
-
未設計可觀測性並且實作以監控和提醒在高流量活動期間可能有風險之服務配額的閾值
建立此最佳實務的優勢：確認應用程式是否會在所有預計的服務負載層級下執行，而不會中斷或降級。
未建立此最佳實務時的曝險等級：中
實作指引
與可用更高容量單位取代的軟服務配額或資源不同，無法變更 AWS 服務的固定配額。這表示在應用程式設計中使用時，必須評估所有此類 AWS 服務的潛在硬容量限制。
硬性限制會顯示在 Service Quotas 主控台中。如果資料欄顯示 ADJUSTABLE = No，則服務有硬性限制。硬性限制也會顯示在一些資源組態頁面中。例如，Lambda 有無法調整的特定硬性限制。
例如，設計 Python 應用程式在 Lambda 函數中執行時，應用程式應該評估以判斷 Lambda 是否有機會執行超過 15 分鐘。如果程式碼可能執行超過此服務配額限制，則必須考慮替代技術或設計。如果在生產部署後達到此限制，應用程式會遭受降級和中斷直到可以矯正為止。與軟性配額不同，沒有任何方法可以變更這些限制，即使是在緊急嚴重性 1 活動下。
一旦應用程式部署到測試環境，應該使用策略來尋找是否達到任何硬性限制。壓力測試、負載測試和混亂測試應該是引入測試計畫的一部分。
實作步驟
-
檢閱 AWS 可在應用程式設計階段使用的服務完整清單。
-
檢閱這些服務的軟性配額限制和硬性配額限制。並非所有限制都會顯示在 Service Quotas 主控台中。有些服務會在替代位置描述這些限制。
-
隨著您設計您的應用程式，檢閱您的工作負載的業務和技術驅動來源，例如業務成果、使用案例、相依系統、可用性目標和災難復原物件。讓您的業務和技術驅動來源引導程序以識別適合您的工作負載的分散式系統。
-
分析區域和帳戶之間的服務負載。許多硬性限制對於服務是區域型的。不過，某些限制是帳戶型。
-
分析區域 (Zonal) 失敗和區域 (Regional) 失敗期間資源用量的彈性架構。在使用主動/主動、主動/被動 – 熱、主動/被動 - 冷和主動/被動 - 指示燈方法的多區預設定進度中，這些失敗案例會導致較高的用量。這會建立達到硬性限制的潛在使用案例。
資源
相關的最佳實務：
相關文件：
相關影片：
相關工具：
