其實以前知道 S3 可以直接上傳檔案到 Bucket 上面去，只是都沒有專案需要這方面的實作，所以就放置 play 了好一陣子。
直到我夢到一個副本級專案。
AWS S3 Browser-based Uploads Using POST
官方有說，
* HTML Forms
[http://docs.aws.amazon.com/AmazonS3/latest/dev/HTTPPOSTForms.html]
* Upload Examples
[http://docs.
人品不好有個缺點，除了 AWS 申請不過、Snapshot 不小心死掉、EBS 掛不起來之外，這次 Amazon EC2
放大絕了！就在幾天前的某個月黑風高(?)的夜晚，正在 co-work 的同事突然傳訊息來，說測試機的 SSH 打不進去了。
就此，展開了一連串奇妙的旅程(!?)
好雲端，不用嗎？
相信我在 AWS
上面撞牆的時間，應該也不算少了（默，但是，這次遇到的事情實在有點誇張。大家都在吵雲端，好像什麼東西不丟到雲端就不夠潮一樣。
我之前寫過關於 AWS 的一些操作心得，然後最近剛好有人一直來信詢問，關於 Auto Scaling
的問題，索性，我就整理成步驟好了。當然，首推外國網友這一篇，這應該是我翻過那麼多資料的最佳解了吧！
Autoscaling with custom metrics
[http://www.thatsgeeky.com/2012/01/autoscaling-with-custom-metrics/]
--------------------------------------------------------------------------------
UPDATE
先來一張圖，
首先，對於 INSUFFICIENT_DATA 的情況解釋，我想連官方都有點講不清楚。
有好一段時間，在網路服務的設備建置上面，都是幾台機器，開個虛擬化，然後丟到 IDC 之後，就這樣上線服務了。近些年來因為 Amazon
掀起的雲端熱潮，所以，手邊的機器蒙主寵招紛紛丟上雲端也是挺合理的。
有興趣的可以先看看我之前寫的文章，
[AWS] Amazon AWS 實戰筆記與心得 [https://blog.hinablue.me/entry/aws-working-with-amazon-aws/]
佈署一二三
在 AWS 上面要開啟一台機器其實不是很困難的事情。但是，當我們的維運環境比較特殊的時候，我們就必須要作一些設定，來讓我們的機器符合運作的環境需求。
只是，
雲端正夯，所以說把工作上的事情丟到雲端上面去也是很合理的。至於為什麼不選種花電信的 HiCloud 呢？這種事情還是去擲筊會比較準。
別鬧了，沒有競爭力的台灣 IDC 們
[http://www.inside.com.tw/2012/04/18/are-you-kidding-me-taiwan-idc]
電費是經營IDC的最大成本??? 搞錯了吧???
[https://www.facebook.com/notes/ben-jai/%E9%9B%BB%E8%B2%BB%
