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

水樹奈奈的官方網站放到 Route53 + S3 + CloudFront 上...

剛剛才意外發現的,是 Route53 + S3 + CloudFront 的組合:

;; ANSWER SECTION:
www.mizukinana.jp.      60      IN      A       54.239.176.113
www.mizukinana.jp.      60      IN      A       54.239.176.150
www.mizukinana.jp.      60      IN      A       54.230.214.85
www.mizukinana.jp.      60      IN      A       54.230.214.89
www.mizukinana.jp.      60      IN      A       54.230.215.52
www.mizukinana.jp.      60      IN      A       54.230.215.91
www.mizukinana.jp.      60      IN      A       54.230.215.156
www.mizukinana.jp.      60      IN      A       54.239.176.88

這些 IP 是台灣的 CloudFront 節點。從 whois 可以看到至少是三月就這樣了?

Domain Information:
[Domain Name]                   MIZUKINANA.JP

[Registrant]                    Most Company Co., Ltd.

[Name Server]                   ns-290.awsdns-36.com
[Name Server]                   ns-1966.awsdns-53.co.uk
[Name Server]                   ns-1265.awsdns-30.org
[Name Server]                   ns-579.awsdns-08.net
[Signing Key]                   

[Created on]                    2005/09/13
[Expires on]                    2014/09/30
[Status]                        Active
[Last Updated]                  2014/03/28 12:36:18 (JST)

Netcraft 上沒有記錄到什麼時候換的:「Site report for www.mizukinana.jp」。

不過 archive.org 上可以看到改版的記錄,應該是 migration 的時候順變換過去的?看 2014/02/10 版本以及 2014/05/18 版本的差異,連結從 mizukinana.jp 變成了 www.mizukinana.jp

所以應該是三月改的?

意外的先進... XD

用 Amazon S3 送 301 重導

參考「Configure a Bucket for Website Hosting」這邊的說明就可以了,拿 test-redirect.abpe.org 當範例,先是 CNAMES3 的 website endpoint 上:(這個 bucket 我是放在 us-west-2 上,所以會指到 us-west-2 的 website endpoint)

;; ANSWER SECTION:
test-redirect.abpe.org. 7200    IN      CNAME   test-redirect.abpe.org.s3-website-us-west-2.amazonaws.com.

然後 S3 上指定 redirect rule:

  <RoutingRules>
    <RoutingRule>
    <Condition>
      <KeyPrefixEquals>img/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <HostName>www.example.com</HostName>
      <ReplaceKeyPrefixWith>img/</ReplaceKeyPrefixWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>

也就是像是這樣:

也就是說,如果是 simple redirect 的話,可以善用 S3 的這個功能而不用自己架設 web server (自己架設需要另外考慮 High Availability),還算蠻方便的?

Route 53 的大改版

Amazon Route 53 的大改版:「Route 53 Update - Domain Name Registration, Geo Routing, and a Price Reduction」。

首先是可以註冊 domain,除了 web console 外,還可以透過 API 註冊:「Actions on Domain Registrations」。

看起來 privacy protection 的部份是跟 Gandi 合作:

Turns privacy protection on or off for the domain, determining whether WHOIS queries return contact information specified in the registrar record. If privacy protection is enabled, the query returns contact information for our registrar partner, Gandi, instead of the contact information that is specified in the registrar record.

沒看到可以註冊的 tld 的 API,但是網站 web console 連進去可以看到其實相當多... (不過目前沒看到 .tw)

另外一個大功能是 Geo Routing,可以選擇洲別,或是地區別。不過「美國本土」(海外的部份有另外分區) 與「中國」這兩個網路大國都各只有一區,而不是把再依照各州或各省細分... (有不少 CDN 所提供的 DNS 服務是把美國依照各州列出設定...)

但至少補上了這一塊,這樣可以用 Route53 配合 multi-CDN 的機制,而不需要自己刻了...

