幹壞事是進步最大的原動力
AWS 的 ALB 宣佈支援 TLS 1.3：「Application Load Balancer now supports TLS 1.3」。
本來以為早就支援了，翻了一下發現應該是太多產品線的關係搞混了：
ALB 則是到了 2023 才支援 TLS 1.3...
看到「Mountpoint for Amazon S3」這個專案，AWS 自己推出了自己的 Amazon S3 FUSE 套件。Hacker News 上也有一些討論：「Mountpoint – file client for S3 written in Rust, from AWS (github.com/awslabs)」。
Amazon S3 的價錢比其他 AWS 提供的 storage 都便宜不少。以美東第一區 us-east-1 來說，S3 是 $0.023/GB，而 EBS (gp3) 要 $0.08/GB，即使是 EBS (st1) 也要 $0.045/GB。
S3 相較於 EBS 來說，多了 API call 的費用，所以對於不會產生大量 API call 的應用來說 (像是常常會寫很大包的資料到檔案裡)，透過 FUSE 操作 Amazon S3 可以讓現有的套裝軟體或是程式直接跑上去。
另外一個常見的應用是讓套裝軟體或是現成的程式可以讀取 S3 的資料。
之前這類應用馬上會想到的專案是 s3fs-fuse，這個專案很久了，大家也都知道多人寫入的部份會是痛點。
這次 AWS 自己出來做的事情有點重工，看起來他想做的事情 s3fs-fuse 都解的差不多了，目前看起來唯一的賣點應該只有 Rust-based，但 s3fs-fuse 主要是 C++，其實也沒差到哪裡：
Mountpoint for Amazon S3 is optimized for read-heavy workloads that need high throughput. It intentionally does not implement the full POSIX specification for file systems.
目前專案還是 alpha release，不確定專案的方向到底是什麼...
看到「Amazon DocumentDB (with MongoDB compatibility) adds support for MongoDB 5.0 wire protocol and client-side field level encryption」這篇，Amazon DocumentDB 推出了 MongoDB 5.0 的支援。
MongoDB 5.0 是 2021 年七月的版本，對使用者端比較重要的看起來是 PII 處理與 TSDB 的支援。
比較感興趣的是，TSDB 的部份是繼續用 PostgreSQL 魔改嗎...？
Amazon EC2 推出了 Graviton3 的機種：「New Graviton3-Based General Purpose (m7g) and Memory-Optimized (r7g) Amazon EC2 Instances」。
第一波只有一般的 在去年五月就推出了：「AWS 推出 c7g 機種」。m7g 與記憶體型的 r7g，而計算型的 c7g 大家在 Twitter 上猜應該晚點會放出消息。
目前只在歐美的 us-east-1、us-east-2、us-west-2 與 eu-west-1 區提供，亞洲目前都還沒有這些機種可以用：
M7g and R7g instances are available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland) AWS Regions in On-Demand, Spot, Reserved Instance, and Savings Plan form.
官方宣稱比 Graviton2 的 m6g & r6g 多了 25% 的效能，不過我另外查了一下 us-east-1 上的價錢，也貴了 6% 左右，如果依照官方宣稱的數字計算，大約是 18% 左右的 CP 值提昇，對於有實際上跑滿的 CPU 的人是個不錯的效能提昇：
Today I am happy to tell you about the newest Amazon EC2 instance types, the M7g and the R7g. Both types are powered by the latest generation AWS Graviton3 processors, and are designed to deliver up to 25% better performance than the equivalent sixth-generation (M6g and R6g) instances, making them the best performers in EC2.
裡面有提到在 Graviton3 的一個架構上的大改變是記憶體從 DDR4 變到 DDR5，這使得記憶體的傳輸頻寬提昇了 50%：
Both types of instances are equipped with DDR5 memory, which provides up to 50% higher memory bandwidth than the DDR4 memory used in previous generations.
接下來是看有沒有下放到 t 系列的計畫，像是 t5g 之類的，有的話再用看看好了，不過 blog 這台已經買了三年 RI，等到期間滿了之後說不定都有 Graviton4 或是 Graviton5 了...
這次 re:Invent 關於 Amazon EFS 推出來的新東西，目前有看到兩個，第一個是「New – Announcing Amazon EFS Elastic Throughput」，介紹 Elastic Throughput。
傳統的 Busrting Throughput 模式會依照你的使用空間分配對應的速度，基礎是 50MB/sec per TB 計算，但可以 burst 到 100MB/sec per TB：
When burst credits are available, a file system can drive throughput up to 100 MiBps per TiB of storage, up to the Amazon EFS Region's limit, with a minimum of 100 MiBps. If no burst credits are available, a file system can drive up to 50 MiBps per TiB of storage, with a minimum of 1 MiBps.
而 Elastic Throughput 是一種高效能的模式，可以提供 3GB/sec 的讀取速度與 1GB/sec 的寫入速度：
Elastic Throughput allows you to drive throughput up to a limit of 3 GiB/s for read operations and 1 GiB/s for write operations per file system in all Regions.
但這然是有代價的，Elastic Throughput 的計費方式按照傳輸量計算，以 us-east-1 的計價來說，讀取是 $0.03/GB，寫入是 $0.06/GB。
粗粗算了一下，比較適合短時間要很大量快速讀寫的應用。如果是不在意時間的 (像是 cron job) 就不需要 Elastic Throughput... 然後 home 目錄拿來用可能是個不錯的選擇？
第二個推出的項目是不用錢的，是 Amazon EFS 效能的改進，降低 latency：「AWS announces lower latencies for Amazon Elastic File System」。
首先是讀取的效能提昇，以敘述看起來像是加上了 cache 層產生的效能改進：
Amazon EFS now delivers up to 60% lower read operation latencies when working with frequently-accessed data and metadata.
另外是對小檔寫入有做處理：
In addition, EFS now delivers up to 40% lower write operation latencies when working with small files (<64 KB) and metadata.
不過這些改進只有在新的 EFS 才會有，而且這波只有 us-east-1 上：
These enhancements are available automatically for all new EFS file systems using General Purpose mode in the US East (N. Virginia) Region, and will become available in the remaining AWS commercial regions over the coming weeks.
今年 AWS 的 re:Invent 又開始了，這一個禮拜會冒出蠻多新功能的，挑自己覺得比較有興趣得來寫。
AWS 針對 Lambda 推出 Lambda SnapStart，改善冷啟動的速度：「New – Accelerate Your Lambda Functions with Lambda SnapStart」。
他拿了一個比較明顯的例子，Java 的 Spring Boot，範例在「Serverless Spring Boot 2 example」這邊，冷啟動的速度可以從 6 秒降到 200ms：
SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.
方法就是把 initialization 的程式完成後的記憶體打一份 snapshot 存起來，之後的冷啟動第一動變成是 restore 而非再 initialize：
With SnapStart, the initialization phase (represented by the Init duration that I showed you earlier) happens when I publish a new version of the function. When I invoke a function that has SnapStart enabled, Lambda restores the snapshot (represented by the Restore duration) before invoking the function handler. As a result, the total cold invoke with SnapStart is now Restore duration + Duration.
不過不是所有的應用程式都可以直接套用，有些要注意的地方，比較好理解的是連線 (像是對後端資料庫的預連線) 以及暫存檔的部份 (像是預先算好某些資料後寫到暫存檔) 都需要重新建立。
比較特別的是亂數產生器需要重新 initialize，不然會有機率產生出一樣的 random data，這個是一般開發者會忽略掉的：
When using SnapStart, any unique content that used to be generated during the initialization must now be generated after initialization in order to maintain uniqueness.
所以 AWS 有針對 SnapStart 下的 OpenSSL 修正，另外外他們也確認過 Java 的 java.security.SecureRandom 本身就沒問題：
We have updated OpenSSL’s RAND_Bytes to ensure randomness when used in conjunction with SnapStart, and we have verified that java.security.SecureRandom is already snap-resilient.
另外 AWS 也推薦可以直接讀系統的 /dev/random 或是 /dev/urandom，這樣就很自然的不會因為 snapshot 而固定，當然也就沒問題：
Amazon Linux’s /dev/random and /dev/urandom are also snap-resilient.
這個功能說不用另外收費，看起來對 Java 族群還不錯？
看到 CloudFront 宣佈支援帶入 JA3 資訊了：「Amazon CloudFront now supports JA3 fingerprint headers」：
Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.
JA3 的頁面上可以看到說明，針對 SSL/TLS 這個複雜的 handshake 過程中，就可以從中得知不同的 client 實做，比起容易偽造的 User-agent 有效：
JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.
像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測：
JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865
先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。
AWS IAM 總算可以掛多個 MFA 到同一個帳號下了：「You can now assign multiple MFA devices in IAM」。
先前的 workaround 是開多個一樣權限的帳號，一個帳號掛 TOTP MFA，另外的每個帳號掛一隻 U2F MFA，但偶而會遇到會認 IAM account 的權限檢查，就會比較麻煩...
先說明一下，目前這個功能看起來還在 rolling update (也有可能是 bug？)，我的公司帳號就成功把本來只有 TOTP MFA 的加掛 U2F MFA 上去，但我自己的 AWS 帳號就怎麼樣都看不到這個新功能。
這是加好的：
這是我自己的 AWS 帳號，沒有像上面那樣可以管理多個 MFA，而點開 Manage 也只會看到移除的選項：
到另外一個掛 U2F MFA 的帳號下一樣也看不到：
另外我在刪除 IAM 帳號時也發現會有無法刪除 MFA 設定的錯誤訊息 (但點進去看 IAM user 可以確認 MFA 已經背山掉了)，這時候再刪一次就會成功，看起來 console bug 還不少... 也許再放個兩天看看？
前幾天才寫了 AWS 開了中歐的瑞士 (在「AWS 加開中歐區 (瑞士，蘇黎世)」這邊)，剛剛看到開了西班牙：「Now Open–AWS Region in Spain」。
注意到代碼不是掛在西歐 (eu-west)，而是南歐 (eu-south)，然後「Regions and Zones」這頁居然還沒更新...
另外機種比瑞士的豐富一些，像是 t4g 與 r6g 這些 ARM 的機種。
歐洲的機房突然變好多，反倒是美洲暫時沒有新的大消息... (大家都愛 us-east-1 的關係？)
AWS 在瑞士蘇黎世開了新的區域，代碼 eu-central-2：「A New AWS Region Opens in Switzerland」，其中代碼 eu-central-1 是德國，這次的歐洲中不稍微往南邊一點開。
I am pleased to announce today the opening of our 28th AWS Region: Europe (Zurich), also known by its API name: eu-central-2.
歐洲的 region 愈來愈多了，但可以看出來東歐一直還沒有點，不過以目前戰火的情況看起來應該不會太快...