AWS 在同一區不同 AZ 頻寬費用的特別地方

剛好在處理 AWS 同一個 region 下不同 AZ 之間的傳輸費用,跟帳單互相比對,查了以後才發現跟想像中不一樣,這邊以 EC2 為例子,可以參考「Amazon EC2 On-Demand Pricing」這頁裡面的說明。

從 Internet 端進 AWS 的流量是不計費的:

Data Transfer IN To Amazon EC2 From Internet
All data transfer in $0.00 per GB

但從 AZ 進到另外一個 AZ 時,in 與 out 都要收費:

Data transferred "in" to and "out" from Amazon EC2, Amazon RDS, Amazon Redshift, Amazon DynamoDB Accelerator (DAX), and Amazon ElastiCache instances, Elastic Network Interfaces or VPC Peering connections across Availability Zones in the same AWS Region is charged at $0.01/GB in each direction.

所以直接用 US$0.01/GB 的計算是不夠的,得用 US$0.02/GB 來計算。

同樣的,如果是 Public IP 與 Elastic IP 也都是雙向收費,跨 VPC 也是雙向收費,所以都要用 US$0.02/GB 來算:

IPv4: Data transferred “in” to and “out” from public or Elastic IPv4 address is charged at $0.01/GB in each direction.
IPv6: Data transferred “in” to and “out” from an IPv6 address in a different VPC is charged at $0.01/GB in each direction.

把 Blog 丟到 CloudFront 上

先前在「AWS 流量相關的 Free Tier 增加不少...」這邊有提到一般性的流量從 1GB/month per region 升到 100GB/month,另外 CloudFront 則是大幅增加,從 50GB/month (只有註冊完的前 12 個月) 提升到 1TB/month (不限制 12 個月),另外 CloudFront 到 EC2 中間的流量是不計費的。

