Tag: elb

Mozilla 提供了 SSL/TLS 設定懶人包

Mozilla 的 Mozilla SSL Configuration Generator 提供了各種 server side 的設定：

以及不同等級的設定 (Modern、Intermediate、Old)，另外還有 HSTS 的選項可以選擇。

對於 security 的東西我不是很喜歡用 generator (因為我覺得既然是資安相關的東西，要盡可能知道每個細節)，但算是一種推廣吧，看了一下設定也都還算合理...

ELB 預設關閉 RC4 Cipher

在 Twitter 上看到 Jeff Barr 轉貼自論壇的公告：「Announcement: Elastic Load Balancing releases security update to disable RC4」。

既有的 ELB 不受影響，不過官方還是建議把現有的 RC4 關閉。新開的 ELB 如果需要 RC4 也還是可以手洞開回來：

If you require RC4 ciphers you can re-enable them by selecting the 2014-10 SSL Security Policy or by manually configuring the SSL ciphers used by the load balancer.

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 秒。

Elastic Load Balancing 總算實做 access log...

AWS 的 Elastic Load Balancing 總算想起來這個欠了許久的功能，access log：「Access Logs for Elastic Load Balancers」。

原文裡有提到用 Hive 分析的部份，挑出最前面的欄位名稱就可以看出提供什麼資訊：

CREATE EXTERNAL TABLE elb_raw_access_logs (
     Timestamp STRING,
     ELBName STRING,
     RequestIP STRING,
     RequestPort INT,
     BackendIP STRING,
     BackendPort INT,
     RequestProcessingTime DOUBLE,
     BackendProcessingTime DOUBLE,
     ClientResponseTime DOUBLE,
     ELBResponseCode STRING,
     BackendResponseCode STRING,
     ReceivedBytes BIGINT,
     SentBytes BIGINT,
     RequestVerb STRING,
     URL STRING,
     Protocol STRING
)

裡面還有些資訊沒包含在上面，像是 availability zone。因為這個資訊是包含在檔名內：

In addition to the bucket name and the prefix that you specified when you configured and enabled access logs, the log file name will also include the IP address of the load balancer, your AWS account number, the load balancer's name and region, the date (year, month, and day), the timestamp of the end of the logging interval, and a random number (to handle multiple log files for the same time interval).

接下來應該要把現有的 ELB 都開起來 XD

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能：「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy)，愈大多數的實做相同，是使用 ECDH。

第二個是 Server Order Preference，由 server 這邊決定最終的 cipher。

最重要的是第三個，也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01，把上面兩個都設進去了。

這次的升級是對安全性的提昇...

猜測 AWS ELB 內的架構...

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

在非雲端的架構上會使用 Layer 4 Switch (像是 F5、Alteon)，或是使用 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 上)

;; ANSWER SECTION:
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.249.68.121
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.238.240.61

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

Delicious 正式換手營運...

前幾天 Delicious 正式從 Yahoo! 換手給 AVOS Systems 營運，並進入 beta 階段：「A New Flavor…Still Delicious」。

這次轉入 beta 用的是 AWS US-West (而不是最大的 US-East)：
www.delicious.com. 300 IN CNAME web-prd-1829768734.us-west-1.elb.amazonaws.com.
web-prd-1829768734.us-west-1.elb.amazonaws.com. 60 IN A 50.18.62.3
Server 用 nginx (可以參考 Site report for www.delicious.com 這邊的資料)，頁面改用 HTML5，目前看起來沒有用 CDN。

比較意外的是沒有用 Google Analytics，而是用 Chartbeat。

超大型網站 re-startup？好像很有趣...