前言

本周 AWS 推出了一項新的實體設備 – AWS Snowcone，比 Snowball edge 更為輕便，且含有運算資源便於實現邊緣運算，讓使用者更方便的移轉資料。在基礎設施方面，AWS CloudFormation Guard 於這周推出了預覽版，可以協助企業減少不必要的營運成本，還能將安全漏洞風險降低。

新服務的推出外，AWS 也優化了許多其他服務，包含無伺服器領域的 AWS Lambda 新增支援 Amazon EFS，深度學習方面，Amazon Lex 現在也支援 Kendra 了。文中我們也會提及 Amazon EC2 Auto Scaling、Amazon ECS Capacity Providers… 等多項服務的更新。

焦點新聞

Amazon EC2 Auto Scaling 新增 Instance Refresh 功能

使用者會利用 Auto Scaling 來自動擴展 EC2 Instance 以符合實際流量，但當使用者要更新設定、替換 EC2 Instance 或抽換 AMI 的時候，這時候如果 ASG 裡面有大量的 EC2 該如何執行呢？使用者需自行以腳本執行替換新的 Launch Configuration 到 ASG 上，之後可能會先提高 ASG 的最大 Instance 數量，讓 ASG 多開幾台新版本的機器出來；然後再調整數量回預設值，將舊版本的 Instance 關掉，來實現版本切換的效果。

此次更新後，EC2 Auto Scaling 提供了新的 Instance Refresh 功能，讓使用者在替換完設定後，可以啟用 Instance Refresh 以滾動更新 Rolling update 的方式，將舊版設定的 EC2 Instance 抽換為新版的 EC2 Instance。

使用者可以設定 Health percentage 至少需幾台 EC2 Instance 來維持應用程式正常運作，以及 EC2 Instance 需要多少時間做 Provision 才能投入工作的 warmup period。可以隨時停用 Instance Refresh，但並不會將已更新的 Instance 還原回舊版設定。

使用者需要切換至新版 EC2 Auto Scaling Console 才能夠操作此功能。

參考來源至：Amazon EC2 Auto Scaling now supports Instance Refresh within Auto Scaling Groups

AWS Snowcone – 小型、輕量、堅固且安全的邊緣運算及資料傳輸設備

AWS Snowcone 是一個新推出的邊緣運算及資料傳輸設備，為 AWS Snow Family 的一員，比 Snowball edge 更為輕便好攜帶，且含有運算資源便於實現邊緣運算。

主要的特色有：

• 更加小型、輕量：Snowcone 大約長 9 英寸、寬 6 英寸、高 3 英寸，重量為 4.5 磅。具備 2 個 CPU，4GB 內存，8TB 可用容量以及支援 Wi-Fi 或有線網絡。
• 堅固：可承受高溫、低溫的環境，甚至受到撞擊仍可以正常使用，即使碰到水，也不會故障。
• 安全：支援多層次加密，可確保資料在傳輸及儲存上的安全性
• 支援 IoT Greengrass 及部分 EC2 Instance Type：使用者在搬遷資料的過程中，即使使用者所在位置的網路訊號不佳，還可以持續做資料處理的工作。

使用者可以選擇透過 off-line 的方式，由 AWS 將設備帶回 Data Center 移轉資料，或是用 on-line 的方式，利用 AWS DataSync 傳輸到 AWS 端。

參考來源至：AWS announces AWS Snowcone – a small, portable, rugged, and secure edge computing and data transfer device

其他服務更新

AWS CloudFormation Guard 預覽版

AWS CloudFormation Guard（cfn-guard）是一種透過 CLI 介面幫助企業在 AWS 上建構的基礎設施及應用程式資源皆擁有合規性，僅需要定義 Policy 來驗證資源配置的規則，就可以幫助管理者檢查 CloudFormation 所建立的資源是否有不合規行為產生，以助於企業減少不必要的營運成本，且能將安全漏洞風險降低，例如：管理者可以透過 Policy 確保開發人員僅能建立加密的 EBS Volume，以降低資料竊取的風險。

也能把 cfn-guard 加入 CI/CD 的一部份，假設模板中的資源未符合規則，那麼 cfn-guard 會發出訊息以提供開發人員識別不合規資源，以預防不必要成本或安全漏洞的問題產生。

現在有一個創建 EBS 的模板：

{
    "Resources": {
        "NewVolume" : {
            "Type" : "AWS::EC2::Volume",
            "Properties" : {
                "Size" : 101,
                "Encrypted": false,
                "AvailabilityZone" : "us-west-2b"
            }
        },
        "NewVolume2" : {
            "Type" : "AWS::EC2::Volume",
            "Properties" : {
                "Size" : 99,
                "Encrypted": false,
                "AvailabilityZone" : "us-west-2c"
            }
        }
    }
}

假設要求 EBS 都必須加密的規則，寫法就像是防火牆規則，易於撰寫：

let encryption_flag = true
let allowed_azs = [us-east-1a,us-east-1b,us-east-1c]

AWS::EC2::Volume AvailabilityZone IN %allowed_azs
AWS::EC2::Volume Encrypted == %encryption_flag
AWS::EC2::Volume Size == 100

透過這個規則，使用者可以檢查模板以確保是否符合規則：

$ cfn-guard -t Examples/ebs_volume_template.json -r Examples/ebs_volume_template.ruleset
   "[NewVolume2] failed because [Encrypted] is [false] and the permitted value is [true]"
   "[NewVolume2] failed because [Size] is [99] and the permitted value is [100]"
   "[NewVolume2] failed because [us-west-2c] is not in [us-east-1a,us-east-1b,us-east-1c] for [AvailabilityZone]"
   "[NewVolume] failed because [Encrypted] is [false] and the permitted value is [true]"
   "[NewVolume] failed because [Size] is [101] and the permitted value is [100]"
   "[NewVolume] failed because [us-west-2b] is not in [us-east-1a,us-east-1b,us-east-1c] for [AvailabilityZone]"
   Number of failures: 6 

