Tag: s3

Amazon VPC 的 Private Subnet 不需要透過 NAT 去 Amazon S3 抓資料了

在今天之前，Amazon VPC 裡 Private Subnet 的機器需要透過 NAT 才能連到 Amazon S3 的 Endpoint API 上操作：(NAT instance 會放在 Public Subnet 裡)

出自「NAT Instances」的說明。

但在這個架構中，如果 NAT instance 不夠大台，甚至是流量需求超過 10Gbps 時就會有效能瓶頸了。而目前沒有比較簡單的方法可以解決。(一種解法是拆多個 subnet 跑，透過多個不同的 NAT instance 連出去，但這樣架構又變複雜了)

今天則是公佈了讓內部可以直接存取 Amazon S3 的方式：「New – VPC Endpoint for Amazon S3」。第一波是美國 (扣除美國政府用的區域)、歐洲、亞洲、澳洲。所以是巴西與美國政府兩個區域還沒上：

Amazon VPC Endpoints for Amazon S3 are available now in the US East (Northern Virginia) (for access to the US Standard region), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), and Asia Pacific (Sydney) regions.

這樣是解了不少問題，不過如果可以直接解決 NAT infrastructure 的問題應該會更痛快？

Treasure Data 用 AWS 的方法

在 Zite 上看到「Treasure Data and AWS - Developers.io 2015」這篇，可以看看 Treasure Data 遇到的問題以及他們的解法。

這種文章除了看「怎麼做」以外，如果有提到「不怎麼做」也很值得看，也就是解釋避開了哪些東西。

像是他們拿 PostgreSQL 放 metadata 這件事情就很奇怪：

而他們解釋 Amazon S3 的 LIST 的品質有問題：

另外也說明了因為 GiST 的需求，所以不使用 MySQL，而且這也自動說明了 Amazon DynamoDB 不符合需求：

另外也遇到與 Netflix 同樣的問題，寫進去後因為 S3 的 Eventually Consistent 性質，不保證馬上讀的到：

如果沒有用到 GiST，用 DynamoDB 放 metadata 好像可以解決問題...

Amazon S3 的 Cross-Region Replication

AWS 宣佈的新功能，自動 replicate 到其他區域的 Amazon S3 上：「New – Cross-Region Replication for Amazon S3」。

需要打開 Versioning 的功能，然後就可以設定了：

新上傳的 object 才會被 replicate，原先的 object 是不會有改變的。

AWS 對外頻寬與 CloudFront 頻寬降價

AWS 在「AWS Data Transfer Price Reduction」這邊宣佈降價，回朔至 2014 年 12 月 1 日開始計算。

分成一般 Outbound 與 CloudFront Outbound 部份。

一般 Outbound 的部份，US/EU 主要降價的部份是一開始的流量 (10TB 以下的部份)，亞洲區的部份主要是新加坡降價特別多，大概是把量養出來了？

CloudFront Outbound 的部份主要也是在 10TB 以下的部份。

另外一個比較特別的地方 (但也許沒有太大差異)，是 CloudFront 往 origin 抓資料時，如果 origin 在 AWS network 內就不計算費用 (包括了 S3 與 EC2)。

如果暫時先不考慮 per request 費用，會注意到 US/EU 一般 Outbound 的費用是 USD$0.90/GB，而 CloudFront 是 USD$0.85/GB，量更大的時候會更明顯？

馬上想到 Netflix 這種單一 request 會有巨大流量的用法會隨著這次計費方式改變而有變化？

Amazon S3 的 Event Notification

在「New Event Notifications for Amazon S3」這邊提到的重點：

The bucket owner (or others, as permitted by an IAM policy) can now arrange for notifications to be issued to Amazon Simple Queue Service (SQS) or Amazon Simple Notification Service (SNS) when a new object is added to the bucket or an existing object is overwritten.

也就是說，S3 上有變動時會透過 SQS 觸發後續行為。由於這是 AWS 自己提供的功能，解決了以往「上傳檔案後自己觸發 SQS」不能保證 atomic 的問題。

好像馬上就想到某個專案可以用到...

EMR 對 S3 Consistency 的補強

今年一月的時候，Netflix 曾經寫過一篇關於對 S3 的 Eventually Consistency 的問題：「Netflix 對 S3 的 Eventually Consistency 的補強...」，當時 Netflix 的作法是實做 s3mper 以確保一致性。

過了半年，AWS 的人在 EMR 上實做了類似的功能：「Consistent View for Elastic MapReduce's File System」。

看文章的說明，應該是用到 DynamoDB 負責 S3 上資料的狀態，而 DynamoDB 的資料並不會砍掉，所以在使用時要注意這點 :o

水樹奈奈的官方網站放到 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 當範例，先是 CNAME 到 S3 的 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)，還算蠻方便的？

AWS 跨區域搬大量資料的方式

AWS 跨區域搬資料有一堆方式，而官方今天在 blog 上推薦了用 Tsunami UDP 搬移的方式：「Moving Big Data into the Cloud with Tsunami UDP」。

看文章上的說明，看起來是從 Tokyo 搬到 Virginia (還是反過來？)，有很穩定的 651Mbps 在傳輸 XD

看起來之後用的到，這個方法留起來參考...