Home » Posts tagged "cloud" (Page 49)

AWS 進入北京!

早上的時候就有看到消息了,而剛剛在 AWS 老大 Werner VogelsTwitter 上看到他宣佈 AWS 北京區的成立:

官方公告在「Coming Soon - New China (Beijing) Region」這邊。中國大陸的官方網站在「亚马逊 AWS | Cloud Computing in China on Amazon Web Services (Simplified Chinese)」這邊。

一如往常的,有中國政府規範的但書:

This Region will allow China-based and multinational companies to make use of a broad collection of AWS services while remaining in compliance with China's legal and regulatory requirements.

要注意的是,目前列出來的服務並沒有 CloudFrontRoute53,只有看到這樣的說明:

We have been working with a number of local data center, bandwidth, and content delivery partners to bring this Region to life. Companies such as China Net Center and SINNET will provide the infrastructure, network services, and CDN services that are required to support the launch and operation of AWS technology services in China.

繼續觀望看看接下來如何...

Amazon 推出 AWS CloudTrail,可以稽核 API 使用量...

因為最近幾天是 re:Invent,所以 AWS 在這個期間會丟出很多新玩意。

這次推出的是 AWS CloudTrail,會將 API call 記錄起來存到 Amazon S3 或是透過 Amazon SNS 發出,於是你就可以利用這些資料分析出各種想要撈出的資訊:「AWS CloudTrail - Capture AWS API Activity」。

目前只支援北美的 US East (Northern Virginia) 以及 US West (Oregon),也就是 us-east-1 與 us-west-1。

AWS Storage Gateway 推出新的模式...

AWS Storage Gateway 推出新的「磁帶」模式:「Create a Virtual Tape Library Using the AWS Storage Gateway」。

原先的 AWS Storage Gateway 只支援兩種模式:

  • Gateway-Cached Volumes:實際資料在 Amazon S3 上,在本地有 cache。
  • Gateway-Stored Volumes:實際資料在本地,定時備份到 Amazon S3 上。

上面兩種方式對於 client 都還是 block storage (random access),可以用 iSCSI 掛上來用。

新的 Gateway-Virtual Tape Library (Gateway-VTL) 則是模擬磁帶架構,除了可以丟到 Amazon S3 上以外,也可以丟到 Amazon Glacier 上!XD

很有趣的架構啊... XD

AWS 的規模...

Netcraft 分析 Amazon Web Services 的規模,以及使用 AWS 的 Heroku:「Amazon Web Services' growth unrelenting」。

分析雖然只看了 HTTP 與 HTTPS 的部份,但以 AWS 的特性,應該是不差太多,所以相對性的數字應該是有參考價值的...

有這些資料後再來看:

雖然寫 4 month,但實際上應該是三個月的成長量 (二月到五月)。

us-east-1 仍然很強大 (還是沒看到 us-east-2 的消息),而 us-west-2 上個月突然有大戶進駐?跟東京與新加坡同個等級了...

另外 CloudFrontRoute 53 的成長數量也很耀眼,都是網站上設定好就可以馬上用,不需要找業務...

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability,然後發現各家 OCSP 的穩定性都不太好:「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫,當 HTTPS 連線建立中,client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制,因為已經發出去的簽名是無法被收回的,只好靠連線時再查詢。

另外一個機制比較舊,叫 CRL (Certificate Revocation List),則是屬於清單類的機制,更新速度比 OCSP 慢。

目前是以 OCSP 為主,而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響,有的影響很明顯,有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣,有些是直接上 Akamai 解決,有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail,也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明,可以挑 OCSP 速度比較快的幾家簽,對速度會有幫助...

Archives