前言

這周 AWS 為容器使用者推出了一種新的 command-line 工具 – AWS App2Container，讓使用者可以將現有應用程式輕鬆模組化，並透過容器將部署和操作流程標準化。大數據領域，AWS 則為 Amazon EMR 新增 Managed Scaling 功能，現在使用者能夠用最低且最有效的方式來自動擴展 Cluster 大小。在機器學習方面，Amazon Personalize 改善了中繼資料遺失的處理方式，更新以後即使在訓練資料時資料不完整，也不會有負面影響了！上述幾項服務外，這周我們也會介紹 Amazon CloudWatch、Transit Gateway、Amazon Route 53…等許多服務的改善。

焦點新聞

推出 AWS App2Container – 容器化處理應用程式並移轉至 AWS 雲端的服務

AWS App2Container（A2C）是一種新的 command-line 工具，可將使用 .NET 及 Java 建構的應用程式模組化為容器化的應用程式。A2C 會分析原本使用虛擬機部署之應用程式所需要的環境設定、套件，像是 run-time、dependency、configuration 等等，並將這些工具打包成 Application inventory。

使用者只需選擇想要容器化的應用程式，A2C 就會將應用程式打包成 Container Image、設定網路連接埠，並產生 ECS Task 和 Kubernetes pod definitions。

A2C 透過 CloudFormation 進行佈建，包含基礎架構和 CI/CD pipeline，才能將容器化之後的 .NET 或 Java 應用程式部署至生產環境。使用 A2C，使用者可將現有應用程式輕鬆模組化，並透過容器將部署和操作流程標準化。

參考來源至：Announcing AWS App2Container – Containerize and Migrate Applications to the AWS Cloud
參考來源至：AWS App2Container – A New Containerizing Tool for Java and .NET Applications
圖片來源至：AWS App2Container – Overview

AWS 針對 CDK 推出了 Solutions Constructs 協助部署良好架構

通常使用者透過雲端來部署其架構的話，基本上都會由好幾個服務組合而成，而 AWS 為了簡化使用者需要一個一個手動開啟服務的痛點，而推出了 CloudFroamtion，透過 Template 的方式將所需的服務都定義在裡面，再透過 CloudFormation 自動部署。

然而，撰寫 Template 不是一件簡單的事情，使用者必須熟悉 Template 語法，通常都是一邊寫一邊參考 AWS 文件，所以 AWS 又推出了 CDK，透過預先打包好的相關服務元件 Service Pattern，使用者可以直接透過常用的高階程式語言來定義所需的 AWS 服務與架構，並透過 CDK 自動轉換成 CloudFormation Template。

現在 AWS 為了優化使用者的架構而推出了 Solution Constructs，Solutions Constructs 是以 AWS Well-Architected 框架為基礎的架構，目前包含數十種常見的架構，使用者可以將這些架構以匯入 CDK 當中，以增加 CDK 撰寫的效率與架構的完整性。

參考來源至：Introducing AWS Solutions Constructs

AWS Direct Connect 在以色列啟用首座服務地點

AWS Direct Connect 現已在以色列海法的 MedOne 上線。這是以色列首座 AWS Direct Connect 服務地點。位於以色列的使用者，現在可以從 on-premise 建立專屬 connection 至 AWS 。

使用 Direct Connect 的使用者，可獲得 1 Gbps 或 10 Gbps 的專用連線，或與合作夥伴協作以獲得速度低於 1 Gbps 的連線。

參考來源至：AWS Direct Connect launches first location in Israel

其他服務更新

Amazon CloudWatch Application Insights 支援監控 SQL Server 應用程式

CloudWatch Application Insights 是一款幫助使用者監控 .NET 應用程式的服務，此次更新後，支援 SQL Server 應用程式，透過此功能可監控應用程式的狀態，遇到異狀時，CloudWatch Application Insights 提供自動化監控儀表板，助於使用者即時做修復處理，此外也能搭配 AWS Launch Wizard 服務整合，使用 AWS Launch Wizard 部署 SQL Server workload 時，只需要在 Launch Wizard 主控台上點按一鍵，CloudWatch Application Insights 會在 CloudWatch 上自動設定相關指標、日誌和警示，並開始監控新部署的 workload。

參考來源至：CloudWatch Application Insights adds support for SQL Server High Availability configurations

Transit Gateway 改善 CloudWatch Metric 指標粒度

Transit Gateway 現在會針對所有連接的元件收集以下指標：BytesIn、BytesOut、PacketsIn、PacketsOut、PacketsDropCountBlackHole 和 PacketsDropCountNoRoute 等指標可查看。

