前言

AWS 這周推出了一項特別的服務 – Amazon Location Service，這個服務類似大家熟悉的 Google Map，特別的是它能夠在地圖上畫出區塊，如果應用裝置離開這個範圍，就可以觸發通知，告訴管理者。

除了地圖服務的推出外，AWS 這周也發布許多讓管理整能夠更輕鬆管理的服務，像是多數 AWS 使用者都會用到的 EC2 推出了 Spot Blueprints，而 AWS CloudShell 則是讓使用者可以從 AWS Console 取用的 browser-based shell。這周我們還會為大家介紹許多服務更新，包含了 AWS IoT、AWS Cost Anomaly Detection、AWS Lambda…等。

焦點新聞

AWS Systems Manager 推出新功能

Systems Manager 是 AWS 針對維運大量 EC2 所設計的服務，讓維運人員可以輕鬆的管理大量、跨帳號的 EC2，但隨著不斷的更新新功能，現在的 Systems Manager 已經不像原先只是管理 EC2 的服務了。

Fleet Manager

Systems Manager 新增了 Fleet Manager 功能，主要能讓使用者透過視覺化介面的方式遠端查閱 Linux、Wondows、MacOS EC2 上的文件及其相關效能圖表。

使用者可以選擇設定好的 Managed instance 並選擇 Instance actions 中的 view file system 或者 View performance counters 來遠端查看這些文件與 log 檔（都是 Read-only）。

參考來源至：Introducing AWS Systems Manager Fleet Manager

Change Manager

Change Manager 是一個針對 AWS Organization OUs 進行 IAM 權限的修改，如下圖中我可以自定義此次權限修改的名稱以及相對應的權限（IAM policy）。

隨後使用者可以針對 整個 Organization 或者個別 OUs 進行此次權限修改。

但有些使用者並不是透過 IAM Policy 來限制底下帳號 User 的權限，有可能是透過 SSO 的方式，所以 Change Manager 可以在 Setting 中設置權限變更所要套用的對象。

最重要的部分是使用者可以針對每次的「Change」下一個變更的概要與原因，並可以在主控台中看到歷史紀錄，這是原先直接使用 AWS Organization 修改權限時所沒有的東西。

參考來源至：Introducing AWS Systems Manager Change Manager

Application Manager

使用者時常會開啟多個 AWS 服務或者透過 CloudFromation 來部署應用程式，換句話說此應用程式其實橫跨了多個 AWS 服務，當使用者要做監控與維運時，時常需要切換不同服務的主控台才得以操作。

此次 Systems Manager 新增了 Application Manager 功能，主要針對 CloudFormation、EKS 或者是 Launch Wazird 所開啟的應用程式提供一站式監控頁面。

使用者可以以「應用程式」為單位來查閱目前的狀況，頁面中提供了一個儀表板、涵蓋的 AWS 服務、設定、log 與 CloudWatch metric，讓使用者可以非常輕鬆的在一個頁面就完成此應用程式的監控與設定。

參考來源至：Introducing AWS Systems Manager Application Manager

Amazon EC2 推出 Spot Blueprints – 可生成 EC2 Spot Instances 架構的 Template 產生器

Amazon Spot Instance 是許多使用者為了降低運算資源成本的方式之一，而 Spot Instance 可以應用在多個服務，例如：Amazon EC2、Amazon EMR、Amazon ECS、Amazon EKS..等。如果使用者想要在多個 AWS 服務上使用 Spot Instance，需要切換各個服務的 Console 畫面，並學習各個服務請求 Spot Instance 的方式及設定，而在管理時也會比較複雜。

現在 Amazon EC2 推出 Spot Blueprints，可以自動產生請求 Spot Instances 的 Template。使用者可從 Template 了解 Spot Instance 相關的設定，或是下載公版後做編輯。除此之外，Spot Blueprints 也支援產生用於 CloudFormation 或是 Terraform 的 Template。

• 使用 Spot Blueprints 的第一步，就是選擇欲使用 Spot Instance 的 AWS 服務：

選擇後，如果僅當作測試，可以直接在 “Just need a template?” 點擊 CloudFormation 或是 Terraform 的 Template 來下載內建、符合最佳實踐的 Template。

