bucket

Amazon S3 改變 403 的收費方式

這算是一連串的故事，首先是四月底的時候「How an empty S3 bucket can make your AWS bill explode」這篇，提到了他一個晚上收到了 US$1,300 的帳單，因為有人 (沒有權限的人) 對他的 S3 bucket 狂打了 100M requests (一億筆)，雖然都是 403 的 access denied，但還是得付 request 與頻寬的費用。

對於想要搞的人來說，us-east-1 的 Amazon S3 費用是 $0.005/1K requests (PUT, COPY, POST, LIST requests)，換算大一點的單位是 $5/1M requests，拿個 ab 之類的工具超級簡單就可以打出破千 reqs/sec，如果是 k6 之類的工具，其實一台電腦就蠻容易打爆？

作者聯絡 AWS 客服後，客服回答你需要付這筆費用 (「這不是 bug，是 feature」)：

Yes, S3 charges for unauthorized requests (4xx) as well[1]. That’s expected behavior.

然後這件事情就在社群傳開了，傳到 Jeff Barr 後直接公開提到他認為客戶不應該付 unauthorized request 的 cost (應該是先跟內部其他高層討論過了)，等於是宣佈了會改掉：

Thank you to everyone who brought this article to our attention. We agree that customers should not have to pay for unauthorized requests that they did not initiate. We’ll have more to share on exactly how we’ll help prevent these charges shortly.#AWS #S3

How an empty S3…

— Jeff Barr ☁️ (@jeffbarr) April 30, 2024

不過這件事情之前應該就有人提過了，結果 Colin Percival 直接戳，他在 2006 年 Amazon S3 剛出來的時候就提過了：

For the record, I pointed out this issue to the Amazon S3 team in 2006. They recommended keeping my S3 bucket names secret. https://t.co/P4jTYkAE7S

— Colin Percival (@cperciva) April 30, 2024

Anyway，兩個禮拜過去後，剛剛看到宣佈收費方式修改：「Amazon S3 will no longer charge for several HTTP error codes」。

針對從不屬於自己帳號所產生的 403 不收費 (包括 request 與頻寬費用)：

With this change, bucket owners will never incur request or bandwidth charges for requests that return an HTTP 403 (Access Denied) error response if initiated from outside their individual AWS account or AWS Organization.

然後多了一頁「Billing for Amazon S3 error responses」專門說明這件事情，這邊列的比較完整，除了 403 以外也包含了其他的 HTTP response code 是不收費的：

The current page shows a full list of HTTP 3XX and 4XX status codes that won't be billed.

補了一個 18 年的洞...

找出任意 S3 bucket 對應的 AWS Account ID

在 Hacker News 上看到「How to find the AWS account ID of any S3 bucket (tracebit.com)」這篇，作者利用不同的額外條件，讓 S3 bucket 產生不同的 response，進而取得 AWS 的 Account ID。

首先是先確定 S3 bucket 在哪一區，這個部分比較簡單，即使是 denied response 也會附上 x-amz-bucket-region 這個資訊。

接下來是在對應的區域建立 VPC 以及 VPC Endpoint for S3，接著準備一台 EC2 instance 確認是否透過 VPC Endpoint for S3 存取 Amazon S3 的資料。

接下來的重點就在「Modify the VPC Endpoint policy to determine whether the account ID of the target bucket starts with "0"」這段了，建立一個 policy，限制只能存取 Account ID 是 0* 的 S3 bucket：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "s3:*",
            "Effect": "Allow",
            "Resource": "*",
            "Principal": "*",
            "Condition": {
                "StringLike": {
                    "s3:ResourceAccount": "0*"
                }
            }
        }
    ]
}

然後發 request 去要檔案，理論上在 command line 這邊都會收到 denied 的訊息，但在 CloudTrail 裡面會有兩種不同的情境，如果 CloudTrail 裡面有這筆記錄，表示 Account ID 是 0*；如果沒有的話，表示 Account ID 不是 0*：

If we find our request in CloudTrail, it means that the VPC Endpoint policy permitted the request - i.e. the Account ID of the bucket starts with 0. If we don't find the request, then the VPC Endpoint policy blocked the request - i.e. the Account ID of the bucket does not start with 0.

有了這個破口後，後續的事情就可以自動化了，平行測試以及二分搜尋法拿出來用就可以加速進行。

而 AWS 的 Account ID 雖然不是敏感資訊，但能挖出來還是頗... 有趣的？

開 S3 bucket 與 IAM 帳號的工具

看到 Simon Willison 的「s3-credentials: a tool for creating credentials for S3 buckets」這篇，裡面講到了幾件事情。

在 AWS 上比較好的安全設計是，不同專案之間都有自己的 S3 bucket，然後建立對應的 IAM user，每個 IAM user 只能存取自己的 S3 bucket。

但這個建立過程很煩：

Creating those credentials is surprisingly difficult!

整個建立的過程包括了四個步驟：

建立 S3 bucket。
建立 IAM user。
將 IAM user 掛上對應的 S3 權限。
建立 IAM user 的 access key。

讓人煩的主要是第三個，那個 JSON format 每次都要翻資料 XD

所以他寫了 s3-credentials 這個套件讓大家用，可以透過 pip 直接安裝起來用。

