幹壞事是進步最大的原動力
看到「HashiCorp Vault 1.0」這則消息，Vault 要出 1.0 不是什麼新聞，重點是他把跟 Cloud Auto Unseal 的功能放出來了：
In Vault 1.0, we are open sourcing Cloud Auto Unseal, allowing for all users of Vault to leverage cloud services such as AWS KMS, Azure Key Vault, and GCP CKMS to manage the unseal process for Vault.
可以看在 AWS 上的作法：「Auto-unseal using AWS KMS」。
這樣在雲上的服務可以再降低風險...
DynamoDB 用起來比較困難的部份就是規劃 R/W capacity，所以 AWS 就推出了 DynamoDB On-Demand，直接計算用多少而不用規劃 R/W capacity：「Amazon DynamoDB On-Demand – No Capacity Planning and Pay-Per-Request Pricing」。
先講一下歷史，在 2014 的時候 Jeff Barr 就有在「Auto Scale DynamoDB With Dynamic DynamoDB」這邊提到開一台 t1.micro 在上面跑程式實做 DynamoDB 的 auto scaling。
另外在 2017 年的時候 AWS 自己推出了同樣的功能，就不需要開機器了，交給 AWS 的服務處理就可以了：「New – Auto Scaling for Amazon DynamoDB」。
所以就一般性的需求來說，其實目前的方案夠用：常態性的需求提昇，以及有預期性的活動時可以手動事前提昇。
目前想到唯一會炸掉的情境應該是突然被熱門媒體報導，而導致大量的 guest session 衝進來，而且架構上又沒有針對 guest session 用 cache 擋住 (Amazon DynamoDB Accelerator 也是個選項)，導致壓力就全部到後端的 DynamoDB，而 auto scaling 機制需要時間看到量才會調整，在這段時間就有可能短時間倒站。
回來看這次的 On-Demand 提出來的價錢。以 us-east-1 的價錢來看：
Write request units $1.25 per million write request units Read request units $0.25 per million read request units
而本來要自己規劃 R/W capacity 的價錢是 (這邊是 hourly)：
Write capacity unit (WCU) $0.00065 per WCU Read capacity unit (RCU) $0.00013 per RCU
由於不管是 On-Demand 還是本來的規劃，Read 價錢都是 Write 的 1/5，所以只要看 Write 一樣可以知道差距。
接下來把 On-Demand 的價錢換算成 3600 個 request units 就可以比較單價，是 $0.0045 (Write)，大約是本來版本 6.92 倍的費用...
而且對於已經有規模的應用，這邊還沒算 Reserved Capacity 會有折扣的部份？
這個定價策略讓我想到 AWS Fargate 的情況... 如果你可以接受這個價錢，你可以平常就開五倍的 R/W capacity 在上面啊 XDDD
AWS 在 EC2 上推出了用 machine learning 協助 auto scaling 控制的功能：「New – Predictive Scaling for EC2, Powered by Machine Learning」。
最少給他一天的資料 (然後他會每天重新分析一次)，接著會預測接下來的 48 小時的使用行為：
The model needs at least one day’s of historical data to start making predictions; it is re-evaluated every 24 hours to create a forecast for the next 48 hours.
所以是個學 pattern 然後預先開好機制等著的概念...
透過預測增加服務穩定性的概念... 如果本來就跑得好好的 (也就是靠 resource-based metric 觸發機器數量的方式跑得很好)，就未必需要考慮這個方案了。
目前支援的區域中，東京不在列表內，不過其他常見的區域都支援了：
Predictive scaling is available now and you can starting using it today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore) Regions.
AWS 宣佈能 auto-scale 的 Aurora Serverless MySQL 進入 GA：「Aurora Serverless MySQL Generally Available」：
不過目前開放的區域有限：
Aurora Serverless for Aurora MySQL is available now in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland).
以秒計費，但低消是 5 分鐘：
You pay a flat rate per second of ACU usage, with a minimum of 5 minutes of usage each time the database is activated.
以 us-east-1 的價錢來看，每個 ACU 是 USD$0.06/hour，而每個 ACU 大約是 standard instance 的價錢：
1 ACU has approximately 2 GB of memory with corresponding CPU and networking, similar to what is used in Aurora Standard instances.
但這沒看懂，是 db.t2.small 還是 db.t2.medium？另外比較是全速還是 small 的 20% 或 medium 的 40%？這部份也許還要再問看看才知道...
storage 與 I/O 的費用則是相同，倒是不用比較這塊... 再來不知道有沒有推出 Reserved ACU 的計畫，光是一年付清就差蠻多的。
要不要換過去其實還是要看看使用的量，以及可以接受的成本來決定...
所以除了一般的 EC2 instance 可以設定 Auto Recovery 外，實體機的 Dedicated Instance 也可以設定了：「Amazon EC2 Auto Recovery is now available for Dedicated Instances」。
不過能用架構做 High Availability 還是用架構做會比較好 (像是透過 ELB 擋在前面提供服務)，Auto Recovery 因為是透過 CloudWatch 偵測 (目前最短的偵測時間應該是 10 秒一次)，再加上要等新機器接手，還是會有明顯的 downtime。
這個功能在 ELB Classic 年代時有跟 AWS 提過，到 ALB 支援了 (總算...)：「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。
Application Load Balancers now support a slow start mode that allows you to add new targets without overwhelming them with a flood of requests. With the slow start mode, targets warm up before accepting their fair share of requests based on a ramp-up period that you specify.
然後時間可以設定，從 30 秒到 15 分鐘：
Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.
就之前的經驗來說，這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣，可能不會這麼吃這個功能。
主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時，儘量將 CPU 留給 opcache，把常用的頁面 compile 完並且放進 cache，而不是讓大量的連線灌進來，這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久，造成每個連線都很慢才跑完)
AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...
HTTPS Everywhere 是我很喜歡的一個套件，裡面有 Ruleset，會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS，這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況，以及網站本身有支援 HTTPS 但沒有設定 HSTS 時，在網址列上誤打 HTTP 版本的情況。
先前版本的 Ruleset 是隨著軟體更新時，包在軟體內一起更新。這樣的缺點是更新速度比較慢，但好處是不需要伺服器端，而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本，以加速 Ruleset 更新的速度：「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。
We've modified the extension to periodically check in with EFF to see if a new list is available.
而頻寬的部份由 Fastly 贊助：
If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!
如果對這點有疑慮的，也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。
AWS 宣佈了 Amazon ECS 也支援 Route 53 提供的 Service Discovery 了：「Introducing Service Discovery for Amazon ECS」。
也就是說現在都整合好了... 比較一下先前需要自己包裝起來套用的方式會少不少功夫：
Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system or connect every service to a load balancer. Now, you can enable service discovery for your containerized services with a simple selection in the ECS console, AWS CLI, or using the ECS API.
AWS 在 2016 年的時候有寫一篇「Service Discovery for Amazon ECS Using DNS」在講怎麼透過事件的觸發配合 AWS Lambda 把服務掛上去或是移除掉：
Recently, we proposed a reference architecture for ELB-based service discovery that uses Amazon CloudWatch Events and AWS Lambda to register the service in Amazon Route 53 and uses Elastic Load Balancing functionality to perform health checks and manage request routing. An ELB-based service discovery solution works well for most services, but some services do not need a load balancer.
現在看起來都可以改用 Auto Naming API 了...
Amazon Route 53 的 Auto Naming API 可以拿來跑 Service Discovery (參考先前的「用 Amazon Route 53 做 Service Discovery」這篇)，當時是 A/AAAA/SRV record，現在則可以註冊 CNAME 了：「Amazon Route 53 Auto Naming Announces Support for CNAME Record Type and Alias to ELB」。
最直接的影響就是 ELB 的部份了，透過 ELB 處理前端的話，覆載平衡以及數量限制的問題就會減輕很多 (之前是靠 Round-robin DNS 打散，而且限制一次最多回應五個 record)：
Beginning today, you can use the Amazon Route 53 Auto Naming APIs to create CNAME records when you register instances of your microservices, and your microservices can discover the CNAMEs by querying DNS for the service name. Additionally, you can use the Amazon Route 53 Auto Naming APIs to create Route 53 alias records that route traffic to Amazon Elastic Load Balancers (ELBs).
Fortnite 遊戲的伺服器放在 AWS 上，看起來這波 Meltdown 的安全更新 (KPTI) 造成非常大的 overhead：
不過看起來出了問題：
We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates.
最有可能的是把 AWS 當作一般的 VPS 在用，另外一種可能是有部份內部服務沒有 scale，造成上了 KPTI 後 overhead 增加，就卡住了...