Amazon SES 開東京區與新加坡區了...

Amazon SES 是 2011 年年初發表的服務,過了九年總算想起來這幾區也是需要 SES 的服務了...:「Amazon Simple Email Service is now available in the US East (Ohio), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Asia Pacific (Seoul) Regions」。

這些年來大家應該都是用 us-west-2 或是 us-east-1 workaround 很久了,現在開這些區域主要還是讓 API 的整合會比較方便,如果本來就是透過 IAM user + username + password 的方式寄信的話就沒什麼差...

另外一種是寄比較大的信件 (產生的流量很大),這次這樣可以避免降低跨區而被收兩次流量費用,不過這應該是比較少見的情況...

AWS 宣佈提昇 Amazon EFS 的最低效率

AWS 宣佈提昇 Amazon EFS 的最低效率:「Amazon Elastic File System increases file system minimum throughput」。

第一段裡的幾個數字差不多就是重點了:

Amazon Elastic File System (Amazon EFS) file systems using the default bursting throughput mode now have a minimum throughput of 1 MiB/s. All EFS bursting mode file systems (regardless of size) can drive 100 MiB/s of throughput, and file systems with more than 1TiB of Standard class storage can drive 100 MiB/s per TB when burst credits are available. This change increases the minimum throughput from 50KiB/s per GiB of Standard class storage to a fixed minimum of 1 MiB/s for file systems with less than 20 GiB of Standard class storage, when burst credits are exhausted.

本來最低保證效率是每 GB 提供 50KB/sec,也就是要使用到 20GB 才會提供 1MB/sec,現在對於不到 20GB 的使用者,直接拉高到固定 1MB/sec。

這對於剛開始用的使用者會方便一些,不過 EFS 主要還是方便在不同機器上共享,效率上還是本機掛 EBS 好很多 (因為 OS 可以 cache)。

先前在 AWS 上把 /home 丟到 EFS 上面,結果因為 i/o 都需要透過網路的關係,編 pyenv 超慢,後來找一天把東西都丟回 EBS 上,速度快多了...

雞肋功能:AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists,就不需要自己在 security group 裡面針對一堆 IP 設重複的設定:「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了:

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用,主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響,如果沒有開 support ticket 調高限制,預設值是:

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時,需要設定「裡面會包含的最大數量」(可以到 1000),是一個你不知道為什麼要設定的東西,然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的),結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule,而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list,改成 15 條後,就可以在 security group 上面掛四次 prefix list (不同的 port),剛好吃完 60 條規則,第五個設定就完全掛不上去... (無論是用 prefix list,或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用:

  • 一開始就要設計好 prefix list 內的最大筆數,如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則,而是以最大筆數佔用,prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎,因為你可以設計機制,改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量,不會有浪費),然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到,都已經用 Terraform 這種工具了,加上你又不是只佔一條規則,我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

HashiCorp 推出 HashiCorp Cloud Platform

HashiCorp 宣佈了 HashiCorp Cloud Platform 這個產品:「Announcing the HashiCorp Cloud Platform」。

不是自己弄機房建 cloud,而是在既有的 cloud 上提供服務,就不需要自己架了:

HashiCorp Cloud Platform (HCP) is a fully managed platform offering HashiCorp products as a service to automate infrastructure on any cloud.

HCP Consul on AWS is now available in private beta. HCP Vault coming soon.

照目前公開的資料,第一個支援的是 AWS 上的 Consul,下一個是 Vault,然後目前推出的是 early access,看起來是走 pay-as-you-go 的模式收費:

Push-button deployments

Production-grade infrastructure, built-in security, and pay-as-you-go pricing accelerate cloud adoption.

有點像是 ConfluentKafka 的玩法,不過 Kafka 光是架設就難搞很多,有他的市場在,另外 Confluent 走的是報價模式,需要找業務提供報價...

HashiCorp 這邊架設簡單不少,不知道玩不玩的起來...

Lambda 可以掛 EFS 了

