因此每月，通过CloudFront分发15 GB数据的费用为：15 GB * $0.201/GB = $3.015
另外，每月产生的请求数量为 50 * 300 * 30 = 450000个，这些请求都是HTTP请求，因此请求处理费用为 450000 / 10000 * 0.0095 = $0.4275
所以就算本站的所有访客都通过位于日本的缓存服务器获取内容，我每月需要付出 3.015 + 0.4275 = $3.44，约合￥22。当然，实际上不可能所有访客都使用日本的缓存服务器，因此只要数据量和浏览量没有太大变化，每月实际的付出只会低于这个价格，绝 对不会高于这个价格。在大部分城市，这个价钱可能只够一个人在外面吃一顿像样的午饭，换来的是网站访问速度的极大提升，我觉得还是挺划算的。不过也幸好我 自己的博客本身访问量不是太大，并且只是发布一些自己写的东西，没有什么推广的念头，想必未来的访问量也不会大到哪里去。
如何使用？针对Dreamhost用户
虽然我曾经觉得DreamHost的主机最近一直遇到稳定性问题，不过大部分时候他家的服务还是不错的，例如常用Web应用的一键式安装，以及各种增值功能的使用，CloudFront就包含在内。
如果您也使用DreamHost提供的虚拟主机或VPS，那就最简单了。开通CloudFront帐户，然后在DreamHost网站登录到后台 Panel，在左侧导航栏中找到Goodies栏目，然后单击“CloudFront”，随后可以看到下图所示界面（如果尚未开通该功能，所看到的界面与 下图有所不同，但我已经开通了，首次开通时候忘记截图，所以只能提供开通后的截图，大致还是一样的）。
Sub-domain Amazon should serve your files from：这里设置的是，在CDN生效后，别人访问CDN中内容时使用的域名，并且该域名必须是网站顶级域名下的一个二级域名。首先从右侧下拉菜单中选择 一个想要用CDN加速的网站（如果你这个帐号下有多个网站的话），然后在左侧输入一个有效的二级域名。
Where you’ll upload files to：这里设置的是，要将DreamHost主机上哪个目录下的文件（先复制到S3，然后自动）复制到CDN缓存服务器中。因此这里首先需要用左侧的下拉 菜单选择承载了该网站的帐户，然后在右侧输入该帐户Home目录下的网站相对路径。这里指定的目录下的所有内容，以及以后新增的或者修改过的内容，都会被 DreamHost的主机自动同步到S3。
AWS Account to bill：这个选项在首次设置时不会显示，该选项的用途是，指定要将该CDN使用的所有相关费用记在哪个Amazon帐户名下。因此只有在设置完毕后才能看到这个选项。
AWS Account Access Key ID/Secret Key：这个就不用说了吧，用于访问Amazon云服务所需的必要凭据。
提供这些必要信息，并点击“Create”按钮后，DreamHost的主机就会使用该Key在您的S3中新建一个Bucket，并将指定目录下的所有内容都复制到这个Bucket中。复制完毕后会发出邮件通知。
至此，全部设置工作就都搞定了。不需要任何其他设置，只需要等待片刻，该服务就会直接生效。
如何使用？针对WordPress用户
通过上面的方法，只要您使用DreamHost的主机，无论在上面运行什么应用，都可以直接获得加速。
但如果您没有使用DH，不过使用WordPress，那么也可以通过WP插件的方式实现类似结果。如果没有用DH，也没有用WP，那我就不知道该怎么做了，暂时没有研究过，并且也没条件进行试验。
言归正传，要让其他主机中运行的WP借助CloudFront进行加速，需要按顺序安装并配置两个插件：WP Super Cache，以及CDN Sync Tool。通过WP后台的插件安装即可找到并安装这两个插件。其实我本来是想用这种方法的，但由于实在不同开发，尤其是不懂Linux和PHP，运行过程 中遇到的一些错误无法解决，最终才退而求其次，使用DH直接提供的功能。当然，这也不是唯一的实现方式，类似的插件有很多，都能提供这种功能。
由于没有试验成功，也不好说具体要怎么做，因此大致说一下实现思路：
WP Super Cache插件在这里的功能是，使用URL Rewriting功能，将指向可缓存文件的链接由原始主机修改为CloudFront。也就是说，假设在WP中发布了一篇文章，其中包含一张图片，该图 片的原始URL是“http://www.xieyidian.com/wp-content/d/file/uploads/picture.jpg”，那么这个插件 可以自动将该链接的域名部分进行更换，把“http://www.xieyidian.com”更换为“http: //xxxxx.cloudfront.net”。这样当访客浏览页面时，就会自动转为向最近的CloudFront服务器请求这张图片，并借此实现加 速。
而CDN Sync Tool插件的主要功能就是决定将哪些文件复制到S3，以及在什么时候进行复制。
因此通过配合使用这两个插件，访客就能在正确的缓存服务器上找到自己需要的内容。而我所遇到的问题，是因为DH主机不支持Fileinfo，我不懂 PHP开发，不知道这是做什么的，只知道与MIME类有关，由于该问题导致CDN Sync Tool无法将内容复制到S3。不过在网上搜索了半天，做了多个实验，依然无法搞定，最终只有作罢了。
两种方法的对比
前一种方法固然比较简单，但存在一定的局限。后一种方法比较强大，因为并不是被限定为只能用特定的插件，而是可以根据实际需要，做到完全掌控。因此主要说说DH提供的自动化方式有哪些局限吧。
DH提供的方法，由于简化了大部分操作，因此有很多东西只能使用默认设置。例如在S3中自动创建Bucket时无法指定要使用的数据中心，而且在向 S3复制数据时无法选择使用标准服务还是更便宜的低冗余服务。实际上在CDN应用中，S3只是在来源服务器和缓存服务器之间充当文件中转站，因此在选择 Bucket所在的数据中心时，选择一个存储费用最低的足矣，那就是US Standard，这也是DH的默认设置。不过服务级别的选择就不同了，默认情况下，DH会直接将文件使用标准级别保存，可靠性一堆“9”的那个，相对来 说更贵一些，但也完全没必要。因此在同步完所有数据后，还可以登录AWS后台，或者使用其他客户端浏览器，手工将存储级别改为使用“RRS”低冗余存储。
