Tag: pricing

Home » Posts tagged "pricing"

Amazon EFS 的 IA Storage Class

Amazon EFS 一直找不太到好用的使用情境，因為 NFS 的關係所以大量 I/O 時的 latency issue 使得速度快不起來，而拿來堆 log 的成本又超級高...

最新推出的 storage class 則是透過提供低儲存成本的版本，解決了堆 log 這種使用情境：「New – Infrequent Access Storage Class for Amazon Elastic File System (EFS)」。

不過 EFS 不像 S3 可以直接選擇 storage class，是需要讓系統管理的：

開啟後 30 天沒有被碰過的檔案就會切過去：

Eligible Files – Files that are 128 KiB or larger and that have not been accessed or modified for at least 30 days can be transitioned to the new storage class. Modifications to a file’s metadata that do not change the file will not delay a transition.

而 latency 也會增加：

Files that have not been read or written for 30 days will be transitioned to the Infrequent Access storage class with no further action on your part. Files in the Standard Access class can be accessed with latency measured in single-digit milliseconds; files in the Infrequent Access class have latency in the double-digits.

以 us-east-1 為例子來說，Standard 是 USD$0.3/GB-month，而 IA 只要 USD$0.045/GB-month，但抓取時會有 USD$0.01/GB 的傳輸費用，可以看出價錢低不少。

不過文章裡沒提到什麼時候會把資料從 IA 跳回 Standard，可能得找機會問問看...

AWS, Cloud, Computer, Murmuring, Network, ServiceNo Comment

DynamoDB Autoscaling 的各種眉眉角角...

AdRoll 用 DynamoDB Autoscaling 的踩雷記錄，裡面有些資訊如果不是跳下去玩應該不會注意到 (魔鬼藏在細節裡的感覺)：「Managing DynamoDB Autoscaling with Lambda and Cloudwatch」。

第一個提到的問題是 autoscaling 的觀察對象：

Ideally, the table should scale based on the number of requests that we are making , not the number of requests that are successful.

另外一個是 autoscaling 遇到完全不用的情況下不會 scale down，看起來是某種保護機制。但這使得平常只有拿來讀取的表格在跑完 batch job 後得自己處理 write scale down 問題：

Additionally, at the time of implementing this algorithm, the DynamoDB capacity could not be brought down automatically if the consumption was exactly zero, which can happen if you write to your table in batch instead of realtime, for example.

This meant that, when enabling autoscaling, tables that were read in realtime, but written to in batch, still needed manual intervention to bring the write capacity down after our jobs were done writing.

另外一個問題是 scale down 是有次數限制的：

Another interesting point that might bite users is that capacity decreases are an expensive operation for AWS, so they’re limited.

The number of decreases cited in the documentation can be achieved under very special conditions, since you need to have 4 decreases in the first hour of the day plus one for each of the remaining hours, for a total of 4 (first hour) + 23 (1 hourly) = 27.

後面就是自己研究什麼 algorithm 可以調整的更細，然後用 lambda 重寫... 最後省下 30% 的成本：

Here is where we detected our costs for our batch tables dropping to around 30% of the initial cost.

AdRoll 的規模應該是不小，所以為了省 30% 可以花不少力氣在上面...

AWS, Cloud, Computer, Database, Murmuring, Network, Service, SoftwareNo Comment

Linode 推出 Dedicated CPU Instances

Linode 決定要推出 Dedicated CPU Instances，看起來相當於 AWS 的 EC2 裡一般性的 EC2 instance (指非 t 系列的)，跟之前 CPU 共用而導致 CPU 可能時快時慢不同，這個方案讓 CPU resource 穩定輸出：「Introducing: Linode Dedicated CPU Instances」。

Dedicated instances are optimized for workloads where consistent performance is required or where full-duty work (100% CPU all day, every day) needs doing.

拿 EC2 裡的 c5.large (2vCPU + 4GB) 比較差不多是一半的價錢，但實際不知道差多少... 回台灣的時候測試看看好了。看起來如果真的要在 Linode 上跑 Kubernetes 的話反而要用這種機器？

Cloud, Computer, Hardware, Murmuring, Network, Service1 Comment

AWS 宣佈 Fargate 大幅降價

AWS Fargate 大幅降價：「Announcing AWS Fargate Price Reduction By Up To 50%」、「AWS Fargate Price Reduction – Up to 50%」。

