前言

AWS 每年最重要的 re:Invent 即將在下周正式開始，而 AWS 也在這周陸續發布許多重要的服務新功能。像是大家常接觸到的 AWS Lambda 在這周針對安全性、效能、處理 request 的數量都做了不少改動。 另外 AWS 也持續在優化許多操作流程，讓使用者能更便利的運用這些服務。例如 AWS 近期推出了 AWS CloudFormation Modules 而 AWS Step Functions 則是支援同步的 Express workflow。

今天我們還會為各位介紹 Amazon ECS、Amazon ECS、AWS Backup、AWS Single Sign-On …等服務，下周的 re:Invent 我們也會整理即時新聞與大家分享，歡迎大家隨時留意我們的粉絲團及部落格，第一時間獲得最新消息！

焦點新聞

AWS Lambda 新增程式碼簽章功能

AWS Lambda 是一個全託管的無伺服器運算服務，讓使用者可無需管理底層基礎設施，只需上傳程式碼並設定好觸發條件，便能自動運行。

程式碼簽章就如同一個虛擬的印章，在編譯好的軟體（程式碼）上蓋章，一旦被重新編譯、竄改，所蓋的章也就會消失，透過此方式來確保程式碼的合規性。

雖然 Lambda 運行程式碼時會在 AWS 安全的環境中運行，但許多使用者會自己建立 Pipeline 從外部自動匯入程式碼，在這過程中程式碼就有可能遭到竄改。

此次更新後，AWS Lambda 推出了程式碼簽章（Code signing），可以幫助使用者強制規範僅來自受信任的來源的程式碼簽章才能執行 Lambda，此 Lambda 的新功能是基於 AWS Signer （AWS 的程式碼簽章服務）這個功能完成的，所以如果使用者要使用此功能，得先於 AWS Signer 中創建簽章設定：

使用者可以在 1 ~ 135 個月之間選擇簽章的有效期限。

創建完成後，便能於 Lambda 的主控台中創建程式碼簽章，並有兩種 Signature validation policy：

• Warn：部署會通過，但會於 CloudWatch log 中留下紀錄。
• Enforce：部署會被阻擋。

隨後便可進入該 Lambda Function 中設定程式碼簽章。

一但設定完成程式碼簽章後，就無法於 Lambda 主控台中編輯程式碼，一定得使用簽章過的 .zip 或 S3 匯入程式碼。

參考來源至：Announcing Code Signing, a trust and integrity control for AWS Lambda

以 Amazon SQS 為事件來源的 AWS Lambda Function 現在支援最高 5 分鐘的 batch windows

先前，當使用者設定 SQS Queue 作為 Lambda Function 的事件來源時，僅能設定 batch size，也就是每次提取的 messages 數量最高可至 10 個。當 SQS Queue 存放很多簡單的 messages 時 ，以 messages 數量作為觸發 Lambda Function 的機制，較容易讓成本升高。

此次更新後，使用者在設定 SQS Queue 觸發 Lambda Function 機制時，多了一種判斷觸發時機的選擇。除了原先以 「messages 數量」 作為基準以外，現在新增以 「間隔時間長度」 為觸發條件，而且最久可達 5 分鐘；也就是說，Lambda Function 現在最長可以間隔 5 分鐘再從 SQS Queue 拉 messages 出來做處理，藉此可幫助使用者降低 Lambda 的成本花費。

除此之外，SQS Standard Queue 也提高 batch size 的限制，單一批次處理可一次處理最多 10000 個 messages；而 FIFO Queue 仍維持單一批次處理 10 個 messages 的限制。

參考來源至：AWS Lambda now supports batch windows of up to 5 minutes for functions with Amazon SQS as an event source

AWS Lambda 支援 Advanced Vector Extensions 2 (AVX2)

現今有許多使用者利用 AWS Lambda 構建許多不同的應用程式，而 Lambda 在其中所擔任的角色，可能是負責處理需要高運算效能（compute-intensive）的程序，或是某一個功能能夠正常運作的關鍵。隨著這次 Lambda 支援 AVX2 套件，使用者現在可以利用 Lambda Function 完成更多高難度的處理程序，例如：機器學習推理、媒體處理、高性能計算（HPC）等等應用程式。

參考來源至：AWS Lambda now supports Advanced Vector Extensions 2 (AVX2)

圖片來源至：Creating faster AWS Lambda functions with AVX2

AWS 推出 AWS CloudFormation Modules

