根據 AWS Blog，AWS 開始提供使用者發送大量 Email 的服務 (Simple Email Service, SES)。價錢是每一萬封信 USD$1，流量費用另計。
要使用 SES 的服務是需要 Amazon 審核通過的，在未通過之前，收件者必須先使用 SES 的 API 認證過才能收到信，並且有一天最多寄出 200 封信的限制。審核通過後，任何收件者都能收到信，但是一開始一天最多只有 1000封信的Quota，隨著使用量與使用情形（例如Amazon有沒有收到 complain）而增加，最大一天可以寄出100萬封信。
另外寄信的速度也有限制。一開始是每秒鐘一封信，隨著使用狀況調整，最大可以到每秒鐘 90 封信。如果有一天寄出超過100萬封信的需求，可以向AWS提出調整要求。
另外，SES也可以整合進現有的Email Server裡面。（Postfix 範例）
根據AWS Blog，現在可以把支援 USB 2.0、eSATA或 SATA 的儲存裝置（例如硬碟）寄到新加坡，讓AWS把資料Import進S3或是從S3裡面把資料拷貝出來。
對於使用S3來備份、或是打算migrate到S3的企業來說比較方便省錢了。
昨天出來的新聞：FreeBSD on Amazon EC2。
目前只有美東這區有，然後只支援t1.micro這個大小的instance，目前還屬於實驗性質。
穩不穩定要跑一陣子才知道，不過看起來Amazon有提供協助，所以應該還算可以期待吧。
head.js是一個很小（只有2.3kb）的javascript程式，主要的功能是可以「非同步」的載入javascript。在head.js自己的網站介紹中，很大膽的說「The only script in your <HEAD>」。更精確的來說，使用head.js以後只需要有一個 script tag載入head.js，其他的 javascript 檔案都可以用head.js來載入。
其實非同步載入javascript的技術已經很成熟了，像是Google Analytics就有提供非同步載入的程式碼。由於Browser在處理<script> tag的時候會block住整個頁面的render（為了要處理 document.write()）與頁面上其他 resource 的載入，所以能夠用非同步的方式載入javascript的話，除了不會 blocking render 讓使用者更快看到頁面之外，也可以平行地載入不同的script，加快整個網頁的載入速度。
但是非同步載入有個問題：如何保證執行javascript時的相依性？（例如，一定要先執行完 A script 才能開始執行 B script。）這點要自己處理的話很麻煩，但 head.js 已經幫忙作掉了。
// load files in parallel but execute them in sequence
head.js("file1.js", "file2.js", ... "fileN.js");
這樣的話就會同時載入file[1-N].js，但是按照順序執行file1.js ~ fileN.js。
有人會說，如果全部壓成一個很大的檔案，不就沒有執行順序的問題了嗎？但是壓成大檔的壞處是，即使只更新一個小功能，整個大檔案都必須重新load。另外，iPhone 的 safari 最大只 cache 單檔大小 15~25kb 的檔案 ((http://www.phpied.com/iphone-caching/)) 。
不過要注意的是，head.js的非同步載入也有一些限制，可以到http://headjs.com/ 去看看 “ Developing with Head JS” 這一段的說明。
除此之外，head.js 還有提供 CSS3 feature detection的功能，在不支援CSS3功能的瀏覽器上，<html>這個元素會被加上相對應的class。例如瀏覽器不支援CSS3 的 borderimage 屬性的話，他的 <html> 元素就會被加上 no-borderimage 這個 class，方便前端工程師寫出替代方案。
另外還有螢幕大小偵測、瀏覽器偵測、HTML5 enabler（讓CSS可以style一些HTML5 tag）等等功能，看起來這些功能的主要目標是放在行動市場。原始碼放在 github。
相關閱讀：http://kaix.in/daddy/2010/12/head-js-the-only-script-in-your-head/
AWS今天推出Amazon Route 53，本質上是一個DNS Hosting服務，價格是每一百萬個 DNS Query收費USD$0.5，超過十億個Query後每百萬個USD$0.25，然後每個Domain每個月要多收USD$1。
根據Amazon CTO Werner Vogels的說法，採用的是Anycast的技術。在全球有16個點，包含亞洲的香港、東京與新加坡。實測起來，從台灣到亞洲的Routing還不錯，但美國的Routing有點不夠好，有的地方RTT大概還要接近100ms。
另外，尚未支援wildcard以及在一個zone file裡面有subdomain的entry，你必需要另外切開成另一個zone file。目前也不能當作其他DNS Server的Slave。
如果未來能夠支援從別的DNS master server 用 zone transfer 的方式進入Route 53的話，使用的彈性會大非常多。
2010/12/17 Updated: 今天的 AWS Webinar 說明了現在已經支援 wildcard! 剛剛實測的結果，在一個 zone file 放 subdomain 的 entry 的功能也支援了，現在已經不需要另外切開成另一個 zone file。
根據 AWS Blog ：Amazon CloudFront Support for Custom Origins，CloudFront開始支援Custom Origin功能。可以把EC2或者自己的Server當作CloudFront的Origin Server，透過 CDN 以獲得更快的速度。公告中也提供了使用Custom Origin的注意事項。
不過，我下載了公告中號稱支援的軟體，每一套都沒找到在哪裡設定；官方的Web Console也尚未支援，倒是 API 頁面已經有說明設定方法了。看起來就等Web Console改版或是等s3cmd把這個功能作進去吧。
Google 前幾天放出的 Apache Module mod_pagespeed 直接把一些網站最佳化在 Apache 吐出去前作掉：
沒有做的最佳化：
各個Filter可以獨立套用，所以如果你已經有用 YUI Compressor 或者Closure Compiler 的話，可以不需要套用相關的 Filter。
目前還不支援 prefork 以外的 MPM，所以暫時沒辦法測就是……（手邊的機器都跑 worker MPM 了）。
直覺想到是因為 Windows Azure 的競爭。AWS從11月1日開始提供新使用者一年的免費Quota。
詳情可見 http://aws.amazon.com/free/ 。
根據 AWS 公告，Cloudfront 從現在開始提供 Cache Invalidation 的API，不過每次Invalidation要USD$0.005（前1000次免費），是跟其他CDN不一樣的（其他CDN大多限制每小時能呼叫API的數目）。
另外Cloudfront目前並沒有提供wildcard或是regular expression的Cache Invalidation功能。
前幾日終於拿到之前申請的Android App Inventor邀請了，稍微玩了一下：
介面像Visual Studio一樣，元件是用拖拉的。
不過觸發的事件也是拖拉的，就如上面的方塊一樣。有種在組樂高積木的感覺XD
元件還不多，一個可以連網路的元件叫做 TinyWebDB，是一個Key-Value based 的 Network Storage Database。官方有API，除了可以用App Engine上的版本外，也可以自己寫一個。
另一個可以連網路的元件叫做Twitter…XD
此外一些基礎元件，像是WebView、OAuth或是RSS Feed都還欠缺，不過寫簡單的透過網路查（公開）資料的程式應該沒問題就是了…