Home » Computer » Network » Cloud » Archive by category "AWS" (Page 56)

AWS API 的認證方式

Amazon Web Services 有提供很多服務,有的早在「雲端風潮」前就有,有的是最近才推出的。把 AWS Documentation library 每個服務的 API 認證方式看完一遍後,只能苦笑對使用 AWS API 的人致敬...

有幾個心得與感想:

  • 文件雖然套用同一組模板 (用 frame 切開,左邊索引,右邊內容),但其中的寫法並沒有統一。理論上每個 API 都會有的 API 簽名環節在不同的文件裡可能會在不同的章節出現。
  • 認證的方式不一致:
    • 早期的服務很亂,大多都是以 SOAP 為基礎的 API,尤其是跟錢有關的這塊特別明顯 (因為 Amazon 很早就 API 化)。
    • 一開始出來的 S3 使用的是 REST 概念,簽名的值放在 HTTP Header 內,欄位名稱是 AuthorizationCloudFront 是 S3 的延伸,所以認證方式與 S3 相同。
    • 但與 S3 同時期推出的 EC2,以及後來大多數的服務,都是以 GET 為基礎。這時候兩套系統的 API 設計邏輯就不同了。
    • 最近出的 Route53,又再引入了 REST 概念,但欄位名稱為 X-Amzn-Authorization,要放的簽名格式又改變了...

這也是為什麼沒有一套 library 可以一直吃遍 AWS 服務的關係,API 的設計讓人感覺頗疲倦... XD

分析 Y Combinator 的 Startup 所使用的服務...

在 HN (Hacker News) 上看到的分析資料 (文章是 ReadWriteWeb 的):「The Services Used By Y Combinator Startups [Infographic]」,文章裡面分析了 Y Combinator「旗下」的 startup 所使用的服務。

統計資料在「Y Combinator」這邊,另外有「Quantcast Top 100」的資料也可以看看,這邊就不提 Quantcast Top 100 的情況了。

網站主機的部份,可以看到是 Amazon Web ServicesRackspace Cloud 兩家雲端服務最大,如果把同屬於 Rackspace 下的 Slicehost 一起併進去算的話就幾乎相同了。不過自己 hosting 的部份也不少...

E-mail 服務的部份以 Google Apps 過半,接下來就是自己 hosting。畢竟 Gmail 真的太好用...

DNS hosting 的部份最大一塊是自己 hosting,而 GoDaddy 有一定的比率倒是沒什麼意外... 而 DNS registrar 的部份當然是 GoDaddy 過半 XD

接近一半的 startup 沒有 SSL,如果有的大多數也都是跟 GoDaddy 買。然後有不少人是買 Wildcard SSL Certificate...

不過還是要講,重點在於挑自己熟悉而且穩定的技術,並不是用了雲端就什麼都不用學。

EC2 上的 FreeBSD 8.2-RC1...

Colin Percival 前陣子公佈了 EC2 上跑 FreeBSD 9.0-CURRENT 的 ami,當時測試覺得太慢了:「在 AWS EC2 上跑 FreeBSD」,昨天他在 Twitter 上提到把 FreeBSD 8.2-RC1 也 porting 上去了

FreeBSD 8.2-RC1 is now available on EC2 as ami-d29b6abb. http://www.daemonology.net/freebsd-on-ec2/ #merrychristmas

實際測試以後發現 8.2-RC1 還是很慢,跑 portsnap fetch 要等半個小時,跑 portsnap extract 也要再等半個小時,看起來是因為 EBS 的速度太慢?如果是這樣的話就得等非 t1.micro 的版本了 (因為 t1.micro 只能用 EBS 跑)。

以目前進度來看,8.2-RELEASE 會是第一個支援 EC2 的 production 版本?

在 AWS EC2 上跑 FreeBSD

Amazon Web Services 的官方網誌上提到了 Colin PercivalFreeBSD 9-CURRENT 放到 AWS EC2 上跑:「FreeBSD on Amazon EC2」。他的網誌也提到這件事情了:「Announcing FreeBSD on EC2」,計畫的頁面在:「FreeBSD on EC2 status」。

花了幾個小時玩,發現用 t1.micro 跑 9-CURRENT 的速度真是太慢了。就算考慮到 9-CURRENT 裡面有很多 debugging code,不過這個速度實在沒辦法測什麼東西... 在乾淨的系統裡編 mtr (WITHOUT_X11=yes) 編一個小時編不完啊 XD

等 backport 回 8-STABLE 後再來玩一次看看吧...

Route 53 的幾個網頁操作介面

目前 Route 53 還沒有 AWS Console 可以用,必須自己寫 API 呼叫,或是透過比較信任的 3rd-party website 更新。

比較早出現的是 DNS 30,背後其實就是 Bucket ExplorerSDB Explorer 的公司,介面簡單而且容易懂。由於宣稱不會將 secret key 存起來,所以每次登入後都要輸入 access key 與 secret key...

另外一個是 Ylastic,這家公司前幾天也宣佈支援 Route 53 了:「AWS Route 53 DNS Management」,他們所提供的 Screenshot 看起來也還蠻簡單易懂的:

不過我不確定 Ylastic 提供的 Route 53 服務是否免費,有興趣的可以去試看看...

Amazon Web Services 新服務:Route 53

當有多個 Data Center 的時候就應該要做的事情!Amazon 總算是出手了...

Amazon 官方的新聞稿在這:「Amazon Route 53 - The AWS Domain Name Service」,CTO Werner Vogels 的介紹在這:「Expanding the Cloud with DNS - Introducing Amazon Route 53」,產品的介紹頁在這:「Amazon Route 53」。

Route 53 是利用 Amazon 目前已經有的 Data Center (依照 CloudFront 的名單,看起來是同一組機房),加上 IPv4 Anycast 而提供的 DNS query 服務。以文件裡的範例可以看到使用了四個不同的 domain,分別是 com、net、org 以及 co.uk:

<NameServer>ns-1638.awsdns-12.co.uk</NameServer>
<NameServer>ns-144.awsdns-18.com</NameServer>
<NameServer>ns-781.awsdns-33.net</NameServer>
<NameServer>ns-1478.awsdns-56.org</NameServer>

到幾個不同的點 mtr 可以看出來有用 Anycast,只是還需要調整... 另外,依照文件看起來,暫時不提供 slave server,而必須透過提供的 API 直接改,這點是比較麻煩的地方,不知道 Console 什麼時候要提供介面...

最後來談價錢好了,每個 zone 的基本費用是 USD$1.5/month (包括 1M query/month 的量),一年也才 USD$18/year...

Route 53 之所以特別,是因為一般人就算有錢也沒辦法架出像樣的 Anycast-based DNS (這要有錢而且有量才做得到),而之前七月的時候 Cotendo 給的 quote 讓我連回信都懶得回 (雙方認知差距太大),我記得價錢好像多了好多 0...

這項服務會給自認 Anycast-based DNS 是「加值服務」而撈錢的公司一記重擊... 尤其大家都知道 Amazon Web Services 的東西出來後還是會花時間 tune,服務水準會不斷改善,比起其他公司來的穩定多了...

Archives