Amazon EC2 讓你可以關閉 vCPU 節省軟體授權費用

在「Amazon EC2 now supports Optimize CPUs post instance launch」這邊看到的:

Amazon EC2 now allows customers to modify an instance’s CPU options after launch. You can now modify the number of vCPUs and/or disable the hyperthreading of a stopped EC2 instance to save on vCPU-based licensing costs.

以往要大量記憶體的會用 r 系列的主機,vCPU:RAM-GB 比率是 1:8,如果要再更高的話有最近推出的 x 系列,可以到 1:16。

對於使用按照 vCPU 收授權費軟體的使用者來說,有可能會希望比率再更大,尤其是應用偏 memory bound + 授權費很貴的情況。

這次 AWS 這次推出讓你關 vCPU 以及 hyperthreading 的選項,雖然機器費用不變,但軟體授權費就可以下降了:

There is no additional or reduced charge for specifying CPU options. You're charged the same as instances that are launched with the default CPU options.

不確定可以關到什麼程度,像是 x8g.48xlarge (192 vCPU + 3TB RAM) 這台機器不知道可不可以關到只有 1 vCPU,我記得實體 CPU 數量與可以控制的記憶體數量有關,虛擬化後的 vCPU 不確定會不會把限制也帶出來。

看起來是個很「有趣」而且「實用」的功能,但這些收授權費的廠商應該不會太開心,不知道會怎麼反應 XDDD

AWS 推出了 c8g 與 m8g 機種

AWS 宣布了新的 c8gm8g 產品線:「Introducing Amazon EC2 C8g and M8g Instances」、「Run your compute-intensive and general purpose workloads sustainably with the new Amazon EC2 C8g, M8g instances」。

比較特別的是沒有提到 CPU 效能提升的數據 (通常在發表 c 系列時都會提),在 2022 年推出 c7g 時的「New – Amazon EC2 C7g Instances, Powered by AWS Graviton3 Processors」有提到:

Our next generation, Graviton3 processors, deliver up to 25 percent higher performance, up to 2x higher floating-point performance, and 50 percent faster memory access based on leading-edge DDR5 memory technology compared with Graviton2 processors.

不確定是不同作者之間的寫作風格?不過這種效能數字應該是重點...

翻了一下本來的作者 Sébastien Stormacq 與這次的作者 Veliswa Boya,從 LinkedIn 上看不太出來什麼資訊。

Anyway 回來看價錢的話,看 c7g.16xlarge (c7g 中最大台的) 是 US$2.32/hr,對應到 c8g.16xlarge 是 US$2.55232/hr,這次新架構大約就是貴 10%。

依照提到的內容,與效能改善有關的主要會是記憶體速度快 75%,以及兩倍的 L2 cache:

C8g and M8g instances offer larger instance sizes with up to three times more vCPUs (up to 48xl), three times the memory (up to 384GB for C8g and up to 768GB for M8g), 75 percent more memory bandwidth, and two times more L2 cache over equivalent 7g instances.

這兩個堆起來沒有 10% 成長嗎?也許等後續有人測試後會知道... (yeah,目前沒動力測?)

AWS 推出 Memory/CPU 比到 16:1 的 x8g 系列主機

看到「Now available: Graviton4-powered memory-optimized Amazon EC2 X8g instances」這篇公告,本來想說 Amazon EC2 的記憶體主機不是有 r8g.* 嗎,對比了一下才發現記憶體比率更高...

在七月的時候 AWS 先推出了 r8g.* 的主機,Memory/CPU 比是 8:1,也就是 8GB RAM 配 1 vCPU:「AWS Graviton4-based Amazon EC2 R8g instances: best price performance in Amazon EC2」。

這次的 x8g.* 則是到 16:1,對於吃記憶體的應用來說更適合?

以美東 us-east-1 的價錢來看,r8g.medium 是 $0.0977/hr (約 $70.344/mo),而 r8g.medium 則是 $0.05891/hr (約 $42.4152/mo),價錢多了約 65.8%,對於很偏記憶體的應用,像是 Memcached 或是 Redis 來說應該還不錯。

另外我查了一下 Reserved Instance (RI) 的價錢,這台最深的折扣 (全預付 + 三年的 RI) 居然是三折 (70% off),就算是最淺的折扣 (月付 + 一年的 RI) 也有六二折 (38% off),換算後分別是 $21.194/mo 與 $43.95/mo。

對比 Vultr 的 16GB RAM 機器,最少也要 $80/mo?雖然這邊有 2 vCPU,而且還送一定的流量,但價差還是頗明顯的。

之前沒有發現這邊的差異,意外的 AWS 在這邊的價碼頗有競爭性啊,尤其是自己用的話,網頁應用搭配 CloudFront 的 always free 方案,Amazon EC2 到 CloudFront 不用錢,然後 CloudFront 到 internet 流量的部分有一大段不用錢:

