【每周快報】0429-0506 AWS 服務更新
前言
這周 AWS 將更多去年提出的 Preview 版本的服務 GA 了!這次 GA 的服務類型十分多元,包含了 IoT 方面的 Fleet Provisioning,這項服務讓使用者註冊流程能夠自動化,節省了不少時間。無伺服器方面則是 Amazon EventBridge Schema Registry 正式 GA 了,這項服務讓前後端應用程式能夠彼此串聯。
除了多項新服務正式推出外,還有許多服務也增加了新功能。在機器學習領域,Amazon Transcribe Medical 現在支援客製化詞彙,新增更多專業名詞及發音。另外,Amazon Translate 多了墨西哥西班牙語,更道地的語言支援可以供給使用者更好的體驗。文內我們也將介紹資安相關的 WAF 更新、管理層面的 AWS Systems Manager Explorer 及 AWS Step Functions 還有多項不同領域的新服務及改善喔!
一、焦點新聞
Amazon Elasticsearch UltraWarm 正式 GA
假設今天想要快速讀取及分析大量機器的 Log,並快速地排除運行安全問題,除了 Log 儲存成本會造成很大的負擔,分析的工具還需要相輔相成,並不是件容易的事。
UltraWarm 在 2019 AWS re:Invent 釋出 Beta 版,這是一個在 Elasticsearch 裡儲存 Hot Data 的功能,最多可以儲存 900 TB 的 Hot Data,滿足以往想要快速存取資料的需求,成本與過往相比,降低了 90 %,在實用及價格上都佔有優勢。
UltraWarm 支援兩種 Storage Tiers:
- Hot Tier: 主要用來創建索引、更新資料及存取資料。
- UltraWarm Tier: 可以存儲不常存取的資料
也就是可以根據資料的存取頻率進行分類,助於成本最佳化。但這樣還是有疑慮,就是使用者如何去決定要不要用,Amazon Elasticsearch Documentation 有提供計算的文件,可以根據自身的需求,計算可預估的成本為何,評估是否使用。
參考來源至:AWS announces Amazon Elasticsearch Service UltraWarm general availability
參考來源至:Announcing UltraWarm (Preview) for Amazon Elasticsearch Service
AWS IoT Core Fleet Provisioning 正式 GA
Fleet Provisioning 是 IoT Core 的一個新功能,能讓使用者快速註冊硬體到 IoT Core 上,像大量製造設備的製造商(OEM),為了測試硬體常一個一個手動註冊至 IoT Core 上,這是一件非常麻煩且耗時的事情,甚至可能會拖延硬體開發的週期,所以現在可以透過 Fleet Provisioning 來自動化這些註冊流程,包括註冊、新增憑證等步驟,替使用者節省大量的時間。
AWS SageMaker Notebooks 與 Amazon SageMaker Studio 正式 GA
Amazon SageMaker Notebooks 替使用者省去以往要手動開一台機器(notebook instance)還要等待它 provision 完環境才可以使用的時間並整合於 SageMaker Studio 中,SageMaker Studio 則是一個整合式的機器學習開發環境,讓使用者可以在同一個環境中建置、訓練、部署和分析模型。
目前這兩個服務正式 GA,目前可於 US East(N. Virginia)、US East(Ohio)、US Wes(Oregon)和 EU(Ireland)使用。
AWS Transit Gateway Network Manager 新增 Route Analyzer 功能
AWS Transit Gateway Network 是一款監視、管理 Transit Gateway 的功能,降低了跨 AWS 區域和遠端位置管理網路操作複雜性,此次更新後,新增 Route Analyzer 功能,助於分析路由,可以透過即時流量,去測試路由配置、排除流量中斷的問題等,確保路由正常運作。
這個功能可以進行 2 個 Transit Gateway 在對等傳輸時的路由分析,以下圖為例,可以看到 Transit Gateway 1 可以連接到 2 個 VPC , Transit Gateway 2 可以利用 VPN 連線到地端網路。現在需要使用 Route Analyzer 確保 VPC 與地端網路能夠相互路由:
- 首先你需要設定
Source
來源,指定 Transit Gateway 1,從 VPC A 當中的 CIDR Block 選擇 IP 位址,例如:10.0.0.7
。 - 設定
Destination
目標地,指定 Transit Gateway 2,在地端網路範圍內指定 IP 位址,例如:172.31.0.8
。 - 選擇
Include return path in results
。 - 開始路由分析,下方圖片就是運行結果,你可以看到從 Transit Gateway 1 到 Transit Gateway 2 路徑,可以看到要返回的時候,發生中斷的狀況,這樣一來可以迅速發現問題,以便快速修正。
參考來源至:Announcing Route Analyzer in AWS Transit Gateway Network Manager
參考來源至:Route Analyzer official document
Amazon EventBridge Schema Registry 正式 GA
Amazon EventBridge 是一個無伺服器的服務,可以幫助使用者串連不同 AWS Account 或是在相同 AWS Organization 的 AWS Account 中的應用程式。不同帳戶的使用者可以將應用程式執行完所產生的 Event 存放在一個共享的 Registry,且在 EventBridge Schema Registry 的 Event,會使用可以直接引用在程式碼之中的格式來記錄,方便前後端應用程式彼此串接。
舉例來說,企業或組織在開發系統時,經常將系統功能的前後端邏輯交由不同的開發團隊執行,以提高效率。當前端程式執行完後(例如:接收到前端消費者的請求),會把接收到的資訊傳送到後端程式做判斷、處理(例如:資料的完整性、真實性),最後才呈現結果。
如果兩個開發團隊使用不同的 AWS Account 開發,AWS resource 是分割而無法互通,需要一個媒介來讓應用程式可以彼此溝通。使用 Amazon EventBridge Schema Registry 便可以作為情境中的媒介,順利的把 Event 的內容傳遞到另一個 Account 的程式中。
- 情境如下圖:CreatAccount 的前端程式收到創立帳戶的請求後,觸發 Lambda 判斷請求的內容,最後產生
ACCOUNT_CREATED
的 Event。此 Event 會放在 EventBridge Schema Registry 裡,提供給 FraudCheck 做後續FAKE_ACCOUNT
的查驗。 - CreatAccount 的前端程式及 FraudCheck 後端程式在不同的 AWS Account 開發。
情境參考自:AWS Blog: New – Amazon EventBridge Schema Registry is Now Generally Available
- 建立 Event bus 時,可選用共享的目標使用者。可直接指定 Account ID,也可以選擇 AWS Organization。
- 創建好之後,啟用 discovery 來發布 Event,之後後端程式就可以搜尋 Registry 裡的 Event。
而組織要如何管控誰可以推送 / 存取在同一個 Registry 的資料呢?EventBridge Schema Registry 支援 resource policies。在創建 EventBridge Schema Registry 後,管理者可以指定 IAM Policy 來控制使用的權限,確保只有專案內的人員才可以取用 Registry 內的 Event。
例如:運用 Principal
參數限制可取用的 AWS Account。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GiveSchemaAccess",
"Effect": "Allow",
"Action": [
"schemas:ListSchemas",
"schemas:SearchSchemas",
"schemas:DescribeSchema",
"schemas:DescribeCodeBinding",
"schemas:GetCodeBindingSource",
"schemas:PutCodeBinding"
],
"Principal": {
"AWS": "123412341234"
},
"Resource": [
"arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas",
"arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas*"
]
}
]
}
參考來源至:Amazon EventBridge schema registry is now generally available
二、其他服務更新
AWS RoboMaker 針對模擬任務新增帳號層級的 CloudWatch 指標
RoboMaker 讓使用者可以透過模擬環境來測試與部署機器人相關的應用程式,以往使用者可以從每個模擬任務的指標中監控此次模擬所消耗的資源與結果等。
此次新增了帳號層級的指標,會匯總所有個別模擬任務的指標數值,如此一來使用者便可以透過 CloudWatch Alarm 設置警報,例如:使用者希望某資源只要超出一定用量就通知使用者。
參考來源至:AWS RoboMaker now supports account-level metrics for simulation resources
快速搬遷 WAF Classic 規則至 AWS WAF
AWS WAF 為新版的 Web 應用程式防火牆,作為 WAF Classic 的替代品,在規則(rule)中新增支援「巢狀規則(nested rules)」、「布林邏輯表達式(Boolean combinations)」、「完整的 CIDR 表示法」等新設定,讓使用者能夠更細緻的定義防火牆的規則。
但 WAF Classic 中的規則是沒有辦法與新版 WAF 共用的,導致許多先前使用 WAF Classic 的使用者得自己在新版 WAF 重新建立規則,而此次更新後,可以透過搬遷精靈(migration wizard)功能快速的將 WAF Classic 的規則轉換成 Cloudformation template,讓使用者可以利用此 template 迅速部署新版 WAF 的規則。
參考來源至:AWS WAF now supports migration wizard for converting WAF rules from AWS WAF Classic
Amazon Transcribe Medical 支援客製化詞彙
Amazon Transcribe Medical 是一款將語音轉換成文字的服務,適合用在醫學、專業領域上,假設今天醫生在看診時,需要紀錄病患的症狀、用藥註記,利用 Amazon Transcribe Medical 可以加快紀錄速度,也讓病患的體驗更好,但是在醫學上面有許多專業名詞是較少見的,導致在記錄上可能有錯誤,此次更新後,新增客製化詞彙功能,新增專業名詞的發音及文字,提升轉換文字的準確度。
參考來源至:Amazon Transcribe Medical now supports custom vocabulary
AWS Storage Gateway – File Gateway 現在支援 S3 Intelligent-Tiering 作為儲存地點
運用 S3 Intelligent-Tiering 可幫助使用者自動將不常存取的檔案轉換至收費比較便宜的儲存空間,而當文件被頻繁存取時,在轉移到一般的儲存空間,以恢復原先支援的存取速度。
在此更新之前,當使用者利用 File Gateway 作為地端環境的 Shared File System,並把檔案存放在 AWS 上時,使用者如果想運用 S3 IA (S3 Infrequent access) 來做部分成本優化,需要自行評估檔案未來被存取的頻率,再透過 S3 Lifecycle policy 來轉移檔案的位置。過程不僅好時也費力,且容易產生錯誤評估的結果,導致資源無法做出最適合的配置。
現在,使用者可以設定 S3 Intelligent-Tiering 作為 File Gateway 的目的地,讓 S3 自動判斷檔案的存取頻率,並轉移儲存的地點。不僅幫助使用者節省成本,也不會影響到現行系統的運行狀況。
參考來源至:AWS Storage Gateway adds Amazon S3 Intelligent-Tiering for File Gateway
Amazon Translate 現在支援墨西哥西班牙語 (Mexican Spanish)
此次更新後,使用者可以運用 Amazon Translate 轉譯墨西哥西班牙語,獲得更良好的使用者體驗,而 Amazon Translate 現在支援的語言也來到了 55 個。
Amazon VPC flow logs 新增更多 metadata 可供紀錄
雲端安全性一直是許多使用者在運用雲端佈建資源時的考量點,因為透過網路連接雲端資源,容易增加系統受到網路攻擊的可能性,例如:接收到未知來源的請求時,應該拒絕存取還是允許進入?因此有些使用者會利用 VPC flow logs 來監控網路環境中流量的狀態。透過 VPC flow log 的紀錄,可知道 VPC 裡流量的起始點與終點的 Endpoint 及 Port,甚至是每個請求做了什麼動作。
VPC flow logs 的紀錄是以 Elastic Network Interface 為基準,VPC 裡具有 ENI 的機器都會被記錄到。
此次更新後,使用者可以在 VPC flow logs 得知 ENI 所在的位置,像是 Region、Availability Zone、Local Zone 等等,取得更多可供分析及追蹤的資訊。此外,現在所有的 VPC flow logs 都可以推送到 CloudWatch Log Group 或是 S3 存放。
參考來源至:Add enriched metadata to Amazon VPC flow logs published to CloudWatch Logs and S3
Amazon EC2 現在支援為 Amazon Machine Images (AMIs) 新增別名
Amazon Machine Images (AMIs) 是啟用一台 EC2 時,必須指定的一項元素。AMIs 會提供 EC2 啟用時所需的資訊,使用者選用不同的 AMIs 就可以啟用不同的 EC2。而使用者也經常針對自己特殊的需求(例如:希望 EC2 在創立過程中可以安裝好 Apache Web Server),可透過客製化 AMIs,以原先的 AMIs 為基底,產生符合自身需求的 AMIs。往後只要用自製的 AMIs 啟用 EC2,就可以省去每次啟用都要讓 EC2 執行安裝、設定腳本的時間。
而每次客製化 AMIs,都會產生一組獨有的 AMIs ID,以區別內容的不同。當使用者對 AMIs 更新(reversion)時,新版的 AMIs 會有新的 AMIs ID。如果使用者原先是利用預先寫好的腳本自動化創立 EC2,會導致使用者每一次更新 AMIs 都要去修改腳本內的 AMIs ID,才可以讓自動化腳本創立新版的 EC2。
此次更新後,使用者不需要再持續修改腳本內的 AMIs ID,透過設立別名(aliases),在創立新版 AMIs 時,指定別名,下次自動化腳本在創 EC2 時直接認別名來選用 AMIs 就可以創立新版 EC2,省去了修改腳本的過程。
- 範例:運用 AWS CLI 執行
run instance
的指令來啟用 EC2。
aws ec2 run-instances \
--image-id resolve:ssm:MyGoldenAMI \
--count 1 \
--instance-type c3.large \
--key-name MyKeyPair \
--security-groups MySecurityGroup
範例中的 ssm:MyGoldenAMI
是用來識別 AMIs 的別名,只要是相同用途、不同版本的 AMIs 都會指定相同的別名。別名可存放在 AWS System Manager 裡,並給予使用者取用 System Manager 資源的權限,就可以成功執行範例中的指令。
參考來源至:Amazon EC2 now supports aliases for Amazon Machine Images (AMIs)
AWS Systems Manager Explorer 現在可以將不同帳號的 Trusted Advisor checks 統整在同一個 dashboard
Trusted Advisor 是一個可提供即時建議的服務,針對不同面向,例如:資安、成本、效能、容錯力等等,建議使用者按照 AWS 最佳實務來佈建資源,以最佳化使用情景。
此次更新後,AWS Systems Manager Explorer 可以把不同帳號的 Trusted Advisor checks 統整在一起,幫助使用者得到整體的營運報告,進而監控、調查系統的狀態,最後可改善系統的效率、花費、可靠度及安全性。
參考來源至:AWS Systems Manager Explorer now provides a multi-account summary of Trusted Advisor checks
AWS Step Functions 工作流程新增 AWS CodeBuild 服務
AWS Step Functions 讓使用者在定義工作流程可以使用多種 AWS 服務(例如AWS Fargate、Amazon SNS,AWS Lambda),藉此直接呼叫並傳遞參數給這些服務的 API。工作流程主要由一系列步驟組成,如下圖當我們要處理 ETL 流程時,就可利用 Step Functions 進行建構,規範每一步驟要使用的服務與傳遞的參數。Step Functions 也有支援在發生錯誤時重試、平行處理等相關功能,讓使用者在開發時方便修改,並且可以追蹤每個步驟的狀態。
除了原先的服務,AWS Step Functions 現在支援使用 AWS CodeBuild 服務,這項更新使用者將可直接在 AWS Step Functions 中呼叫 AWS CodeBuild 服務相關 API,如 StartBuild
、StopBuild
等 API,利用這些 API 使用者可以自定義 CI/CD 的流程,像是自動化測試系統 API 等,如下圖。透過 Step Functions,藉由參數決定是否進行測試,然後在觸發 AWS CodeBuild 進行測試,當測試結果產生後再利用 SNS 寄送通知給使用者們。這次的更新將可以節省使用者在進行 CI/CD 所花費的時間並減少撰寫重複的程式碼,同時利用發生錯誤時重試、平行處理等功能建立更彈性的工作流程 。
參考來源至:AWS Step Functions now supports AWS CodeBuild service integration
參考來源至:Orchestrate multiple ETL jobs using AWS Step Functions and AWS Lambda
參考來源至:New – Building a Continuous Integration Workflow with Step Functions and AWS CodeBuild
Amazon CloudWatch 新增 Prometheus metrics
Prometheus 是一個第三方開源的專案,用於監控應用程式的狀態。過去使用者如果想觀看 Container 裡 Prometheus 監控的結果,需要連入個別的 Container 下指令查詢,一旦 Container 的數量提高,查詢就會成為一項耗時耗力的手續,最後導致管理上的不便。此次更新後,對於已習慣使用 Prometheus 作為監控應用程式工具的使用者,不再需要手動查找,而是透過安裝於 Container 的 AWS CloudWatch Agent 來收集 Prometheus metrics,並推送到 CloudWatch metrics,作為一個集中管理、呈現的平台。
目前 Prometheus metrics 僅支援 Amazon Elastic Kubernetes Service (EKS) 及 在 EC2 上的 Kubernetes clusters,預計未來也會支援 Amazon ECS 和 AWS Farget。
針對現有已運行在 Kubernetes 且支援 Prometheus 的 CloudWatch Agent,使用者須先刪除舊有的版本再安裝新版,才能成功將 Prometheus metrics 推送到 CloudWatch metrics。此外,CloudWatch Agent 利用一個 YAML 檔案來指定如何收集 Prometheus metrics,使用者若有客製化的需求,也可以更動此 YAML 檔案成自己所需的。更多安裝方式請參考 Amazon CloudWatch Doucmentation。
參考來源至:Amazon CloudWatch now monitors Prometheus metrics – Now in Beta
Tag:Amazon CloudWatch, Amazon EC2, Amazon Elasticsearch UltraWarm, Amazon EventBridge Schema Registry, Amazon Machine Images, Amazon SageMaker Studio, Amazon Transcribe Medical, Amazon Translate, Amazon VPC Flow Logs, AMIs, AWS CodeBuild, AWS IoT Core Fleet Provisioning, AWS RoboMaker, AWS SageMaker Notebooks, AWS Step Functions, AWS Storage Gateway - File Gateway, AWS Systems Manager Explorer, AWS Transit Gateway Network Manager, AWS WAF, CloudWatch, Dashboard, GA, Hot Data, IoT Core, log, Metadata, Mexican Spanish, Prometheus metrics, Route Analyzer, S3 Intelligent-Tiering, Trusted Advisor checks, WAF Classic