幹壞事是進步最大的原動力
所以除了一般的 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 增加，就卡住了...
Amazon Route 53 的新功能，可以解決以前自己要建立 Service Discovery 服務的工作：「Amazon Route 53 Releases Auto Naming API for Service Name Management and Discovery」。官方的文件在「Using Autonaming for Service Discovery」這邊。
不過目前有些限制，一個 namespace (domain name) 目前只能有五個服務：
DNS settings for up to five records.
然後 DNS 回應時，最多回八個 record：
When Amazon Route 53 receives a DNS query for the name of an instance, such as backend.example.com, it responds with up to eight IP addresses (for A or AAAA records) or up to eight SRV record values.
回應八個 record，但應該是可以註冊超過八個吧... (i.e. 每次都回不一樣)
自建服務 (像是 Cassandra 或是 ScyllaDB) 可以直接用這個服務掛上去，就不用自己架 Consul 了。
目前支援了這四區，亞洲不在這波提供範圍：
Amazon Route 53 Auto Naming is available in US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) regions.
Amazon Aurora 推出了兩包玩意，第一包是 Serverless，讓需要人介入的情況更少：「In The Works – Amazon Aurora Serverless」。
在 Serverless 的第一個重點是支援以秒計費：
Today we are launching a preview (sign up now) of Amazon Aurora Serverless. Designed for workloads that are highly variable and subject to rapid change, this new configuration allows you to pay for the database resources you use, on a second-by-second basis.
然後是極為快速的 auto-scaling：
The endpoint is a simple proxy that routes your queries to a rapidly scaled fleet of database resources. This allows your connections to remain intact even as scaling operations take place behind the scenes. Scaling is rapid, with new resources coming online within 5 seconds
這兩個組合起來，讓使用端可以除了在 Amazon EC2 上可以快速 scale 外，後端的資料庫也能 scale 了...
第二個是 Multi-master 架構：「Sign Up for the Preview of Amazon Aurora Multi-Master」。
Amazon Aurora Multi-Master allows you to create multiple read/write master instances across multiple Availability Zones. This enables applications to read and write data to multiple database instances in a cluster, just as you can read across Read Replicas today.
(話說我一直都誤以為 Aurora 是 R/W master...)
Anyway，這個功能不知道怎麼疊上去的... 不笑得會不會有嚴重的 distributed lock issue，反而推薦大家平常都寫到同一台 (像是 PXC 就會這樣)。
DynamoDB 可以透過 console 或是 API 調整 R/W 的 capacity，但一直都沒有全自動的機制這件事情為人詬病頗久。
以前都是自己用 AWS Lambda 或是其他架構判斷調整，現在官方直接提供了：「New – Auto Scaling for Amazon DynamoDB」。
終於啊...
anttiviljami/browser-autofill-phishing 這邊示範了怎麼用隱藏的 form input 與自動完成功能取得敏感資料。在這邊可以看到示範 (把 POST 丟到 httpbin 上看 response)。
想法不算困難，但好像也不是很好防... 關掉 autofill 是比較簡單的解法 (我是裝好瀏覽器就會關掉，不過好像很多人都喜歡用這個功能)，所以這個問題就丟回給這些 browser vendor 想了 :o