AWS SAA系列

AWS 導流(CloudFront、ELB)與Auto Scaling

Photo by Agape Trn on Unsplash

AWS CloudFront

CloundFront是AWS提供的CDN(Content Delivery Network或Content Distribution Network)服務，CDN是內容傳遞網路，利用最靠近使用者的節點，將緩存的html靜態內容(HTTP)或是影音檔案(RTMP)更快且低延遲的傳遞給使用者。

Edge Location

邊緣節點，AWS在世界各地遍布的47 個國家/地區、90+ 個城市總共 275+ 個連接點，這些節點會緩存Origins的內容或是DNS，更快地提供給世界各地的使用者。可以自訂緩存的類型與時間。

aws doc

Origins

原始位置，通常是S3，也可以是EC2，可以將網站交由S3託管，禁止其他來源訪問S3，僅透過CloudFront，藉此達到增加效能與監控流量的目的。

signed URLs & signed cookies

都是限制檔案只允許特定使用者存取，使用時機的差別是signed URLs適用於RTMP、個別的檔案限制、不支援cookies的客戶端，signed cookies適用於多個限制檔案，像是頻道會員專屬。

georestrictions

可以針對地理位置封鎖，只有當使用者位於已核准的地區或是不在不允許的地區，才允許他們存取您的內容。

AWS WAF Web ACL

Clouud Front可以搭配WAF來針對特定IP限制存取。

Amazon CloudFront Adds SNI Custom SSL

支援SSL certificates搭配Server Name Indication (SNI)。來源：aws doc

AWS Elastic Load Balancing(ELB)

ELB是AWS提供的負載平衡器，用來將來源請求分散到不同的目標實體，僅存在單一region，可以跨AZ，上面介紹的CloudFront解決靜態資源的問題，動態資源仍需要回到來源伺服器取得，這時候就需要ELB的幫助，提高服務的可用性與容錯能力。

• listener 監聽流量來源的port
• register實體服務
• 將來源轉導至註冊的實體服務上
• Sticky Sessions：如果服務是有狀態的，像是已登入的會員，如果登入後備ELB分配到不同的實體上，導致有被登出的可能性，因為另一個實體沒有登入的紀錄，這時候就可以透過Sticky Sessions的特性，讓使用者保持在同一個實體上，當然系統設計上可能就要避免掉這個情形發生。
• X-Forwarded-For Header：背後實際運作的服務如果有需要來源IP的情況，但透過ELB後來源IP會變成ELB的IP，這時候在header裡面的X-Forwarded-For Header就是真正的來源IP。

Classic Load Balancer

CLB

最傳統的ELB，目標只能是固定的實體，建議都改用NLB/ALB。

Application Load Balancer

ALB

在OSI第七層，依序評估監聽規則(uri/hostname)，根據規則選取目標群組中的目標。支援動態的port對應，能夠將WAF放在ALB上，很適合用在WEB服務之上。

關於Host-Based Routing可以參考AWS Blog，附圖比較清楚。

Network Load Balancer

OSI第四層運作，每秒處理數百萬個請求，可以用更低延遲的效能，適用於急遽波動的情境，像是多人的線上遊戲。

詳細比較可參考aws

Auto Scaling

Auto Scaling 能確保有足夠的實體來應付流量，可以建立一群EC2的集合，稱之為Auto Scaling Group，並設定最大值與最小值，以及相對應的擴展條件，定期health check檢查，置換掉unhealthy的實體，適合與ELB、CloudWatch搭配使用。

• Launch Configuration：建立實體的設定，建立後無法編輯，Instance Type、AMI、Userdata……等。
• Auto Scaling Group：建立實體的位置，AZ、Subnet、ELB……等。
• Scheduled Action：根據指定時間調整ASG，適用於已知流量會上升的時候。
• Scaling Policy：根據定義的規則，通常是資源的使用量來調整ASG。
• Simple scaling：根據單一條件來調整。
• Step scaling：Simple scaling的進化版，根據一組條件。
• Target tracking scaling：提前設定好要追蹤的目標(CPU、Memory)，根據目標來決定增加或減少，相對於Step scaling，比較單純，只要設定好目標值，會自動增加或減少來達到，就像是設定冷氣溫度一樣。
• Scheduled Scaling：根據設定的時間。
• Predictive Scaling：監控歷史流量模式並預測未來，以排定在適當的時間進行 EC2 執行個體數目變更。Predictive Scaling 使用機器學習模型來預測每日和每週模式。
• Cool down time：等候上一個擴展活動生效的時間量即稱為冷卻期間。
• 平衡：Auto Scaling Group會在所有AZ之間重新平均分配應用程式執行個體，也就是新增會從最少的開始，減少則會優先減少最多實體的AZ。aws doc。

Scale In的規則

按造以下順序關閉機器，若前一個規則相同則依序往下比對。

1. 平均分配所有AZ之間的執行個體。
2. 先關閉執行個體中所屬的啟動設定是最舊的。
3. 關閉最接近下一個計費小時的執行個體。
4. 隨機。

來源：AWS

資料來源

• aws doc(CloudFront)
• aws doc(ELB)
• aws doc(Auto Scaling)
• AWS Certified Solutions Architect — Associate 2020(freeCodeCamp.org)

SAA學習筆記目錄