AWS 這次在 CloudWatch 上推出了新功能,可以直接透過機器學習的演算法,對 CloudWatch 所記錄的值提供異常偵測 (anomaly detection) 的能力:「New – Amazon CloudWatch Anomaly Detection」,對應的文件則可以在「Using CloudWatch Anomaly Detection」這邊讀到。
這個功能可以抓一個預期的區間出來,然後針對超出區間時發出警報:
這邊感覺把以前很多工作自動化掉了,省了很多事情...
幹壞事是進步最大的原動力
AWS 這次在 CloudWatch 上推出了新功能,可以直接透過機器學習的演算法,對 CloudWatch 所記錄的值提供異常偵測 (anomaly detection) 的能力:「New – Amazon CloudWatch Anomaly Detection」,對應的文件則可以在「Using CloudWatch Anomaly Detection」這邊讀到。
這個功能可以抓一個預期的區間出來,然後針對超出區間時發出警報:
這邊感覺把以前很多工作自動化掉了,省了很多事情...
Amazon SES 的新功能,讓使用者可以設定 policy,以確保 mail reputation 不會掉的太差:「Amazon SES introduces email pausing and reputation metrics for configuration sets」,介紹的文章在「Protect your Reputation with Email Pausing and Configuration Set Reputation Metrics」。
所以你可以設定某些條件,停用某個 configuration set,或是停用整個帳號:
This release includes API operations that allow you to temporarily pause email sending for a specific configuration set, or across your entire Amazon SES account. You can use this feature to automatically pause email sending when your reputation metrics cross certain thresholds that you define.
這應該是在一個帳號有多個服務使用的情境下,用來降低風險的方式... 某個服務突然送出一堆 bounce mail 時可以只停用有問題的服務,而不是被 Amazon SES 整包停用。
另外因為經過 Amazon CloudWatch,所以可以串上 Amazon SNS 後將 AWS Lambda 接上去做更複雜的處理:
AWS CloudWatch 推出了秒級的記錄功能:「New – High-Resolution Custom Metrics and Alarms for Amazon CloudWatch」。
從一分鐘變成一秒鐘讓之後的調整以及 debug 好用很多... 不過這次支援秒級的是 custom metrics,原先 AWS 自家服務的支援不在這次範圍:
Today we are adding support for high-resolution custom metrics, with plans to add support for AWS services over time. Your applications can now publish metrics to CloudWatch with 1-second resolution.
另外 alarm 的時間可以降到十秒:
You can watch the metrics scroll across your screen seconds after they are published and you can set up high-resolution CloudWatch Alarms that evaluate as frequently as every 10 seconds.
對於市場上一堆服務的衝擊應該不小 XD
AWS 宣佈把 gp2 的 I/O burst credit 數字給量化了:「New – Burst Balance Metric for EC2’s General Purpose SSD (gp2) Volumes」。
gp2 最小的也可以衝到 3000 IOPS,另外可以累積 5.4M credits:
Each volume can accumulate up to 5.4 million credits, and they can be spent at up to 3,000 per second per volume.
算了一下,1GB 的空間一個小時可以累積 10,800 IOPS,如果切 10GB 的系統碟,大約 50 個小時就會滿。如果 100GB 的話就是 5 個小時了,其實對於真的超級大量持續 I/O 的應用還是要考慮用 Provisioned IOPS SSD (io1)。
不過明顯的好處是可以建立 alarm,當機器的 burst I/O credit 快用完的時候可以叫一叫,這樣讓人可以評估下一步:
另外也可以藉由這個數字來評估是要加大空間以換取 IOPS,或是換到有保障的 Provisioned IOPS SSD (io1)。