先前 Fargate 的定價超級高，基本上是不會有正常應用會丟上去的情境... 如果可以接受 Fargate 的價錢，平常就用 ECS 或是 EKS 開三到五倍的機器在旁邊待機就好了，container scale 的速度還比 Fargate 快。

這次降價幅度很大，vCPU 降 20% 其實不算小，但相較於 Memory 降的 65% 就感覺好像沒降很多 (...)：

Effective Jan 07, 2019, we are reducing the price for AWS Fargate by 20% for vCPU and 65% for memory across all regions where Fargate is currently available.

拿 us-east-1 上 m5.24xlarge 的價錢來看是 USD$4.608/hr。以他的 96 vCPU + 384 GiB RAM 對應到 Fargate 來算是 USD$5.59296/hr，大約多 21% 的價錢。

這樣的產品價位看起來才有對應的空間...

AWS, Cloud, Computer, Murmuring, NetworkNo Comment

EC2 開始陸續推出支援 100Gbps 網路的機器

AWS 開始陸陸續續在推出有 100Gbps 能力的 EC2 instance 了：「New – EC2 P3dn GPU Instances with 100 Gbps Networking & Local NVMe Storage for Faster Machine Learning + P3 Price Reduction」。

從「Amazon EC2 Instance Types」這邊可以看到先前只有 c5n.18xlarge 有支援 100Gbps 網路，現在推出的 p3dn.24xlarge 是第二個支援的...

另外是 P3 系列的降價消息，比較奇怪的是從 2018/12/06 開始生效，而不是從月初開始。另外區域與條件也有一些複雜，有常在用的人可以翻一下說明...

AWS, Cloud, Computer, Hardware, Murmuring, Network, ServiceNo Comment

EC2 支援休眠

AWS 對 EC2 instance 推出了休眠模式：「New – Hibernate Your EC2 Instances」。

休眠模式主要是透過保留記憶體內的內容 (會寫到 EBS 裡)，讓機器開起來比較快，不過這邊有要求 root EBS volume 需要加密：

When an instance is instructed to hibernate, it writes the in-memory state to a file in the root EBS volume and then (in effect) shuts itself down. The AMI used to launch the instance must be encrypted, as must the root EBS volume of the instance. The encryption ensures proper protection for sensitive data when it is copied from memory to the EBS volume.

費用的部分是 EBS volume 與 Elastic IP：

While the instance is in hibernation, you pay only for the EBS volumes and Elastic IP Addresses attached to it; there are no other hourly charges (just like any other stopped instance).

一般對外服務的伺服器好像用不太到... 應該是內部系統或是開發機的需求？

AWS, Cloud, Computer, Hardware, Murmuring, NetworkNo Comment

貴不少的 DynamoDB On-Demand...

DynamoDB 用起來比較困難的部份就是規劃 R/W capacity，所以 AWS 就推出了 DynamoDB On-Demand，直接計算用多少而不用規劃 R/W capacity：「Amazon DynamoDB On-Demand – No Capacity Planning and Pay-Per-Request Pricing」。

先講一下歷史，在 2014 的時候 Jeff Barr 就有在「Auto Scale DynamoDB With Dynamic DynamoDB」這邊提到開一台 t1.micro 在上面跑程式實做 DynamoDB 的 auto scaling。

另外在 2017 年的時候 AWS 自己推出了同樣的功能，就不需要開機器了，交給 AWS 的服務處理就可以了：「New – Auto Scaling for Amazon DynamoDB」。

所以就一般性的需求來說，其實目前的方案夠用：常態性的需求提昇，以及有預期性的活動時可以手動事前提昇。

目前想到唯一會炸掉的情境應該是突然被熱門媒體報導，而導致大量的 guest session 衝進來，而且架構上又沒有針對 guest session 用 cache 擋住 (Amazon DynamoDB Accelerator 也是個選項)，導致壓力就全部到後端的 DynamoDB，而 auto scaling 機制需要時間看到量才會調整，在這段時間就有可能短時間倒站。

回來看這次的 On-Demand 提出來的價錢。以 us-east-1 的價錢來看：

Write request units$1.25 per million write request units
Read request units$0.25 per million read request units

而本來要自己規劃 R/W capacity 的價錢是 (這邊是 hourly)：