• BytesIn：transit gateway 接收的位元組數量。
• BytesOut：transit gateway 傳送的位元組數量。
• PacketsIn：transit gateway 接收的封包數量。
• PacketsOut：transit gateway 傳送的封包數量。
• PacketDropCountBlackhole：因路由目標為 black hole 而遭捨棄的封包數量。
• PacketDropCountNoRoute：未配對至路由而遭捨棄的封包數量。

參考來源至：AWS Transit Gateway now supports more granular CloudWatch Metrics for improved network monitoring

Amazon RDS Performance Insights 針對多個資料庫引擎支援 query plan 功能

Query Plan 是一連串用來存取關聯式資料庫管理系統 (DBMS) 內資料的步驟。DBMS 通常會有優化 Query 的程式來選擇一種最佳的 query 方式來執行特定查詢，但通常使用者必須手動檢驗並調整，才能提升效能。

現在可以透過 Performance Insights 讓使用者在原有的視覺化儀表板上找出最佔用資源的 SQL query，也可以比較 query plan 之間的效能落差，以改進應用程式。

目前新增支援的資料庫引擎有：

• Amazon Aurora with PostgreSQL Compatibility
• Amazon RDS for PostgreSQL
• Amazon RDS for MySQL
• Amazon RDS for MariaDB

參考來源至：Amazon RDS Performance Insights supports query plan capture on Amazon Aurora with PostgreSQL Compatibility, Amazon RDS for PostgreSQL, Amazon RDS for MySQL, and Amazon RDS for MariaDB

Amplify CLI 支援 Lambda layers 以跨 Lambda Function 來共享程式碼和 assets

Lambda layers 是一個 ZIP 的壓縮檔案，其中包含 libraries、自定義的 runtime 或其他 dependencies。Lambda layers 提供了以下好處：

• 可重複使用程式碼：Lambda Function 可以共用存放在 layers 裡的程式碼和 assets。開發人員就不需要在每個 Lambda Function 裡重複程式碼，進而簡化程式碼。
• 加速部署的速度：當程式碼需要更新時，使用者可直接更新 layers 裡的程式碼，而不需要一個個修改。

此次更新後，如果使用者選擇 Node.js 及 Python 作為 Lambda runtimes，並利用 Amplify CLI 部署 Lambda Function 應用程式，Amplify CLI 提供了簡易的指導步驟來創建、更新及部署 Lambda layers。使用者可針對現有的 Amplify 應用程式或是新的 Amplify 應用程式，都適用新的 Amplify CLI。

## 使用者可將 Lambda layers 加入應用程式中
$ amplify add function

## 透過一步步的指導語，設定 Lambda layers
? Select which capability you want to add:

## 選擇 Lambda layer
> Lambda layer (shared code & resource used across functions)

? Provide a name for your Lambda layer: layerblog4dac28df
? Select up to 2 compatible runtimes: NodeJS

## 使用者可以設定誰可以存取 Lambda layers
? The current AWS account will always have access to this layer.
Optionally, configure who else can access this layer. (Hit <Enter> to skip)
❯◯ Specific AWS accounts
 ◯ Specific AWS organization
 ◯ Public (Anyone on AWS can use this layer)

完成上述的步驟，Lambda layers 就已經設定完畢。設定完成之後，如果要開始放程式碼或是其他 assets 到 layers 裡，可以切換到 amplify/backend/function/layerblog4dac28df/nodejs/ 目錄下，其中會有一個 package.json 檔案，並輸入 npm install <your modules> 指令，加入想加入的程式碼或是其他 assets。之後在利用 Amplify CLI 創立 Lambda Function 時，就可以引用 Lambda layers。

參考來源至：Amplify CLI adds support for Lambda layers to easily share code & assets across Lambda functions
案例來源至：How to use Lambda layers with the Amplify CLI

Amazon EMR 新增 Managed Scaling 功能 – 以最佳效能及最低成本的方式自動擴展 Cluster 大小

原先使用者如果要調整 EMR Cluster 的大小，需要手動修改 Cluster，或是利用 CloudWatch Metrics 監控目前 Cluster 內的 capacity，並自訂 scaling policy。當 scaling policy 被觸發時，使用自訂義的腳本，擴展 EMR Cluster 大小。

此次更新後，EMR 支援 Managed Scaling，基於最佳 performance 並同時使用最低成本的前提下，EMR 會自動擴展 Cluster，不再需要自訂 scaling policy，比起設置資源最大及最小值的固定大小群集，可幫助節省最高 60% 的成本。

