Home » Posts tagged "aws" (Page 54)

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

Amazon EC2 增加 T2 instance

Amazon EC2 增加了新的 T2 instance:「New Low Cost EC2 Instances with Burstable Performance」。

T2 系列出了三個等級:t2.micro (1GB)、t2.small (2GB)、t2.medium (4GB)。以 us-east-1 的 t2.micro 價錢來看,只貴 t1.micro 一點點 (USD$0.012/hour 與 USD$0.013/hour),但記憶體大了不少 (640MB 與 1GB)。

另外推出了 CPU Credits 這種計算方式,可以累計 24 小時的 CPU Credits。我在想,AWS 能夠推出這個機制,是已經做到像是 VMware 的 vMotion 之類的不停機遷移嗎?對於在 10Gbps 的 1GB RAM 上的確是不用一秒鐘就可以傳完 RAM 的內容...

CPU Credits 這個機制跟 auto scaling 解決問題的方向有點不太一樣,但也是還不錯的方法... 拿來打組合拳應該還不錯 :p

另外一個比較特別的是在文末有提到對 m1.small 與 m1.medium 的想法。t2.{small,medium} 被認為是 m1.{small,medium} 的接班人 (之一?):

  • t1.micro to t2.micro
  • m1.small to t2.small
  • m1.medium to t2.medium

其中 m3.medium 之前是被認為是 m1.medium 的接班人,看起來雖然都是 General Purpose,但打算多分幾種不同的應用來滿足需求。

Instagram 從 AWS 搬到 Facebook 機房

InstagramInstagram Engineering Blog 上宣佈的消息:「Migrating From AWS to FB」。

整個 migration 的過程是採取不停機轉移,所以 effort 比直接停機轉移高很多:

The main blocker to this easy migration was that Facebook’s private IP space conflicts with that of EC2. We had but one route: migrate to Amazon’s Virtual Private Cloud (VPC) first, followed by a subsequent migration to Facebook using Amazon Direct Connect. Amazon’s VPC offered the addressing flexibility necessary to avoid conflicts with Facebook’s private network.

先把整個系統轉移到 Amazon VPC 裡,然後再拉 AWS Direct Connect 串起來,接下來才是慢慢把 instance 轉移到 Facebook 的機房內。

中間也有一些工作:

To provide portability for our provisioning tools, all of the Instagram-specific software now runs inside of a Linux Container (LXC) on the servers in Facebook’s data centers.

所以已經導入 LXC 了...

Amazon Elastic Transcoder 與 Zencoder 的比較

在「Amazon Elastic Transcoder: Review」這邊比較了 Amazon Elastic TranscoderZencoder 兩個服務。

結論在一開頭就先提出來了:

For broadcasters and high-volume producers, Amazon's Elastic Transcoder has too many limitations. For everyone else, it's an appealing, if flawed, solution.

就轉出來的品質來說,作者認為沒什麼差異:

但就速度來說,Amazon Elastic Transcoder 的速度偏慢:

另外作者在文末也給了不少負面評價... 記錄起來以後應該用的到 :o

Amazon CloudFront 的新增功能

Amazon CloudFront 新增了 Whitelist Header 的功能:「Deliver Custom Content With CloudFront」。

如同在 post 裡說明的:

If you choose the Whitelist option, each header that you add to the list becomes part of the cache key for the URLs associated with the distribution.

有點像是 HTTP 協定裡 Vary 想要解決的問題,只是做在 CDN 這端。這個功能蠻多 CDN 都有,AWS 總算補上了...

這次除了可以針對 custom HTTP header 處理外,CloudFront 還做了不少事情:

  • Mobile Device Detection
  • Geo-Targeting
  • Multi-Site Hosting
  • Protocol Detection
  • CORS (Cross Origin Resource Sharing)

前兩項還蠻有意義的,這代表會有人幫你更新資料。而 CloudFront 總算是支援 CORS 了...

Archives