Tag: aws

Amazon EC2 AMI 的 root volume 可以直接抽換了

這個功能等了十年以上總算是出現了，Amazon EC2 的 AMI 總算是能直接抽換 root volume，不用先停掉機器：「Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume」。

Starting today, Amazon EC2 supports the replacement of instance root volume using an updated AMI without requiring customers to stop their instance. This allows customers to easily update their applications and guest operating system, while retaining the instance store data, networking and IAM configuration.

算是 pre-container 時代會遇到的問題，後來大家都把 workaround 變成 practice 了：每次需要時候都是直接整包重新打包 (像是 Packer 這類的工具)，然後用工具更新 AMI id 改開新的機器，這樣就能夠避開需要先停掉現有機器的問題...

怎麼會突然想到要回來支援這個功能 XD

Amazon EC2 的 Trn1 正式開放使用

AWS 自家研發晶片的 trn1.* 上線了：「Amazon EC2 Trn1 Instances for High-Performance Model Training are Now Available」。

先前三家雲端的廠商只有 Google Cloud Platform 有 TPU 可以 train & evaluate，現在 AWS 推出 AWS Trainium，補上 train 這塊的產品。其中官方宣稱可以比 GPU 架構少 50% 的計算成本：

Trainium-based EC2 Trn1 instances solve this challenge by delivering faster time-to-train while offering up to 50% cost-to-train savings over comparable GPU-based instances.

然後 PyTorch 與 TensorFlow 都有支援：

The Neuron plugin natively integrates with popular ML frameworks, such as PyTorch and TensorFlow.

另外用 neuron-ls 可以看到 Neuron 裝置的資訊，不過沒看懂為什麼要 mask 掉 private ip 的資訊：

大型的 cluster 會使用 Amazon FSx for Lustre 整合提供服務：

For large-scale model training, Trn1 instances integrate with Amazon FSx for Lustre high-performance storage and are deployed in EC2 UltraClusters. EC2 UltraClusters are hyperscale clusters interconnected with a non-blocking petabit-scale network.

但第一波開放的區域有點少，只有萬年美東一區 us-east-1 與美西二區 us-west-2：

You can launch Trn1 instances today in the AWS US East (N. Virginia) and US West (Oregon) Regions as On-Demand, Reserved, and Spot Instances or as part of a Savings Plan.

在 us-east-1 上 trn1.2xlarge 的價錢是 US$1.34375/hr，但沒有實際跑過比較好像沒辦法評估到底行不行...

但總算是擺出個產品對打看看，畢竟要夠大才能去訂製這些東西。

AWS 東京區有 12TB 記憶體的機器了

月初 AWS 宣佈東京區有 u-12tb1.112xlarge 可以用了：「Amazon EC2 High Memory instances with 3, 6, 9, and 12TiB of memory are now available in Asia Pacific (Tokyo) region」。查了一下 on-demend 的價錢是 $131.733/hr，如果一個月以 720 小時來算，要 $94847.76/mo...

沒記錯的話，這種機器應該是要另外申請 limit 才能開，沒辦法說測就測。另外在公告裡面有提到 savings plan ，但沒提到 RI (reserved instance)，不確定是不是還沒開 RI 讓使用者買 (不過我記得 savings plan 好像也有類似的折扣結構)：

Starting today, Amazon EC2 High Memory instances with 3TiB (u-3tb1.56xlarge), 6TiB (u-6tb1.56xlarge, u-6tb1.112xlarge), 9TiB (u-9tb1.112xlarge), and 12TiB of memory (u-12tb1.112xlarge) are available in Asia Pacific (Tokyo) region. Customers can start using these new High Memory instances with On Demand and Savings Plan purchase options.

這種機器是用暴力解決問題的機器...

Amazon CA 在 renew 時將引入動態的 Intermediate CA

上個月 AWS 發的公告，其實已經生效了，但整理的時候才發現還沒寫：「Amazon introduces dynamic intermediate certificate authorities」。