• 接著，Spot Blueprints 會逐步詢問這次 Spot request 需要的其他設定，像是 VPC 網路環境、Instance Type，都可以透過 Spot Blueprints 生成對應的 Template 內容。

此外，在選擇 Instance Type 時，如果使用者不知道該選擇哪一個，可以輸入需要的運算資源，例如：多少 Memory、vCPU，Spot Blueprints 可幫使用者預估，產生可用的類型以供選擇。

• 最後 Spot Blueprints 會生成完整的 Template。往後使用者需要再請求 Spot Instances，就可以重複利用，或是下載之後自行編輯其餘設定。以下範例是透過 Spot Blueprints 生成用於創建 EMR Spot Instance 的 Template。

參考來源至：Amazon EC2 announces Spot Blueprints, an infrastructure code template generator to get started with EC2 Spot Instances

圖片來源至：Introducing Spot Blueprints, a template generator for frameworks like Kubernetes and Apache Spark

AWS CloudShell – 可從 AWS Console 取用的 browser-based shell

使用者與 AWS 溝通的方式有三種：AWS Console、AWS SDK 及 AWS CLI。其中，如果要使用 AWS CLI，使用者需要先在自己的電腦下載 AWS CLI，接著還需要設定 IAM User 的 Credential 才可以具有操作 AWS 的權限。

現在 AWS 推出 CloudShell，直接從 Console Home Page 點選 CloudShell 的按鈕之後，AWS 會開啟一個 terminal，使用者可直接下 AWS Command Line，而 CloudShell 使用的就是使用者登入的 IAM User 權限來做操作。如此一來，省去使用者自己下載 AWS CLI 的功夫；也因為不用管理 Credential，降低 Credential 外洩的風險。

除此之外，CloudShell 其實是 AWS 替使用者開了一台 Amazon Linux 2 的虛擬機來下指定，因此它本身具有 1GB 的儲存空間，可以讓使用者額外下載套件，例如：pip3、aws-cdk…等。

參考來源至：Introducing AWS CloudShell

Amazon Location Service (Preview) – 安全地添加個人位置資料至應用程式

當使用者想在自己的應用程式，加入地圖或是即時定位…等與位置相關的地理資訊時，可以利用 AWS 這次推出的 Location Service 來做到。Amazon Location Service 提供一個安全且保持使用者隱私的方式，加入個人位置資訊到應用程式裡。

Amazon Location Service 與另外兩個 (Esri 及 HERE) 具有公信力的第三方合作，提供三種功能：

• 不同的地圖樣式，未來也會持續增加更多樣式。

• 經緯度位置搜尋：利用 SearchPlaceIndexForPosition 函式搜尋特定經緯度的實際地址

$ aws location search-place-index-for-position --index-name MyIndex1 \
  --position "[-122.33805,47.62748]" --output json \
  |  jq .Results[].Place.Label
"Terry Ave N, Seattle, WA 98109, United States"
"900 Westlake Ave N, Seattle, WA 98109-3523, United States"
"851 Terry Ave N, Seattle, WA 98109-4348, United States"
"860 Terry Ave N, Seattle, WA 98109-4330, United States"
"Seattle Fireboat Duwamish, 860 Terry Ave N, Seattle, WA 98109-4330, United States"
"824 Terry Ave N, Seattle, WA 98109-4330, United States"
"9th Ave N, Seattle, WA 98109, United States"

• 追蹤裝置位置：使用者可以利用 BatchUpdateDevicePosition 函式抓取多個裝置的即時位置；也可以利用 geojson.io 在地圖上畫出指定區塊，結合兩個函式，就可以做到當裝備離開所選區域時，傳送通知。

可直接串接 Amazon EventBridge 來傳遞通知

參考來源至：AWS announces Amazon Location Service (Preview)

圖片來源至：Amazon Location – Add Maps and Location Awareness to Your Applications

Amazon Managed Service for Prometheus (AMP) – 全託管、與 Prometheus 兼容的監控服務