AWS CloudFormation 是一個 Infrastructure as a code 的服務，使用者可透過 JSON 或 YAML 事先定義好資源配置模板（CloudFormation Template），便可以透過 CloudFormation 自動部署 Template 中的服務資源，來達到快速部署與重複部署。

以往 Cloudformation 讓人感到有點麻煩的是，使用者必須明確的定義所有服務資源的設定，包括 properties 等，使用者很難把一些東西抽象出來封裝成類似 CDK construct 的概念，讓它可以重複使用，也沒辦法讓使用者把一些公司團隊要求的 best practice 或合規要求封裝起來，讓其他員工直接調用。

此次更新後 Cloudformation modules 正式登場，讓使用者不需要鉅細靡遺地去重複撰寫 Resource properties 細節，可以自己封裝或使用別人封裝的 modules，就像搭建樂高積木一樣，但目前 CloudFormation modules 僅支援 JSON 格式的 Template，所以使用者僅能夠使用 .json 並透過 ::MODULE 作結尾語法匯入或創建 module。

參考來源至：Announcing Modules for AWS CloudFormation

圖片來源至：AWS CloudFormation Documentation – Using modules to encapsulate and reuse resource configurations

AWS Step Functions 支援同步的（Synchronous）的 Express workflow

AWS Step Functions 是一項管理工作流程的服務，可在流程中串接多個 Serverless 應用程序。許多使用者利用 Step Functions 來提供微服務，像是訂單處理、媒體轉檔、ETL 流程等應用程式後端的處理程序。其中，Step Functions 有兩種類型的 workflow：Standard 及 Express。

Express workflow 是於 2019 年 12 月推出的新類型，Express 利用 in-memory 的運算方式，提供高處理速度，適合用於處理時間較短、觸發頻率較高的 workflow，例如：處理串流型數據、收集 IoT 數據等等 workflow。

在過去，許多使用 Step Function 的使用者都曾遇到一個問題：因為 Step Functions 採取 Asynchronous（異步）的處理方式，因此使用者必須另外寫腳本或是使用其他服務，不停詢問 Step Functions 是不是已經處理完畢，才能知道 Step Functions 處理的結果。

此次更新後，Express workflow 支援同步（Synchronous）模式，使用者不需要再花額外的時間做 polling 的動作，當 Step Functions 處理完成後，會返回結果給使用者知道。藉此，使用者將複雜的邏輯打包成一連串的處理程序後，只要啟用 Step Function，就可以得到最終結果了，簡化設計程序。

參考來源至：AWS Step Functions now supports Synchronous Express Workflows

圖片來源至：New Synchronous Express Workflows for AWS Step Functions

Amazon ECS 優化了 Cluster Auto Scaling 的邏輯

在 2019 年 12 月時，AWS 推出了可幫助節省成本的 Fargate Spot 類型；同時，搭配新推出的 ECS Capacity Provider，使用者可以利用設定 Capacity Provider 的比重，決定當 Container Instances 需要擴展時，使用哪一種 Compute Resource 來增長 / 減少 Container Instances，例如：50% 的 Tasks 使用 Fargate，另外 50% 的 Tasks 使用 Fargate Spot。

另外，對於 EC2 類型的 Container Instances，使用者可以將 EC2 Auto Scaling Group 註冊到 Capacity Provider 底下，方便下次使用 Service 或是 Tasks 啟用 Container 時，選擇該 Auto Scaling Group 裡的 EC2 Instance 作為 Compute Layer。

此次更新後，AWS 優化了 Cluster Auto Scaling 的機制。當使用者將 EC2 Auto Scaling Group 註冊到 Capacity Provider 底下時，可選擇啟用 Managed scaling 的設定，ECS 便會以監控 AWS 自定義的 CloudWatch Metrics –CapacityProviderReservation 作為擴展的基準。

而 CapacityProviderReservation Metrics 又是如何決定何時該增長或減少 Instances 數量呢？其中有兩個相當重要的計算數字，第一個是 M，代表「能滿足運行現有與預計啟用的 Tasks 的 Container Instance 數量」；而另一個則是 N，代表「現行 Cluster 裡的 Container Instance 數量」

• 如果 M=N，那 Cluster 內的 Compute Resource 是足夠 Container 使用。

上圖在每一個 Container Instance（紫色方框）裡，都運行至少一個 Task（綠色方框），並且沒有任何的 Container Instance 可以在不影響 Task 運作的狀態下關閉。

• 如果 M≠N，那 Cluster 就需要做擴展的動作。

