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 之前都應該是下降的趨勢...

Let's Encrypt 的 Wildcard Certificate 將會再延...

先前有提到 Let's Encrypt 的 Wildcard Certificate 從一月延到二月底 (表訂 2/27,參考先前的「Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出」這篇),今天想說歐美的時區也差不多要過完 2/27 了,結果翻資料發現在「ACMEv2 and Wildcard Launch Delay」這邊又宣佈延期了,這次也不給時間了 XDDD

主要是 TLS-SNI 認證方式的前提有問題,導致 Let's Encrypt 臨時調度人力處理這個包 (可以參考「2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure」這篇,裡面有提到共用產生的問題假設):

The biggest reason for this delay is the recent TLS-SNI deprecation. This unexpectedly pulled most engineering resources away from ACMEv2 and wildcard support for approximately two weeks.

然後 2/27 的說明提到目前是沒什麼大問題,但目前還在 QA 階段,然後目前先不給 release date:

Feb 27 Update: There are no known major issues with the ACMEv2/wildcard test endpoint. ACMEv2 and wildcard support quality assurance is continuing. No release date to announce yet.

就只能繼續等了... XD