先介紹一下 Amazon CA，這是 Amazon 自己維護的 Root CA，有走過 CA/Browser Forum 的規範與稽核，以及各家瀏覽器額外的要求，所以是個用戶端預設都有信任的 CA。

這個服務後來也被用在 AWS Certificate Manager (ACM) 上，由 ACM 申請到的憑證也都可以掛到 AWS 的各種服務上。

通常 root CA 的憑證不會直接拿來簽最終使用者使用的憑證 (leaf certificate)，而是 root CA 的憑證先簽 intermediate CA 的憑證，然後 intermediate CA 可能有好幾層一路簽下來，到最後面再用 intermediate CA 的憑證簽最終使用者使用的憑證。

這次公告的內容就題到了，之前的 intermediate CA 是一個固定範圍的量，而且會確保 renew 時用的 intermediate CA 跟先前的是相同的：

Before this change, Amazon maintained a limited number of intermediate CAs and issued and renewed certificates from the same intermediate CAs.

這次則是會變成動態：

With this change, leaf certificates issued to you will be signed by different intermediate CAs.

生效日期是這個月十一日，其實已經生效了：

Starting October 11, 2022 at 9:00 AM Pacific Time, public certificates obtained through ACM will be issued from one of the multiple intermediate CAs that Amazon manages.

一般的用戶端 (像是瀏覽器) 基本上應該是不會有問題，因為大多數預設都是信任 root CA，而非 intermediate CA，而這次的改變還是可以從 root CA 產生出對應的 trust chain。

官方有提到一個有可能的情況：如果你的應用程式有設定 certificate pinning 的話，應該是對 root CA 設定，而非對 intermediate CA 或是 leaf 做：

If you use intermediate CA information through certificate pinning, you will need to make changes and pin to an Amazon Trust Services root CA instead of an intermediate CA or leaf certificate.

這個也算通則，因為就 certificate pinning 想要做到的效果，對 root CA 做就就行了...

AWS 台北區的網路狀況 (Routing & CDN 的情況)

在「目前 AWS 台北區只能開 *.2xlarge 的機器」這邊把機器開起來了，所以先測一下 AWS 台北區對台灣各家的 ISP 的網路狀況。

先看台灣內的點，看起來都有 peering，用 IP 測可以看到 latency 都很低：

再來試看海外 internet 的部份，美國蠻多點是從東京 AWS 過去，但測了香港的部份 www.three.com.hk，是從 TPIX 換出去，看起來台灣這邊也有一些出口，peering 與 transit 目前沒看到大問題。

但幾乎所有透過 GeoDNS-based 的查詢都會被丟到東京：

走 anycast 的 Cloudflare 就好不少，像是付費版本的 www.plurk.com 就是台北的 PoP，而免費版本的 wiki.gslin.org 也會丟到亞洲的某個點上？(看不出來是不是東京，出現 jtha 這個有點像是日本，但也有可能是泰國的點？)

這應該主要還是因為這段 IP 目前還是被認到東京的 ap-northeast-1 上，得等各家調整才有機會放到台灣的 PoP 上，不然就是要故意用沒有 EDNS Client Subnet 的 DNS resolver 了。

目前 AWS 台北區只能開 *.2xlarge 的機器

前面在「AWS 的台北區 (Local Zone) 開了」這邊有提到機器開不起來，剛剛查價錢的時候才發現只能開 {c5,g4dn,m5,r5}.2xlarge：

改成 c5.2xlarge 然後就開起來了：

翻了目前所有的 local zone，看起來大多都是類似的情況，選擇性會很少... 目前只有邁阿密與洛杉磯的選擇比較多，這是邁阿密：

這是洛杉磯：

這樣目前要拿來當 VPS 取代品還不太好用，就真的是 local zone 的定位。

AWS 的台北區 (Local Zone) 開了

AWS 總算是宣佈啟用台北 Local Zone 了：「AWS Local Zones Expansion: Taipei and Delhi」，中文的公告在「AWS 宣布在台全新 AWS Local Zone 正式啟用」。