剛剛花了點功夫把 blog 從 Cloudflare 搬到 CloudFront 上,另外先對預設的 /* 調整成 no cache,然後針對 /wp-content/* 另外加上 cache 處理,跑一陣子看看有沒有問題再說...

目前比較明顯的改善就是 latency,從 HiNet 連到免費版的 Cloudflare 會導去美國,用 CloudFront 的話就會是台灣了:

另外一方面,這樣國際頻寬的部份就會走進 AWS 的骨幹,比起透過 HiNet 自己連到美國的 PoP 上,理論上應該是會快一些...

Wasabi 與 Storj DCS

WasabiStorj 是在看到「Will Cloudflare R2 Win Customers from Amazon S3?」這篇文章時翻到了三個 Cloud Storage Provider,文章本身我倒是沒什麼吸收...。

第一個是 BackblazeB2,這個產品平常的曝光度就還算夠。

另外是 Wasabi 的部份,其中一個賣點是免費的頻寬,但其實限制意外的多。首先是各地區的價錢:

我找了一下到底是什麼地區,目前只有看到「Wasabi Technologies Inc Status」這邊有編號 (US-East-1、US-East-2、US-Central-1、US-West-1、EU-Central-1、AP-Northeast-1),但也沒找到地區... US 的都在美國沒問題,AP-Northeast-1 應該是日本,但 EU-Central-1 是哪裡就找不到了。

另外是 pay-as-you-go 的方案最小是 1TB,如果是歐美區的話是 US$5.99:

For customers using the Wasabi pay-as-you-go pricing model, Wasabi has a minimum monthly charge associated with 1 TB of active storage. If you store less than 1 TB of active storage in your account, you will still be charged for 1 TB of storage based on the pricing associated with the storage region you are using.

然後也有 90 天的最短計價時間:

Wasabi has a minimum storage duration policy that means if stored objects are deleted before they have been stored with Wasabi for a certain number of days (90 days when using the Wasabi pay-go pricing model), a Timed Deleted Storage charge equal to the storage charge for the remaining days will apply.

另外 Wasabi's free egress policy 這邊也可以看出來他們的設計就是拿來當 storage 用,然後前面需要擋 CDN 之類的服務。

最後一個是 Storj 的 DCS,US$4/TB/month 的空間費用,與 US$7/TB 的流量費用感覺還算便宜?他的做法是把檔案拆成 80 份,然後取 29 份就可以算回來:

How many Nodes are files stored on?

80. We split each file into 80 different encrypted pieces, and each piece is stored on a different Node.

When you retrieve an object, only 29 of its 80 pieces are needed to reconstitute that object. With no central point of failure, your data is always quickly available, all over the world.

這部份是則是透過 Reed-Solomon error correction 實做:

Automate file repair and know that Reed-Solomon erasure coding enables the highest levels of durability for all files uploaded to Storj DCS.

好一陣子沒看到 Reed-Solomon 了,沒想到在這邊看到... 先不管技術的部份,看起來 Storj DCS 的價錢可以玩看看。

Cloudflare 推出 Cloudflare R2 Storage,相容於 S3 API,但沒有傳輸費用

Cloudflare 宣佈了 Cloudflare R2 Storage,相容於 S3 API,但是沒有傳輸費用:「Announcing Cloudflare R2 Storage: Rapid and Reliable Object Storage, minus the egress fees」,Hacker News 上的「Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees (cloudflare.com)」可以看一下討論,裡面有負責 R2 的 PM (帳號是 greg-m) 回答一些東西。

R2 的第一個特點就是剛剛提到的傳輸費用:一般的雲端都是傳進去不用錢,但傳出來會很貴,而 R2 其中一個主打的點就是傳出來不用錢:

R2 builds on Cloudflare’s commitment to the Bandwidth Alliance, providing zero-cost egress for stored objects — no matter your request rate. Egress bandwidth is often the largest charge for developers utilizing object storage and is also the hardest charge to predict. Eliminating it is a huge win for open-access to data stored in the cloud.

另外 storage cost 也算低,S3 目前的費用是 US$0.023/GB/month (拿 us-east-1 相比),而 R2 目前的定價是 US$0.015/GB/month:

That doesn’t mean we are shifting bandwidth costs elsewhere. Cloudflare R2 will be priced at $0.015 per GB of data stored per month — significantly cheaper than major incumbent providers.

在 durability 的部份,與 S3 都是一年 11 個 9:

The core of what makes Object Storage great is reliability — we designed R2 for data durability and resilience at its core. R2 will provide 99.999999999% (eleven 9’s) of annual durability, which describes the likelihood of data loss.

目前還沒有公開,算是先對市場放話:

R2 is currently under development — you can sign up here to join the waitlist for access.

有幾個點還蠻有趣的,第一個是 Cloudflare 自己在推的 Bandwidth Alliance 裡有不少 VPS 跟 Cloudflare 之間的流量是不計頻寬費用的,所以等於是 VPS 到 R2 不計費,而 R2 到 VPS 也不計費,但要注意 VPS 自己也都有在推 object storage。

像是 Vultr 的 US$5 方案包括了 250GB 的空間與 1TB 的頻寬,扣掉頻寬的部份 (可以透過 Cloudflare 處理),相當於是 US$0.02/GB。

Linode 也類似,US$5 的方案包括了 250GB 的空間與 500GB 的頻寬,算出來也是 US$0.02/GB。

Backblaze 也有類似的產品 B2,US$0.005/GB/month 的儲存費用以及 $0.01/GB 的傳輸費用,但頻寬的部份也可以透過 Cloudflare 處理。

這個產品出來以後可以再看看如何,但看起來是蠻有趣的。對目前的雲端商應該還好 (因為資料進 R2 還是有費用),但對這些 VPS 來說應該是有蠻大的衝擊...

重寫 Ptt 上的 Imgur Userscript 解決圖片出不來的問題

前幾個禮拜 Imgur 決定擋掉 Ptt 的網頁版,所以 Ptt 網頁版上會發現 Imgur 的圖都不見了:「[問題] 突然imgur的貼圖無法顯示」。

這是因為 Imgur 用 Referer 擋了 Ptt 的關係,後來 Ptt 官方在 8/15 後有針對 https://i.imgur.com/ 的圖片改用 https://cache.ptt.cc/ 過一層,不過 https://imgur.com/ 的就沒圖了。

這邊可以參考 Certificate Transparency 的「crt.sh | cache.ptt.cc」記錄,以及台大對於 Ptt 的流量的記錄 (出自「PTT 流量分析」這邊):

除了 Ptt 官方的解法外,另外可以自己寫 userscript,用 Referrer-Policy 繞過 (需要比較新版的瀏覽器,不過目前的瀏覽氣應該都夠新),看了一下本來的 ptt-imgur-cleaner-gm,發現要整個打掉改寫,索性就開一個新的專案變成 imgur-links-rewriting-on-ptt

這個版本的特色:

  • 加上對 https://imgur.com/a/ (album) 的支援,可以顯示第一張圖。
  • WebP 的版本,下載速度應該會快一些。
  • 偏好都是用大圖 (原始大小的圖片)。
  • 把本來走 https://cache.ptt.cc/ 的版本換回直接走 https://i.imgur.com/,就不用透過 TANet 或是台大的出國頻寬了。

程式碼不長 (參考「imgur-links-rewriting-on-ptt.user.js」這邊),主要是練手... 沒事就寫一下 userscript 可以維持對於 JavaScript 的基本熟悉度。

Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能,畢竟是公司要用的,還是實際測一下數字,之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWSap-southeast-1 (Singapore) 的 EC2 測試,直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令,其他的是出自我自己 wiki 上的 Ubuntu 這頁),然後再重開機:

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s,另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上,這樣可以捲回去看每一秒的傳輸速度,就可以看出來變化了,不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline):

EC2 instance Baseline Burstable vCPU RAM Pricing (USD$)
c6g.medium 500Mbps 10Gbps 1 2GB 0.0392
c6g.large 750Mbps 5Gbps (claimed 10Gbps) 2 4GB 0.0784
c6g.xlarge 1.25Gbps 10Gbps 4 8GB 0.1568
t4g.small 125Mbps 5Gbps 2 2GB 0.0212
t4g.medium 255Mbps 5Gbps 2 4GB 0.0424
t4g.large 510Mbps 5Gbps 2 8GB 0.0848
t4g.xlarge 1Gbps 5Gbps 4 16GB 0.1696

這邊沒列出來的是 burstable 可以持續的時間,但這跟你機器吃的網路資源有關,我就決定只用 baseline 來做決策了,這樣可能會多花一點錢,但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead,所以就順便查了一下資料:

  • OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候):「OpenVPN performance」。
  • SSH 也有些 overhead,大約是 6% (把來回的封包都算進去):「What is the overhead of SSH compared to telnet?」。
  • rsync 的部份鐵定也有 overhead,但這邊就沒找到現成的文章有統計過了。
  • 另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的,會有 10% packet loss,改用預設的 CUBIC 會好很多,大約 1% 到 2% 左右。

綜合這些測試,我自己抓了 35% 的 overhead 來推估,最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量,大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠,有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多,應該是不需要降...

rsync 的預設值是傳整個檔案,不是 delta

剛好最近工作上需要透過 4G 網路傳大檔案,但希望大檔案傳到一半斷掉後可以續傳,而不要浪費頻寬整個重傳,所以查了資料並且測了一些東西...

其中一個比較特別的是發現 rsync 的預設是傳整個檔案 (當檔案有變化時),而不是傳 delta (有變更的部份),不過還好,可以透過指令強制使用 delta。

在「Does rsync --inplace write to the entire file, or just to the parts that need to be updated? (for btrfs+rsync backups)」這邊有提到幾個需要設定的指令。

首先是標題就有提到的 --inplace,在 manpage 裡面有提到是直接更新檔案,而非建立一個新檔案再 rename,這樣做的缺點是其他的應用程式可能會讀到改到一半的檔案:

update destination files in-place

另外一個提到的是 --no-whole-file,這個要看 --whole-file 的說明來理解,後者就是不開 delta:

copy files whole (w/o delta-xfer algorithm)

第三個是 -c,強制使用 checksum 比對:

skip based on checksum, not mod-time & size

不過我的應用裡面不太想管這個,就沒設定 -c 了,基本上是靠 ssh 的保護,不會有收到錯誤封包的問題。

整體來說,這個方法對兩邊的機器都比較吃資源,而且會遇到應用程式在還在傳輸時讀到檔案的問題,但如果可以克服,而且目標是省頻寬的話,算是個還不錯的方法...

AWS 同一區的 VPC Peering 流量不收費了

AWS 在同一個 AZ 裡面的流量是不收費的,但如果是跨帳號的話,還是要當作 inter-AZ 流量 (收 USD$0.01/GB 的費用),現在則是宣佈不用了:「Amazon VPC Announces Pricing Change for VPC Peering」。

要注意的是不同帳號的 a 不一定相同 (像是 us-east-1a 在不同帳號對應到的實際 AZ 不同),得透過 AWS 提供的資料確認底層實際的 AZ 是哪個。

回朔到這個月月初生效:

Starting May 1st 2021, all data transfer over a VPC Peering connection that stays within an Availability Zone (AZ) is now free. All data transfer over a VPC Peering connection that crosses Availability Zones will continue to be charged at the standard in-region data transfer rates. You can use the Availability Zone-ID to uniquely and consistently identify an Availability Zone across different AWS accounts.

Google 新推出的 Lyra audio codec

Hacker News Daily 上看到「Lyra audio codec enables high-quality voice calls at 3 kbps bitrate」,講 Google 新推出的 Lyra audio codec:「Lyra: A New Very Low-Bitrate Codec for Speech Compression」,論文在「Generative Speech Coding with Predictive Variance Regularization」這邊可以抓到。

目前 Google 提出來的想法是想辦法在 56kbps 的頻寬下實現還堪用的視訊通話:

Pairing Lyra with new video compression technologies, like AV1, will allow video chats to take place, even for users connecting to the internet via a 56kbps dial-in modem.

這次的突破在於可以使用 3kbps 的頻寬傳輸,但清晰度比 Opus 的 6kbps 效果還好不少。

Google 在文章裡面給了兩個 sample,一個是乾淨背景音,另外一個是吵雜的背景音,跟 Opus 與 Speex 比起來都好很多。

論文是說不需要太高的運算力,但沒翻到 GitHub 之類的 source code,先當作參考:

We provide extensive subjective performance evaluations that show that our system based on generative modeling provides state-of-the-art coding performance at 3 kb/s for real-world speech signals at reasonable computational complexity.

Backblaze 與 Fastly 合作

Twitter 上看到的消息,BackblazeFastly,免除 Origin 到 CDN 這段的流量費用:

新聞稿是「Set Your Content Free With Fastly and Backblaze B2」這篇:

Our new collaboration with Fastly, a global edge cloud platform and CDN, offers an integrated solution that will let you store and serve rich media files seamlessly, free from the lock-in fees and functionality of closed “goliath” cloud storage platforms, and all with free egress from Backblaze B2 Cloud Storage to Fastly.

不過這不是第一家提供這樣的方案,在 2018 年的時候就有跟 Cloudflare 合作,免除了 Origin 端到 CDN 端這段費用:「Backblaze 與 Cloudflare 合作,免除傳輸費用」。