Write capacity unit (WCU)$0.00065 per WCU
Read capacity unit (RCU)$0.00013 per RCU

由於不管是 On-Demand 還是本來的規劃，Read 價錢都是 Write 的 1/5，所以只要看 Write 一樣可以知道差距。

接下來把 On-Demand 的價錢換算成 3600 個 request units 就可以比較單價，是 $0.0045 (Write)，大約是本來版本 6.92 倍的費用...

而且對於已經有規模的應用，這邊還沒算 Reserved Capacity 會有折扣的部份？

這個定價策略讓我想到 AWS Fargate 的情況... 如果你可以接受這個價錢，你可以平常就開五倍的 R/W capacity 在上面啊 XDDD

AWS, Cloud, Computer, Murmuring, Network, ServiceNo Comment

Amazon S3 推出了一個自動分析後分類的 Storage Class

Amazon S3 推出了新的 Storage Class，後面直接用演算法分析 access pattern (所以要跑一陣子才會生效)，然後決定要放到 Standard 或是 Standard IA 裡：「Announcing S3 Intelligent-Tiering — a New Amazon S3 Storage Class」。

混了 Standard 與 Standard IA：

S3 Intelligent-Tiering stores objects in two access tiers: one tier that is optimized for frequent access and another lower-cost tier that is optimized for infrequent access.

然後連續 30 天沒有被存取的就會被丟到 Standard IA，如果有被存取的話就會被搬回來，而搬移的部份不用收費：

For a small monthly monitoring and automation fee per object, S3 Intelligent-Tiering monitors access patterns and moves objects that have not been accessed for 30 consecutive days to the infrequent access tier. There are no retrieval fees in S3 Intelligent-Tiering. If an object in the infrequent access tier is accessed later, it is automatically moved back to the frequent access tier. No additional tiering fees apply when objects are moved between access tiers within the S3 Intelligent-Tiering storage class.

從費用上可以看到演算法本身是有費用的，換算一下 1M objects 是 USD$2.5/month，好像還可以...

Monitoring and Automation, All storage / Month$0.0025 per 1,000 objects

不過有蠻多要注意的 pattern。像是這邊有提到 128KB 以下的檔案不會搬到 IA 上，但不知道算不算 Monitoring 的費用？

S3 Intelligent-Tiering has a minimum eligible object size of 128KB for auto-tiering. Smaller objects may be stored but will always be charged at the Frequent Access tier rates.

另外這邊講 S3 Intelligent-Tiering 的三十天也不知道是不是 Standard + Standard IA，或是分開算：

S3 Intelligent-Tiering, S3 Standard-IA, and S3 One Zone-IA storage are charged for a minimum storage duration of 30 days.

可以先觀望一下...

AWS, Cloud, Computer, Murmuring, Network, ServiceNo Comment

Amazon EFS 也要推出 IA 版本了 (Infrequent Access)

Amazon EFS 也要推出 IA (Infrequent Access) 版本了，Infrequent Access 指的是不常存取的資料：「Coming Soon – Amazon EFS Infrequent Access Storage Class」。

這剛好配合上很多人拿 Amazon EFS 來堆 log 的行為... AWS 是說有機會到省到 85%，不過應該是非常大的量才有機會有這個價錢？

EFS IA reduces storage costs for files not accessed every day, with savings up to 85% compared to the EFS Standard storage class.

其實用過 Amazon EFS 的人都對效能抱怨頗嚴重 (透過 NFS 有太多操作沒辦法 cache，於是 network latency issue 就出現了)，堆 log 或是當作跨機器的空間大概是目前的主流用法...

AWS, Cloud, Computer, Murmuring, Network, ServiceNo Comment

Amazon API Gateway 推出分級收費 (降價)

Amazon API Gateway 推出分級收費：「Amazon API Gateway Announces Tiered Pricing」。

原先的費用不變，大多數的地區是超過 333M reqs/month 的部分降價了... (不過雪梨跟南非是超過 1B reqs/month，而且北卡超過 333M 的部分也只降個零頭，實際比較深的折扣還是在 1B)，333M reqs/month 這個量換算下來需要 11.1M reqs/day，平均值要 128 reqs/sec，看起來是設計給整個站都搬上去的折扣方案 (不然就是本身量就超大)。

AWS, Cloud, Computer, Murmuring, Network, ServiceNo Comment

Recent Comments

Archives

Blogroll