近年來，Prometheus 是許多 Container 使用者愛用的監控工具。AWS 推出 Amazon AMP，是一個全託管的 Prometheus 專案，使用者可直接使用 PromQL 來監控 on-premise 或是 AWS 上的容器化應用程式。

啟用之後，AMP 會直接產生 Endpoint，並教學如何設置使用者自己的 Prometheus Server 來寫入資料。

使用 AMP，使用者不用管理基礎設施，且 AMP 會自動擴展效能，同時支援與其他 AWS 服務整合，例如：Amazon IAM、Amazon CloudTrail、PrivateLink..等。

參考來源至：AWS announces Amazon Managed Service for Prometheus for container monitoring

圖片來源至：Amazon Managed Service for Prometheus Product Page, Join the Preview – Amazon Managed Service for Prometheus (AMP)

Amazon Managed Service for Grafana (AMG) – 全託管、安全的視覺化資料服務

Grafana 是一個可以跨平台、開源的資料視覺化的工具，可以整合使用者多種來源的 Logs、Metrics 資料後，生成簡單的圖表，讓即使不是技術人員也可以了解系統的表現。

現在 AWS 推出 Amazon Managed Service for Grafana 服務，將 Grafana 和 AWS 服務結合，讓使用者可以用全託管的 Grafana 工具來視覺化存放在 AWS 平台上的資料，例如：Amazon Managed Service for Prometheus、CloudWatch、IoT SiteWise、X-Ray、Timestream、Amazon ES，以及 Aurora PostgresSQL…等服務裡收集到的資料。

使用者如果升級到 Grafana Enterprise，還可以連接各種第三方合作夥伴的資源，例如：Datadog、MongoDB、New Relic、Splunk 和 ServiceNow，還可以從 Grafana Labs 獲得培訓和諮詢的幫助。

除了視覺化以外，Amazon Managed Service for Grafana 也可以讓使用者即時查詢這些資料，同時受益於 Amazon Managed Service for Grafana 內建的合規性，讓資料收集更加安全。

參考來源至：AWS announces Amazon Managed Service for Grafana in Preview

圖片來源至：Amazon Managed Service for Grafana Product Page, Amazon Managed Grafana – Getting Started

其他服務更新

Amazon SageMaker Studio 支援 AWS PrivateLink 及 IAM SourceIP Restrictions

此次更新後，SageMaker Studio 與使用者個人 VPC 之間的溝通，可透過 AWS PrivateLink 傳輸，而不會暴露在公有網路，提高安全性。除此之外，新增適用於 SageMaker Studio 的 IAM Policy – SourceIP Restrictions，使用者可限定能夠存取 SageMaker Studio 的來源 IP 位置，例如：僅接受個人私有環境中的 IP。

參考來源至：Now Secure Your SageMaker Studio Access Using AWS PrivateLink and AWS IAM SourceIP Restrictions

AWS IoT 相關服務推出新功能

AWS IoT SiteWise Edge – 讓 IoT SiteWise 可收集、處理、監控本地端工業設備的功能

工廠為了維持產線穩定並最大化產品質量、確保工作人員安全，AWS 推出了 IoT SiteWise Edge 讓使用者能夠在本地收集和處理設備數據。

AWS IoT SiteWise Edge 可安裝在硬體（例如第三方的 Gateway 或電腦）上，或者安裝在 AWS Outposts 和 AWS Snow Family 等設備中。

借助 SiteWise Edge，使用者可以使用 AWS IoT SiteWise 在設備中統整、處理設備數據。例如：可以計算總體設備效率（OEE）、平均故障間隔時間（MTBF）、平均故障恢復時間（MTTR）等指標，所以即使設備的網路連線中斷，也可以讓此設備在 edge 端持續運作，確保不會中斷。

SiteWise Edge 目前支援 OPC-UA、Modbus 和 EtherNet / IP 等三種常見的協議，可以安全的連線並讀取歷史資料，或從設備讀取感測數據。

因此使用者可以將較機密的數據（Critical Data）保留在本地以滿足合規性，同時可以將數據發送到 AWS IoT SiteWise 或其他 AWS 服務（例如 Amazon S3 和 Amazon Timestream），以進行長期存儲和進一步分析。

