幹壞事是進步最大的原動力
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
Cloudflare 推出了自己的 IPFS Gateway：「Cloudflare goes InterPlanetary - Introducing Cloudflare’s IPFS Gateway」。
IPFS 偏靜態性應用 (雖然官方一直很堅持說動態的資訊也可以在上面跑)，這就很適合 CDN 架構拿出來用... Cloudflare 出手應該可以讓 IPFS 的門檻再降低一些。
相較於官方提供的 ipfs.io，Cloudflare 的應該會快不少... (畢竟是直接連到最近的機房)
Amazon API Gateway 支援壓縮了：「Amazon API Gateway Supports Content Encoding for API Responses」。
You can now enable content encoding support for API Responses in Amazon API Gateway. Content encoding allows API clients to request content to be compressed before being sent back in the response to an API request. This reduces the amount of data that is sent from API Gateway to API clients and decreases the time it takes to transfer the data. You can enable content encoding in the API definition. You can also set the minimum response size that triggers compression. By default, APIs do not have content encoding support enabled.
打開後傳回的資料就會自動壓縮了，然後還可以設定觸發的 response size... 依照文件 (Content Codings Supported by API Gateway)，目前支援的壓縮格式應該是最常見的 gzip 與 deflate。
這功能好像是一開始有 API Gateway 就一直被提出來的 feature request...
AWS 宣佈可以透過 Network Load Balancer 把 API Gateway 接進 VPC 內了：「Amazon API Gateway Supports Endpoint Integrations with Private VPCs」。
You can use API Gateway to create an API endpoint that is integrated with your VPC. You create an endpoint to your VPC by setting up a VPC link between your VPC and a Network Load Balancer (NLB), which is provided by Elastic Load Balancing.
基本上是所有的區域都有了，除了美國政府的區域外：
This feature is now available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Central), South America (São Paulo), EU (Ireland), EU (Frankfurt), EU (London), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), and Asia Pacific (Mumbai) AWS regions.
是透過 NLB 接進去，而不是 ELB Classic 或是 ALB，可以來想像網路架構是怎麼做的...
Amazon API Gateway 支援 Canary Release 了：「Amazon API Gateway Supports Canary Release Deployments」。
Canary Release 重點在於逐步轉移，而不是直接硬切，大致上可以分成三個階段。
首先是一開始的情況：
切到一半的情境：
最後完全使用新版本：
這個方法可以避免新的 code 有效能問題，造成後端壓力過大... 不過這樣就要確定新舊版本的程式碼可以同時跑 (像是後端資料庫的 schema 必須相容這兩個版本)。
前幾天提到的「AWS CodeDeploy 支援在 AWS Lambda 上跑更多奇怪花樣」算是相關的功能，讓 AWS CodeDeploy 參與其中做出各種變化。
Amazon API Gateway 先前一定要跟 Amazon CloudFront 綁在一起 (而且還是很奇怪的 distribution，不是 Price Class 裡面任何一種分類)，現在總算可以獨立自己運作了：「Amazon API Gateway Supports Regional API Endpoints」。
A regional API endpoint is a new type of endpoint that is accessed from the same AWS region in which your REST API is deployed. This helps you reduce request latency when API requests originate from the same region as your REST API.
而且這樣一來，如果還是要用 Amazon CloudFront 擋在前面的話，可以自己選擇 Price Class：
Additionally, you can now choose to associate your own Amazon CloudFront distribution with the regional API endpoint.
以前用起來頗莫名其妙的 XDDD
AWS Storage Gateway 推出新功能 File Gateway：「File Interface to AWS Storage Gateway」。
可以讓使用者在前面用 NFS，後面實際接的是 Amazon S3：
After you set it up in your data center or in the cloud, your configured buckets will be available as NFS mount points. Your application simply reads and writes files and directories over NFS; behind the scenes, the gateway turns these operations into object-level requests on your S3 buckets, where they are accessible natively (one S3 object per file).
以前自己用 FUSE 惡搞的方式，現在變成官方支援的功能？XDDD
每次遇到 AWS 業務就會抱怨的功能總算推出來了，VPC NAT Gateways：「New – Managed NAT (Network Address Translation) Gateway for AWS」。
與自己用 EC2 架設的不同點在於處理的流量也要計費，但好處是以前得自己處理 HA，現在 AWS 幫你做掉這塊，不過 scalability 還是限制在 10Gbps：
The gateway has built-in redundancy for high availability. Each gateway that you create can handle up to 10 Gbps of bursty TCP, UDP, and ICMP traffic, and is managed by Amazon. You control the public IP address by assigning an Elastic IP Address when you create the gateway.
要注意的是流量計費這塊收費很貴 (非常貴)，有大量連外需求的機器，還是用 public ip 直接連外會比較省，或是用老方法自己架設 NAT instances 處理。
WeeChat 上的 buffers.pl 是個很好用的套件，可以在側邊列出 channel，像是這樣：
其中一個特點是，左側的 channel list 會自動伸展到目前最長的 channel name。由於我用 WeeChat 連 Slack 提供的 IRC Gateway，加上最近提供多人交談的功能，就產生出這樣的 channel name：
#mpdm-gslin--persona--personb--personc--persond--persone----1
解法是限制側邊的寬度，用 /set buffers.look.name_size_max 32 後再 /save 存起來就可以了。是在「[buffers.pl] name_size_max adding crop suffix too soon in certain cases」這邊找到的關鍵字。
在「Creating An Amazon API Gateway With aws-cli For Domain Redirect」這邊看到用 Amazon API Gateway 重導整個網域的方法。一般的做法是用 Amazon S3 (用 web hosting 重導) + Amazon CloudFront (for HTTPS) 堆出來，事實上這個方法成本也比較低，這篇文章只是示範怎麼用而已：
I’m not saying the API Gateway method is better than using S3 plus CloudFront for simple hostname redirection. In fact, it costs more (though still cheap), takes more commands to set up, and isn’t quite as flexible in what URL paths get redirected from the source domain. It does, however, work and may be useful as an API Gateway aws-cli example.
可以從中間學到一些東西，尤其是可以看到如何使用 aws-cli 操作 Amazon API Gateway 的部分...