翻了一下先前的預告是六月初的時候，大概是四個月前，當時寫了「AWS 宣佈將在台灣推出 Local Zone」這篇。

看 Jeff Barr 提供的 screenshot 可以看到如同先前了解的，就是掛在東京區下面 (ap-northeast-1)：

比較奇怪的地方是啟用的方式，我是在在 EC2 的 dashboard 上看到這個進去開 (然後是 Service health)，在 VPC 裡面反而沒看到：

然後開了之後要等他幾分鐘啟用，不是幾秒後 refresh 就會出現，我大概等了兩分鐘，跟當初開其他 non-default region 的經驗類似：

然後再回到 VPC 裡面開 subnet，開完後再回到 EC2 上開機器，流程不是很直覺。

另外從「AWS Local Zones features」這邊可以看到目前的服務有限，另外 Jeff Barr 的公告也可以看到目前台北區支援的項目：

After you do this, you can launch Amazon Elastic Compute Cloud (Amazon EC2) instances, create Amazon Elastic Block Store (Amazon EBS) volumes,and make use of other services including Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and Amazon Virtual Private Cloud (Amazon VPC). The new Local Zones include T3, C5, M5, R5, and G4dn instances in select sizes, along with General Purpose SSD (gp2) EBS volumes.

不過這邊有不一致的地方：在 AWS 頁面上是寫 T3 是 upcoming，但 Jeff Barr 的公告則是說可以用 T3，這點晚點來測試看看才知道哪個是對的... 因為我現在連 m5.large 也開不起來：

只要把設定換到東京的 subnet 內就正常，這個錯誤訊息實在是不知道發生什麼事情 (已經設 gp2)，還得繼續摸...

Prerender 從 AWS 搬回傳統機房的成本節省

在 Hacker News 上看到「We reduced our server costs by moving away from AWS (gitconnected.com)」這篇，原文在「How we reduced our annual server costs by 80% — from $1M to $200k — by moving away from AWS」這邊。

偶而會看到這類的報導，這次是 Prerender 這家的服務，從本來在 AWS 上的 $1m/y 降到 $200k/y (這邊都是用美金在計算)。

但好像沒提到第一次投資購買硬體花了多少錢，不過就以前的經驗上來說，把每個月非人力的 OPEX 加上 CAPEX 的各種攤提，大概會是雲端的 1/3 到 1/2 的費用。

近年來 k8s 以及各種架構愈來愈完整，很多技術也都收斂，慢慢變成業界標準了，不需要自己土砲搞一堆東西而導致產生可觀的維護成本。

從 crt.sh 上面搜尋 prerender.io 可以看到 Prerender 選擇的工具，像是在地端上面應該是用 k8s，然後有用 Sentry 以及 Redash。

這個跟當年算過的經驗類似，startup 可以先上雲端把服務做起來，雲端的擴充性對於初期的幫助會很大 (先 scale up 撐住，再改寫成可以 scale out 的版本)，而當量又大到一定程度時就反過來先問 discount，如果不滿意的話就可以規劃搬回地端。

Prerender 的量看起來超過臨界值不少，搬到地端省成本應該是蠻理所當然的...

Route 53 提供 100% SLA，而 Route 53 Resolver 提供 99.99% SLA

AWS 宣佈 Route 53 提供 100% 的 SLA，而 Route 53 Resolver 則提供 99.99% 的 SLA：「Amazon Route 53 Resolver Endpoints announces 99.99% Service Level Agreement and updates its Service Level Agreement for Route 53 hosted zones」。

Route 53 的部份指的是 hosted zone，參考「Amazon Route 53 Service Level Agreement」這邊，可以看到是 2022/08/29 更新的條款。

Route 53 Resolver 的部份可以參考「Amazon Route 53 Resolver Endpoints Service Level Agreement」這邊，也是 2022/08/29 更新的條款。

要注意 99.99% 是指 Multi-AZ Resolver Endpoints SLA；如果是 Single-AZ Resolver Endpoints SLA 看起來是設定在 99.5%。

不確定是不是 AWS 的第一個 100% SLA 條款...