Tag: service

AWS KMS 支援 ECDH

看到「Announcing AWS KMS Elliptic Curve Diffie-Hellman (ECDH) support」這篇的介紹，AWS KMS 支援 ECDH 了。

從 AWS 的文件「DeriveSharedSecret」這邊可以看到就是在不將 private key 暴露出來的情況下得到 ECDH 產生的 shared secret：

The private key in your KMS key pair never leaves AWS KMS unencrypted. DeriveSharedSecret returns the raw shared secret.

翻了一下其他兩個雲的 Cloud HSM 類服務，好像沒有看到 ECDH 的，不過如果是實際硬體 HSM 的話，Azure Dedicated HSM 似乎有支援，可以在 FAQ 這邊看到：

Dedicated HSM service provisions Thales Luna 7 HSM appliances.

Cryptography (ECDSA, ECDH, Ed25519, ECIES) with named, user-defined, and Brainpool curves, KCDSA

AWS KMS 畢竟是軟體基底的，要支援什麼演算法可以直接加...

AWS 的 VPC 可以設定 Private IPv6 address 了

AWS 的 VPC 以前都只能設定 public IPv6 address，現在總算是可以設定 private IPv6 address 了：「AWS announces private IPv6 addressing for VPCs and subnets」，另外一篇講的比較詳細：「Understanding IPv6 addressing on AWS and designing a scalable addressing plan」。

IPv6 address 的熟悉度沒有 IPv4 address 高... 看起來 AWS 所提到的 private 包括了 GUA 與 ULA：

Private IPv6 addresses on AWS can include ULA, which are intended for local communication, and private GUA, which could be globally routable according to protocol definition.

GUA 好像是就是拿 public ip 區段用 (反正 IPv6 區段夠大)？反而是 ULA 這邊用的 fd00::/8 跟以前 IPv4 的 private range 剛好相對應，比較好理解...

Meta 的 Llama 3.1

Meta 發佈了 Llama 3.1：「Introducing Llama 3.1: Our most capable models to date」，這本來就只是個發佈而已，但讓我注意到的是 AWS 與 GCP 都同時宣佈在雲端上支援 Llama 3.1 了：

這代表 Meta 在 Llama 3.1 發表前就先跟 AWS & GCP 合作了，這看起來是一個包圍 OpenAI (以及微軟) 的姿態，之前好像沒看到這樣？(單純印象...)

Amazon DocumentDB (with MongoDB compatibility) 支援壓縮

看到「Amazon DocumentDB announces improvements to document compression」這則公告提到 Amazon DocumentDB 5.0 支援壓縮了：

These compression benefits are now supported in Amazon DocumentDB 5.0 instance-based clusters in all regions where Amazon DocumentDB is available.

官方宣稱可以壓七倍：

Compressed documents in Amazon DocumentDB can be up to 7 times smaller than uncompressed documents, leading to lower storage costs, I/O costs, and improved query performance.

在「Managing collection-level document compression」這份文件裡面則是提到演算法是 LZ4：

Amazon DocumentDB uses the LZ4 compression algorithm to compress documents.

因為大家都猜 DocumentDB 後面是 PostgreSQL，所以我就查了一下 PostgreSQL 這邊的資料，可以從 PostgreSQL 14.0 (2021/09/30) 的 Release Notes 看到支援 LZ4：

Add ability to use LZ4 compression on TOAST data (Dilip Kumar)

This can be set at the column level, or set as a default via server parameter default_toast_compression. The server must be compiled with --with-lz4 to support this feature. The default setting is still pglz.

而 DocumentDB 則是 2019 年一月的時候出的，大概是 DocumentDB 5.0 用到的 PostgreSQL 比較新所以可以支援了...

Amazon EC2 推出 Graviton4 的機種 r8g.*

Amazon EC2 推出了 Graviton4 的新機種：「AWS Graviton4-based Amazon EC2 R8g instances: best price performance in Amazon EC2」。

第一波 Graviton4 的機種是 R 系列的機器，r8g.*，依照官方說法有機會到 30% 的效能提升：

AWS Graviton4-based Amazon EC2 R8g instances deliver up to 30% better performance than AWS Graviton3-based Amazon EC2 R7g instances.

價錢的部分翻了一下，貴了 10% 左右。另外機器大小上限也有改變，之前 r7g.metal 是 64 vCPU + 512GB RAM，這次 r8g.metal-24xl 是 96 vCPU + 768GB RAM，另外還有 r8g.metal-48xl 的 192 vCPU + 1536GB RAM 的版本，上限拉到原來的三倍。

話說 t4g 還是 Graviton2 的機種呢，什麼時候有機會用到 t5g 呢...

lite-youtube-embed

繼續清 tab，在「YouTube embeds are heavy and it’s fixable (frontendmasters.com)」這邊看到的是提出改善 YouTube 的外嵌功能 (embed)，因為 loading 太肥了。原文在「YouTube Embeds are Bananas Heavy and it’s Fixable」，裡面提到一個只有 YouTube 的 embed (iframe) 頁面就抓了 1.3MB 的資料：