AWS Lambda 可以掛 Amazon EFS 了:「New – A Shared File System for Your Lambda Functions」。

這有點像是一開始 Amazon EC2 只能把資料存到 Amazon S3 上,後來支援 EBS 的感覺:這使得很多程式可以直接用內建的 library 操作檔案系統,而不需要掛 AWS 專用的 library 操作 Amazon S3。

有了一個 filesystem 後馬上就可以想到很多惡搞的方法,像是用 lambda 搞 serverless PHP 之類的,之後應該會看到很有「創意」的玩法...

Amazon EC2 推出 AMD 版本的 C5a 主機

前幾天 AWS 宣佈了使用 AMD CPU 的 c5a 主機:「New – Amazon EC2 C5a Instances Powered By 2nd Gen AMD EPYC™ Processors」。

定價上與其他 AWS 上 AMD 的機器都類似 (m5ar5a 以及 t3a),大約都低 10% 左右:

Today, I am excited to announce the general availability of compute-optimized C5a instances featuring 2nd Gen AMD EPYC™ processors, running at frequencies up to 3.3 GHz. C5a instances are variants of Amazon EC2’s compute-optimized (C5) instance family and provide high performance processing at 10% lower cost over comparable instances.

以這兩年 AMD 在 CPU 這塊碾壓 Intel 的情況來說 (AMD YES!),目前 AMD CPU 上唯一的缺點應該是單核的時脈比較低,這在捉機上的領域裡面來說,遇到一些沒有做好多核最佳化的遊戲時 Intel 的表現會比較好,其他的情況其實都可以看出 AMD 幹爆 Intel。

如果你在 AWS 上跑的應用程式也有類似需要吃單核效能,無法充分使用多核環境時,還是可以回頭看一下 c5 系列,頻率會高一些:

C5 and C5d instances feature either the 1st or 2nd generation Intel Xeon Platinum 8000 series processor (Skylake-SP or Cascade Lake) with a sustained all core Turbo CPU clock speed of up to 3.6 GHz. The new C5 and C5d 12xlarge, 24xlarge, and metal instance sizes feature the 2nd generation Intel Xeon Scalable Processors (Cascade Lake) with a sustained all-core Turbo CPU frequency of 3.6GHz.

說到這個,Linus 前陣子在發表 5.7-rc7 的時候也說換了 AMD 的 3970x,整個處理 kernel 編譯的速度是用倍數在改善:「Linux 5.7-rc7」:

In fact, the biggest excitement this week for me was just that I upgraded my main machine, and for the first time in about 15 years, my desktop isn't Intel-based. No, I didn't switch to ARM yet, but I'm now rocking an AMD Threadripper 3970x. My 'allmodconfig' test builds are now three times faster than they used to be, which doesn't matter so much right now during the calming down period, but I will most definitely notice the upgrade during the next merge window.

回到 AWS 這邊... 目前有提供的區域來說,歐美比較大的區域都在首發清單,台灣這邊比較常用的東京還沒有看到,不過公司在用的新加坡上了:

You can launch C5a instances today in eight sizes in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Sydney), and Asia Pacific (Singapore) Regions in On-Demand, Spot, and Reserved Instance or as part of a Savings Plan.

如果沒有什麼特別成本壓力的人,可以等一陣子看看有沒有其他人丟效能測試出來,看看 CPU 的計算能力是不是可以無痛換過去... (這邊是相較於 ARM 那邊)

FreeBSD 12.2 在 AWS 的 Amazon EFS 整合 (autofs)

Colin Percival 提到了 FreeBSD 12.2 上 autofs 會整合 Amazon EFS,讓掛載進來變得更方便:「Some new FreeBSD/EC2 features: EFS automount and ebsnvme-id」。

用法是先設定 autofs,然後啟用 autofs:

# echo '/efs -efs' > /etc/auto_master 
# sysrc autofs_enable="YES"

然後重開機後就可以直接切到 /efs/FSID 把 EFS 掛起來了:

