[英]AWS architecture - Web application (Diagram)
我正在為 Web 項目設置中型 AWS 基礎設施。 我可能多慮了幾件事,因此想向社區征求意見。 任何輸入表示贊賞。
請看圖:這里
解釋(從左到右):
我錯過了什么? 這太多了嗎? 這個結構有什么起伏?
非常感謝大家!
到第 6 步為止,一切看起來都很合理。無需查找最近的 MySQL 數據庫,因為您的實例已經知道它在哪里——它是本地區域中的一個。
步驟 7 有問題,因為 ELB 不能用於平衡 RDS 實例。 但是,使用 Aurora/MySQL,您將獲得一個具有短 TTL 的單個集群“讀取器”端點主機名,可在您的 Aurora 副本之間進行負載平衡。 如果副本死亡,它會自動從 DNS 中刪除。
第 8 步 使用 API Gateway 並不是絕對必要的——實例可以通過 Lambda API 直接調用 Lambda 函數。
此外,還有 Lambda@Edge 允許直接從 CloudFront 觸發 Lambda 函數——盡管如果您需要的 Lambda 函數規模很大(依賴項)或需要在 VPC 內運行,您必須級聯其中兩個——邊緣函數(不在 VPC 中)調用區域功能(大型,或在 VPC 中)——但這通常仍然比 API 網關便宜。 邊緣函數會自動全局復制並在最接近處理單個請求的 CloudFront 邊緣的區域中運行,並且在任何給定的函數調用中,這可以通過檢查process.env.AWS_REGION
來識別。 邊緣函數還可用於更改提供內容的源——因此,例如,如果您的函數發現它在歐盟地區被調用,它可以重寫請求,以便 CloudFront 將 S3 請求發送到歐盟存儲桶。
如果您的站點位於域的頂點,例如example.com
而不是www.example.com
,您的域將需要托管在 Route 53 中,而不是 Go Daddy,因為 DNS 標准中的限制不允許CloudFront 在頂點所需的動態行為。 您仍然可以向他們注冊您的域,但不是由他們托管。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.