EC2:
运算:
- Micro instance 虽然可以短暂 burst 使用较多的 CPU 资源, 但很快会就会被限制到比
burst 前还慢的程度 (可能几乎没 CPU 可用), 过一会儿会回复
- Cluster Compute Instances 的网络互连很快
IO:
- 如果 IO 不重要的话用一般的 EBS, 重要的话可用 P-IOPS (预留 IO 效能),
一般的 EBS大约是 P-IOPS 100 的程度.
- 如果不想用 P-IOPS, 可用多个 EBS 做 RAID (可增进流量, 但无法降低延迟)
- 有些 instance type 有提供 EBS-Optimized Instances 让 EBS IO 较快
S3:
- 配合 CDN (如 CloudFront) 用的话读取较快
- 如果对同一 bucket 有每秒 100 个以上存取, 建议档案完整路径的前几个字符
不同, 可避免流量增加时 S3 必须把档案重新分区, 让短期间内效能较低.
( http://goo.gl/r1ibn )
- S3 支援生命周期, 可以设定档案在多久之后会被自动删除, 或转移到 Glacier
- 透过 S3 使用 Glacier 一般会比直接用方便.
Glacier:
- 提取资料时, 注意价格是以"每月最高每小时流量"计算.
- 过早删除资料有额外费用.
SimpleDB:
- SimpleDB 不太会再增加新功能
RDS:
- RDS 和 EC2 一样也有 P-IOPS, MySQL 的话从 1000 起跳.
DynamoDB:
- 避免对同一 hash key 做太多存取, 因为 table 的 r/w capacity 是平均分散到
每个分区上 (一个分区存放一至多个 hash key 的资料) ( http://goo.gl/x5l341 )
- 避免同一 hash key 放太多资料 (限制: 10GB, http://goo.gl/uFycq )
- 如果流量不是平均分布在每个 hash key, 避免多次增加和减少 table r/w capacity.
修改 capacity 可能会增加分区个数.
- DynamoDB 容许一定程度的 burst, SDK 也有自动重试的功能, 因此就算 1 R/W
capacity 也可以做不少事
- 要简单备份 DynamoDB 资料可考虑使用 AWS Data Pipeline 内建的范本
- 其他: http://goo.gl/7zJMWk
SQS:
- SQS 保证讯息"至少"送达一次, 不是刚好一次. 另外不保证送达顺序.
- 建议使用 long polling 来减少 request 次数.