在配置 CloudFront Distribution 时，需要填写的有一项是Alternate Domain Names (CNAMEs)，中文是备用域名 (CNAMEs)。一直不太清楚为什么要填这一项。

• 在 DNS 上直接把域名解析到 CloudFront Distribution 生成的域名 dxxxxxxxxxxxx.cloudfront.net 上不就可以了吗？
• 为什么新建 CloudFront Distribution 时填写的 Alternate Domain Names (CNAMEs) 不能与现有的重复？
• 是填写 subdomain 好，还是填写 wildcard domain 好？

昨天，在我创建 CloudFront Distribution 时，AWS 提示我填写的 subdomain 已经配置在了一个 Distribution 上，而我的账号上并没有这样的配置。由此我了解到了 CloudFront 域名劫持这一现象。带着上面的疑问我做了些实验，查询了文档并向 AWS Support 了解到了相关原理，在这里记录一下。

前面几篇文章记录了我学习使用 AWS Lambda@Edge 由浅入深的过程，通过 Lambda@Edge 实现了请求重定向和动态生成响应：

• AWS Lambda@Edge小试牛刀——代替Nginx处理请求
• 使用Route53配置顶级域名跳转的两种方式——Lambda@Edge再显身手
• AWS Lambda@Edge动态生成响应

今天再进一步，使用 Lambda@Edge 实现反向代理。

最近用了不少 AWS Lambda@Edge，前两篇文章记录了我用 Lambda@Edge 实现请求重定向的过程，今天我又完成了一项新的需求，使用 Lambda@Edge 动态生成响应。

As we know, 在 RFC 中有明确说明 CNAME 记录不能与其他记录共存，特别是容易与 MX 记录产生冲突。因此，很多域名解析服务提供商都不允许为顶级域名设置 CNAME 解析。那如果我希望访问域名 example.net 跳转到 example.com 该如何做呢？

使用Nginx等后端服务器做跳转这里不考虑，现在讲究 Serverless 嘛。通过查询 AWS 相关文档，我找到了两种方法。

1. 使用 Route53 提供的 Alias 别名记录配合 S3 静态网站托管功能实现。
2. 使用 Route53 提供的 Alias 别名记录配合 CloudFront 和 Lambda@Edge 实现。

需要注意：

• 两种方法都依赖于 Route53 的别名记录功能，这不是 RFC 标准中提供方法，详细原理下文中说明。其他解析服务商应该也有类似的功能。
• 方法1使用 S3 静态网站托管功能实现跳转，设置简单，但无法配置 SSL 证书，需要 https 协议的网站不适用于此方法。
• 为了解决方法1不适用 https 协议的问题，可以使用方法2，在 CloudFront 上配置 SSL 证书，利用 Lambda@Edge 实现跳转。

下面详细记录我的配置过程。

前一段时间，我在工作中用 Lambda 实现了很多功能，比如，对云上资源进行定时巡检，CloudWatch警报转发等等。现在我对 AWS Lambda 类似的传统用法已经非常熟悉了，除此之外，AWS Lambda还有一个强大的功能 —— Lambda@Edge。之前通过学习文档了解了一些，今天正好有实际需求可以拿来练练手。

看过这么一种理论：一年的时间对于一个3岁的孩子来说，是他所经历的整个人生的三分之一，而对于一个耄耋老人来说，只是他漫长人生中的短短的一小部分，所以年龄越大会感到时间流逝的越快。小时候一下午就可以跑东跑西玩个痛快，暑假就好像有一年那么长。而现在一年似乎也不过是转瞬之间的事情。从前鲜活的记忆在慢慢褪色，那些令人开心、激动、难忘亦或是伤心的事情似乎也越来越远。翻看老照片时我会感到恍惚，这些真的是我所经历过的生活吗？这些事真的是我亲身参与其中的吗？往昔不可谏,来者犹可追。还是希望能把生活过的更加充实，更加有意义一些。至少在一年结束之际回首之时，可以想起些什么有趣的事会心一笑，而不至于空叹时光飞逝。在2018年结束之前我就打算着做做总结了，因为各种原（jie）因（kou），今天已经是2019年的1月12日了，就算是流水账也要写点什么了。

前段时间把很多项目都上了 Auto Scaling 功能，这两天发现有些 EC2 实例缩减后留下了 EBS 没有释放。这是因为实例的块存设备(Block devices)没有设置终止时释放(DeleteOnTermination)。
在启动新实例或创建 AMI 映像时可设置终止时释放(DeleteOnTermination)，但已启动的实例该怎么办呢？就此问题我求助了 AWS 客户支持，在这里把解决方案分享出来。

前两天对 AWS Lambda 做了一些学习，发现正好有实际需求用的上。于是业务需求又反推学习，现在我对 AWS Lambda 有了更多的了解。下面以问答形式记录一些我遇到的问题和解决方案。

背景

按照团队的标准规范，在 AWS 上新建的 EC2 实例都要添加 Name, Region, App, Env, Layer, Group 等标签。其中 Name 标签的格式是：{Region}-{App}-{Layer}-{Env}-{Group}-{IP后两段}，例如：vg-store-web-release-a-12-34。
在 Auto Scaling Group 的配置上，我设置了为新扩容出的实例自动添加 Region, App, Env, Layer, Group 这些标签，但因为 Name 标签中包含 IP 后缀，因此没办法预先设置在 Auto Scaling Group 上，只能在实例创建出来分配到私有 IP 后手动的添加 Name 标签。

为了解决这个问题，我最先想到的方案是：使用脚本调用 API 定时扫描没有 Name 标签的实例，然后获取实例的 PrivateIP 和其他标签拼装出 Name 添加到实例上。
我很快就编写出 Demo，经过测试，可以实现需求，但总觉得不够优雅：

1. 需要定时调用脚本，间隔时间过长就不能及时发现新扩容的实例，间隔过短则显得有些浪费计算资源（事实上，在我们的业务场景中发生扩容的次数很少，间隔以天为单位设置都有些多余）。
2. 需要部署维护脚本及crontab。
3. 需要找一台服务器运行脚本。

后来我想到了 Auto Scaling Group 有 LifeCycle Hook，又从它的设置界面了解到了 CloudWatch Events 这一服务。
最后通过 CloudWatch Events 和 AWS Lambda 就可以很好的实现我的需求！

在了解了目标跟踪扩展策略（Target Tracking Scaling Policy）的机制之后，突然就对 AWS Auto Scaling 有了新的理解。它最核心的部分其实是 CloudWatch！

想明白了这一点之后，AWS Auto Scaling 就不再那么神奇与神秘了。我甚至可以利用 CloudWatch 和 EC2 的相关 API 自己来实现一套 Auto Scaling！

（当然，这并不能否认 AWS Auto Scaling 的强大，无论是在细节上还是用户体验上它都打磨的非常完美了。）