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 指過去就打完收工。