Having done this, any access to the path /efs/FSID (e.g., /efs/fs-01234567) will automatically and transparently mount that filesystem.

另外加上原來對 EBS 與 ephemeral disk 的支援,這樣 storage 的部份算是該有的都有了:

Using the tool and some devd magic, FreeBSD now maintains a tree under /dev/aws/disk containing the symlinks of the forms

  • /dev/aws/disk/ebs/vol-0123456789abcdef
  • /dev/aws/disk/linuxname/sdh
  • /dev/aws/disk/ephemeral/SERIALNO

Cloudflare 也推出自己的 Speed Test 服務

Cloudflare 推出了自己的 Speed Test 服務:「Test your home network performance」。

這個服務跟 Netflix 推出的 fast.com 類似,測試的是使用者端到 Netflix (或是 Cloudflare) 中間的速度,主要的目的還是公關 (PR),所以看看就好,實際上用 Speedtest 測出來會比較有參考價值,而且可以選擇不同的點測試...

不過這讓我想到之前有人測出來遠傳會對偵測使用者要使用 Speedtest 測試時開放速限的情況 (像是「遠傳吃到飽只有 Speedtest 沒限速」這篇),然後就有各種定時去打 Speedtest 觸發開放速限的方法...

目前好像只剩下這篇活著,內文提到的是 Android 上的方法,另外推文有人提到 iOS 下的方法:「[心得] 在Android破解遠X限速」,如果有遇到的可以用看看...

疾管署的 COVID-19 每日送檢數的 Open Data

記者會上有提到現在疾管署的網站上有公開每日送檢數的資料,花了些時間找,在「台灣COVID-19冠狀病毒檢測每日送驗數」這邊可以看到,網站提供的 preview 的界面沒辦法看到最新的資料,但下載後可以看到檔案格式是 UTF-8 的 CSV 檔,應該還算能處理...

找到這個資料花了一些功夫 (因為用 DuckDuckGoGoogle 都沒直接找到),後來是靠這樣的步驟找到的:

本來點選熱門資料那邊的「COVID-19台灣最新病例、檢驗統計」結果發現只有一筆資料,而且看起來最後更新時間是 2020/04/24,所以得往其他地方翻。

首先點了上面的「最新消息」發現是個系統公告區,不是我要的,接下來才又找到正確的路線...

這時候就會看到最前面提到的「台灣COVID-19冠狀病毒檢測每日送驗數」了。

然後 data.cdc.gov.tw 這個網站看起來是放在 Microsoft Azure 的日本區?

Cloudflare 的 Enterprise 客戶可以用 Secondary DNS 服務了

Cloudflare 宣佈了新,提供 Enterprise 客戶使用 Secondary DNS:「Secondary DNS — A faster, more resilient way to serve your DNS records」。

先前 Cloudflare 的客戶只能透過網頁或是 Cloudflare 提供的 API 管理 DNS,現在則是可以透過標準協定直接建出 Secondary DNS:

Starting today, enterprise customers who are entitled to secondary DNS will be able to configure their zone in the Cloudflare Dashboard.

這樣對於自己在管理 DNS 的客戶會方便不少 (像是用 BIND 的單位),不過因為安全性的考量,需要啟用 TSIG 確保資料不會被竄改:

Zone transfers between a primary and secondary server are unauthenticated on their own. TSIGs (Transactional Signatures) were developed as a means to add authentication to the DNS protocol, and have mostly been used for zone transfers.

另外就會想到 StackOverflow (「StackOverflow 對於多 DNS 商的同步方式...」) 與 GitHub (「GitHub 也自己搞了一套管理多家 DNS 的程式...」) 的方式,是直接在不同的系統之間疊管理抽象層,這種搞法應該會更穩定,畢竟是直接丟到兩個不同系統管理。

然後我記得市場上有一些 Secondary DNS 的服務可以選,Cloudflare 目前看起來算是補產品線而不是進來殺市場 (畢竟是掛在 Enterprise 等級才能用)。