AWS 增加 CloudFront 的 AWS-managed prefix list 讓管理者使用

看到 AWS 公告提供 CloudFront 的 origin subnet 資訊 (AWS-managed prefix list) 讓管理者可以用:「Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront」。

以往會自己去「AWS IP address ranges」這邊提供的 JSON 檔案定時撈出來再丟到 managed prefix list 裡面,這次的功能等於是 AWS 自己管理這個 prefix list 讓管理者使用。

馬上想的到的用途就是 HTTP/HTTPS port 了,只開放給 CloudFront 的伺服器存取:

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

要注意的是這不應該當作唯一的 ACL 手段,因為其他人也可以建立 CloudFront distribution 來穿透打進你的 origin server。

另外有個比較特別的地方,這個 prefix list 的權重很重,使用他會算 55 條 rule 的量,在 security group 內很容易撞到 60 條的限制,在 route table 裡面則是直接撞到 50 條的限制;不過這兩個限制都可以跟 AWS 申請調昇:

The Amazon CloudFront managed prefix list weight is unique in how it affects Amazon VPC quotas:

  • It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.
  • It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

如果 HTTP 一條,HTTPS 也一條,那就會算 110 rules 了,有暴力的感覺...

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 上,速度快多了...

在 Chrome 的 FileSystem API 的漏洞被補上後,偵測私密瀏覽模式的方式

Google Chrome 74 版修掉了一般模式與私密瀏覽模式下 FileSystem API 明顯的不同處後,自然就會有人研究其他的偵測方式:「Bypassing anti-incognito detection in Google Chrome」。

作者提出來的方式是透過 Quota Management API,一般模式與私密瀏覽模式下會得到不同的值,尤其是硬碟夠大的時候上限是不一樣的:

不過這個看起來應該比較好修?

t2 系列機器的 CPU credit 超出 Quota 的現象

在看 CPU credit 時發現 EC2 上有台 t2.micro CPU credit 一直掉,但是上面沒有跑什麼東西,所以先在內部的 Trac 上開張 ticket 追蹤... 然後這種事情都是一開 ticket 就馬上想到了 @_@

首先發現這些 CPU credit 是超出 max quota 144 的限制 (參考 AWS 的文件「CPU Credits and Baseline Performance」),就馬上想到是因為 t2 系列的機器在開機時會贈送 CPU credit 以避免開機時太慢 (參考文件「T2 Standard」),而贈送的這塊會優先使用,但不吃 max quota:

Launch credits are spent first, before earned credits. Unspent launch credits are accrued in the CPU credit balance, but do not count towards the CPU credit balance limit.

另外系統對每個帳號有限制,每個帳號每 24 小時在每區有 100 次的贈送限制:

There is a limit to the number of times T2 Standard instances can receive launch credits. The default limit is 100 launches or starts of all T2 Standard instances combined per account, per region, per rolling 24-hour period.

新帳號可能會更低,隨著使用情況調昇:

New accounts may have a lower limit, which increases over time based on your usage.

所以就知道為什麼會緩緩下降了,在到 144 之前都應該是下降的趨勢...

AWS CodeBuild 可以管 Secret 了...

AWS CodeBuild 可以管理 secret 了:「AWS CodeBuild Now Provides Ability To Manage Secrets」。

AWS CodeBuild now further enhances securing your build environment. CodeBuild can now store sensitive information as secrets, which can now get directly passed to your build jobs. This can be achieved by modifying the parameter store directly in your buildspec.yml, or via the CodeBuild console.

在文件裡提到:

We strongly discourage using environment variables to store sensitive values, especially AWS access key IDs and secret access keys. Environment variables can be displayed in plain text using tools such as the AWS CodeBuild console and the AWS CLI. For sensitive values, we recommend you use the parameter-store mapping instead, as described later in this section.

這次算是補上其他家已經有蠻久的功能...

不過在找資料的時候,發現 AWS CodeBuild 提供了每個月一百分鐘的 free quota,不論是新帳號還是現有帳號都一直有?(這點是之前沒注意到的...)

The AWS CodeBuild free tier includes 100 build minutes of build.general1.small per month. The CodeBuild free tier does not expire automatically at the end of your 12-month AWS Free Tier term. It is available to new and existing AWS customers.

Let's Encrypt 宣佈脫離 Beta

Let's Encrypt 宣佈脫離 beta,正式開放:「Leaving Beta, New Sponsors」。

翻資料的時候發現在今年 3/26 的時候,限制已經放寬了:「Rate Limits for Let’s Encrypt」。

首先一張證書只能包括 100 個 hostname,跟原來相同:

Names/Certificate is the limit on how many domain names you can include in a single certificate. This is currently limited to 100 names, or websites, per certificate issued.

再來是每個禮拜可以申請的數量從 5 個 hostname 變成 20 個,另外本來 renew 也算 quota,現在變成不會吃到 quota:

Certificates/Domain limits how many certificates can be issued that contain a single registered domain*.
This is limited to 20 certificates per domain per week. Exception: When you request a certificate with the same exact set of FQDNs as previously-issued certificate, this rate limit does not apply, but the one below does.

不知道會不會再放寬限制...

Linode 骨幹升級,傳輸量限制提昇為原來的十倍!

Linode 剛剛發表了「Linode Nextgen: The Network」,對外說明他們砸了大筆銀子在骨幹網路上,於是把本來的傳輸限制提昇為原來的十倍。也就是本來限制 200GB 的 Linode 512 就變成 2000GB。

六個機房都包括在內:(於是東京機房也是其中之一)

We’re upgrading our entire network, in all six datacenters.

然後所有架構都是以 Cisco Nexus 為主:

看起來 Cisco 給了很漂亮的價錢讓 Linode 廣告... XD

這麼多頻寬好像可以拿來幹些事情... (來想看看)