【每周快報】1022-1028 AWS 服務更新
前言
這周 AWS 在應用程式整合上推出了些新支援以及新服務。像是 Amazon SNS 為了確保資料的發送有依照事件的先後順序,推出資料不重複且能確保排序的 First-in-First-out Topics,這項新服務可以改善許多產業的訊息發送問題,像是銀行交易紀錄或是、車次追蹤等先後順序問題的訊息。另一項服務則是 AWS Step Functions 支援與 Amazon Athena 整合,現在使用者可以在 Step Function workflow 加入 query S3 資料湖的步驟,來作為檢查或是查詢的程序。
除了應用程式整合的部分,AWS 在機器學習、容器服務…等各領域也都有推出些服務改動,這周我們會向大家介紹 Amazon CloudFront、Amazon Redshift、AWS Fargate、Amazon SageMaker…等服務的改善,我們也會分享這些服務更新的應用及場景!
焦點新聞
Amazon SNS 推出資料不重複且能確保排序的 First-in-First-out (FIFO) Topics
Amazon SNS 是一項全託管的發布 / 訂閱 (pub/sub) 消息的服務,訂閱了同一個 Topic 的 Subscribers,皆可收到任何 Publishers 傳送到該 Topic 的資訊。
此次更新後,Amazon SNS 在 First-In-First-Out (FIFO) Topic 中增加了排序以及刪除重複資訊的功能,對於注重訊息先後順序的 workload,SNS FIFO Topic 是一項實用的 Solution。
此外,使用者可以將 Amazon SNS FIFO Topic 與 Amazon SQS 結合使用,用來部署一個需要按照順序處理,且資訊不可重複的應用程式。例如:銀行交易紀錄、股票現值紀錄系統、航班追蹤等等。另外,不管是 SNS Standard Topic 或是 FIFO Topic 都支援將 Messages 傳遞到多個 Subscribers 的功能。
參考來源至:Amazon SNS introduces First-in-First-out (FIFO) topics with strict ordering and deduplication of messages
參考來源至:https://aws.amazon.com/tw/blogs/aws/introducing-amazon-sns-fifo-first-in-first-out-pub-sub-messaging/
Amazon SNS 支援指定發送方的電話號碼
當人們接收到一個簡訊時,往往會查看發送簡訊的來源是哪一個電話號碼,若是來路不明的號碼,可能會認為是垃圾簡訊或是釣魚簡訊等等惡意簡訊。現在 Amazon SNS 推出「指定發送簡訊的號碼」的功能,幫助解決上述的隱憂。
此次更新後,當使用 Amazon SNS 向 Subscribers 發送簡訊時,可以指定 Subscribers 收到該簡訊的來源為客製指定的電話號碼,例如:使用者向當地電信局所申請的短號碼或長號碼。對於接收者而言,每次 SNS 所傳送的簡訊皆來自固定的電話號碼,且為合法號碼,讓使用者與接收者之間有更良好的信任關係。
除此之外,使用者也可以管理電話號碼發送簡訊的目的地,藉以來分類每個號碼的用途及限制乘載量,例如:特定短號碼所發的簡訊,皆是發送至同一國家、同一城市的用戶;不同的號碼平均每日以發送 200 則訊息為上限,以符合當地電信公司的收費標準。
參考來源至:Amazon SNS now supports selecting the origination number when sending SMS messages
Amazon CloudFront 支援以 IAM User 管理 Signature 金鑰
針對敏感、隱蔽性要求較高檔案,為了不讓使用者可以任意存取,在網站結構上常經由認證授權去驗證使用者身份,再以 Signed URLs 或 Signed cookies 的方式,對特定使用者限制存取的權限。在 CloudFront 上可以透過 CloudFront 金鑰產生 Signer 去做加簽 URL 或是 cookie,讓使用者在有效期限內針對這些隱密內容做存取。
以往 CloudFront 金鑰僅能透過 Root Account 去管理,不管是要新增、刪除或是要置換,都需要在 Root Account 權限下做操作。且若要做自動置換該金鑰的話,意味著需要以 Root Account AccessKey 的方式派發權限才能執行,這是非常不方便且安全性較低的方法。
此次更新後,可以透過 IAM User 去管理 CloudFront 金鑰,且可透過 IAM Policy 去管控使用者可以針對哪幾把金鑰、哪幾個金鑰群組做什麼操作,如以下範例。
管理員可以透過open-ssl
產生一組金鑰對,含有 public key & private key,並以 IAM User 身份從 CloudFront Console 中,選擇 Public Key 創建公鑰,並輸入名稱及公鑰資訊:
如果要拿金鑰做 Signature,必須將這把金鑰加進去 Key Group 裡:
接著在 CloudFront Distribution 針對不同的 Behavior ,可以選擇要使用哪一個 Key Group:
Trusted Signer 為透過 Root Account 產生的 CloudFront 金鑰
接著如以往,透過 AWS.CloudFront.Signer 產生 Signed URL 或 Signed cookie,並提供給使用者來存取。當 CloudFront 收到 Client Request 時,該 Request 會夾帶著 Signature,如此一來 CloudFront 即可加以驗證此 Request 是否為有效。
管理員在 CloudFront 金鑰管理上可以透過 IAM 層級實現、且透過 IAM 管理,進而取代使用 Root Account 身份,大幅地降低安全性隱憂。
其他服務更新
AWS Step Functions 支援與 Amazon Athena 整合
使用者可透過 AWS Step Function wrokflow 串接不同的 AWS 服務,作為自動化的觸發程序,Step Function 已經支援使用者能夠在 wrokflow 加入 AWS Lambda、AWS Glue 及 Amazon SNS 服務。
此次更新後,新增支援了 Athena 加入流程。如果使用者利用 S3 Bucket 當作存放資料的資料湖,Athena 可幫助使用者在 Step Function workflow 加入 query S3 資料湖的步驟,作為檢查或是查詢的程序。
參考來源至:AWS Step Functions now supports Amazon Athena service integration
Amazon Elasticsearch Service 中 Kibana 支援以 SAML 做身份驗證
Amazon Elasticsearch Service 是一個可以進行即時搜尋、分析及可視化數據的服務,其安全性為 Elasticsearch 管理者即為在乎的事情。近年來功能不斷地在優化,先前出了 Fine–grained access control,企業可以依據使用性質,利用 Role 去設定權限為何,可以設定哪些使用者可以看到數據、更改資料⋯等等,且可以透過 Amazon Cognito 做身份驗證,在權限控管方面更加地嚴謹。
此次更新增加了 SAML 驗證,使用者可以利用以 Okta,Ping,OneLogin,Auth,Active Directory 和 Azure Active Directory 等方式與第三方做 SSO 登入 Kibana 和 ElasticSearch,提供管理者以單一授權模組管理其登入權限。
參考來源至:Amazon Elasticsearch Service adds native SAML Authentication for Kibana
AWS CloudFormation 提高五項 Service Quotas Limits
此次更新後,AWS CloudFormation 提高了 CloudFormation Template 大小限制,以及每個 Template 中的 resources、parameters、mappings 及 outputs 數量的上限。詳細調整如下列所述:
- CloudFormation Template 大小:存放在 S3 Bucket 的 Template 大小,最高可達 1MB
- 每個 Template 中:
- Resources:從 200 項提高至最多 500 項
- Parameters:最多至 200 項
- Mappings:最多至 200 項
- Outputs:最多至 200 項
調整 Limit 後,可讓使用者僅使用單一個 Template 部署較大型的 Application,同時透過調高 Parameters 及 Mappings 的數量,也可以讓 Template 重複使用的彈性增高,而提高 Outputs 數量則是可以幫助使用者在部署過後,快速找到與 Resource 相關的資訊。
參考來源至:AWS CloudFormation now supports increased limits on five service quotas
Amazon Redshift 支援 SQL Query 排程
當企業管理及使用資料庫時,需要定期執行某些任務以維持最佳性能或達到業務目的,像這些工作它們本質上是重複性的,一般會透過排程服務如 cron 或 Task Scheduler…等方式實現自動化流程。
此次更新後,Amazon Redshift SQL Query 可以透過 Amazon EventBridge 做日常排程來觸發;藉以取代手動配置的過程,除了節省人力及時間,同時也能降低出錯率。
參考來源至:Amazon Redshift now supports the scheduling of SQL queries by integrating with Amazon EventBridge
AWS Fargate Spot 可透過 CloudFormation 部署
Fargate 讓管理者不需要去預測、調配、Scale 或是管理 EC2 資源,只需要宣告該 Container 要多少運算資源,在 Container 服務跑起來的時候,AWS 便會自動配給給該 Container 使用。今年 AWS 更推出新的計費模式 — Fargate spot,相較於 Fargate 價格,Fargate spot 來得便宜許多,對大量使用 Container 的使用者為一大福音。
此次更新後,AWS CloudFormation 加入 Fargate 與 Fargate Spot 的資源做自動化構建及部署,且能透過 Capacity Providers 去調整兩者比例,以助使用者在打包、宣告或是部署 CloudFormation Template,便能加入 Fargate 作為 Container 運算資源使用。
參考來源至:AWS Fargate Spot for Amazon ECS is now supported in AWS CloudFormation
Amazon SageMaker Studio Notebooks 支援客製 Image
Amazon SageMaker Studio 是一個用於機器學習的開發環境(IDE),數據科學家和開發人員可以透過內建的 Image 啟用 SageMaker Studio Notebook,內建的 Image 包含了 Amazon SageMaker Python SDK 以利運算構建 Model。
此次更新後,使用者可以透過自己的 Image 啟動 SageMaker Studio Notebook,像是 echo_kernel、TensorFlow Image 等等,帶來更大的彈性部署開發環境。
參考來源至:Amazon SageMaker Studio Notebooks now support custom images
Amazon Textract 提升 API 回覆速度 – API 處理時間降低 20%
Amazon Textract 可幫助使用者自動偵測檔案中的文字和數據,其偵測的檔案類型包括文字檔、圖像中的表格及表格中數據。使用者可透過呼叫 Textract DetectDocumentText 和 AnalyzeDocument API 來進行審查檔案中是否存在不雅字眼、敏感性資料等等的文件審核工作。
此次更新後,Textract 降低了 DetectDocumentText 和 AnalyzeDocument API 大約 20% 的處理時間,優化服務的表現。
參考來源至:Amazon Textract announces improvements to reduce average API processing times by up to 20%
Tag:Amazon Athena, Amazon CloudFront, Amazon Elasticsearch Service, Amazon Redshift, Amazon SageMaker Studio Notebooks, Amazon SNS, Amazon SQS, Amazon Textract, API, AWS CloudFormation, AWS Fargate Spot, AWS Step Functions, Behavior, Capacity Providers, CloudFormation, Fargate Spot, FIFO, Fine–grained access control, First-In-First-Out, IAM User, Image, Key Group, Kibana, Public Key, SAML, Service Quotas Limits, Signature, SQL Query