上圖在每一個 Container Instance（紫色方框）所有的 Compute Resource 都已經分配給 Task（綠色方框），但仍有更多的 Task 因為資源不足而無法運行。

詳細 M 跟 N 的計算方式，可參考 AWS 官方部落格：Deep Dive on Amazon ECS Cluster Auto Scaling。

除此之外，先前如果使用者在啟用更多 Tasks 時，ECS 發現當前的 EC2 Container Instacnes 已無法提供更多 Compute Resource 來運行 Tasks，那麼 Tasks 會直接關閉並顯示為 Fail 的狀態。現在，在使用者啟用 Managed scaling 的設定後，當遇到相同狀況時，Tasks 並不會直接關閉，而是停滯在 provisioning 的狀態，待 EC2 Container Instance 增長後，便會轉為 running，進而優化 Cluster Auto Scaling 的表現。

參考來源至：Amazon ECS Cluster Auto Scaling now offers more responsive scaling

圖片來源至：Deep Dive on Amazon ECS Cluster Auto Scaling

其他服務更新

Amazon Honeycode 支援 single sign-on (SSO)

以往 Amazon Honeycode 都是使用自己特定的憑證來登入，此次更新之後，Amazon Honeycode 支援使用 single sign-on (SSO) 登錄了！可以使用 Microsoft Active Directory, Azure AD, Okta, OneLogin, PingFederate, Google Workspace 等基於 SAML (Security Assertion Markup Language) 的身份提供商提供的憑證進行 single sign-on (SSO) 登錄。

參考來源至：Amazon Honeycode supports single sign-on with popular identity providers

Amazon EC2 Auto Scaling 宣布 Auto Scaling groups 可以支援多個 launch templates

Amazon EC2 Auto Scaling 現在讓使用者在使用 MixedInstancesPolicy 和指定多種 instance 時可以設定 Auto Scaling group 執行多個 launch templates。使用者將可以利用這個更動達到在同一個 Auto Scaling group 啟動不同 Amazon Machine Images (AMIs) 及不同 CPU 架構的 instances。

參考來源至：Amazon EC2 Auto Scaling announces support for multiple launch templates for Auto Scaling groups

Amazon EC2 Auto Scaling 支援可在啟用 EC2 instances 時掛載多個 network interfaces

Amazon EC2 Auto Scaling 同時也宣布支持 Auto Scaling group 在啟動 EC2 Instances 時，可以連接上多個網路介面（network interfaces）。在這個更動之前使用者必須自己寫腳本才能達到，這個功能現在只要設定 Launch Template 就好了。

參考來源至：Amazon EC2 Auto Scaling now supports attaching multiple network interfaces at launch

AWS Backup 支援跨帳戶複製備份

為了降低人為誤刪資料、不可預期的災害風險，備份已成為企業管理中重要的一環，在 AWS 上有 Backup 這項服務可幫助企業進行備份。此次更新後，AWS Backup 允許使用者複製自己的備份給同一個 AWS Organization 中其他使用者。

使用者可以讓來源帳戶的備份複製到目標帳戶的備份空間。如果來源帳戶因為意外、被惡意刪除或勒索軟體而導致業務中斷，還有其他備份可以重構。使用者不需要自定義腳本或使用昂貴的第三方軟體，即可從目標帳戶或從第三個帳戶還原。

此外， AWS Backup 除了提供跨帳戶備份以外，也能啟用跨區域備份，將備份複製到不同區域中的另一個帳戶，可透過 AWS Organization 來定義來源帳戶和目標帳戶，讓使用者可以使用 AWS Organization 將某些帳戶指定為目標帳戶。這可以幫助使用者確保將備份僅複製到組織中受信任的帳戶，以防止未經授權的存取，達到持續滿足合規性的需求。

參考來源至：AWS Backup and AWS Organizations bring cross-account backup feature

Amazon CodeGuru Reviewer 支援標籤功能

Amazon CodeGuru Reviewer 主要是在審查程式碼階段給予建議，透過使用者對 git 的 pull/push 請求，標記可能有問題的程式碼，對 Bitbucket、GitHub、AWS CodeCommit 及 GitHub Enterprise Server 中的程式碼進行分析並提供建議。此次更新後，可以在 Repositories 上標籤，以利開發人員辨別資源以外，有些較為機密的程式碼也能根據標籤去設定 AWS Policy，以達到權限分層管理目的。

參考來源至：Amazon CodeGuru Reviewer announces tag support to better organize resources

AWS Copilot CLI 正式 GA