On a page with literally nothing at all on it other than a YouTube Embed, we’re looking at:

32 requests
1.3 MB of data transfer
2.76s to load the page on my current WiFi connection

而「One YouTube Embed weighs almost 1.2 MB」這邊更提到了這邊的 resource 會線性疊加不會共用的：

The weight also grows linearly with every embed—resources are not shared: two embeds weigh 2.4 MB; three embeds weigh 3.6 MB (you get the idea).

測了一下 https://home.gslin.org/tmp/ytembed.html 這個，是 1.2MB transferred：

如果放兩個一樣的影片，也就是 https://home.gslin.org/tmp/ytembed2.html 的話，變成 2.4MB transferred：

所以不共用的部分的確超大，懷疑 iframe 之間不共用資源是不是跟 cache partition 的實作有關：「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」。

Anyway，所以作者提案用 lite-youtube-embed 這個套件改善：

Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster.

不過這種事情你想得到，Google 也一定想得到，全篇只講 lite-youtube-embed 的好處一定哪邊有問題。

所以翻一下 Hacker News 上，在 id=40897582 這邊就有人提到缺點了，很明顯 lite-youtube-embed 的載入速度比較慢：

The author says they don't believe that a lighter version has been shown to reduce engagement.

I, on the other hand, fully believe that.

The recommended lite-youtube-embed project page has a demo of both lite and regular players [0], and the lite version takes noticeably longer to start playing the video.

Every additional millisecond of load time will reduce engagement, and here the difference is more on the order of hundreds of milliseconds or more.

[0] https://paulirish.github.io/lite-youtube-embed/

yeah，這樣就合理了。

即使 embed 吃超多資源，但因為 YouTube 是影音網站，主要的流量還是影音的部分，利用這個方法增加載入速度，在成本結構上面可以接受，而且還可以拿到更多瀏覽資料？

但對於網站端以及使用者端就不是什麼愉快的事情，所以網站端要不要用這個套件就是看各自的取捨了。

使用 SQLite 實作出 API 相容 Amazon SQS 的 SmoothMQ

在「Show HN: Drop-in SQS replacement based on SQLite (github.com/poundifdef)」這邊看到的，就如同標題所提到的，是個 Amazon SQS 的相容 API 實作，專案在 GitHub 上的「SmoothMQ」這邊。

底層是 SQLite，實作語言是用 Go，然後有 web interface 可以觀察與管理。

不過 Amazon SQS 的 API 層有特別優秀嗎...？而且大多數的情況都不是直接呼叫，應該是透過 message queue sdk 處理，像是作者自己寫的 sample code 用 Celery？如果是 Celery 的話後面應該有很多 backend 可以抽換...

也許在測試的角度用的到？

AWS Direct Connect 開始提供 400Gbps 的選擇

AWS Direct Connect 開始有 400Gbps 的選擇了：「AWS Direct Connect announces native 400 Gbps Dedicated Connections at select locations」。

依照裡面的 AWS Direct Connect Locations 連結可以知道目前開放的地點都在北美：

  • CoreSite VA1, Reston, VA
  • Equinix DC2/DC11, Ashburn, VA
  • CoreSite SV4, Santa Clara, CA
  • Equinix SV5, San Jose, CA

Terabit Ethernet 這邊翻400Gbps 的部分，是 2017 年的標準，另外有些比較長距離的選擇是後續推出來的。

這樣算是給了一些需要穩定大流量的企業的選擇，不然 internet 集縮比的問題造成線路頻寬時高時低。

話說 Direct Connect 在台灣的兩個點目前都還是掛到東京區 (ap-northeast-1) 上，後續台北 region 開點後不知道是會支援多個 region (i.e. 可以掛東京，也可以掛台北)，還是會另外找機房接？

OpenDNS 停止在法國的 DNS Resolver 服務

前陣子法國法院要求在 DNS 層阻擋的事情 (參考「Google Public DNS 接受法國法院的阻擋要求」) 有新的進度了，OpenDNS 直接停止在法國的 DNS Resolver 服務：「OpenDNS Suspends Service in France Due to Canal+ Piracy Blocking Order」。

不是把法國當地的服務停掉改由其他地區的 anycast 提供服務，而是在服務本身上面直接阻擋法國的使用者：

Reports of problems with the OpenDNS service seemed to begin on Friday, and it didn’t take long to discover the cause. The technical issues were isolated to France and apparently parts of Portugal too, with an explanation having appeared on the OpenDNS website, perhaps as early as Thursday evening.

網站上的公告則是：

Effective June 28, 2024: Due to a court order in France issued under Article L.333-10 of the French Sport code and a court order in Portugal issued under Article 210-G(3) of the Portuguese Copyright Code, the OpenDNS service is not currently available to users in France and certain French territories and in Portugal. We apologize for the inconvenience.

這下衝突升級了...