參考來源至：Announcing AWS IoT SiteWise Edge (Preview), a new capability of AWS IoT SiteWise to collect, process, and monitor industrial equipment data on-premises

AWS IoT Device Defender – ML Detect

AWS IoT Device Defender 新增了一項新功能 – ML Detect，這項新功能可學習過去的紀錄自動檢測 IoT 設備的操作和安全異常。

以往使用者可以透過 AWS IoT Device Defender 的 Rules Detect 功能來手動設置警報，而 ML Detect 是透過機器學習的方式預測設備的狀況來簡化手動設置警報的麻煩，因此即使不了解設備相關指標所代表的意思也可以透過此功能識別異常，並對設備做出相對應的措施。

AWS IoT Device Defender ML Detect 包括以下功能：

• 支援六個 metric 的監控（near real-time）
• 支援設定高 / 中 / 低可信度的 ML 警報通知
• 在最初的 ML 訓練期間，此功能將在設備上每 14 天替每個指標紀錄 25,000 個數據點，並會在創建初始模型後，開始識別設備異常行為
• 建立初始模型後，可每天對模型進行重新訓練
• 有內建緩解措施，解決設備問題
• 使用與 AWS IoT Device Defender Rules Detect 相同的警報通知機制，如 Amazon SNS

參考來源至：Announcing AWS IoT Device Defender ML Detect public preview

AWS IoT Core – Device Advisor (Preview)

Device Advisor 是基於雲端的全託管測試功能，用於在軟體開發期間驗證 IoT 設備。Device Advisor 提供了預先建立的測試，使用者可以用這些測試來驗證 IoT device 與 AWS IoT Core 的可靠性和連接安全性，然後再部署到生產中。

使用 Device Advisor，使用者可以：

• 確認 IoT Device 可靠地連接到 AWS IoT Core 並同時進行安全性最佳實踐。
• 下載資格報告，提交到 AWS Partner Network 進行驗證，使設備符合AWS Partner Device Catalog 的規範。
• 獲得測試結果以及詳細的日誌紀錄。

參考來源至：AWS IoT Core Device Advisor now available in preview

AWS IoT Device Management – Fleet Hub

使用者在 IoT Core 支援批量（Fleet）註冊後，可以一次性的將相同屬性或用途的硬體設備註冊到 IoT Core 上，讓使用者省去了不少麻煩，但大量的數據同時上來後卻沒有一個統一監控的儀表板來做維護。

此次更新後新增了 IoT Device Management – Fleet Hub，可讓使用者以「應用程式為單位」也就是使用者當初自己定義的 Fleet 來監視這些硬體設備的運行狀況，因此使用者可以透過此服務清楚的看到硬體設備間的溝通狀況與硬體本身的狀態，例如：韌體版本、連線狀態、電池電量等相關資訊。

而對於維運人員來說，他們可能不一定有 AWS 帳號，而 Fleet Hub 也提供 SSO 功能讓使用者進行登入。

參考來源至：AWS IoT Device Management introduces Fleet Hub, a new, easy way to monitor and interact with IoT device fleets

AWS IoT Greengrass 2.0

AWS IoT Greengrass 2.0 是 AWS IoT Greengrass 的新版本，使設備製造商可以建立、部署和管理設備軟體。AWS IoT Greengrass 2.0 提供 open source edge runtime，含有各種內建軟體，例如用於開發的工具，以及用於管理大量設備上軟體的新功能：local debug console 可以讓使用者在部署後快速開發與測試設備。

使用者可以根據設備的 CPU 及 Memory 自由的選擇這些內建軟體，例如：

• 在需要處理資料流的時候再把 stream manager 加進來
• 需要進行機器推論的時候才加入機器學習套件

有關 Greengrass 2.0 open source edge runtime 的細節可在 GitHub 上面找到。
AWS 把所有寶藏都放在 GitHub 上了，去找吧！

參考來源至：AWS IoT Greengrass 2.0 provides an open source edge runtime and new capabilities for building and operating IoT device software

AWS IoT EduKit

AWS IoT EduKit 是 AWS 新推出的一項學習套件，透過 IoT EduKit ，幫助開發人員（從學生到經驗豐富的工程師）學習如何建立 end-to-end IoT 應用程式。