1 TB of data transfer out to the internet per month
10,000,000 HTTP or HTTPS Requests per month
2,000,000 CloudFront Function invocations per month
2,000,000 CloudFront KeyValueStore reads per month

不過目前沒有太多區域有,但頗意外的是德國法蘭克福居然在第一波,而不是愛爾蘭:

X8g instances are available today in the US East (N. Virginia), US West (Oregon), and Europe (Frankfurt) AWS Regions in On Demand, Spot, Reserved Instance, Savings Plan, Dedicated Instance, and Dedicated Host form.

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 呢...

換成 t4g.small 後的一些整理

昨天在這邊提到因為 Amazon EC2t4g.small 提供了 free tier 方案 (到今年年底),blog 主機剛好從 t4g.micro 改成用 t4g.small,到年底前可以看看有沒有 t5g 或是類似的主機出來:「往上升級或是用 Unlimited mode 撐」。

除了換完後 CPU credit 給的量上升減緩了情況以外,我在檢查時才發現 PHPopcache 的 cache 使用量也超過預設值 128MB 了,改成 192MB 後看起來 CPU usage 也有下降一些:

這點算是先前沒注意到的,上面 PHP 跑兩個 WordPress 以及一個 MediaWiki (都掛了各式各樣的 plugin & extension),還有一個自己寫的小東西,這樣會超過 opcache 的 cache 大小...

現在換到 t4g.small 後總算又開始養的起 CPU credit 了:

另外也補上幾個 CloudWatch Alarms (看起來 free tier 是十個) 監控主機的 CPUCreditBalance,然後透過 AWS Chatbot 接到自己的 Slack 上,至少之後有狀況的時候會主動通知。

往上升級或是用 Unlimited mode 撐

這個 blog 跑在 Amazon EC2t4g.micro 上面,以往跑起來 baseline 是 10% CPU credit 也還算夠用,但最近的 loading 特別的大,發現是有 bot 在砍站砍的比較兇 (參考「t4g 的 CPU credit 被吃完了」這邊),雖然擋掉後有降不少,但看起來還是比之前高不少:(這邊是一天的平均,拉三個月資料來看)

以往這種一陣一陣的可以靠 CPU credit 頂過去,但因為先前 CPU credit 被 bot 砍完後沒了,就常常撞到底,只好先開 Unlimited mode 擋著了。

另外一方面,當初買的三年 RI 時間也快到了 (居然),這幾天差不多要處理了:

Start
February 9, 2021, 17:43 (UTC+8:00)

Expires
February 9, 2024, 17:43 (UTC+8:00)

升級到 t4g.small 剛好會符合 AWS 的免費方案,看起來可以先掙扎一陣子:

Until December 31, 2024, all AWS customers will be enrolled automatically in the T4g free trial as detailed in the AWS Free Tier. During the free-trial period, customers who run a t4g.small instance will automatically get 750 free hours per month deducted from their bill during each month.

我記得我算過但沒找到文章,所以這邊還是算一下... 如果 t4g.small 要錢的話,與 Unlimited mode 的消費差異大概是多少。

us-east-1t4g.small 是 $0.0168/hr,用 720 小時換算是 $12.096/mo。

假設 CPU 使用率平均在 15%,那用 t4g.micro 的 $0.0084/hr 會是 $6.408/mo,另外加上 5% * 2vCPU = 10% 的 Unlimited mode 費用 ($0.04/hr/vCPU),會是 $2.88/mo。

假設 CPU 使用率平均在 20% (剛好跟 t4g.small 的 baseline 相同的話),會是 $5.76/mo,所以如果用不到對應的記憶體的話,跑 Unlimited mode 會比較划算。

先開一張票。年底的時候再來看看當時的機種與優惠方案...

t4g 的 CPU credit 被吃完了

這個站 blog.gslin.org 掛了三個多小時:

先連機器 SSH 看起來是正常的,但習慣性的 w 看一下情況發現 CPU load 有 6.x,用 top 看一下就看到幾隻 php82-fpm 跑滿 CPU,心裡大概有底是被砍站了...

先把 nginx 停下來,瞄了一下 /var/log/nginx 下面的 log 就知道是 ClaudeBot 造成的,看起來都是從 AWSus-east-1 機器打過來的。

然後翻一下 log 看看什麼時候開始打的,先看 log 已經被 gzip 起來的這些:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log.{?,??}.gz | xargs -n1 | xargs -n1 -I% sh -c "echo %; zgrep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log.2.gz
  13031  169403 1986719
/var/log/nginx/blog.gslin.org_ssl-access.log.3.gz
    459    5967   85350
/var/log/nginx/blog.gslin.org_ssl-access.log.4.gz
  14533  188929 2219819
