AWS CloudWatch 推出秒級的記錄功能

AWS CloudWatch 推出了秒級的記錄功能:「New – High-Resolution Custom Metrics and Alarms for Amazon CloudWatch」。

從一分鐘變成一秒鐘讓之後的調整以及 debug 好用很多... 不過這次支援秒級的是 custom metrics,原先 AWS 自家服務的支援不在這次範圍:

Today we are adding support for high-resolution custom metrics, with plans to add support for AWS services over time. Your applications can now publish metrics to CloudWatch with 1-second resolution.

另外 alarm 的時間可以降到十秒:

You can watch the metrics scroll across your screen seconds after they are published and you can set up high-resolution CloudWatch Alarms that evaluate as frequently as every 10 seconds.

對於市場上一堆服務的衝擊應該不小 XD

所以 Netflix 也往 Google Cloud Platform 嘗試了...

看到「Netflix Security Monkey on Google Cloud Platform」這則消息,看起來 Netflix 也往 Google Cloud Platform 在嘗試了。

Netflix Security Monkey 本來是對 AWS 分析,現在則是開始支援 GCP (雖然還在 beta):

Security Monkey monitors policy changes and alerts on insecure configurations in an AWS account. While Security Monkey’s main purpose is security, it also proves a useful tool for tracking down potential problems as it is essentially a change tracking system.

AWS Lambda 支援 Node.js 4.3

AWS 宣佈 Lambda 支援 Node.js 4.3:「AWS Lambda Supports Node.js 4.3」:

You can now develop your AWS Lambda functions using Node.js 4.3.2 in addition to Node.js 0.10.4.

另外同步在「Node.js 4.3.2 Runtime Now Available on Lambda」這邊也有文章介紹。


AWS 通過的認證的證書資料連結

在「Frequently Asked Questions About Compliance in the AWS Cloud」這邊 AWS 的人列出一張表,提供了 AWS 目前所通過的認證以及證書資料。

舉例來說,在「ISO 27001 Compliance」這邊就有提供證書的 PDF 版本:「」。

但也有一些證書是沒有給出來的,應該是要另外跟 AWS 要...

Amazon 的 CTO 對 AWS 十週年的想法

雖然還沒到十週年,但 Amazon 的 CTO 還是寫下他對 AWS 十週年的想法了,也是這十年來學到的經驗:「10 Lessons from 10 Years of Amazon Web Services」。

The epoch of AWS is the launch of Amazon S3 on March 14, 2006, now almost 10 years ago.


  • Build evolvable systems
  • Expect the unexpected
  • Primitives not frameworks
  • Automation is key
  • APIs are forever
  • your resource usage
  • Build security in from the ground up
  • Encryption is a first-class citizen
  • The importance of the network
  • No gatekeepers

原來 AWS 也十年了...

RFC7686:保留 .onion 給 Tor 的 Hidden Services 使用

看到 Tor Project 很高興的宣佈 .onion 這個 TLD 在 RFC 7686 成為 Standards Track:「Landmark for Hidden Services: .onion names reserved by the IETF」。

而且也因為成為 IETF 的標準,在 CA/Browser Forum 上更有依據討論在上面的 CA 架構:

With this registration, it is should also be possible to buy Extended Validation (EV) SSL/TLS certificates for .onion services thanks to a recent decision by the Certification Authority Browser Forum.

Amazon VPC 的 Private Subnet 不需要透過 NAT 去 Amazon S3 抓資料了

在今天之前,Amazon VPC 裡 Private Subnet 的機器需要透過 NAT 才能連到 Amazon S3 的 Endpoint API 上操作:(NAT instance 會放在 Public Subnet 裡)

出自「NAT Instances」的說明。

但在這個架構中,如果 NAT instance 不夠大台,甚至是流量需求超過 10Gbps 時就會有效能瓶頸了。而目前沒有比較簡單的方法可以解決。(一種解法是拆多個 subnet 跑,透過多個不同的 NAT instance 連出去,但這樣架構又變複雜了)

今天則是公佈了讓內部可以直接存取 Amazon S3 的方式:「New – VPC Endpoint for Amazon S3」。第一波是美國 (扣除美國政府用的區域)、歐洲、亞洲、澳洲。所以是巴西與美國政府兩個區域還沒上:

Amazon VPC Endpoints for Amazon S3 are available now in the US East (Northern Virginia) (for access to the US Standard region), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), and Asia Pacific (Sydney) regions.

這樣是解了不少問題,不過如果可以直接解決 NAT infrastructure 的問題應該會更痛快?

Amazon 首次公佈 Amazon Web Services (AWS) 的財報資訊

在「Amazon Finally Discloses Cloud Services Sales, Showing 49% Jump」這篇提到 Amazon 首次在財報上公開 AWS 的營收資訊:

The first-ever disclosure of results from the Amazon Web Services division showed revenue increased 49 percent from a year earlier. AWS cranked out operating income of $265 million for Amazon, helping offset losses in other businesses. Net losses for the enlarged company came in at $57 million.

Amazon 的公開資訊可以參考「 Announces First Quarter Sales up 15% to $22.72 Billion」這篇。可以看得出來到處在燒錢,但 AWS 本身是賺錢的...

AWS 的 ELB 可以自訂 HTTP/HTTPS Timeout 時間了

Elastic Load Balancing 之前的 timeout 時間是預設值 60 秒,現在可以自訂時間了:「Elastic Load Balancing Connection Timeout Management」。


Some applications can benefit from a longer timeout because they create a connection and leave it open for polling or extended sessions. Other applications tend to have short, non- recurring requests to AWS and the open connection will hardly ever end up being reused.

目前可以設定 1 秒到 3600 秒,預設值是 60 秒。

猜測 AWS ELB 內的架構...

AWS Elastic Load Balancing (ELB) 是 AWS 在雲端上推出的 Load balancer。

在非雲端的架構上會使用 Layer 4 Switch (像是 F5Alteon),或是使用 open source 的 HAProxy

從實驗猜測 ELB 是這樣做的:

  • ELB 是 Amazon 自己開發的「軟體」,而非硬體。可能就是跑在 EC2 上,也可能為了 billing 的需求是跑在另外一個 cluster 上。
  • 在每一個有 instance 需要服務的 availability zone 上都會開一台 ELB instance 起來。
  • 每一個 ELB instance 會有一個 public IP 對外,在 ELB domain 解出來的 IP 可以查出來。

所以 ELB 的文件上會警告「每一個 AZ 的運算能力要盡可能接近」:

By default, the load balancer node routes traffic to back-end instances within the same Availability Zone.

To ensure that your back-end instances are able to handle the request load in each Availability Zone, it is important to have approximately equivalent numbers of instances in each zone.

這是因為不同 AZ 的平衡是靠 DNS round robin 處理,所以下面的例子就有建議儘量打平:

For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones.

As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a.

As a best practice, we recommend that you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones.

So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.

而量大到一個 ELB instance 撐不住的時候,AWS 就會自動開出第二台:(目前都只放在同一個 zone 上)


以這樣的架構,當量夠大的時候,AWS 應該要有能力生出足夠多的 ELB instance 打散?之後再來觀察看看好了... 還有很多煩惱要處理 ~_~