使用 AWS IoT EduKit 有以下好處：

• 簡化的硬體設備，且具有高度擴充性（例如透過 grove 連接感測器）
• 廣泛的軟體支援（FreeRTOS、Arduino、MicroPython 等等）
• 與 Amazon Alexa 相容

要開始使用這項學習資源，前往 Amazon.com 或是 M5Stack 官方商店 購買一個 M5Stack 開發板。收到開發板時，跟著內附的教學步驟來建立不同的 IoT 應用。

想瞭解更多相關資訊，可前往 AWS IoT EduKit 工作坊 得到更詳細的內容。

參考來源至：Introducing AWS IoT EduKit

AWS Cost Anomaly Detection 正式 GA

AWS Cost Anomaly Detection 可以免費替使用者監控 AWS 帳號內的支出模式，來檢測異常支出並提供根本原因的分析，幫助使用者最大程度地降低成本意外及掌控成本狀態。

AWS Cost Anomaly Detection 利用機器學習技術，能夠有效地找出支出增加的幅度及模式，或一次性增加的高峰值。除此之外，使用者可以創建自己的成本監控機制並設立通知，即時了解狀況。

另外，使用者也可以透過回報檢測結果的準確度，優化 Cost Anomaly Detection 的表現。

參考來源至：AWS Cost Anomaly Detection is now generally available

AWS Lambda 功能更新

使用者自行管理的 Apache Kafka 現在可當作 AWS Lambda 觸發事件的來源

Lambda Function 是以事件觸發，使用者可設置特定操作來觸發 Lambda 做後續處理。此次更新後，Lambda Function 新增以 Apache Kafka Cluster 裡的數據作為觸發事件來源，且不論是運行在 on-premise 或是 AWS 雲端上的 Apache Kafka Cluster 皆可支援。

如此一來，使用者就可以串接 Apache Kafka Cluster 裡的數據，讓 Lambda 來進行批次處理。目前 Lambda 支援最高 10,000 筆 record 時觸發，或是 playload 達到 6GB 時觸發。

參考來源至：AWS Lambda now supports self-managed Apache Kafka as an event source

AWS Lambda 可對 Amazon Kinesis 及 Amazon DynamoDB Streams 處理程序加上檢查點 (checkpointing)

當使用者利用 Lambda Function 來批次處理在 Kinesis Data Streams 或是 DynamoDB Streams 裡的數據時，常常發生一種狀況是：重複處理錯誤的數據 (Error)。因為數據本身有誤而導致 Lambda 處理失敗，而 Lambda 就會進行 retry，直到 retry 的次數達到上限才會停止，進而浪費使用者的運算資源。

使用者可以啟用 BisectBatchOnFunctonError 的功能，當 Lambda 處理發生 Error 時，會將發生錯誤的 Batch 拆分為二，並分別 retry 前後 items，最終找到實際發生錯誤的 item。但仍花費許多額外的運算資源，像是 item4，就 retry 了 4 次。

此次更新後，透過設置 checkpoints 的新功能，使用者可以輕易的在某次批次處理中，了解在哪裡發生了 Error。此外，當產生 Error 時，Lambda 僅會 retry 在上一次成功處理的 item 之後的數據，而不會 retry 先前的數據。

使用者需要在 Lambda Function code 裡設定：當發生 Error 時，回報 Error 的 item 位置到 batchItemFailures 參數裡，Lambda 會在該 item 位置設為 checkpoint；如果有多個 Error，就可以設置多個 checkpoints 來做註記。接著，Lambda 僅會 retry checkpoint 之後的 item。

如此一來，當整個批次處理完成後，使用者可以在 CloudWatch Log 裡看到 Lambda 回報的 checkpoints，讓使用者很直觀地知道哪裡有 Error；同時降低 Lambda retry 的次數。

啟用該功能，只要打開 Report batch item failures 的功能即可。

參考來源至：AWS Lambda launches checkpointing for Amazon Kinesis and Amazon DynamoDB Streams

圖片來源至：Optimizing batch processing with custom checkpoints in AWS Lambda