AWS CloudFront 的等級

在 CDN 報價時,會把歐美與非歐美區 (通常是指亞洲與澳洲) 的報價分開,主要是因為頻寬的成本不同。

不過亞洲客戶通常不會遇到這個問題,因為對方看你是亞洲客戶,第一份報價會直接使用亞洲區的報價,當你跟業務一直橋價錢,業務就有可能會跟跟你解釋這是因為亞洲區成本比較高 blah blah blah... 這時候業務就會拿出 US & EU only PoP 的報價單出來,如果你測過覺得 okay,那麼就搞定...

所以每次遇到 AWS 的業務被問到「你覺得 AWS 有什麼可以改善的?」幾乎都會提分級的事情,而從三年前 (應該吧) 就一直提的東西終於做出來了:「Amazon CloudFront - Cookie Support and More」。

現在 CloudFront 支援三種等級,Price Class All (預設等級,包含所有的 PoP),Price Class 200 (歐美、日本、香港、新加坡),以及 Price Class 100 (歐美),可以透過 Web Console 直接設定,接下來可以來觀察看看有哪些網站換掉 :p

找 CloudFront 問題的方法...

分別是 identity.cloudfront.netresolver-identity.cloudfront.net 的 TXT record,像是這樣:

;; QUESTION SECTION:
;identity.cloudfront.net.       IN      TXT

;; ANSWER SECTION:
identity.cloudfront.net. 60     IN      TXT     "ns-nrt52-02.cloudfront.net.nrt52"

以及:

;; QUESTION SECTION:
;resolver-identity.cloudfront.net. IN   TXT

;; ANSWER SECTION:
resolver-identity.cloudfront.net. 10 IN TXT     "210.242.135.97"

看起來是 AWS 在 forum 上回答時的 SOP 之一...

AWS CloudFront 爆炸...

發現連到 AWS 首頁出現破圖,結果發現 CloudFront 的 DNS 爆炸,不管是從 HiNet 或是從 Linode 東京查都查不到:

AWS Developer Forums 上面也開始有人問了:

晚點應該會有說明吧...

AWS CloudFront 增加的功能

引用 CTO Werner Vogels 寫的「Dynamic Content Support in Amazon CloudFront」這篇好了,雖然沒有講完整,但把重點都提到了,而且比官方網誌「Amazon CloudFront - Support for Dynamic Content」這篇清楚...

這次 AWS CloudFront 上的功能都可以在 AWS Management Console 上設定,不需要另外安裝 3rd party 軟體或是自己寫程式呼叫 API。

這次最主要的更新在支援 query string。在之前的版本,這兩個 url 會被 CloudFront 當作是同樣的 url 而被 cache 成同一份:

  • http://www.example.com/user.php?username=gslin
  • http://www.example.com/user.php?username=gslin2

而這次可以設定是否要將 query string 納入計算。

另外一個重要的設計是支援 Cache-ControlExpires,當 Cache-Control 給出 no-cache 的時候,新版的 CloudFront 可以依照 Cache-Control 的要求處理。

有了這兩個改善後,本來需要在 server workaround 的事情就可以交還給 CloudFront 處理。之後應該是試著支援像 AkamaiDynamic Site Accelerator 的功能?另外一方面也有可能讓消費者自己選擇 PoP?

功能愈來愈完整了...

Hosting Plan

2009 年在 Ptt 寫的文章有提到不少 hosting plan,2012 年現在有不少變化...

VPS 的部份,Linode 的 CPU 一向是 C/P 值超漂亮的方案。最小的方案從 384MB RAM 變成 512MB RAM (價錢沒變,仍然約 USD$20/month),在有 swap 的情況下,即使跑 ApacheMySQL 也應該還算堪用。

Linode 另外一個改變是多了東京機房。東京機房與台灣各 ISP 之間的 latency 都相當好。當以台灣使用者為主要族群而挑選 VPS 時,在東京的 Linode 主機通常是個好選擇。如果在 Linode 上面有 High Availability 需求,也有 NodeBalancer 可以用 (2011 年,Introducing NodeBalancer)。

Linode 已經算是不錯的方案,但如果你對 latency 非常重視 (日本與台灣之間大約有 30ms 的 latency) 而一定要使用台灣內部的 VPS (像是遊戲的伺服器),那麼中華的 HiCloud 會是一個可以考慮的方案。