然後最後是 query 的價錢降價 20%:

Last, but certainly not least, I am happy to tell you that we have reduced the prices for Standard and LBR (Location-Based Routing) queries by 20%.

是該看看要不要撤掉 Zerigo,因為目前這塊最大的成本其實是報帳以及帳號控管,而非單純租用成本 :o

AWS 的 ELB 可以自訂 HTTP/HTTPS Timeout 時間了

Elastic Load Balancing 之前的 timeout 時間是預設值 60 秒,現在可以自訂時間了:「Elastic Load Balancing Connection Timeout Management」。

文章裡有提到好處:

Some applications can benefit from a longer timeout because they create a connection and leave it open for polling or extended sessions. Other applications tend to have short, non- recurring requests to AWS and the open connection will hardly ever end up being reused.

目前可以設定 1 秒到 3600 秒,預設值是 60 秒。

Amazon EC2 增加 T2 instance

Amazon EC2 增加了新的 T2 instance:「New Low Cost EC2 Instances with Burstable Performance」。

T2 系列出了三個等級:t2.micro (1GB)、t2.small (2GB)、t2.medium (4GB)。以 us-east-1 的 t2.micro 價錢來看,只貴 t1.micro 一點點 (USD$0.012/hour 與 USD$0.013/hour),但記憶體大了不少 (640MB 與 1GB)。

另外推出了 CPU Credits 這種計算方式,可以累計 24 小時的 CPU Credits。我在想,AWS 能夠推出這個機制,是已經做到像是 VMware 的 vMotion 之類的不停機遷移嗎?對於在 10Gbps 的 1GB RAM 上的確是不用一秒鐘就可以傳完 RAM 的內容...

CPU Credits 這個機制跟 auto scaling 解決問題的方向有點不太一樣,但也是還不錯的方法... 拿來打組合拳應該還不錯 :p

另外一個比較特別的是在文末有提到對 m1.small 與 m1.medium 的想法。t2.{small,medium} 被認為是 m1.{small,medium} 的接班人 (之一?):

  • t1.micro to t2.micro
  • m1.small to t2.small
  • m1.medium to t2.medium

其中 m3.medium 之前是被認為是 m1.medium 的接班人,看起來雖然都是 General Purpose,但打算多分幾種不同的應用來滿足需求。

Instagram 從 AWS 搬到 Facebook 機房

InstagramInstagram Engineering Blog 上宣佈的消息:「Migrating From AWS to FB」。

整個 migration 的過程是採取不停機轉移,所以 effort 比直接停機轉移高很多:

The main blocker to this easy migration was that Facebook’s private IP space conflicts with that of EC2. We had but one route: migrate to Amazon’s Virtual Private Cloud (VPC) first, followed by a subsequent migration to Facebook using Amazon Direct Connect. Amazon’s VPC offered the addressing flexibility necessary to avoid conflicts with Facebook’s private network.

先把整個系統轉移到 Amazon VPC 裡,然後再拉 AWS Direct Connect 串起來,接下來才是慢慢把 instance 轉移到 Facebook 的機房內。

中間也有一些工作:

To provide portability for our provisioning tools, all of the Instagram-specific software now runs inside of a Linux Container (LXC) on the servers in Facebook’s data centers.

所以已經導入 LXC 了...

Amazon Elastic Transcoder 與 Zencoder 的比較

在「Amazon Elastic Transcoder: Review」這邊比較了 Amazon Elastic TranscoderZencoder 兩個服務。

結論在一開頭就先提出來了:

For broadcasters and high-volume producers, Amazon's Elastic Transcoder has too many limitations. For everyone else, it's an appealing, if flawed, solution.

就轉出來的品質來說,作者認為沒什麼差異:

但就速度來說,Amazon Elastic Transcoder 的速度偏慢:

另外作者在文末也給了不少負面評價... 記錄起來以後應該用的到 :o

Archives