不過我是偏好用 awscli 的，直接把指令放在 wiki page 上面：「awscli」，需要的時候就 copy & paste 過來執行就可以了。在公司的 wiki 上還有直接把 EC2 instance 生到對應的 subnet 指令可以用...

這東西大概不會簡化，只能大家自己找出路 XD

限制流量的方式 (rate limit)

在 Lobsters Daily 上看到這篇 2017 年的文章，Figma 的工程師講怎麼做 rate limit：「An alternative approach to rate limiting」，只要大一點的站台就會遇到 spammer 之類的攻擊，就會希望實做自動化的機制擋住 spammer。

文章裡面提到了三種方式，第一種 (類) 提到了經典的 Token bucket 與 Leaky bucket，這邊文章提供的演算法是讓每個使用者都會有一筆資料紀錄在 Redis 裡面 (這邊的用法可以抽換換成 Memcached)，裡面記錄了最後一次的 access time 以及還剩下多少 token 可以用，接下來就可以照時間計算 token 的補充與消耗：

但這個演算法的缺點是 race condition，需要另外設計一些機制確保操作的 atomic：

不過大多數的實做就算不管 atomic 也還行 OK，只是會比較不精確一點。

第二個方法他叫做 Fixed window counters，這個方法把時間切齊為單位 (像是 60 秒為一個 window)，所以可以把起點的時間也放到 key 裡面，然後 value 就是數量：

這個作法的好處就是簡單，而且 Redis 與 Memcached 都有提供 atomic 的 +1 操作。但缺點是可能會發生兩倍以上的 request，像是 5 reqs/min 的限制有可能會有連續的一分鐘內達到 10 reqs/min：

不過我覺得就 antispam 來說算是夠用了，當年 (大概是 2007 或是 2008 年？) 在 PIXNET 時用 C 寫 Apache module 就是把資料丟到 Memcached 裡面就是這樣實做的，然後每次學術網路的實驗室跑來掃站的就會自動被擋 XDDD

第三種方式他們稱作 Sliding window log，就是把每個 request 的 timestamp 都存起來，這個部份用 Redis 的資料結構會比用 Memcached 方便一些：

這個方式在控制上更精確，不過空間成本上就高很多... 這樣算是把常見的實做方式都提到了。

Amazon S3 淘汰 Path-style 存取方式的新計畫

先前在「Amazon S3 要拿掉 Path-style 存取方式」提到 Amazon S3 淘汰 Path-style 存取方式的計畫，經過幾天後有改變了。

Jeff Barr 發表了一篇「Amazon S3 Path Deprecation Plan – The Rest of the Story」，裡面提到本來的計畫是 Path-style model 只支援到 2020/09/30，被大幅修改為只有在 2020/09/30 後建立的 bucket 才會禁止使用 Path-style：

In response to feedback on the original deprecation plan that we announced last week, we are making an important change. Here’s the executive summary:

Original Plan – Support for the path-style model ends on September 30, 2020.

Revised Plan – Support for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.

這樣大幅降低本來會預期的衝擊，但 S3 團隊希望償還的技術債又得繼續下去了... 也許再過個幾年後才會再被提出來？

B2 的 Application Key

來講個 Backblaze 放出來一陣子的功能：「What’s New In B2: Application Keys + Java SDK」。

B2 的價位很便宜 (單位成本比 S3 低不少)，加上前 10 GB 屬於 free tier 不收費，拿來丟一些資料還蠻方便的。

以往的 B2 在 API 操作只提供一把 master key，安全性上需要很小心，只要被攻陷就直接打穿了，現在則是提供 application key 操作，但不像 AWS 的 IAM 那樣可以在一個 key 上設很多權限。B2 提供的架構很簡單，只能針對一個 bucket 設定權限。這應該是解決 B2 最常見的情境？也就是需要在各機器上分別備份...

另外摸索了一陣子後才確認用法，在文章的 comment 有提到：

You use the ApplicationKeyID with the ApplicationKey, and not the account ID, per the b2_authorize_account documentation.

In a sense, the master key is a special case of this: the AccountID is the ‘key ID’ for the master key.

也就是產生 application key 的時候會給你 secret key 以外，也會給你另外一組 key id，要用這兩個傳入呼叫 API，所有的操作都會受到限制。

關於備份的工具，大家蠻常用 rclone 的，主要是因為他可以加密再丟上去，讓 Backblaze 沒辦法直接存取內容。而 rclone 在 Ubuntu 18.04 可以 apt 直接裝，先前的版本則需要透過 snap 裝 (實在不愛 snap...)，不過看起來還需要新版才會支援 application key。

過陣子來把現有的 master key 換一換...

AWS Storage Gateway 的新功能：File Gateway

AWS Storage Gateway 推出新功能 File Gateway：「File Interface to AWS Storage Gateway」。

可以讓使用者在前面用 NFS，後面實際接的是 Amazon S3：

After you set it up in your data center or in the cloud, your configured buckets will be available as NFS mount points. Your application simply reads and writes files and directories over NFS; behind the scenes, the gateway turns these operations into object-level requests on your S3 buckets, where they are accessible natively (one S3 object per file).

以前自己用 FUSE 惡搞的方式，現在變成官方支援的功能？XDDD