PaaS 的部份,目前比較有名的是 Heroku,支援的語言多,而且有 free quota,對於一些小站台或是測試應用應該是沒什麼問題,不過目前只有美東 us-east-1 機房 (Heroku 用 AWS 為底層)。另外 AWS Elastic Beanstalk 的方案也可以看看,目前支援 JavaPHP 兩種語言,區域比較多。

如果是 IaaS 的部份,AWS 能提供的功能比較多,AWS 東京機房對台灣的速度也不差。另外 AWS S3 在雲端靜態儲存這個領域還是領先者,就算用 VPS 或是 Dedicated Hosting 也還是可以考慮把一些東西放到 S3 上。

Dedicated Hosting 的部份,目前還會選的是美西的 Energy Group Networks (EGIHosting) 以及 Limestone Networks。需要大頻寬的時候可以到 Dedicated Servers 這頁翻翻,或是寫信跟 EGIHosting 要 quote,當你 commit 1Gbps 含機器的價錢大約是 USD$1/Mbps (台幣 NTD$30/Mbps),連台灣的頻寬應該是透過 HE 或是 nLayer 連進來。

至於 CDN 服務,我的建議是,如果你不知道哪個比較好,就不要用吧... 等到你開始 profiling & analyze 後再回頭決定。

AWS 又降價...

剛剛才開個小會,出來就被 jnlin 提醒,AWS 宣佈降價:「AWS Announces New Data Transfer Pricing」。

自 7/1 開始,從 Internet 流入 AWS 的費用全免,另外美國與歐洲區的頻寬費再降。美國本來是 10TB 以下 USD$0.15/GB,到 50TB 以下的是 USD$0.11/GB,現在改成 10TB 以下都是 USD$0.12/GB,50TB 以下則是 USD$0.09/GB。除了普通的 data transfer 以外,CloudFront 也有對應的調整。

對於自己的機器混搭 AWS 的公司來說,光是 inbound bandwidth 不算錢就可以省下一筆可觀的金額...

Amazon Web Services Console 加強 CloudFront 設定...

之前在 AWS Console 上一直沒辦法設定 AWS CloudFront 的 Custom Origin,必須透過 3rd-party 軟體設定,而現在總算是把這個功能補上去了:「Improved CloudFront Support in the AWS Management Console」。

直接拿 Demo 的圖,最重要的 Custom Origin 功能的畫面:

AWS CloudFront Custom Origin

不過好像還是沒看到 Purge...

Blog 關掉 CloudFront CDN...

剛剛用手機看自己的 blog 發現版面亂掉,看起來是 CSS 有問題...

測了一些東西後發現,如果 W3 Total Cache 使用 CloudFront CDN,會使得 WPTouch 失效,拿掉 CDN 的部份就會恢復正常...

那只好先拿掉了,現在用手機看 blog 的人應該就正常了...

利用 AWS CloudFront 的 Custom Origin 實做標準 deflate/gzip 壓縮

在「gzip support for Amazon Web Services CloudFront」這篇提到了要如何用 CloudFront 的 Custom Origin 實做標準 deflate/gzip。

之前 CloudFront 就有支援 Vary header,雖然只支援 Accept-Encoding,但這就是我們要的:(Appendix: Custom Origins)

The only acceptable value for the Vary header is Accept-Encoding.

本來 S3 沒有能力依據 Accept-Encoding 送出不同的結果,這次有了 Custom Origin 出來以後掛個有能力 gzip-on-the-fly 的 Web Server 就可以做到了,檔案也不一定要放到 S3 上 (可以放 EBS)。

基本上這個功能可以用現有的外部機器做 (因為 CloudFront 連到 Origin 的量應該不大),或是 EC2 的 micro instance 應該也夠用了...

AWS CloudFront 支援 Non-S3 Origin 了!

AWS CloudFront 支援非 S3 的 Origin Server 了:「Amazon CloudFront Support for Custom Origins」。

這樣等於直接與現有 CDN 市場競爭,使用者可以用 EdgeCastCloud Storage 或是自己的 Origin Server,甚至是用 GitHub 直接當 Origin Server,晚點再來玩...

另外也從 Beta 畢業成為正式的服務,並正式提供 99.9% 的 SLA:「Amazon CloudFront - Production Status and an SLA」。