/var/log/nginx/blog.gslin.org_ssl-access.log.5.gz
   6502   84526 1026178
/var/log/nginx/blog.gslin.org_ssl-access.log.6.gz
  32483  422279 4905919
/var/log/nginx/blog.gslin.org_ssl-access.log.7.gz
  21304  276952 3221877
/var/log/nginx/blog.gslin.org_ssl-access.log.8.gz
   7921  102973 1199356
/var/log/nginx/blog.gslin.org_ssl-access.log.9.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.10.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.11.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.12.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.13.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.14.gz
      0       0       0

看起來是從 blog.gslin.org_ssl-access.log.8.gz 這邊開始的,大概是 1/25 開始 (機器上面是 UTC 時間):

-rw-r----- 1 www-data adm   1894325 Jan 26 00:00 /var/log/nginx/blog.gslin.org_ssl-access.log.8.gz

然後再來看一下最近的 log,看起來是這兩天打的特別重,到五萬多:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log{,.?} | xargs -n1 | xargs -n1 -I% sh -c "echo %; grep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log
  29436  382668 4387703
/var/log/nginx/blog.gslin.org_ssl-access.log.1
  51712  672256 7852345

拉了 AWS 的圖來看跟預期的差不多:

機器是 t4g.micro 而且沒開 burstable,先前差不多都是略低於 10% 的線在跑,剛好利用 CPU credit 的概念,這幾天看起來就是被打而跑上去。

好像該補一下 alarm,丟到我自己的 Slack 以及 Pushover...

把 AWS 上的 EC2 instance 改成 IPv6-only

因為「AWS 將開始收取 IPv4 的 Public IP 費用」的關係,先試著把其中一台 EC2 instance 改成 IPv6-only,結果遇到不少問題...

首先是對外服務的部分,本來想用 CloudFront 擋在前面,但 CloudFront 到現在還是不支援 IPv6-only origin:「CloudFront support for IPv6 origins」,所以這邊的選擇變成是 Cloudflare

第二個是 AWS 自家的 API 還是有些沒有 IPv6 address,像是取得 AWS 擁有的 IP pool 的 https://ip-ranges.amazonaws.com/ip-ranges.json (本來是要取得 CloudFront 的區段,用在 nginx 的設定裡)。

另外就是周邊的問題,很多服務都沒有 IPv6 address,像是 api.slack.com

各種 proxy 與 NAT 架構還是必要的措施...

捷克政府宣布 2032/06/06 政府網站將停用 IPv4 服務

看到「Czech republic sets IPv4 end date (konecipv4.cz)」這篇,捷克政府公告了政府網站將在 2032/06/06 停用 IPv4 服務:「Czech republic sets IPv4 end date」。

On 17 January 2024, the Government of the Czech Republic approved the material "Restarting the implementation of DNSSEC and IPv6 technologies in the state administration". On the basis of this decision, the Czech state administration will stop providing its services over IPv4 on 6 June 2032. Thus, the Czech Republic knows its IPv4 shutdown date.

剛好昨天在試著將手上 AWSEC2 instance 拔掉 IPv4 address (因為 2024/02/01 開始收費,參考先前寫的「AWS 將開始收取 IPv4 的 Public IP 費用」),結果還是遇到相依服務還沒有上 IPv6 endpoint 的問題,如果要轉移的話得開 DNS64NAT64,但因為目前就只有兩台小機器在 AWS 上,在上面租 NAT64 或是自己架 NAT64 的費用反而比付 IPv4 address 的費用還貴,就先暫時丟著了。

我這邊遇到的問題是 api.slack.com 目前只有 IPv4 address,這邊因為是走 HTTPS,也許可以靠其他在有 IPv6 address 的 VPS 上的 proxy server 解決 (我剛好有租一些 VPS instance),這幾天再來看看怎麼弄...

AWS 延長 t4g.small 的 free trial

Plurk 上看到朋友貼的「Announcing Amazon EC2 T4g Free Trial Extension」。

t4g.small 的 free trial 延長到明年年底了:

The Amazon Elastic Compute Cloud (Amazon EC2) T4g instance Free Trial is extended to December 31, 2024. All new and existing AWS customers can utilize the free trial to automatically deduct up to 750 hours per month with the t4g.small instances through December 31, 2024. You can start building on Graviton-based instances for no charge with the T4g free trial, though charges may apply for surplus CPU credits. Refer to Amazon EC2 FAQs for more details on the free-trial.

這台算是還蠻好用的 ARM-based 主機,t4g.small 是 2 vCPU + 2GB RAM 的規格,如果是自己會 tune 的話已經可以做不少事情了,再加上 EC2 在前 12 個月的 t3.micro (2 vCPU + 1GB RAM) 免費,就已經可以玩不少東西了:

750 hours per month of Linux, RHEL, or SLES t2.micro or t3.micro instance dependent on region