更多規則編輯說明，請參考 aws-cloudformation/cloudformation-guard。

參考來源至：Introducing AWS CloudFormation Guard (Preview) – a new open-source CLI for infrastructure compliance
參考來源至：aws-cloudformation/cloudformation-guard

AWS Lambda 新增支援 Amazon EFS

當使用者利用 Lambda 執行運算處理時，有時候會需要自行 import libraries 到 Lambda 裡，像是利用 Lambda 執行影像辨識、大數據分析等等，需要 import 的 libraries 大小可能會超過目前支援的上限（512GB），當 libraries 大小超過 512GB 時，會導致 function 無法順利執行。

此次更新後，使用者可以掛載 EFS 到 Lamnda。掛載完成後，會提供一個在 Lambda 的本地路徑，使用者可以將 libraries 放在 EFS 中，在執行 Function 時，直接取用。此外，也可以多個 Lambda 共用同一個 EFS File，就不需要在多個 Lambda import 多次同樣的 libraries。

在 Lambda 掛載 EFS 的方法，可參考 AWS 官方文件：Using Amazon EFS with Lambda

參考來源至：AWS Lambda support for Amazon Elastic File System now generally available

Amazon Lex 新增支援 Kendra

Kendra 是一個企業搜尋的服務，使用者可以將企業存放文件的地方（例如：onedrive、S3）與 Kendra 做整合，以便快速的搜尋這些數量龐大且雜亂的文件。

當使用者試圖透過 Lex 打造聊天機器人來查找企業文件，以往的作法會透過 Lambda 去呼叫 Kendra 的搜尋結果，再回傳至 Lex 做回覆，意味著使用者須自行以程式碼邏輯來執行、取得結果。

此次更新後，Lex 在內建的 Intent 中新增了 AMAZON.KendraSearchIntent 讓使用者可以直接與 Kendra 做互動，而不需要透過 Lambda，方便之外也同時節省了 Lambda 的費用成本。

參考來源至：Amazon Lex announces built-in search intent to enable Amazon Kendra integration

Amazon CloudFront 現在支援設定嘗試與 origin source 連線的次數以及每次連線逾時的時間長度

為了降低應用程式的 Latency，有些使用者會利用 CloudFront 來 Cache 部分資料。例如：利用 CloudFront cache 網站內媒體類的資料，以便當終端使用者下一次發送請求時，可以從 Edge Location 快速回覆給終端使用者。

當 CloudFront 要從 origin source 端快取資料時，如果連線失敗或是 origin source 的運作發生錯誤，那 CloudFront 會做 Retry 與等候回應，在這種情況下反而有機會增加 Latency。因此，使用者可以建立另一個用以 Failover 的 secondary origin source，當 master origin source 發生錯誤時，可以轉移到 secondary origin source 請求資料。

此次更新後，使用者可以設定每一次 CloudFront 向 origin source 嘗試連線的次數及逾時的時間長度（1 至 60 秒）。當每一次嘗試都逾時，且超過嘗試次數，就切換到 secondary origin source，幫助快速做出反應，降低終端使用者得到回覆的 Latencies。

以提供影片串流的平台來說，可以設定 CloudFront 在 1 次連線嘗試及 1 秒逾時時間內，容錯移轉至 secondary origin source。透過快速的 failover，保持終端使用者觀看影片時的流暢程度，避免影響使用者體驗。

參考來源至：Amazon CloudFront enables configurable origin connection attempts and origin connection timeouts

Amazon EC2 新增 Instance Type：C6g Instance & R6g Instance

採用 Arm 架構 AWS Graviton2 處理器的 compute-optimized Amazon EC2 C6g Instance 與 memory-optimized Amazon EC2 R6g Instance 正式上市！

在 compute-intensive workload，例如：高效能運算 (HPC)、批次處理、影片編碼、遊戲、分散式分析，以及基於 CPU 的機器學習推論，相較於採用 x86 的 Amazon EC2 C5 執行個體，Amazon EC2 C6g 執行個體的性價比最高可提升 40%；而在 memory-intensive workload 方面，例如：資料庫、記憶體內快取，以及即時大數據分析，相較於採用 x86 的 Amazon EC2 R5 執行個體，Amazon EC2 R6g 執行個體的性價比最高可提升 40%。

除了此次推出的 C6g 及 R6g Instance 外，同樣採用 AWS Graviton2 處理器的 general purpose M6g Instance，相較於採用 x86 的 M5 Instance，也有較好的性價比。推薦使用者可以多多採用新的 Instance Type。

參考來源至：Amazon EC2 C6g and R6g instances powered by AWS Graviton2 processors are now generally available

Amazon ECS Capacity Providers 新支援 Delete Functionality

當使用者利用 Capacity Providers 來分配 ECS Container 啟用的運算資源時，可以指定 Auto Scaling Group、Fargate 或是 Fargate Spot 作為提供 capacity 的來源。但隨著使用時程拉長，使用者不需要某些 Capacity Providers 了，就需要從 ECS Task 或是 ECS Service 中，移除已捨棄的 Capacity Providers。如果 Task 及 Service 的數量多，容易造成沒有完整移除的人為疏失。

此次更新後，使用者可以直接刪除 Cluster 裡不需要的 Capacity Providers，而不用一個個 Task / Service 手動移除。刪除後的 Capacity Providers 會進入 INACTIVE 的狀態，ECS Container 就不會再啟用在 INACTIVE 的 Capacity Providers。

參考來源至：Amazon ECS Capacity Providers Now Support Delete Functionality