AWS Copilot CLI 提供使用者可以在 Amazon ECS 和 AWS Fargate 上創建、發布及運行容器化應用程序的工具，幫助使用者開發應用程序的整個過程，只需要透過執行命令，就能夠輕鬆運行容器。此次更新後，使用者可以透過 AWS Copilot CLI 部署測試、正式環境，不管是 Windows、Linux 及 Mac OS 皆有支援。

參考來源至：AWS Copilot CLI is now Generally Available

AWS Systems Manager 支援 Amazon VPC endpoint policy

此次更新後，AWS Systems Manager 支援 Amazon VPC endpoint policy，讓使用者可以設定對 Systems Manager API 的訪問。當使用者創建一個 Systems Manager 的 VPC endpoint 時，使用者可以連結 AWS Identity and Access Management (IAM) ，以限制使用者對 Systems Manager API 的操作。例如，使用者可以限制某些用戶只能「List」 Systems Manager Run Command，而不能做其他動作，透過此方式來控管權限。

參考來源至：AWS Systems Manager now supports Amazon Virtual Private Cloud (Amazon VPC) endpoint policies

Amazon Comprehend 推出 Comprehend Events

Amazon Comprehend 是一個全託管的 NLP 服務，可分析使用者文件檔案中的專有名詞、詞性、情緒等。

以往 Amazon Comprehend 會分析使用者的文字並依序排列，並沒有任何後續的動作，使用者若要從中找出一些端倪得自己針對 Comprehend 的結果進行處理。

此次更新後，Amazon Comprehend 推出了 Comprehend Events 功能，除了分析使用者的文字外，還會進一步的根據分析結果給出一個懶人包，例如：假設一篇新聞報導指出「Amazon 將收購 WholeFoods Market」，這時 Comprehend 可將收購者「Amazon」、被收購者「WholeFoods Market」、交易金額以及交易日期和時間等報導內的重要資訊擷取出來，並整合成一段懶人包。

Comprehend Events 目前僅針對「合併」、「破產」和「IPO（首次公開發行）」等事件進行訓練。

參考來源至：AWS announces the launch of Amazon Comprehend Events

AWS Single Sign-On 加強權限控管

為了簡化煩瑣的登入步驟，SSO（Single Sign-On）漸漸成了趨勢，在企業組織裡，除了要防範外部的威脅以外，內部的權限管理也是很重要的一環，此次更新後，AWS Single Sign-On 針對 身分認證 及 權限控管 皆有進一步的加強。

AWS Single Sign-On 現在可設定 User 需要綁定 MFA 裝置才可登入

此次更新後，AWS Single Sign-On（SSO）管理員可以要求使用者必須綁定（MFA）設備，加強身份驗證，對於還未綁定 MFA 設備的使用者，管理者可以要求他們在成功進行密碼身份驗證後，強制完成 MFA 綁定。

目前支援的 MFA 有 Google Authenticator 的一次性密碼（OTP）機制的軟體，還有 FIDO 安全密鑰 YubiKey，或適用於 Android，iOS，Windows 和 macOS 平台的預設身份驗證器，以確保合規性並簡化管理流程。

參考來源至：AWS Single Sign-On enables administrators to require users to set up MFA devices during sign-in

AWS Single Sign-On 支援 attribute-based access control（ABAC）授權方式

Attribute-Based Access Control (ABAC) 是一種透過 Attribute (屬性) 為依據的權限控管策略，而 AWS 上提供 Tags (標籤) 的功能，除了讓使用者增加資源識別性、做 Cost allocation…等辨識需求，也可以搭配 IAM Policy 來要求 IAM User 在建立 AWS Resources 時必須同時新增 Tags。

Tags (標籤)也能使用在 IAM User 和 IAM Role 上，搭配 ABAC Policy 可以實現透過 Tags 配對 Key、Value 決定該 IAM 身份能不能對該 AWS Resources 做操作。

更多與 ABAC 相關內容，請參考 eCloudture 先前的 Blog 文章：透過 AWS Tags 實作 Attribute-Based Access Control (ABAC)。

此次更新後，AWS Single Sign-On 支援 ABAC，只要定義 Tags，就可以依照業務性質，去設定這個Policy 套用在哪些人身上，使用者透過 SSO 成功登入後即適用對應的權限，如此一來管理員就不必一一調整每個人的權限，也能簡化管理及調整權限流程。

參考來源至：AWS Single Sign-On enables attribute-based access control for workforce users to simplify permissions in AWS