Amazon S3

[AWS] 使用 Uploadify 直接上傳 S3

其實以前知道 S3 可以直接上傳檔案到 Bucket 上面去，只是都沒有專案需要這方面的實作，所以就放置 play 了好一陣子。 直到我夢到一個副本級專案。 AWS S3 Browser-based Uploads Using POST 官方有說， HTML Forms Upload Examples POST with Adobe Flash 但是，依照 Amazon AWS 文件的慣例就是，文件基本上只是參考用，實際上會遇到的小毛病，也得要遇到了才知道。
Amazon AWS

[AWS] 雲端之出來跑的總是要還

人品不好有個缺點，除了 AWS 申請不過、Snapshot 不小心死掉、EBS 掛不起來之外，這次 Amazon EC2 放大絕了！就在幾天前的某個月黑風高(?)的夜晚，正在 co-work 的同事突然傳訊息來，說測試機的 SSH 打不進去了。 就此，展開了一連串奇妙的旅程(!?) 好雲端，不用嗎？ 相信我在 AWS 上面撞牆的時間，應該也不算少了（默，但是，這次遇到的事情實在有點誇張。大家都在吵雲端，好像什麼東西不丟到雲端就不夠潮一樣。
CloudWatch

[AWS] Auto Scaling with custom metrics

我之前寫過關於 AWS 的一些操作心得，然後最近剛好有人一直來信詢問，關於 Auto Scaling 的問題，索性，我就整理成步驟好了。當然，首推外國網友這一篇，這應該是我翻過那麼多資料的最佳解了吧！ Autoscaling with custom metrics UPDATE 先來一張圖， 首先，對於 INSUFFICIENT_DATA 的情況解釋，我想連官方都有點講不清楚。我們先來看 mon-put-data 到底做了什麼事情， --metrics-name 測量的名稱 --namespace 所屬命名空間 --dimensions
AWS

[AWS] 自動佈署、擴展與高可用性實作筆記

有好一段時間，在網路服務的設備建置上面，都是幾台機器，開個虛擬化，然後丟到 IDC 之後，就這樣上線服務了。近些年來因為 Amazon 掀起的雲端熱潮，所以，手邊的機器蒙主寵招紛紛丟上雲端也是挺合理的。 有興趣的可以先看看我之前寫的文章， [AWS] Amazon AWS 實戰筆記與心得 佈署一二三 在 AWS 上面要開啟一台機器其實不是很困難的事情。但是，當我們的維運環境比較特殊的時候，我們就必須要作一些設定，來讓我們的機器符合運作的環境需求。 只是，每一次開一台機器，都要作一次相關的設定，不是很煩嗎？所以，這個時候我們也可以把 EC2
AWS

[AWS] Amazon AWS 實戰筆記與心得

雲端正夯，所以說把工作上的事情丟到雲端上面去也是很合理的。至於為什麼不選種花電信的 HiCloud 呢？這種事情還是去擲筊會比較準。 別鬧了，沒有競爭力的台灣 IDC 們 電費是經營IDC的最大成本??? 搞錯了吧??? HiCloud 的頻寬計價現況與對比 Amazon AWS 的簡要分析 你看完再決定你要不要用 HiCloud... Why Amazon? 跟傳統的 Hosting 比起來，當然可以自己控管的虛擬主機是比較有彈性的。那或許你會說，VPS 也不錯啊，的確，市面上還是有許多不錯的 VPS 服務商，在價格上也略顯優勢（
EBS

[AWS note.] 貧民老百姓之 EBS 一個月初心得

AWS之免費的最貴！ 這就是 AWS 啊！雖然說 t1.micro 有許許多多免費的可以用，但是總結下來（大哥說得對，這是戰爭！）他還是收得到錢的！所以，既然一定會被收錢，那麼，就來看看哪裡是癥結點了。 首先請看一下 Account Activity 的部份！ EC2 的使用時間我目前為止是 538 個機器/小時，收費 0.00 鎂。 儲存裝置（t1.micro）我只有開一台，
Amazon AWS

[AWS] 天邊一朵雲之 EC2 小筆記

總算是把部落格的東西全部丟到 AWS 上面了。原本以為會很順利的申請到 EC2 的，結果因為電話認證人品問題搞了三天才請 SDpower 幫我搞定。果真申請 Amazon Web Services 人品都要很好（喂）。 總結來說，AWS 申請算是很無腦的，只是有些地方需要仔細看一下，大抵上照著 Hank 的書，都可以完成絕大部分的申請以及操作的動作。而做完你所需要的 EC2 環境之後，接下來就是自己設定你所需要的主機了。最後，再去申請一個靜態的 IP，然後把 DNS 指過去就打完收工。