幹壞事是進步最大的原動力
AWS 推出了實體伺服器版本的 Storage Gateway，以 Dell 的伺服器為底，上面安裝 AWS 的軟體：「New – AWS Storage Gateway Hardware Appliance」。
可以直接從 Amazon 上訂：「AWS Storage Gateway pre-loaded on a Dell EMC PowerEdge server」。
從網路界面是 em{1,2,3,4} 猜，裡面看起來應該不是 Linux Kernel 為底的系統：
對於使用虛擬機版本不夠用的使用者可以直接搬一台回去用... XD
來講個 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 宣佈提高了 Amazon S3 的效能：「Amazon S3 Announces Increased Request Rate Performance」。
每個 S3 prefix 都可以到 5500 RPS read 與 3500 RPS write：
Amazon S3 now provides increased performance to support up to 3,500 requests per second to add data and 5,500 requests per second to retrieve data, which can save significant processing time for no additional charge. Each S3 prefix can support these request rates, making it simple to increase performance exponentially.
舊的資料可以看「Request Rate and Performance Considerations」這邊，裡面沒有明講速度，但有提到如果超過 800 RPS read 與 300 RPS write 的門檻，建議開 case：
However, if you expect a rapid increase in the request rate for a bucket to more than 300 PUT/LIST/DELETE requests per second or more than 800 GET requests per second, we recommend that you open a support case to prepare for the workload and avoid any temporary limits on your request rate.
不過如果有量的話，還是建議照著原來的 prefix 建議，打散處理會比較好，通常在前面的 CDN 通常可以跑簡單的 url rewrite 處理掉 (像是 CloudFront 自家或是 Cloudflare)，像是把使用 unix timestamp (ms) 的 https://www.example.com/1531843366123.jpg 變成 https://www.example.com/6123/1531843366123.jpg，這樣可以讓 Amazon S3 的後端依照 prefix 打散 loading，避免當站愈來愈大的時候很難處理。
以往用 Amazon EBS Snapshot 需要用 Lambda 當 cron job 建立 snapshot，以及管理要存的數量 (要刪掉舊的)，現在 AWS 直接提供服務幫你處理：「New – Lifecycle Management for Amazon EBS Snapshots」。文章的截圖就說明了這個新功能：
不收另外的費用，不過目前只有開放三區，東京不在裡面：
You can create and use Data Lifecyle Manager policies at no charge; you pay the usual storage charges for the EBS snapshots that it creates.
Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and EU (Ireland) Regions.
先繼續用 Lambda，等東京有的時候再換過去...
AWS 宣佈可以動態擴充 EBS (Magnetic Volume) 的大小了：「Amazon EBS Extends Elastic Volumes to Support EBS Magnetic (Standard) Volume Type」。EBS (Magnetic Volume) 被歸類到前個世代的產品，意外的把這個功能支援了前個世代的產品...
前世代的 Magnetic Volume 與 Throughput Optimized HDD (st1) & Cold HDD (sc1) 來比較起來貴了一些，但可以當作開機空間，另外低消只有 1GB (而 st1 與 sc1 是 500GB)，不過如果與 General Purpose SSD (gp2) 比的話，只要 I/O 有點量，整體的價錢就會超過 gp2，目前看起來還是用 gp2 會好一些...
Amazon EC2 對 M5 instance 推出了帶 NVMe SSD 的版本：「EC2 Instance Update – M5 Instances with Local NVMe Storage (M5d)」。先推出歐美的區域：
M5d instances are available in On-Demand, Reserved Instance, and Spot form in the US East (N. Virginia), US West (Oregon), EU (Ireland), US East (Ohio), and Canada (Central) Regions. Prices vary by Region, and are just a bit higher than for the equivalent M5 instances.
算是 M3 系列的後繼產品？對應到四年前推出的 m3.medium 是 1 vCPU、3.75GB RAM 以及 8GB SSD (不過 m3.large 就變成 2 vCPU、7.5GB RAM 與 32GB SSD，硬碟的部份多了不少)。
這樣 M5 就更全面了...
AWS 推出了 C5d instance，同時針對 CPU 與 Disk 最佳化的機種：「EC2 Instance Update – C5 Instances with Local NVMe Storage (C5d)」。可以看出是在本地端掛上 NVMe 的方式在租用，價錢也不算高：
以帶了一個 local NVMe 的規劃來看，像是補 c3 系列產品線的感覺：
然後不是每個有 c5 的區域都會有 c5d，目前只有五區有：
C5d instances are available in On-Demand, Reserved Instance, and Spot form in the US East (N. Virginia), US West (Oregon), EU (Ireland), US East (Ohio), and Canada (Central) Regions. Prices vary by Region, and are just a bit higher than for the equivalent C5 instances.
Amazon S3 有 RRS，提供給那些掉了可以重新產生的資料使用 (像是縮圖)；另外也有 IA，提供給不常存取的資料使用。現在推出的這個等級結合了兩者，使得價錢更低：「Amazon S3 Update: New Storage Class and General Availability of S3 Select」。
New S3 One Zone-IA Storage Class – This new storage class is 20% less expensive than the existing Standard-IA storage class. It is designed to be used to store data that does not need the extra level of protection provided by geographic redundancy.
去年年底的時候 Percona 的人在 AWS 上測試 Percona XtraDB Cluster 的效能，尤其是針對底層應該選擇哪種 EBS 的部分給了一些建議。可以參考先前寫的「Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)」這篇。
當時的建議是用 io1，雖然是比較貴，但對於效能比較好。
而後來 Percona 的人收到 AWS 工程師的建議，可以用另外一個方式，可以在 gp2 上拉出類似的效能，但成本會比 io1 低不少：「Percona XtraDB Cluster on Amazon GP2 Volumes」。
這個方式是利用 gp2 會依照空間大小，計算可用的 IOPS。在官方的文件裡是這樣描述 gp2 的效能 (IOPS)：
General Purpose SSD (gp2) volumes offer cost-effective storage that is ideal for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 10,000 IOPS (at 3,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size. AWS designs gp2 volumes to deliver the provisioned performance 99% of the time. A gp2 volume can range in size from 1 GiB to 16 TiB.
在這個前提下，需要 10000 IOPS 的效能會需要 3.3TB 以上的空間，所以 Percona 就被 AWS 的工程師建議直接拉高空間重新測試：
After publishing our material, Amazon engineers pointed that we should try GP2 volumes with the size allocated to provide 10000 IOPS. If we allocated volumes with size 3.3 TiB or more, we should achieve 10000 IOPS.
首先是測出來的效能，可以看到沒有太大差異：
接下來就比較儲存成本，大約是 io1 版本的一半價錢：
如上面文件中提到的，gp1 不完全保證效能，但統計出來經常能夠提供出 3 IOPS/GB 的效能。而 io1 則是保證效能，不太需要擔心效能不穩定的問題。就是這個差異，反應到成本上面就有蠻大的差距。善用這點設計系統，應該會對整體成本有蠻大的幫助... (但對 latency 就未必了，尤其是 P99 之類的數值)
算是另外一種搞法讓大家可以考慮...