參考來源至：Amazon EMR now supports Managed Scaling – automatically resizing clusters to lower cost

Amazon EMR 運用 real-time capacity insights 佈建 Spot Instance，以降低成本及減少任務中斷的情形

Amazon EMR 開始提供「Capacity Optimized (容量優化)」分配策略，可在 Amazon EMR Cluster 中佈建 Spot Instance。「容量優化」分配策略可自動以最有效率的方式使用 AWS 可用的運算容量，同時提供 Spot Instance 的價格折扣。除此之外，容量優化策略還可減少中斷發生的可能性，進而降低工作負載的整體成本。此分配策略適合中斷成本較高的工作負載。例如：執行 Apache Spark、Apache Hive 和 Presto，長時間運作的任務的持久性叢集。

「容量優化」分配策略使用 real-time capacity insights 的資料，分配啟用 Spot Instance pools 裡的 Instance，同時符合使用者所需的最佳容量。此分配策略利用「EC2 Fleet（艦隊）」的方式，當使用者以 instance fleet configuration 建立群集時，每個 task node 可指定最多五種 EC2 Instance Type，不僅使 Spot request 的多元化，也讓使用者繼而享有大幅折扣。

參考來源至：Amazon EMR uses real-time capacity insights to provision spot instances to lower cost and interruption

Amazon Route 53 推出全新 API Action 以列出與 Amazon VPC 關聯的 Private Hosted Zones

此次更新後，使用者可以透過呼叫 ListHostedZonesByVPC API Action，來確定哪些 Private Hosted Zones 與自身的 VPC 有關，可以幫助掌控現在整個組織內 Private Hosted Zones 與 VPC 之間的關聯。例如：使用者可以識別與 VPC 關聯的 Private Hosted Zones，即使這些 Private Hosted Zones 由其他 AWS 帳戶建立。

參考來源至：Amazon Route 53 Launches New API Action to list Private Hosted Zones associated with your Amazon VPCs

Amazon Elastic File System 提高檔案系統最低的輸送量

以往，所有 EFS bursting 模式的檔案系統（無論大小）可驅動 100 MiB/s 的輸送量。而大於 1TiB 的 Standard 類別 storage，當還有 burst credits 可以使用時，每 TB 可驅動 100 MiB/s。

對於 Standard 類別 storage 低於 20 GiB 的檔案系統，當 burst credits 全部用完時，最低輸送量只有每 GiB 50 KiB/s。此次更新後，即使 burst credits 用盡，仍可提升最低輸送量為固定的 1 MiB/s。

此外，建議使用者使用 AWS CloudWatch 監控 burst credits 的剩餘額度。當應用程式突然需要大量的輸送量時，仍可以提升輸送量，而不論檔案系統中儲存的資料量為何。

參考來源至：Amazon Elastic File System increases file system minimum throughput

Amazon ECS 提升部分服務限制

此次更新後，使用者可以在每個 ECS Service 裡部署最多 2,000 個 Tasks，而每個 ECS Cluster 最多可有 2,000 個 ECS Service。

參考來源至：Amazon ECS announces increased service quotas

Amazon Personalize 改善中繼資料遺失的處理方式

Personalize 在訓練 Model 的過程中，常常會因為 Souce data 的 metadata 不完整，例如：產品品牌、使用者年齡層、使用者經常瀏覽的裝置類型，而這些資料其實是有助改善推薦模型的準確性與相關性，但可能因為疏失而遺失，若在 Personalize 模型培訓的流程中未妥善處理，可能會對 model 的效能帶來負面影響。

此次更新後，Amazon Personalize 接受可在結構描述時定義「null」值，即使 metadata 並不完整，也不會有負面影響，進而改善推薦的相關性。在定義「null」為允許的 metadata 值後，使用者可放心的將資料集匯入 Personalize 並建置 Solution。建置 Solution 時，Personalize 會自動辨識缺少 metadata 的欄位，並以妥善方式加以處理。

參考來源至：Amazon Personalize adds improved handling of missing metadata

AWS CodeDeploy 支援自動安裝及定期更新 CodeDeploy Agent

使用者現在可以利用 AWS Systems Manager Distributor 與 CodeDeploy 的整合，將 AWS CodeDeploy Agent 的安裝和更新流程自動化。

藉由此整合，使用者可以透過 AWS Console 或 AWS CLI 安裝 CodeDeploy Agent，或針對 Amazon Elastic Compute Cloud（Amazon EC2）和內部部署伺服器上的目標 Instances 建立更新排程。

參考來源至：AWS CodeDeploy now enables automated installation and scheduled updates of the CodeDeploy Agent