Tag: zone

AWS 弄出了 AWS Dedicated Local Zones，很像 AWS Outposts...

AWS 推出了 AWS Dedicated Local Zones：「Announcing AWS Dedicated Local Zones」。

先講 AWS Outposts，他就是提供 AWS 自己的硬體，放到用戶的機房裡面，所以依照需求有不同大小的機器，甚至是整個機櫃：

AWS Outposts is a family of fully managed solutions delivering AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience. Outposts solutions allow you to extend and run native AWS services on premises, and is available in a variety of form factors, from 1U and 2U Outposts servers to 42U Outposts racks, and multiple rack deployments.

在「What is AWS Outposts?」這邊有詳細列出有哪些服務可以跑在上面，可以看到主要就是基礎服務，以及一些吃 local 特性的服務。

另外在「How AWS Outposts works」這邊可以看出架構上會在同一個 VPC 裡面，但是不屬於同一個 AZ 下：

而這次推出的 Dedicated Local Zones 還是有些地方沒看懂跟 AWS Outposts 差在哪裡，看起來很像是重新包裝而已...

首先是首頁提到的，這邊有提到 AWS Nitro System，所以猜測這是 AWS 的硬體，而不是自己的硬體：

Build with AWS managed secure cloud infrastructure

Benefit from the same AWS security standards that apply to AWS Regions and AWS Local Zones and are delivered with the security of the AWS Nitro System to help ensure confidentiality and integrity of customer data.

另外在公告裡面提到的服務，跟 Outposts 有些差異：

AWS services, such as Amazon EC2, Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS), Elastic Load Balancing (ELB), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Direct Connect are available in Dedicated Local Zones.

另外在「AWS Dedicated Local Zones FAQs」這邊則試著說明兩者差異，但就這些句子看起來，只是不同面向的東西：

Q: How are AWS Dedicated Local Zones different from AWS Outposts?

AWS Outposts is designed for workloads that need to remain on-premises due to latency requirements, where customers want those workloads to run seamlessly with their other workloads in AWS. AWS Outposts racks are fully managed and configurable compute and storage racks built with AWS-designed hardware that allow customers to run compute and storage on-premises, while seamlessly connecting to AWS’s broad array of services in the cloud.

AWS Dedicated Local Zones are designed to eliminate the operational overhead of managing on-premises infrastructure at scale. Some customers have long-term, complex cloud migration projects and need infrastructure that seamlessly scales to support their large-scale demand. Some of these customers represent the interests of a customer community and also need multi-tenancy features to efficiently coordinate across their stakeholders. Dedicated Local Zones enable these customers to reduce the administrative burden of managing their own infrastructure on-premises with scalable, resilient, and multitenant cloud infrastructure that is fully AWS-managed and built exclusively for their use.

另外回到首頁看使用單位，目前是 GovTech Singapore，看起來就是重新包裝？

另外一個猜測是在客戶的機器上面裝 AWS Nitro System，然後裝 AWS 的軟體？這就有點怪了，而且這樣相容性之類的問題也頗麻煩，也許要指定配合的機種？

等有機會遇到的時候再跟 AWS 的人問問看好了，目前也還用不到...

目前 AWS 台北區只能開 *.2xlarge 的機器

前面在「AWS 的台北區 (Local Zone) 開了」這邊有提到機器開不起來，剛剛查價錢的時候才發現只能開 {c5,g4dn,m5,r5}.2xlarge：

改成 c5.2xlarge 然後就開起來了：

翻了目前所有的 local zone，看起來大多都是類似的情況，選擇性會很少... 目前只有邁阿密與洛杉磯的選擇比較多，這是邁阿密：

這是洛杉磯：

這樣目前要拿來當 VPS 取代品還不太好用，就真的是 local zone 的定位。

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.

AWS 宣佈將在台灣推出 Local Zone

公司的人丟了訊息過來，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 開了 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 同一區的 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.

Amazon EFS 推出 One Zone 版本

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 大阪區開放

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 壓出來)，但既有的服務應該不需要急著搬...

這幾天 blog 被掃，用 nginx 的 limit_req_zone 擋...

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