幹壞事是進步最大的原動力
前面在「AWS 的台北區 (Local Zone) 開了」這邊有提到機器開不起來，剛剛查價錢的時候才發現只能開 {c5,g4dn,m5,r5}.2xlarge：
改成 c5.2xlarge 然後就開起來了：
翻了目前所有的 local zone，看起來大多都是類似的情況，選擇性會很少... 目前只有邁阿密與洛杉磯的選擇比較多，這是邁阿密：
這是洛杉磯：
這樣目前要拿來當 VPS 取代品還不太好用，就真的是 local zone 的定位。
剛好在處理 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.
公司的人丟了訊息過來，AWS 要在台灣設 local zone 了：「AWS 宣布在台部署全新 AWS 本地區域，擴充本地基礎設施」。
Amazon Web Services（AWS）宣布將在台灣推出全新 AWS Local Zone（本地區域）。
沒看到確切的時間點... 不過 local zone 的功能都很少，可以參考「AWS Local Zones features」這邊的列表，看看目前已經啟用的 local zone 所支援的服務與機種，像是 RDS 都不一定會有。
不過對個人來說，拿來當 VPS 用還不錯？到時候來看看 routing 的調教如何...
是一篇 2017 年的文章，前幾天在 Hacker News 上重新被提出來：「The Line of Death (2017) (textslashplain.com)」。
文章開頭在講瀏覽器 UI 的信任區，這條線以上是 native UI，以下是網站可以任意操控的內容：
所以 UI 上面有些小細節讓你區分，但這其實對不是專精 phishing 的人很不友善：
另外當然就會提到 browser-in-a-browser (以及 picture-in-picture) 類的 phishing 了：
另外提到了 Fullscreen API，這使得信任區間變成 0：
提到 Fullscreen API 所以就去翻資料，意外發現 IE11 居然支援這組 API，雖然是帶 ms 的 prefix，而且不支援一些輔助性的功能 (像是傳回 Promise object)。
這些 UI 與 security 類的問題，主要還是得考慮到使用者未必那麼熟悉，以及就算有經驗的人也很有可能不小心中獎...
AWS 開了 us-east-1 的 Local Zone 了，包括波士頓、邁阿密與休士頓：「AWS Local Zones Are Now Open in Boston, Miami, and Houston」。
Last December I told you about our plans to launch a total of fifteen AWS Local Zones in 2021, and also announced the preview of the Local Zones in Boston, Miami, and Houston. Today I am happy to announce that these three Local Zones are now ready to host your production workloads, joining the existing pair of Local Zones in Los Angeles.
The parent region for all three of these zones is US East (N. Virginia).
在「AWS Local Zones features」這邊可以看到 local zone 並不是所有服務都有，主要是提供 computing 能力，不過連 ELB 都沒有就有點...
不清楚是不是因為 us-east-1 真的很大，所以要透過 local zone 提供擴張... 這些區域對 us-east-1 北維吉尼亞的 latency 不算低，找機會玩一下確認 local zone 的情況好了...
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.
Amazon EFS 提供 One Zone 的版本，用較低的可靠度提供更低的價錢：「New – Lower Cost Storage Classes for Amazon Elastic File System」。
價錢大約是 53 折，不過要注意不在同一個 AZ 時使用會有頻寬費用：
Standard data transfer fees apply for inter-AZ or inter-region access to file systems.
目前想的到的是 /net/tmp 這類的用途，資料掉了也就算了，考慮到可靠度，其他的用途好像暫時想不到...
AWS 大阪區開放給大家使用了，而且有標準的三個 AZ 可以用：「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」。
大阪區因為之前就已經有機房 (附加在東京區)，所以對應的 routing 看起來不算太差，但也沒有特別好... 剛剛測了一下從 HiNet 光世代過去的 latency，分別是 35.5ms (東京的 ap-northeast-1) 與 34.6ms (大阪的 ap-northeast-3)。
另外測了其他的 ISP，有些上日本的點是以東京為主，反而會多繞了一圈，大阪區的 latency 會比較高。
不過如果放遠來說，東京大阪的直線距離大約是 400km，光纖的傳輸速度大約是光速的 2/3，所以單趟大約差了 2ms，如果有機會最佳化的話應該有機會擠出 4ms 出來？
然後是 EC2 的 Pricing 頁面，上面還是寫 Asia Pacific (Osaka-Local)，無法確定是新資料還是舊資料，但以往的慣例應該是更新了...
對照文章裡有提到支援的機器，目前看起來還沒有很齊，像是目前都還沒有 AMD 與 ARM 架構的機器，另外也沒有 GPU 類型的機器：
The Asia Pacific (Osaka) Region supports the C5, C5d, D2, I3, I3en, M5, M5d, R5d, and T3 instance types, in On-Demand, Spot, and Reserved Instance form. X1 and X1e instances are available in a single AZ.
就支援的類型隨意挑了幾個 instance type 比較，翻了一下價錢看起來跟東京的一樣。
整體看起來，如果是有考慮到異地的需求是可以考慮，另外如果是新的服務的話也可以考慮看看 (畢竟各 ISP 應該有機會再把 latency 壓出來)，但既有的服務應該不需要急著搬...
Update：這個方法問題好像還是不少，目前先拿掉了...
這幾天 blog 被掃中單一頁面負載會比較重的頁面，結果 CPU loading 變超高，從後台可以看到常常滿載：
看了一下是都是從 Azure 上面打過來的，有好幾組都在打，IP address 每隔一段時間就會變，所以單純用 firewall 擋 IP address 的方法看起來沒用...
印象中 nginx 本身可以 rate limit，搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個，就設起來暫時用這個方式擋著，大概是這樣：
limit_conn_status 429; limit_req_status 429; limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;
其中預設是傳回 5xx 系列的 service unavailable，但這邊用 429 應該更正確，從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明：
429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.
然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來，目前比較困擾的是需要 copy & paste try_files 與 FastCGI 相關的設定：
location /path/subpath {
limit_req zone=myzone;
try_files $uri $uri/ /index.php?$args;
include fastcgi.conf;
fastcgi_intercept_errors on;
fastcgi_pass php74;
}
這樣一來就可以自動擋下這些狂抽猛送的 bot，至少在現階段應該還是有用的...
如果之後有遇到其他手法的話，再見招拆招看看要怎麼再加強 :o
AWS 在 Los Angeles 開了第二個 Local Zone：「Announcing a second Local Zone in Los Angeles」，所以現在兩個 zone 的代碼分別是 us-west-2-lax-1a 與 us-west-2-lax-1b。
稍微回頭複習一下，發現大阪區 (Local Region) 跟東京的直線距離大約是 400km 左右，但如果是以 Los Angeles (Local Zone) 與 Portland 的話則是 1300km 左右，如果是 Seattle 的話就會到 1500km 左右。
而且 Los Angeles 的 Local Zone 是掛在 us-west-2 而不是 us-west-1 (N. California) 上面，看起來這兩個主要的差異是在商業考量上，us-west-2 應該是目前的主力 (從各種產品推出的發佈時程看得出來)，所以才會這樣規劃...
回頭翻「AWS 在 us-west-2 開 Local Zone」這篇的時候，發現當時我應該是把 Local Region 與 Local Zone 搞混了...