Tag: cloudfront

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-Control 與 Expires，當 Cache-Control 給出 no-cache 的時候，新版的 CloudFront 可以依照 Cache-Control 的要求處理。

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

功能愈來愈完整了...

Hosting Plan

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

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

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 的方案也可以看看，目前支援 Java 與 PHP 兩種語言，區域比較多。

如果是 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 市場競爭，使用者可以用 EdgeCast 的 Cloud Storage 或是自己的 Origin Server，甚至是用 GitHub 直接當 Origin Server，晚點再來玩...

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